Freeradius and 2 Factor Authentication

[Cornelius Kölbel]

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 at kzoo.edu
> 
> 
> -----Original Message-----
> From: Freeradius-Users [mailto:freeradius-users-bounces+aaron.smith=kzoo.edu at 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 at 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 at 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


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20160602/cd2d433d/attachment.sig>