I've been working on setting up a Microsoft Routing and Remote Access server that uses Freeradius for Authentication. Out of the box, it works fine with simple user entries in the "users" file. This is with both the Ubuntu 14.04 apt-get installations of Freeradius (2.1.x) as well as a compiled from source version of Freeradius 2.2.9. I run in to trouble when I try to add two factor authentication to the mix. I'm trying to use LinOTP as a possible replacement of our CryptoCard Blackshield implementation. The problem is that both products seem to only work with unencrypted passwords. LinOTP has two options for Freeradius authentication. There is a linotp2 module that can be compiled and installed along with Freeradius, and there is also a perl script that can be linked in with the rlm_perl module. Looking at the perl script, it is expecting to find the attribute "User-Password" in the radius request, which it uses, along with the username, to go to a web URL on the LinOTP server to verify authentication. I suspect that the linotp2 module works similarly. The documentation provided by LinOTP says to set "DEFAULT Auth-Type := linotp2" if you're using the module or "DEFAULT Auth-Type := perl" if you're using the perl script in the freeradius users file. Now, this will "work" for narrow authentication types like Microsoft's SSTP with an unencrypted password, but I'd like this solution to be more widely usable (Macs, iOS devices, etc) and use something like IKEv2, but that uses EAP-MSCHapv2. If I try that, the authentication fails saying there is no password. My question is...am I tilting at windmills trying to make this work? I feel like it *should* be possible to do 2 factor authentication without having to resort to PPTP/unecrypted password or microsoft's proprietary SSTP. Is there a way to have freeradius pass the MSChapv2 password to a perl script or another module? Or perhaps it's possible to modify the perl script so it can accept an encrypted password? I feel like maybe there's a way to configure authentication in the "inner-tunnel" freeradius site that would make this possible. EAP-MSChapv2 authentication works with a plain, unencrypted password in the users file, so it obviously HAS the password that the user sends in SOME fashion. A secondary question is that I imagine I can't be the first person to use Freeradius with 2 factor authentication. I'd be curious to know how other folks have tackled this project and what products they used to accomplish it. ----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
A secondary question is that I imagine I can't be the first person to use Freeradius with 2 factor authentication. I'd be curious to know how other folks have tackled this project and what products they used to accomplish it.
They do it with a non-EOLd version, which has a full REST client and integration with SMSOTP, SecureID, and Yubikey out of the box. -Arran
SecureId is pretty expensive, and it looks like Yubikey is hardware only. Our users prefer a software based token. SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens. I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius with an opensource OTP solution like LinOTP or privacyIDEA unless you restrict your clients to either proprietary VPN protocols like SSTP or barely secure VPN protocols like PPTP as those are the only ones that will allow you to use Unencrypted Passwords. If I'm wrong about that, I'd love to hear what kind of VPN clients/protocols are in use with Freeradius and LinOTP/privacyIDEA. ----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Wednesday, June 01, 2016 10:48 AM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
A secondary question is that I imagine I can't be the first person to use Freeradius with 2 factor authentication. I'd be curious to know how other folks have tackled this project and what products they used to accomplish it.
They do it with a non-EOLd version, which has a full REST client and integration with SMSOTP, SecureID, and Yubikey out of the box. -Arran
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible? -Arran
Doesn't matter how awesome SecureID is if you don't have the budget for it. :) I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server. I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with. ----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 02, 2016 2:10 PM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible? -Arran
On Jun 2, 2016, at 2:52 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
Doesn't matter how awesome SecureID is if you don't have the budget for it. :)
Oh, no, SecureID is awful, Yubikey is awesome.
I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server.
Well no. Because MSCHAPv2 doesn't give you the password in cleartext, so you can't pass it off to anything.
I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with.
Yeah, you need to run EAP-TTLS-PAP instead, which does give you the plaintext password. -Arran
Hi Aaron, you are right about the hashed password. The implementations I know use RADIUS with PAP. Yes, that password is transmitted encrypted, so the FreeRADIUS module can decrypt it and forward it to linotp/privacyidea. With the corresponding effort the mschapv2 protocol could be investigated to enhance the backend functionality. I say "investigate mschapv2" since I am not even sure if it will work out: since the server sends a challenge initially which is based on the password hash. And if the server initially picks the wrong password, the client probably will end the authentication handshake. And even if you manage to achieve this: You still have to store the users password (knowledge, 1st factor) in a decryptable manner. So the question is if you are more happy with an decryptable password in the user database or with a week encrypted password between the VPN server and the RADIUS server. Are you using the Windows domain password or a token PIN? Kind regards Cornelius Am Donnerstag, den 02.06.2016, 18:52 +0000 schrieb Aaron Smith:
Doesn't matter how awesome SecureID is if you don't have the budget for it. :) I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server. I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 02, 2016 2:10 PM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible?
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Well at least I was able to research the issue correctly! To be clear, I'm not looking to find a way to make MSchapv2 to work. The end goal is to have a VPN solution that would allow Windows, Mac, and iOS users to connect securely, with a minimum of fuss. Tall order I know. :) I was looking at IKEv2 as it seemed to be supported natively on at least Windows and iOS, but windows clients insisted on using EAP-MSChapv2 for it. I suspect iOS does the same. SSTP works great for windows clients (and can do PAP), and I've heard rumors of third party clients for MAC OS, but I'm coming up empty on iOS clients that do SSTP. OPenVPN is a possible alternative, but the certificate aspect sounds like a management nightmare. We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost. ----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 3:25 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication Hi Aaron, you are right about the hashed password. The implementations I know use RADIUS with PAP. Yes, that password is transmitted encrypted, so the FreeRADIUS module can decrypt it and forward it to linotp/privacyidea. With the corresponding effort the mschapv2 protocol could be investigated to enhance the backend functionality. I say "investigate mschapv2" since I am not even sure if it will work out: since the server sends a challenge initially which is based on the password hash. And if the server initially picks the wrong password, the client probably will end the authentication handshake. And even if you manage to achieve this: You still have to store the users password (knowledge, 1st factor) in a decryptable manner. So the question is if you are more happy with an decryptable password in the user database or with a week encrypted password between the VPN server and the RADIUS server. Are you using the Windows domain password or a token PIN? Kind regards Cornelius Am Donnerstag, den 02.06.2016, 18:52 +0000 schrieb Aaron Smith:
Doesn't matter how awesome SecureID is if you don't have the budget for it. :) I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server. I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 02, 2016 2:10 PM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible?
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
On Jun 2, 2016, at 3:44 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
Well at least I was able to research the issue correctly! To be clear, I'm not looking to find a way to make MSchapv2 to work. The end goal is to have a VPN solution that would allow Windows, Mac, and iOS users to connect securely, with a minimum of fuss. Tall order I know. :) I was looking at IKEv2 as it seemed to be supported natively on at least Windows and iOS, but windows clients insisted on using EAP-MSChapv2
Windows 10 should do TTLS.
for it. I suspect iOS does the same.
No, IOS supports EAP-TLS, EAP-PEAP, EAP-TTLS.
SSTP works great for windows clients (and can do PAP), and I've heard rumors of third party clients for MAC OS, but I'm coming up empty on iOS clients that do SSTP. OPenVPN is a possible alternative, but the certificate aspect sounds like a management nightmare.
IKEv2 based solutions are your best bet.
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
Anything that'll give you the plaintext password from the OTP server back will work with MSCHAPv2. -Arran
Am Donnerstag, den 02.06.2016, 15:58 -0400 schrieb Arran Cudbard-Bell:
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
Anything that'll give you the plaintext password from the OTP server back will work with MSCHAPv2.
The OTP server could return the plain text OTP password. But this is only the 2nd factor. It will not return the LDAP user password, which is the 1st factor. So in a setup were you have two steps of authentication, this will work. But often the password and OTP are entered in conjunction. This will fail. Kind regards Cornelius
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
On Jun 2, 2016, at 4:33 PM, Cornelius Kölbel <cornelius.koelbel@netknights.it> wrote:
Am Donnerstag, den 02.06.2016, 15:58 -0400 schrieb Arran Cudbard-Bell:
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
Anything that'll give you the plaintext password from the OTP server back will work with MSCHAPv2.
The OTP server could return the plain text OTP password. But this is only the 2nd factor. It will not return the LDAP user password, which is the 1st factor.
Yeah, if you're using an LDAP server that doesn't give you access to the plaintext password, and if you're set on using passwords. Certificates do the job just as well. Especially if they're encrypted. -Arran
On Jun 2, 2016, at 4:53 PM, Arran Cudbard-Bell <a.cudbardb@freeradius.org> wrote:
On Jun 2, 2016, at 4:33 PM, Cornelius Kölbel <cornelius.koelbel@netknights.it> wrote:
Am Donnerstag, den 02.06.2016, 15:58 -0400 schrieb Arran Cudbard-Bell:
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
Anything that'll give you the plaintext password from the OTP server back will work with MSCHAPv2.
The OTP server could return the plain text OTP password. But this is only the 2nd factor. It will not return the LDAP user password, which is the 1st factor.
Yeah, if you're using an LDAP server that doesn't give you access to the plaintext password, and if you're set on using passwords.
Certificates do the job just as well. Especially if they're encrypted.
3FA FTW! -Arran
On Thu, Jun 02, 2016 at 04:57:57PM -0400, Arran Cudbard-Bell wrote:
Certificates do the job just as well. Especially if they're encrypted.
3FA FTW!
OpenVPN service I've run for years has certs with encrypted keys, requires user logon, and shared key. Does that make it 4FA? :) Matthew -- Matthew Newton, Ph.D. <mcn4@le.ac.uk> Systems Specialist, Infrastructure Services, I.T. Services, University of Leicester, Leicester LE1 7RH, United Kingdom For IT help contact helpdesk extn. 2253, <ithelp@le.ac.uk>
On Thu, Jun 2, 2016 at 5:34 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Thu, Jun 02, 2016 at 04:57:57PM -0400, Arran Cudbard-Bell wrote:
Certificates do the job just as well. Especially if they're encrypted.
3FA FTW!
OpenVPN service I've run for years has certs with encrypted keys, requires user logon, and shared key. Does that make it 4FA? :)
I bet you could convince an PCI auditor that it was. ;-) -- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication
I've been looking at the TOTP open standard and there is a perl script written for FreeRadius. It's super easy to enroll the soft token on your phone by scanning the QR code. Plenty of clients across all mobile devices and you can get hard tokens if that's your bag. I really struggle why anyone would want to use anything else. On Jun 3, 2016 9:38 AM, "Nick Owen" <owen.nick@gmail.com> wrote:
On Thu, Jun 2, 2016 at 5:34 PM, Matthew Newton <mcn4@leicester.ac.uk> wrote:
On Thu, Jun 02, 2016 at 04:57:57PM -0400, Arran Cudbard-Bell wrote:
Certificates do the job just as well. Especially if they're encrypted.
3FA FTW!
OpenVPN service I've run for years has certs with encrypted keys, requires user logon, and shared key. Does that make it 4FA? :)
I bet you could convince an PCI auditor that it was. ;-)
-- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
On Jun 2, 2016, at 6:22 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:
I've been looking at the TOTP open standard and there is a perl script written for FreeRadius.
I looked at one point, and figured out you could implement it in unlang policies without too much trouble :) I really don't understand that whole fascination people have with OTP though. I think it's a cruel and unusual punishment to force on users (unless it's Yubikey, which is lovely). -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Fri, Jun 3, 2016 at 11:28 AM, Arran Cudbard-Bell < a.cudbardb@freeradius.org> wrote:
On Jun 2, 2016, at 6:22 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:
I've been looking at the TOTP open standard and there is a perl script written for FreeRadius.
I looked at one point, and figured out you could implement it in unlang policies without too much trouble :)
I really don't understand that whole fascination people have with OTP though. I think it's a cruel and unusual punishment to force on users (unless it's Yubikey, which is lovely).
While I agree with you philosophically on OTP in general being a bit of a painful experience. And plugging a Yubikey into a USB Port hitting a button and getting a bit long string makes for a pleasant end user experience. I do see there are multiple sites now support TOTP where the enrollment is seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code. The enrollment experience is awesome when you're armed with your smart phone using a browser on a desktop and consistent across multiple sites / cloud providers as everyone is doing TOTP multi-factor authentication. If you go into the Yubikey world, even though it's awesome you are still locked into that vendor. The pain is when using the OTP when logging in, granted it's not much fun on a phone if you are logging into a site and you need to copy & paste inside the time limit from the TOTP client into the phone browser. When they are different devices it's pretty simple. The Fortinet FortiToken-200 is a pretty good build quality physical token yet it still conforms to the RFC6238 / OATH standard. I really like this site www.xanxys.net/totp/ as it's super easy to implement a full client side browser based enrollment process all in a single dumb html page. Preaching to the choir here. But I am a big advocate for the open standard RFC compliant token solution rather than locking you into any particular vendor. Some people say Open Standards gives you the ultimate flexibility. :) This blog entry: https://blog.evernote.com/tech/2013/06/18/freeradius-openldap-totp-part-2/ Covers how to do it all using Perl. It's a little dodgy since they use perl to query ldap to get the hash which seems a very complex way to go about it IMHO. Was thinking an rlm_totp would be awesome. Pull out the TOTP hex string key from the database of your choice during Authorize putting it into a control VSA and then during Authenticate make sure it matches up with an option in the module config to support how many cycles + / - the current time to support. I'm sure you will say patches welcome :), which is something I plan to do once one other things is off my plate.
Peter Lambrechtsen wrote:
do see there are multiple sites now support TOTP where the enrollment is seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code.
I really wonder why scanning the shared secret as QR code from a screen is considered an acceptable security practice. :-/ Ciao, Michael.
Michael Ströder wrote:
Peter Lambrechtsen wrote:
do see there are multiple sites now support TOTP where the enrollment is seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code.
I really wonder why scanning the shared secret as QR code from a screen is considered an acceptable security practice. :-/
BTW: And hosted OTP services have access to all the shared secrets... Ciao, Michael.
On Jun 6, 2016 8:32 AM, "Michael Ströder" <michael@stroeder.com> wrote:
Michael Ströder wrote:
Peter Lambrechtsen wrote:
do see there are multiple sites now support TOTP where the enrollment
is
seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code.
I really wonder why scanning the shared secret as QR code from a screen is considered an acceptable security practice. :-/
BTW: And hosted OTP services have access to all the shared secrets...
How is that any different to SecurID, safeword,Vasco or any of the other commercial token vendors? By it's very nature the secret needs to be kept somewhere. Yes Yubikey is marginally better as you can generate your own. But the CD that comes with your hard token had to be written somewhere and the vendors keep a copy. I have in the past been able to get replacement keys when rebuilding a SecurID and Vasco box so it would surprise me if they destroyed all copies of the token data. The historic SecurID hack seems to indicate they didn't then. http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-c... The beauty in soft tokens is it's trivial to reenroll everyone on next login. "Sorry our db with hashed passwords and otps got hacked. Please reenroll by scanning the qr and remove the old one." If it were so bad how come Google, dropbox, linkedin, github and a whole myriad of different online companies have implemented it for second factor auth? And they all enroll you separately so you now need a key locker / authy / google authenticator to manage the individual otps for each company. I see it no worse than any other OTP solution as the secret needs to be kept secret.
Ciao, Michael.
- List info/subscribe/unsubscribe? See
On 5 Jun 2016, at 17:17, Peter Lambrechtsen <peter@crypt.nz> wrote:
On Jun 6, 2016 8:32 AM, "Michael Ströder" <michael@stroeder.com> wrote:
Michael Ströder wrote:
Peter Lambrechtsen wrote:
do see there are multiple sites now support TOTP where the enrollment
is
seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code.
I really wonder why scanning the shared secret as QR code from a screen is considered an acceptable security practice. :-/
BTW: And hosted OTP services have access to all the shared secrets...
How is that any different to SecurID, safeword,Vasco or any of the other commercial token vendors?
By it's very nature the secret needs to be kept somewhere. Yes Yubikey is marginally better as you can generate your own.
I guess they don't open source the code the actually goes on the keys, and even if they did you would have no way of validating that was on the key, as they intentionally don't leave any way to access the key firmware. But the master keys live on *your* servers, and the code to perform the validation is open sourced. It's just AES 256 encryption.
But the CD that comes with your hard token had to be written somewhere and the vendors keep a copy. I have in the past been able to get replacement keys when rebuilding a SecurID and Vasco box so it would surprise me if they destroyed all copies of the token data.
Ooo that's bad.
The historic SecurID hack seems to indicate they didn't then. http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-c...
The beauty in soft tokens is it's trivial to reenroll everyone on next login. "Sorry our db with hashed passwords and otps got hacked. Please reenroll by scanning the qr and remove the old one."
If it were so bad how come Google, dropbox, linkedin, github and a whole myriad of different online companies have implemented it for second factor auth?
Cos it's cheap and easy, and plays into the whole security theatre thing.
And they all enroll you separately so you now need a key locker / authy / google authenticator to manage the individual otps for each company.
I see it no worse than any other OTP solution as the secret needs to be kept secret.
Well, not really worse than any other soft tokens, no. But it does present a nice target for malware developers. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
On Sun, Jun 5, 2016 at 5:17 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:
On Jun 6, 2016 8:32 AM, "Michael Ströder" <michael@stroeder.com> wrote:
Michael Ströder wrote:
Peter Lambrechtsen wrote:
do see there are multiple sites now support TOTP where the enrollment
is
seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code.
I really wonder why scanning the shared secret as QR code from a screen is considered an acceptable security practice. :-/
BTW: And hosted OTP services have access to all the shared secrets...
How is that any different to SecurID, safeword,Vasco or any of the other commercial token vendors?
We are a vendor that uses asymmetric keys generated on the devices/your on-premises server designed exactly to avoid this 'vendor-in-the-middle' threat. So, that's different.
By it's very nature the secret needs to be kept somewhere. Yes Yubikey is marginally better as you can generate your own.
But the CD that comes with your hard token had to be written somewhere and the vendors keep a copy. I have in the past been able to get replacement keys when rebuilding a SecurID and Vasco box so it would surprise me if they destroyed all copies of the token data. The historic SecurID hack seems to indicate they didn't then. http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-c...
The beauty in soft tokens is it's trivial to reenroll everyone on next login. "Sorry our db with hashed passwords and otps got hacked. Please reenroll by scanning the qr and remove the old one."
This is why I think the OTP algorithm is not that important. The important protocol for most orgs is radius, b/c it will allow you to move between auth servers easily.
If it were so bad how come Google, dropbox, linkedin, github and a whole myriad of different online companies have implemented it for second factor auth? And they all enroll you separately so you now need a key locker / authy / google authenticator to manage the individual otps for each company.
Like most things in security, it was there and made it easy to check the box.
I see it no worse than any other OTP solution as the secret needs to be kept secret.
I'll just say that I am very glad to not have possession of all our customers' shared secrets. It helps me sleep at night. I am very glad to see other people actually care about this.
Ciao, Michael.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication
On Tue, Jun 7, 2016 at 2:22 AM, Nick Owen <owen.nick@gmail.com> wrote:
On Sun, Jun 5, 2016 at 5:17 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:
How is that any different to SecurID, safeword,Vasco or any of the other commercial token vendors?
We are a vendor that uses asymmetric keys generated on the devices/your on-premises server designed exactly to avoid this 'vendor-in-the-middle' threat. So, that's different.
But WiKiD is a public / private key solution where the client needs to communicate with the server. There doesn't seem to be any way to enroll a token without some sort of network connectivity back to the server.
By it's very nature the secret needs to be kept somewhere. Yes Yubikey is marginally better as you can generate your own.
But the CD that comes with your hard token had to be written somewhere
and
the vendors keep a copy. I have in the past been able to get replacement keys when rebuilding a SecurID and Vasco box so it would surprise me if they destroyed all copies of the token data. The historic SecurID hack seems to indicate they didn't then.
http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-c...
The beauty in soft tokens is it's trivial to reenroll everyone on next login. "Sorry our db with hashed passwords and otps got hacked. Please reenroll by scanning the qr and remove the old one."
This is why I think the OTP algorithm is not that important. The important protocol for most orgs is radius, b/c it will allow you to move between auth servers easily.
This is where I fundamentally disagree with you. By using an open RFC standard algorithm it means I can easily move between hardware / software manufactures without being locked into any particular vendor. I could choose to allow end-users to enroll software tokens using a their phone, or have them bring their phone to a central location to be enrolled for them or build your own app to securely enroll them over SSL. Or use hard tokens and issue them that way. By using the same open algorithm you are no longer constrained to one vendor on one platform.
I see it no worse than any other OTP solution as the secret needs to be kept secret.
I'll just say that I am very glad to not have possession of all our customers' shared secrets. It helps me sleep at night.
But you do require the client and server to be connected at some point and I couldn't see any offline / disconnected enrollment process. And if the server gets compromised the public keys can be rebuilt from the private keys. So there are pros & cons with each solution. But having an open standard that means you are vendor agnostic is surely a good thing?
On Mon, Jun 6, 2016 at 9:32 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:
On Tue, Jun 7, 2016 at 2:22 AM, Nick Owen <owen.nick@gmail.com> wrote:
On Sun, Jun 5, 2016 at 5:17 PM, Peter Lambrechtsen <peter@crypt.nz> wrote:
How is that any different to SecurID, safeword,Vasco or any of the other commercial token vendors?
We are a vendor that uses asymmetric keys generated on the devices/your on-premises server designed exactly to avoid this 'vendor-in-the-middle' threat. So, that's different.
But WiKiD is a public / private key solution where the client needs to communicate with the server. There doesn't seem to be any way to enroll a token without some sort of network connectivity back to the server.
That is correct. This comes up in pre-sales sometimes, but not in operation. I know that some markets it will never work, but most it does fine. People use 2FA to connect so they usually have a connection. We have a fall-back to a challenge-response mode for authentication if the token device is out-of-coverage but no one has had to use it to my knowledge.
By it's very nature the secret needs to be kept somewhere. Yes Yubikey is marginally better as you can generate your own.
But the CD that comes with your hard token had to be written somewhere
and
the vendors keep a copy. I have in the past been able to get replacement keys when rebuilding a SecurID and Vasco box so it would surprise me if they destroyed all copies of the token data. The historic SecurID hack seems to indicate they didn't then.
http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-c...
The beauty in soft tokens is it's trivial to reenroll everyone on next login. "Sorry our db with hashed passwords and otps got hacked. Please reenroll by scanning the qr and remove the old one."
This is why I think the OTP algorithm is not that important. The important protocol for most orgs is radius, b/c it will allow you to move between auth servers easily.
This is where I fundamentally disagree with you. By using an open RFC standard algorithm it means I can easily move between hardware / software manufactures without being locked into any particular vendor. I could choose to allow end-users to enroll software tokens using a their phone, or have them bring their phone to a central location to be enrolled for them or build your own app to securely enroll them over SSL. Or use hard tokens and issue them that way. By using the same open algorithm you are no longer constrained to one vendor on one platform.
I agree with you in principal and we have looked at publishing the algorithm. I'm still open to it. We may have missed that boat. I think most people don't care, just like they don't care about what type of encryption you use. We could add TOTP to our server or support yubikey as well.
I see it no worse than any other OTP solution as the secret needs to be kept secret.
I'll just say that I am very glad to not have possession of all our customers' shared secrets. It helps me sleep at night.
But you do require the client and server to be connected at some point and I couldn't see any offline / disconnected enrollment process. And if the server gets compromised the public keys can be rebuilt from the private keys.
So there are pros & cons with each solution. But having an open standard that means you are vendor agnostic is surely a good thing?
yes, all things considered. My experience is that they often are not. Most of our pre-sales questions are "Does you system work with my Cisco VPN?". To which I respond knowingly "does it support radius?". So please know how much I appreciate this intelligent discussion! -- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication
Am Montag, den 06.06.2016, 09:17 +1200 schrieb Peter Lambrechtsen:
On Jun 6, 2016 8:32 AM, "Michael Ströder" <michael@stroeder.com> wrote:
Michael Ströder wrote:
Peter Lambrechtsen wrote:
do see there are multiple sites now support TOTP where the enrollment
is
seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code.
I really wonder why scanning the shared secret as QR code from a screen is considered an acceptable security practice. :-/
BTW: And hosted OTP services have access to all the shared secrets...
How is that any different to SecurID, safeword,Vasco or any of the other commercial token vendors?
By it's very nature the secret needs to be kept somewhere. Yes Yubikey is marginally better as you can generate your own.
But the CD that comes with your hard token had to be written somewhere and the vendors keep a copy. I have in the past been able to get replacement keys when rebuilding a SecurID and Vasco box so it would surprise me if they destroyed all copies of the token data. The historic SecurID hack seems to indicate they didn't then. http://arstechnica.com/security/2011/06/rsa-finally-comes-clean-securid-is-c...
The beauty in soft tokens is it's trivial to reenroll everyone on next login. "Sorry our db with hashed passwords and otps got hacked. Please reenroll by scanning the qr and remove the old one."
If it were so bad how come Google, dropbox, linkedin, github and a whole myriad of different online companies have implemented it for second factor auth? And they all enroll you separately so you now need a key locker / authy / google authenticator to manage the individual otps for each company.
Google, Dropbox, linkedin have only limited interest in the security of the user. Or the other way round, the users, enrolling the optional 2nd factor have an interest in security. This is why Go, Dr, Li can do it this way. It is convenient for them and the security aware user will take care. But in an enterprise environment you must suppose, that the users are not security aware and care less about enterprise data then their personal data. Often you have the problem that users share their passwords. When using Google Authenticator in TOTP mode it is easy for the users to also share the 2nd factor. https://netknights.it/en/the-problem-with-the-google-authenticator/
I see it no worse than any other OTP solution as the secret needs to be kept secret.
Ciao, Michael.
- List info/subscribe/unsubscribe? See
http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Am Sonntag, den 05.06.2016, 22:31 +0200 schrieb Michael Ströder:
Michael Ströder wrote:
Peter Lambrechtsen wrote:
do see there are multiple sites now support TOTP where the enrollment is seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code.
I really wonder why scanning the shared secret as QR code from a screen is considered an acceptable security practice. :-/
BTW: And hosted OTP services have access to all the shared secrets...
This is why you should run the OTP service yourself!
Ciao, Michael.
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Peter Lambrechtsen wrote:
While I agree with you philosophically on OTP in general being a bit of a painful experience. And plugging a Yubikey into a USB Port hitting a button and getting a bit long string makes for a pleasant end user experience. I do see there are multiple sites now support TOTP where the enrollment is seamless for end-users. Login to a web site, use Google Authenticator or Authy or any other myriad of TOTP clients to scan the QR code. The enrollment experience is awesome when you're armed with your smart phone using a browser on a desktop and consistent across multiple sites / cloud providers as everyone is doing TOTP multi-factor authentication.
And it's also awesome for attackers that the long-term secret is shown as plain-text on a screen. ;-} Also the enrollment authentication is only as strong as the login password.
If you go into the Yubikey world, even though it's awesome you are still locked into that vendor.
You don't have to use the proprietary Yubico-OTP algorithm. You can initialize the yubikey with your own shared secret for OATH HOTP (RFC 4226). Still it's hard work to implement a really secure token enrollment but BTDT.
The Fortinet FortiToken-200 is a pretty good build quality physical token yet it still conforms to the RFC6238 / OATH standard.
Hmm, still the user has to type in the OTP. Also seems to be limited to 6 digits.
I really like this site www.xanxys.net/totp/ as it's super easy to implement a full client side browser based enrollment process all in a single dumb html page.
Every implementation which display the shared secrets as QR code in security theatre.
Preaching to the choir here. But I am a big advocate for the open standard RFC compliant token solution rather than locking you into any particular vendor.
+1
This blog entry: https://blog.evernote.com/tech/2013/06/18/freeradius-openldap-totp-part-2/
Covers how to do it all using Perl. It's a little dodgy since they use perl to query ldap to get the hash which seems a very complex way to go about it IMHO.
They have pre-calculated hashes in the directory for the whole drift window? Ciao, Michael.
On 11/06/2016 17:23, Michael Ströder wrote:
Every implementation which display the shared secrets as QR code in security theatre.
For many organisations the primary threat w.r.t. authentication credentials is credential theft and remote use (phishing. etc.). Provisioning to a soft-token via a QR code is perfectly adequate for that threat model. The attacker is not looking over your shoulder, and TOFU works great almost all of the time. We've looked at this in detail, and there are about 250 people in our organisation of 30k+ that could justify a hard token. If we ever get 2FA deployed, it's going to be soft-tokens deployed w/ in-band provisioning for almost everyone, because it's the only thing that makes sense and it ABSOLUTELY IS NOT security theatre for us. It addresses a real threat. Regards, Phil
Phil Mayers wrote:
If we ever get 2FA deployed, it's going to be soft-tokens deployed w/ in-band provisioning for almost everyone, because it's the only thing that makes sense and it ABSOLUTELY IS NOT security theatre for us. It addresses a real threat.
YMMV. Time will tell. Good luck. Ciao, Michael.
On 12/06/2016 10:07, Michael Ströder wrote:
Phil Mayers wrote:
If we ever get 2FA deployed, it's going to be soft-tokens deployed w/ in-band provisioning for almost everyone, because it's the only thing that makes sense and it ABSOLUTELY IS NOT security theatre for us. It addresses a real threat.
YMMV. Time will tell. Good luck.
Yes, it will.
Am Samstag, den 11.06.2016, 21:26 +0100 schrieb Phil Mayers:
On 11/06/2016 17:23, Michael Ströder wrote:
Every implementation which display the shared secrets as QR code in security theatre.
For many organisations the primary threat w.r.t. authentication credentials is credential theft and remote use (phishing. etc.). Provisioning to a soft-token via a QR code is perfectly adequate for that threat model. The attacker is not looking over your shoulder, and TOFU works great almost all of the time.
We've looked at this in detail, and there are about 250 people in our organisation of 30k+ that could justify a hard token.
So you should choose a solution, where you can combine soft tokens, text messages, OTPs via email *argh* and hardware tokens, just as you wish. This would make the best sense for your scenario.
If we ever get 2FA deployed, it's going to be soft-tokens deployed w/ in-band provisioning for almost everyone, because it's the only thing that makes sense and it ABSOLUTELY IS NOT security theatre for us. It addresses a real threat.
Regards, Phil - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
On 12/06/2016 19:30, Cornelius Kölbel wrote:
We've looked at this in detail, and there are about 250 people in our organisation of 30k+ that could justify a hard token.
So you should choose a solution, where you can combine soft tokens, text messages, OTPs via email *argh* and hardware tokens, just as you wish. This would make the best sense for your scenario.
Ideally yes. So I'm very supportive of the idea of a standard set of protocols that can integrate all of the above. In reality, cost and vendor support for our most exposed apps (Office 365, web-based SAML/Shibboleth auth) will matter hugely.
Am Montag, den 13.06.2016, 11:46 +0100 schrieb Phil Mayers:
On 12/06/2016 19:30, Cornelius Kölbel wrote:
We've looked at this in detail, and there are about 250 people in our organisation of 30k+ that could justify a hard token.
So you should choose a solution, where you can combine soft tokens, text messages, OTPs via email *argh* and hardware tokens, just as you wish. This would make the best sense for your scenario.
Ideally yes. So I'm very supportive of the idea of a standard set of protocols that can integrate all of the above.
In reality, cost and vendor support for our most exposed apps (Office 365, web-based SAML/Shibboleth auth) will matter hugely.
Oups, we left the RADIUS track. ;-) Are you bound to a certain IdP like ADFS? Have you implemented shibboleth? E.g. SimpleSAMLphp has a bunch of plugins that authenticate an 2FA backend. I think they have a native yubikey plugin. But there is also a privacyIDEA plugin. You can manage all kind of tokens in privacyIDEA (Disclaimer: I am developing this 2FA auth backend, which supports hardware HOTP/TOTP, smartphones, yubikey, sms, email...). Usually you will only have to get support/SLA for such a setup. Of course there a lot of plugins/connectors for ADFS, too. Which might result in more licenses costs. Here is a video, where you can even use U2F tokens (under certain conditions) https://www.youtube.com/watch?v=0VKFGSAlL80 -- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
On 13/06/2016 12:18, Cornelius Kölbel wrote:
In reality, cost and vendor support for our most exposed apps (Office 365, web-based SAML/Shibboleth auth) will matter hugely.
Oups, we left the RADIUS track. ;-)
Kind of. I see a RADIUS backend as a perfectly acceptable way of integrating multiple token types; either by having one backend isolate the token-type details from the frontends, or having multiple backends behind a proxy that knows which user goes to which backend. So I think RADIUS is a hugely useful tool for doing OTP. This doesn't mean standards like TOTP and HOTP aren't important as well; they're complementary, not contradictory.
Are you bound to a certain IdP like ADFS? Have you implemented
That's a complicated question. Like a lot of enterprises we have multiple paths to authenticate, some legacy, some newer, and a mix of web- and other protocols. Since it's not RADIUS related, I won't go into it here, but thanks for the pointers.
On Sat, Jun 11, 2016 at 4:26 PM, Phil Mayers <p.mayers@imperial.ac.uk> wrote:
On 11/06/2016 17:23, Michael Ströder wrote:
Every implementation which display the shared secrets as QR code in security theatre.
For many organisations the primary threat w.r.t. authentication credentials is credential theft and remote use (phishing. etc.). Provisioning to a soft-token via a QR code is perfectly adequate for that threat model. The attacker is not looking over your shoulder, and TOFU works great almost all of the time.
It is difficult to determine since most surveys like the Verizon DBIR to not request the info (yet) but expect to see more companies deploying 2FA for admin access thanks to PCI and the fact that it makes a ton of sense. 2FA can help minimize pass-the-hash attacks and other escalation techniques used to get data once in the network. If I were a new CSO, I would put 2FA on outbound connections too, just to see what's going on. (yes, we are far from radius. apologies.) nick
We've looked at this in detail, and there are about 250 people in our organisation of 30k+ that could justify a hard token.
If we ever get 2FA deployed, it's going to be soft-tokens deployed w/ in-band provisioning for almost everyone, because it's the only thing that makes sense and it ABSOLUTELY IS NOT security theatre for us. It addresses a real threat.
Regards, Phil
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication
Hi Aaron, you do not necessarily need client certificates for OpenVPN. You can very well use openvpm with passwords/OTP. Here is a howto, which was written by another user http://privacyidea.readthedocs.io/en/latest/application_plugins/openvpn.html Which SafeNet OTP solution are you using or planing on migrating to? Kind regards Cornelius Am Donnerstag, den 02.06.2016, 19:44 +0000 schrieb Aaron Smith:
Well at least I was able to research the issue correctly! To be clear, I'm not looking to find a way to make MSchapv2 to work. The end goal is to have a VPN solution that would allow Windows, Mac, and iOS users to connect securely, with a minimum of fuss. Tall order I know. :) I was looking at IKEv2 as it seemed to be supported natively on at least Windows and iOS, but windows clients insisted on using EAP-MSChapv2 for it. I suspect iOS does the same. SSTP works great for windows clients (and can do PAP), and I've heard rumors of third party clients for MAC OS, but I'm coming up empty on iOS clients that do SSTP. OPenVPN is a possible alternative, but the certificate aspect sounds like a management nightmare.
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 3:25 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication
Hi Aaron,
you are right about the hashed password.
The implementations I know use RADIUS with PAP. Yes, that password is transmitted encrypted, so the FreeRADIUS module can decrypt it and forward it to linotp/privacyidea.
With the corresponding effort the mschapv2 protocol could be investigated to enhance the backend functionality. I say "investigate mschapv2" since I am not even sure if it will work out: since the server sends a challenge initially which is based on the password hash. And if the server initially picks the wrong password, the client probably will end the authentication handshake. And even if you manage to achieve this: You still have to store the users password (knowledge, 1st factor) in a decryptable manner.
So the question is if you are more happy with an decryptable password in the user database or with a week encrypted password between the VPN server and the RADIUS server.
Are you using the Windows domain password or a token PIN?
Kind regards Cornelius
Am Donnerstag, den 02.06.2016, 18:52 +0000 schrieb Aaron Smith:
Doesn't matter how awesome SecureID is if you don't have the budget for it. :) I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server. I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 02, 2016 2:10 PM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible?
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Ooohh really? I'll take a look at that. Right now we have Blackshield ID Pro. It's so old it still says CryptoCard on it. :) I believe the tech said it's equivalent was Safenet Authenticatioin Service. If OpenVPN can be done with username/passwords that would be an excellent alternative though. I know that privacyIDEA can be set up with OpenVPN pretty easily. Thanks for the info! ----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 4:19 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication Hi Aaron, you do not necessarily need client certificates for OpenVPN. You can very well use openvpm with passwords/OTP. Here is a howto, which was written by another user http://privacyidea.readthedocs.io/en/latest/application_plugins/openvpn.html Which SafeNet OTP solution are you using or planing on migrating to? Kind regards Cornelius Am Donnerstag, den 02.06.2016, 19:44 +0000 schrieb Aaron Smith:
Well at least I was able to research the issue correctly! To be clear, I'm not looking to find a way to make MSchapv2 to work. The end goal is to have a VPN solution that would allow Windows, Mac, and iOS users to connect securely, with a minimum of fuss. Tall order I know. :) I was looking at IKEv2 as it seemed to be supported natively on at least Windows and iOS, but windows clients insisted on using EAP-MSChapv2 for it. I suspect iOS does the same. SSTP works great for windows clients (and can do PAP), and I've heard rumors of third party clients for MAC OS, but I'm coming up empty on iOS clients that do SSTP. OPenVPN is a possible alternative, but the certificate aspect sounds like a management nightmare.
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 3:25 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication
Hi Aaron,
you are right about the hashed password.
The implementations I know use RADIUS with PAP. Yes, that password is transmitted encrypted, so the FreeRADIUS module can decrypt it and forward it to linotp/privacyidea.
With the corresponding effort the mschapv2 protocol could be investigated to enhance the backend functionality. I say "investigate mschapv2" since I am not even sure if it will work out: since the server sends a challenge initially which is based on the password hash. And if the server initially picks the wrong password, the client probably will end the authentication handshake. And even if you manage to achieve this: You still have to store the users password (knowledge, 1st factor) in a decryptable manner.
So the question is if you are more happy with an decryptable password in the user database or with a week encrypted password between the VPN server and the RADIUS server.
Are you using the Windows domain password or a token PIN?
Kind regards Cornelius
Am Donnerstag, den 02.06.2016, 18:52 +0000 schrieb Aaron Smith:
Doesn't matter how awesome SecureID is if you don't have the budget for it. :) I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server. I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 02, 2016 2:10 PM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible?
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Yes, blackshield is the SAS. I think they are planning on something new/polished. The on premise solution SAM does a good job, but it is a bit aged, now. Kind regards Cornelius Am Donnerstag, den 02.06.2016, 20:23 +0000 schrieb Aaron Smith:
Ooohh really? I'll take a look at that. Right now we have Blackshield ID Pro. It's so old it still says CryptoCard on it. :) I believe the tech said it's equivalent was Safenet Authenticatioin Service. If OpenVPN can be done with username/passwords that would be an excellent alternative though. I know that privacyIDEA can be set up with OpenVPN pretty easily. Thanks for the info!
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 4:19 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication
Hi Aaron,
you do not necessarily need client certificates for OpenVPN. You can very well use openvpm with passwords/OTP. Here is a howto, which was written by another user http://privacyidea.readthedocs.io/en/latest/application_plugins/openvpn.html
Which SafeNet OTP solution are you using or planing on migrating to?
Kind regards Cornelius
Am Donnerstag, den 02.06.2016, 19:44 +0000 schrieb Aaron Smith:
Well at least I was able to research the issue correctly! To be clear, I'm not looking to find a way to make MSchapv2 to work. The end goal is to have a VPN solution that would allow Windows, Mac, and iOS users to connect securely, with a minimum of fuss. Tall order I know. :) I was looking at IKEv2 as it seemed to be supported natively on at least Windows and iOS, but windows clients insisted on using EAP-MSChapv2 for it. I suspect iOS does the same. SSTP works great for windows clients (and can do PAP), and I've heard rumors of third party clients for MAC OS, but I'm coming up empty on iOS clients that do SSTP. OPenVPN is a possible alternative, but the certificate aspect sounds like a management nightmare.
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 3:25 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication
Hi Aaron,
you are right about the hashed password.
The implementations I know use RADIUS with PAP. Yes, that password is transmitted encrypted, so the FreeRADIUS module can decrypt it and forward it to linotp/privacyidea.
With the corresponding effort the mschapv2 protocol could be investigated to enhance the backend functionality. I say "investigate mschapv2" since I am not even sure if it will work out: since the server sends a challenge initially which is based on the password hash. And if the server initially picks the wrong password, the client probably will end the authentication handshake. And even if you manage to achieve this: You still have to store the users password (knowledge, 1st factor) in a decryptable manner.
So the question is if you are more happy with an decryptable password in the user database or with a week encrypted password between the VPN server and the RADIUS server.
Are you using the Windows domain password or a token PIN?
Kind regards Cornelius
Am Donnerstag, den 02.06.2016, 18:52 +0000 schrieb Aaron Smith:
Doesn't matter how awesome SecureID is if you don't have the budget for it. :) I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server. I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 02, 2016 2:10 PM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible?
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Here's a tutorial on how to automatically build a combined openvpn/2FA server appliance including server certs using packer.io: https://www.wikidsystems.com/support/tutorials/build-a-2fa-ready-openvpn-com.... If you are testing or deploying on a virtual environment, packer is very handy. For clarity, if you are using a separate service for authentication, then the openvpn certs only perform encryption and each user can use the same one, making management, distribution etc much easier. On Thu, Jun 2, 2016 at 4:23 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
Ooohh really? I'll take a look at that. Right now we have Blackshield ID Pro. It's so old it still says CryptoCard on it. :) I believe the tech said it's equivalent was Safenet Authenticatioin Service. If OpenVPN can be done with username/passwords that would be an excellent alternative though. I know that privacyIDEA can be set up with OpenVPN pretty easily. Thanks for the info!
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 4:19 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication
Hi Aaron,
you do not necessarily need client certificates for OpenVPN. You can very well use openvpm with passwords/OTP. Here is a howto, which was written by another user http://privacyidea.readthedocs.io/en/latest/application_plugins/openvpn.html
Which SafeNet OTP solution are you using or planing on migrating to?
Kind regards Cornelius
Am Donnerstag, den 02.06.2016, 19:44 +0000 schrieb Aaron Smith:
Well at least I was able to research the issue correctly! To be clear, I'm not looking to find a way to make MSchapv2 to work. The end goal is to have a VPN solution that would allow Windows, Mac, and iOS users to connect securely, with a minimum of fuss. Tall order I know. :) I was looking at IKEv2 as it seemed to be supported natively on at least Windows and iOS, but windows clients insisted on using EAP-MSChapv2 for it. I suspect iOS does the same. SSTP works great for windows clients (and can do PAP), and I've heard rumors of third party clients for MAC OS, but I'm coming up empty on iOS clients that do SSTP. OPenVPN is a possible alternative, but the certificate aspect sounds like a management nightmare.
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Thursday, June 02, 2016 3:25 PM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication
Hi Aaron,
you are right about the hashed password.
The implementations I know use RADIUS with PAP. Yes, that password is transmitted encrypted, so the FreeRADIUS module can decrypt it and forward it to linotp/privacyidea.
With the corresponding effort the mschapv2 protocol could be investigated to enhance the backend functionality. I say "investigate mschapv2" since I am not even sure if it will work out: since the server sends a challenge initially which is based on the password hash. And if the server initially picks the wrong password, the client probably will end the authentication handshake. And even if you manage to achieve this: You still have to store the users password (knowledge, 1st factor) in a decryptable manner.
So the question is if you are more happy with an decryptable password in the user database or with a week encrypted password between the VPN server and the RADIUS server.
Are you using the Windows domain password or a token PIN?
Kind regards Cornelius
Am Donnerstag, den 02.06.2016, 18:52 +0000 schrieb Aaron Smith:
Doesn't matter how awesome SecureID is if you don't have the budget for it. :) I think the issue stems from an initial misunderstanding (on my part) of authentication in Freeradius. I was thinking that Freeradius would be able to negotiate MSChapv2 and then give the password that the user supplied to a module or perl script to be authenticated by the OTP server. I was thinking this because if I configure my windows 7 client to create an IKEv2 tunnel using EAP-MSCHAPv2, it will work just fine with Freeradius and a plain old user in the Users file. I figured "Well, it can see my password to compare it to THAT, so it must HAVe the password". After further reading, though, I think what it gets after negotiating MSchapv2 is a hashed password, so it snags the password from the users file, hashes THAT and then compares the hashes. So it has no way of giving the plain text password to anything at all, thus limiting the types of authentication that will work to those that provide plain text passwords to begin with.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
-----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Arran Cudbard-Bell Sent: Thursday, June 02, 2016 2:10 PM To: FreeRadius users mailing list Subject: Re: Freeradius and 2 Factor Authentication
On Jun 2, 2016, at 1:26 PM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
SecureId is pretty expensive, and it looks like Yubikey is hardware only.
But awesome.
Our users prefer a software based token.
Meh. Honestly, with NFC/USB, using a hardware token is simpler, press the button and it all just works.
SMSOtp might work, but although MOST of our users prefer software tokens, we do have some that prefer the hardware KT type tokens.
You shouldn't have any issues getting it working with Google authenticator. The only time you have difficulty is when there needs to be more of a conversation.
I've been working on this for a while now, trying a ton of different freeradius permutations and have pretty much decided that it's impossible to use Freeradius
Sounds like a protocol limitation to me. So more accurately it's not possible to use RADIUS or EAP authentication with the OTP solutions you're trying because they're fundamentally incompatible?
-Arran
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417
NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798
Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
It may not be useful yet in this respect, but we've strongly encouraged Safenet to move to FR 3 on their solution (their custom rlm_* module) to allow them to take advantage of newer developments. They're still using FR 2. We've done that because we do have interest in seeing FR 3 work with Safenet and other OTP systems for Moonshot authentication tech. Stefan Paetow Moonshot Industry & Research Liaison Coordinator t: +44 (0)1235 822 125 gpg: 0x3FCE5142 xmpp: stefanp@jabber.dev.ja.net skype: stefan.paetow.janet jisc.ac.uk Jisc is a registered charity (number 1149740) and a company limited by guarantee which is registered in England under Company No. 5747339, VAT No. GB 197 0632 86. Jisc’s registered office is: One Castlepark, Tower Hill, Bristol, BS2 0JA. T 0203 697 5800.
On 3 Jun 2016, at 05:47, Stefan Paetow <Stefan.Paetow@jisc.ac.uk> wrote:
We actually have a commercial OTP solution via SafeNet, but it's a bit long in the tooth and also only supports PAP. However, I opened a ticket today and their newer versions actually support MSChapv2 so that might be the way to go if converting our token licenses isn't too ridiculous in cost.
It may not be useful yet in this respect, but we've strongly encouraged Safenet to move to FR 3 on their solution (their custom rlm_* module) to allow them to take advantage of newer developments.
Just get them to expose a REST API. There's very little point in having a C module for something as ephemeral as an OTP solution. The only exceptions are RSA, because they're so inflexible the only way to do anything is with their magic protocol. Yubikey, because validation can be performed on the server itself, so there's a real advantage to having a local native C module. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
Hello Aaron, you are not the first to use FreeRADIUS with two factor authentication. There are many installations of LinOTP and privacyIDEA using FreeRADIUS. But the problem with OTP and MSCHAPv2 is MSCHAPv2. Roughly: In MSCHAPv2 the the RADIUS server sends a challenge to the client. The client will hash the challenge and the user password. Problem: The user password is usually combined out of <static password><OTP value>. The RADIUS server receives a hash value of something, which it does not know. I.e. it does not know the OTP value. So the RADIUS server - or the linotp plugin - would have to try the hashes of all possible OTP values. Since there could be a time skew in TOTP or the user could have blank presses in HOTP. But it gets worse: The password usually is not only the OTP value but the concatenation of the users password or PIN and the OTP value. To be able to calculate the hash of the users password and the dynamic OTP value, the OTP server needs to know the users password in clear text, since HASH( pw+otp) != HASH(pw) + HASH (otp) This way the only way to implement MSCHAPv2 with OTP is, to store the users passwords not hashed, but encrypted. At this point you need to decide, if your users would like this. Kind regards Cornelius Am Mittwoch, den 01.06.2016, 14:41 +0000 schrieb Aaron Smith:
I've been working on setting up a Microsoft Routing and Remote Access server that uses Freeradius for Authentication. Out of the box, it works fine with simple user entries in the "users" file. This is with both the Ubuntu 14.04 apt-get installations of Freeradius (2.1.x) as well as a compiled from source version of Freeradius 2.2.9. I run in to trouble when I try to add two factor authentication to the mix. I'm trying to use LinOTP as a possible replacement of our CryptoCard Blackshield implementation. The problem is that both products seem to only work with unencrypted passwords. LinOTP has two options for Freeradius authentication. There is a linotp2 module that can be compiled and installed along with Freeradius, and there is also a perl script that can be linked in with the rlm_perl module. Looking at the perl script, it is expecting to find the attribute "User-Password" in the radius request, which it uses, along with the username, to go to a web URL on the LinOTP server to verify authentication. I suspect that the linotp2 module works similarly. The documentation provided by LinOTP says to set "DEFAULT Auth-Type := linotp2" if you're using the module or "DEFAULT Auth-Type := perl" if you're using the perl script in the freeradius users file. Now, this will "work" for narrow authentication types like Microsoft's SSTP with an unencrypted password, but I'd like this solution to be more widely usable (Macs, iOS devices, etc) and use something like IKEv2, but that uses EAP-MSCHapv2. If I try that, the authentication fails saying there is no password.
My question is...am I tilting at windmills trying to make this work? I feel like it *should* be possible to do 2 factor authentication without having to resort to PPTP/unecrypted password or microsoft's proprietary SSTP. Is there a way to have freeradius pass the MSChapv2 password to a perl script or another module? Or perhaps it's possible to modify the perl script so it can accept an encrypted password? I feel like maybe there's a way to configure authentication in the "inner-tunnel" freeradius site that would make this possible. EAP-MSChapv2 authentication works with a plain, unencrypted password in the users file, so it obviously HAS the password that the user sends in SOME fashion.
A secondary question is that I imagine I can't be the first person to use Freeradius with 2 factor authentication. I'd be curious to know how other folks have tackled this project and what products they used to accomplish it.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Thanks for the in depth answer. So, it sounds like it *can* be done, but not easily. I think I'll keep at it. I might end up just settling on different tunnel protocols for different devices. ----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu -----Original Message----- From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu@lists.freeradius.org] On Behalf Of Cornelius Kölbel Sent: Wednesday, June 01, 2016 10:55 AM To: freeradius-users@lists.freeradius.org Subject: Re: Freeradius and 2 Factor Authentication Hello Aaron, you are not the first to use FreeRADIUS with two factor authentication. There are many installations of LinOTP and privacyIDEA using FreeRADIUS. But the problem with OTP and MSCHAPv2 is MSCHAPv2. Roughly: In MSCHAPv2 the the RADIUS server sends a challenge to the client. The client will hash the challenge and the user password. Problem: The user password is usually combined out of <static password><OTP value>. The RADIUS server receives a hash value of something, which it does not know. I.e. it does not know the OTP value. So the RADIUS server - or the linotp plugin - would have to try the hashes of all possible OTP values. Since there could be a time skew in TOTP or the user could have blank presses in HOTP. But it gets worse: The password usually is not only the OTP value but the concatenation of the users password or PIN and the OTP value. To be able to calculate the hash of the users password and the dynamic OTP value, the OTP server needs to know the users password in clear text, since HASH( pw+otp) != HASH(pw) + HASH (otp) This way the only way to implement MSCHAPv2 with OTP is, to store the users passwords not hashed, but encrypted. At this point you need to decide, if your users would like this. Kind regards Cornelius Am Mittwoch, den 01.06.2016, 14:41 +0000 schrieb Aaron Smith:
I've been working on setting up a Microsoft Routing and Remote Access server that uses Freeradius for Authentication. Out of the box, it works fine with simple user entries in the "users" file. This is with both the Ubuntu 14.04 apt-get installations of Freeradius (2.1.x) as well as a compiled from source version of Freeradius 2.2.9. I run in to trouble when I try to add two factor authentication to the mix. I'm trying to use LinOTP as a possible replacement of our CryptoCard Blackshield implementation. The problem is that both products seem to only work with unencrypted passwords. LinOTP has two options for Freeradius authentication. There is a linotp2 module that can be compiled and installed along with Freeradius, and there is also a perl script that can be linked in with the rlm_perl module. Looking at the perl script, it is expecting to find the attribute "User-Password" in the radius request, which it uses, along with the username, to go to a web URL on the LinOTP server to verify authentication. I suspect that the linotp2 module works similarly. The documentation provided by LinOTP says to set "DEFAULT Auth-Type := linotp2" if you're using the module or "DEFAULT Auth-Type := perl" if you're using the perl script in the freeradius users file. Now, this will "work" for narrow authentication types like Microsoft's SSTP with an unencrypted password, but I'd like this solution to be more widely usable (Macs, iOS devices, etc) and use something like IKEv2, but that uses EAP-MSCHapv2. If I try that, the authentication fails saying there is no password.
My question is...am I tilting at windmills trying to make this work? I feel like it *should* be possible to do 2 factor authentication without having to resort to PPTP/unecrypted password or microsoft's proprietary SSTP. Is there a way to have freeradius pass the MSChapv2 password to a perl script or another module? Or perhaps it's possible to modify the perl script so it can accept an encrypted password? I feel like maybe there's a way to configure authentication in the "inner-tunnel" freeradius site that would make this possible. EAP-MSChapv2 authentication works with a plain, unencrypted password in the users file, so it obviously HAS the password that the user sends in SOME fashion.
A secondary question is that I imagine I can't be the first person to use Freeradius with 2 factor authentication. I'd be curious to know how other folks have tackled this project and what products they used to accomplish it.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Cornelius Kölbel cornelius.koelbel@netknights.it +49 151 2960 1417 NetKnights GmbH http://www.netknights.it Landgraf-Karl-Str. 19, 34131 Kassel, Germany Tel: +49 561 3166797, Fax: +49 561 3166798 Amtsgericht Kassel, HRB 16405 Geschäftsführer: Cornelius Kölbel
Aaron: Yes, it is doable. Here's a tutorial on how to set up WiKID 2FA with freeradius: https://www.wikidsystems.com/support/how-to/how-to-add-two-factor-authentica.... HTH, nick On Wed, Jun 1, 2016 at 10:41 AM, Aaron Smith <Aaron.Smith@kzoo.edu> wrote:
I've been working on setting up a Microsoft Routing and Remote Access server that uses Freeradius for Authentication. Out of the box, it works fine with simple user entries in the "users" file. This is with both the Ubuntu 14.04 apt-get installations of Freeradius (2.1.x) as well as a compiled from source version of Freeradius 2.2.9. I run in to trouble when I try to add two factor authentication to the mix. I'm trying to use LinOTP as a possible replacement of our CryptoCard Blackshield implementation. The problem is that both products seem to only work with unencrypted passwords. LinOTP has two options for Freeradius authentication. There is a linotp2 module that can be compiled and installed along with Freeradius, and there is also a perl script that can be linked in with the rlm_perl module. Looking at the perl script, it is expecting to find the attribute "User-Password" in the radius request, which it uses, along with the username, to go to a web URL on the LinOTP server to verify authentication. I suspect that the linotp2 module works similarly. The documentation provided by LinOTP says to set "DEFAULT Auth-Type := linotp2" if you're using the module or "DEFAULT Auth-Type := perl" if you're using the perl script in the freeradius users file. Now, this will "work" for narrow authentication types like Microsoft's SSTP with an unencrypted password, but I'd like this solution to be more widely usable (Macs, iOS devices, etc) and use something like IKEv2, but that uses EAP-MSCHapv2. If I try that, the authentication fails saying there is no password.
My question is...am I tilting at windmills trying to make this work? I feel like it *should* be possible to do 2 factor authentication without having to resort to PPTP/unecrypted password or microsoft's proprietary SSTP. Is there a way to have freeradius pass the MSChapv2 password to a perl script or another module? Or perhaps it's possible to modify the perl script so it can accept an encrypted password? I feel like maybe there's a way to configure authentication in the "inner-tunnel" freeradius site that would make this possible. EAP-MSChapv2 authentication works with a plain, unencrypted password in the users file, so it obviously HAS the password that the user sends in SOME fashion.
A secondary question is that I imagine I can't be the first person to use Freeradius with 2 factor authentication. I'd be curious to know how other folks have tackled this project and what products they used to accomplish it.
----------------------------------- Aaron Smith System Administrator Information Services Kalamazoo College 1200 Academy Street, Kalamazoo, MI 49006 (269) 337-7496 Aaron.Smith@kzoo.edu
- List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- -- Nick Owen WiKID Systems, Inc. http://www.wikidsystems.com Commercial/Open Source Two-Factor Authentication
participants (9)
-
Aaron Smith -
Arran Cudbard-Bell -
Cornelius Kölbel -
Matthew Newton -
Michael Ströder -
Nick Owen -
Peter Lambrechtsen -
Phil Mayers -
Stefan Paetow