Cache One Time Password OTP
Has anyone had success in getting free radius to cache a HOTP so it works like a TOTP. The problem I have is a ThinLinc authentication were our LDAP is configured for a HOTP, and ThinLink requires the OTP to be used twice in quick succession across the distributed architecture (once to master once to client) Looks like someone had some relative success IN Feb 2013 http://lists.freeradius.org/pipermail/freeradius-users/2013-February/065163.... But I'm not following whats going on. Mark Gardner Www.gtopia.org/blog
On Feb 25, 2015, at 2:54 PM, Gardner, Mark <mark.gardner@kc.frb.org> wrote:
Has anyone had success in getting free radius to cache a HOTP so it works like a TOTP.
What does that mean?
The problem I have is a ThinLinc authentication were our LDAP is configured for a HOTP, and ThinLink requires the OTP to be used twice in quick succession across the distributed architecture (once to master once to client)
Which isn’t clear to me. Can you describe *exactly* what you’re looking for? Give examples. Alan DeKok.
On Feb 25, 2015, at 2:54 PM, Gardner, Mark <mark.gardner@kc.frb.org> wrote:
Has anyone had success in getting free radius to cache a HOTP so it works like a TOTP.
What does that mean?
I'm speaking in reference to One Time Passwords (OTPs) that are simply appended to the end of a user's regular password, as a form of "Two Factor Authentication" (2FA) This appending style OTP has the advantage of not needing client modifications to take advantage of the second factor, users simply login with their username and password appending the OTP to the end of their password. (as opposed to the client asking for their username and password, and additionally challenging them to provide the One Time Password. ) I'm using a Yubikey configured in "Hashed One Time Password" ( HOTP ) mode. The token uses only the secret and an incrementing counter to generate the OTP. This Hashed One Time Password is then appended to the users password and sent to the authentication service to be validated. In my case, an LDAP server configured to authenticate this OTP. These HTOP passwords are truly only good for one valid authentication. The authentication server's counter is incremented after a successful login. Typically a "TIME One Time Password" (TOTP) , uses a time component (and sometimes a counter) to generate the OTP. Some of these types of OTP generators use OTPs that are good for small windows of time; from 30 seconds up to several minutes or longer. Many implementations of TOTP allow a password/token pair to be used several times in quick succession without needing a new OTP.
The problem I have is a ThinLinc authentication were our LDAP is configured for a HOTP, and ThinLink requires the OTP to be used twice in quick succession across the distributed architecture (once to master once to client)
The ThinLinc documentation (https://www.cendio.com/resources/docs/tag/otp_authentication.html) states in its requirements. " An OTP server which accepts the OTP twice. This is due to the ThinLinc architecture: The client first contacts the master machine, and then the agent host. The NordicEdge One Time Password Server has built-in support for ThinLinc. When using RSA SecurID, we recommend using the Steel-Belted Radius server as a "Token Caching Server". " I don't want to setup Steel-Belted Radius, or RADIATOR. I'd rather use freeradius. I found something in the archives that I belive is exactly what I need. I'm just not sure how to go about setting it up. http://lists.freeradius.org/pipermail/freeradius-users/2013-February/065200.... It may be my version of freeradius is too old to use this particular type of caching. I'm using freeradius-server 2.1.1-7.18.1 SLES11-SP3 Hopefully This clears things up a little.
The ThinLinc documentation (https://www.cendio.com/resources/docs/tag/otp_authentication.html) states in its requirements.
" An OTP server which accepts the OTP twice. This is due to the ThinLinc architecture: The client first contacts the master machine, and then the agent host. The NordicEdge One Time Password Server has built-in support for ThinLinc. When using RSA SecurID, we recommend using the Steel-Belted Radius server as a "Token Caching Server". "
I don't want to setup Steel-Belted Radius, or RADIATOR. I'd rather use freeradius. I found something in the archives that I belive is exactly what I need. I'm just not sure how to go about setting it up. http://lists.freeradius.org/pipermail/freeradius-users/2013-February/065200....
It may be my version of freeradius is too old to use this particular type of caching. I'm using freeradius-server 2.1.1-7.18.1 SLES11-SP3
Hopefully This clears things up a little.
Assuming you have an architecture like: thinLinc1 -|- FreeRADIUS - LDAP<sasl><yubikey plugin> thinLinc2 -| Yes you can use rlm_cache to allow the same password to be used within a given window without sending it to LDAP. Your version of FreeRADIUS does not support caching. It is very old. You can upgrade to 2.2.6 which should be config compatible, and does support caching. You'll have to be careful when defining your policy to only allow duplicate auths from servers within the same cluster, else you'll break the replay protection. Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On 2/25/15, 4:08 PM, "Arran Cudbard-Bell" <a.cudbardb@freeradius.org> wrote:
The ThinLinc documentation (https://www.cendio.com/resources/docs/tag/otp_authentication.html) states in its requirements.
" An OTP server which accepts the OTP twice. This is due to the ThinLinc architecture: The client first contacts the master machine, and then the agent host. The NordicEdge One Time Password Server has built-in support for ThinLinc. When using RSA SecurID, we recommend using the Steel-Belted Radius server as a "Token Caching Server". "
I don't want to setup Steel-Belted Radius, or RADIATOR. I'd rather use freeradius. I found something in the archives that I belive is exactly what I need. I'm just not sure how to go about setting it up. http://lists.freeradius.org/pipermail/freeradius-users/2013-February/0652 00.html
It may be my version of freeradius is too old to use this particular type of caching. I'm using freeradius-server 2.1.1-7.18.1 SLES11-SP3
Hopefully This clears things up a little.
Assuming you have an architecture like:
thinLinc1 -|- FreeRADIUS - LDAP<sasl><yubikey plugin> thinLinc2 -|
Yes you can use rlm_cache to allow the same password to be used within a given window without sending it to LDAP. Your version of FreeRADIUS does not support caching. It is very old. You can upgrade to 2.2.6 which should be config compatible, and does support caching.
You'll have to be careful when defining your policy to only allow duplicate auths from servers within the same cluster, else you'll break the replay protection.
SO I¹ve installed a newer version of freeradius with the rlm_cache module. I¹ve configured it like the Feb2013 email above. However a curious problem. If I use radtest and submit two bad passwords one after another. The first fails with a Reject; the second passes with Accept.
On Mar 13, 2015, at 10:52 PM, Gardner, Mark <mark.gardner@kc.frb.org> wrote:
SO I¹ve installed a newer version of freeradius with the rlm_cache module. I¹ve configured it like the Feb2013 email above. However a curious problem. If I use radtest and submit two bad passwords one after another. The first fails with a Reject; the second passes with Accept.
So… there’s debug output you can read, right? Alan DeKok.
On Mar 13, 2015, at 10:52 PM, Gardner, Mark <mark.gardner@kc.frb.org> wrote:
SO I¹ve installed a newer version of freeradius with the rlm_cache module. I¹ve configured it like the Feb2013 email above. However a curious problem. If I use radtest and submit two bad passwords one after another. The first fails with a Reject; the second passes with Accept.
So… there’s debug output you can read, right?
So I mucked around with it some more and I think I have it figured out. Here is my default site. cat sites-enabled/default | egrep -v "(#.*|^$)" authorize { preprocess eap { ok = return } ldap cache if (ok) { update control { Auth-Type := Accept Cache-Status-Only !* ANY Cache-TTL = 0 } ok } else { update control { Cache-Status-Only !* ANY } } expiration logintime pap } authenticate { Auth-Type PAP { ldap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } eap } preacct { preprocess acct_unique suffix files } accounting { detail exec attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject update control { Cache-TTL = 0 } cache update control { Cache-TTL !* ANY } } cache } pre-proxy { } post-proxy { eap } This is just for pam_radius_auth for other linux boxes. The only situation I have is that I may want to resolve is. If the second request (within the TTL of 10 seconds) has a different/bad password, it will still ACCPET and not REJECT. Mostly because I don’t see it cacheing the password.
I think I¹ve found a solution. I¹m posting it here for mostly a sanity check and to share if anyone else is having issues combining a YUBIKEY Hashed One Time Password (HOTP) for a token caching service. This is very similar to the offering that Steel Belted Radius provides. FreeRadius Version: freeradius-2.2.6-1 Must be compiled with ‹with-edir and have the rlm_cache caching module available. eDirectory server configured with HOTP NMAS Method ( https://www.netiq.com/communities/cool-solutions/using-yubico-yubikey-with- edirectory-for-two-factor-authentication/ ) The main driver behind this solution was using two factor authentication with Thinlinc. Their solution requires that a OTP be used twice. Their documentation recommends steel belted radius that has this feature build in for them. I¹d rather use a freeRadius solution. 1) Get PAP working with ldap. (not comparing extracted passwords) 2) copy the modules/cache to modlues/hotpcache cache hotpcache{ key = "%{User-Name}/%{urlquote:%{User-Password}}² ttl = 5 epoch = 0 add-stats = no update { reply:Reply-Message += "I'm the cached reply from %t" control:Class := 0x010203 } } 3) Here is the default site that uses the new cache module authorize { preprocess eap { ok = return } ldap hotpcache if (ok) { update control { Auth-Type := Accept Cache-Status-Only !* ANY Cache-TTL = 0 } hotpcache # remove entry ok } else { update control { Cache-Status-Only !* ANY } } expiration logintime pap } authenticate { Auth-Type PAP { ldap } Auth-Type CHAP { chap } Auth-Type MS-CHAP { mschap } eap } preacct { preprocess acct_unique suffix files } accounting { detail exec attr_filter.accounting_response } session { radutmp } post-auth { exec Post-Auth-Type REJECT { attr_filter.access_reject update control { Cache-TTL = 0 } hotpcache update control { Cache-TTL !* ANY } } hotpcache } pre-proxy { } post-proxy { eap }
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Gardner, Mark