Hello Henk,
I've looked closely at your video and accomplishment with smsotp, congrats!
thank you. However the video shows something that is outdated. I now wrote a perl module for rlm_perl which does it much better without all the moving parts.
Did you also had a look at OATH TOTP instead of SMS authentication? This is a RFC (http://tools.ietf.org/html/rfc6238) as you may know. A user installs an app on their phone which implements this RFC (e.g. Google Authenticator) and it acts as a soft token.
I did and evaluated it together with RADIUS.
I've got this running with freeradius and the google authenticator PAM module. The downside of PAM is the lack of challenge-access and response support (AFAIK).
If you want a challenge response integration like the user first needs to authenticate with username and password and than gets a challenge and needs to answer with a response that is possible. You could also tweak it that you leave the first step out. Just have a look at the rlm_perl implementation in http://thomas.glanzmann.de/smsotpd.2012-08-16.tar.bz2
Do you know of anything that supports OATH and TOTP natively with freeradius and can be used with the access-challenge/response system (or am I wrong about PAM not supporting that feature)?
I think there was a module, but I don't recall, maybe ask the FreeRadius List, or grep in the modules directory. I take it on CC. Cheers, Thomas
On 7 Sep 2012, at 17:20, Thomas Glanzmann <thomas@glanzmann.de> wrote:
Hello Henk,
I've looked closely at your video and accomplishment with smsotp, congrats!
thank you. However the video shows something that is outdated. I now wrote a perl module for rlm_perl which does it much better without all the moving parts.
What is the server missing as of 2.2.0 that requires the use of rlm_perl? On the surface it seems all you're missing is random string generation? With 3.0 you can define policies which have 'methods' that map to the different sections of the server, so you could write the whole thing as a virtual module. -Arran
Hello Arran,
What is the server missing as of 2.2.0 that requires the use of rlm_perl?
I'm not aware of the FreeRadius internals but you can simply look at the FreeRadius Module rlm_smsotp. This is what happens. - User authenticates with PAP - The server answer will be of access challenge type and includes two additional fields: - State: Random number (FreeRadius has to keep it an associate that with the generated otp) - Prompt At the same time a otp random number is also saved and associated with the state and the user and sent to the user for example using a SMS but it could of course use any other otp method for example with preshared key. - The client answeres and provide the state and otp in the 'passowrd' field. The server than has to verify: - Is the state corresponding to user name and otp? - Is the request still valid (timeout)? That's basically it.
On the surface it seems all you're missing is random string generation?
If it can't do that, than yes for the state and the otp value.
With 3.0 you can define policies which have 'methods' that map to the different sections of the server, so you could write the whole thing as a virtual module.
If you walk me through it, I would like to try that. Cheers, Thomas
On 9 Sep 2012, at 05:27, Thomas Glanzmann <thomas@glanzmann.de> wrote:
Hello Arran,
What is the server missing as of 2.2.0 that requires the use of rlm_perl?
I'm not aware of the FreeRadius internals but you can simply look at the FreeRadius Module rlm_smsotp. This is what happens.
- User authenticates with PAP - The server answer will be of access challenge type and includes two additional fields:
- State: Random number (FreeRadius has to keep it an associate that with the generated otp)
- Prompt
At the same time a otp random number is also saved and associated with the state and the user and sent to the user for example using a SMS but it could of course use any other otp method for example with preshared key.
- The client answeres and provide the state and otp in the 'passowrd' field. The server than has to verify:
- Is the state corresponding to user name and otp?
- Is the request still valid (timeout)?
That's basically it.
Ok
On the surface it seems all you're missing is random string generation?
If it can't do that, than yes for the state and the otp value.
With 3.0 you can define policies which have 'methods' that map to the different sections of the server, so you could write the whole thing as a virtual module.
If you walk me through it, I would like to try that.
Just name your policies using <virtual_module>.<section> {}, then use instances of the always module to set the return code :) For storing the state take a look at the new rlm_cache module, it'd be perfect for this (so long as you don't need state to be shared between servers, or persist after restarts). I'll look at adding a special xlat method to generate random strings. -Arran
participants (2)
-
Arran Cudbard-Bell -
Thomas Glanzmann