RE: EAP-MD5: Password sources
There are 2 types of EAP authentications that are currently supported by Freeradius 1. EAP-MD5 2. EAP-TLS The one which you tested is EAP-md5. It is just similar to CHAP authentication. It works only with PLAIN TEXT passwords. So if you have plain text password stored in files, database or LDAP, then it works. EAP-TLS is Certificate based authentication. I don't understand where this restriction comes from. Once the FreeRADIUS server gets the password from the NAS, what prevents it from checking that password against /etc/shadow, PAM, another RADIUS server, or whatever? --J - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-MD5: Password sources
hello I don't understand where this restriction comes from. Once the FreeRADIUS server gets the password from the NAS, what prevents it from checking that password against /etc/shadow, PAM, another RADIUS server, or whatever? in fact, it's not a restriction of freeradius. it's a necessary restriction of the CHAP (and EAP-MD5, which is basically the same). the problem is that the client doesn't send a password which the server can check against whatever in whichever way. the client sends an authentication string (i'm not going to be very precise, it's the principal which we are talking about) produced by the user basically out of user's identity, the challenge sent before by the server, etc. and of course the password itself. what's good about this authentication string is that you can't guess whatever information has been taken to create it by just looking at the result (it's usually a cryptographic hash built using MD5, so a one-way function with rare collisions). the second good thing about it: it's very improbable, that you will be successful in producing the same result just using some crap instead of values used by the user. so, the only way to verify such an authentication string on the server side is to re-compute it the same way the client did. the only (theoretical) way to do so is to have the same input values and to process them in the same order and in the same concatenation through the same algorithm (MD5). then you compare the results. if they don't match - the user loses. if they do, the server sends the accept message. so, the server needs the unencrypted password. hope this helps. artur -- Artur Hecker Groupe Accès et Mobilité [EMAIL PROTECTED]Département Informatique et Réseaux +33 1 45 81 750746, rue Barrault 75634 Paris cedex 13 http://www.infres.enst.fr ENST Paris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FW: EAP-MD5: Password sources
On Tue, Apr 02, 2002 at 04:43:43PM -0600, McNutt, Justin M. wrote: Okay, so the way that Microsoft's RADIUS server gets away with this is due to the fact that in a Microsoft domain, user names and passwords are not stored using strong (one-way) encryption. You can decrypt the password file. No. Microsoft stores a cleartext equivalent of the password. So when an EAP request comes in to an MS RADIUS server, MS decrypts your password, then encrypts it again using EAP-MD5, which it can then check against the string that came from the NAS. Right? No, it hashes the cleartext equivalant the same way the client does. It then compares the two hashes. And the real alternative is to use EAP-TLS, correct? dunno /fc -Original Message- hello I don't understand where this restriction comes from. Once the FreeRADIUS server gets the password from the NAS, what prevents it from checking that password against /etc/shadow, PAM, another RADIUS server, or whatever? in fact, it's not a restriction of freeradius. it's a necessary restriction of the CHAP (and EAP-MD5, which is basically the same). the problem is that the client doesn't send a password which the server can check against whatever in whichever way. the client sends an authentication string (i'm not going to be very precise, it's the principal which we are talking about) produced by the user basically out of user's identity, the challenge sent before by the server, etc. and of course the password itself. what's good about this authentication string is that you can't guess whatever information has been taken to create it by just looking at the result (it's usually a cryptographic hash built using MD5, so a one-way function with rare collisions). the second good thing about it: it's very improbable, that you will be successful in producing the same result just using some crap instead of values used by the user. so, the only way to verify such an authentication string on the server side is to re-compute it the same way the client did. the only (theoretical) way to do so is to have the same input values and to process them in the same order and in the same concatenation through the same algorithm (MD5). then you compare the results. if they don't match - the user loses. if they do, the server sends the accept message. so, the server needs the unencrypted password. hope this helps. artur -- Artur Hecker Groupe Accès et Mobilité [EMAIL PROTECTED] Département Informatique et Réseaux +33 1 45 81 7507 46, rue Barrault 75634 Paris cedex 13 http://www.infres.enst.frENST Paris - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FW: EAP-MD5: Password sources
McNutt, Justin M. wrote: Again, same idea. MS uses the repository of password-equivalent strings that are stored in Active Directory, the NT domain, whatever to compare against the authentication string provided in the EAP request. The problem I have with all of this is the fact that the actual passwords can be deduced using the cleartext equivalent that MS stores. This is a huge weakness in NT/2K-based authentication that I was hoping to get around using FreeRADIUS. Unfortunately the way EAP-MD5 works with FreeRADIUS is just as bad (or worse) from the standpoint of having a file somewhere with all of my users' passwords in them in cleartext (or a trivially-decodable) form. So if I want to use FreeRADIUS and EAP, EAP-TLS is the only option I have left (so far). I am not sure about MS but based on your observation, I think EAP-TLS is your best option. Here you are talking about 2 different aspects 1. Secure mechanism of storing Passwords locally. You got to deal this locally. Partly the same problem applies even for certificates. 2. Secure mechanism of authentication over the network. CHAP, EAP-MD5 are better but EAP-TLS is the best (IMHO). -- (( )) | |.| HereUAre !! |_| (( Raghu )) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: FW: EAP-MD5: Password sources
On Tue, Apr 02, 2002 at 05:53:28PM -0600, McNutt, Justin M. wrote: The problem I have with all of this is the fact that the actual passwords can be deduced using the cleartext equivalent that MS stores. This is a huge weakness in NT/2K-based authentication that I was hoping to get around using FreeRADIUS. The actual password cannot be deduced from the cleartext equivalent in any way other than dictionary attack / guessing (same as for unix crypt or md5). The only problem with this is that the M$ hash has no salt, so an attacker can precompile a dictionary. However, a salt is relatively useless as the md4 hash (what M$ stores) is cleartext equivalent, so an attacker does not need to deduce the actual password -- at least not for purposes of using M$ style authenticated resources. So MS-CHAP is not worse than regular CHAP (essentially EAP-MD5) in this regard. There is definitely a problem if someone has the md4's and a user re-uses their password on other systems, eg to authenticate to both unix and windows machines. You could use PAP auth or perhaps EAP-TLS. PAP auth has the disadvantage of the password going over the wire in the clear to the NAS, so you have to weigh your concerns here. I don't know of any radius servers that do EAP-TLS. (But then, I know almost nothing about EAP period.) There are better ways to do this, but there are no implementations of them. /fc - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-MD5: Password sources
Okay, new question: Now that I have the NAS talking to the RADIUS server properly, I need the RADIUS server to use something other than hard-coded passwords when it authenticates using Auth-Type := EAP. Here's an example from /usr/local/etc/raddb/users: gilpina Auth-Type := EAP Port-Priority = Platinum, Tunnel-Private-Group-Id = 201, Tunnel-Type = 13, Tunnel-Medium-Type = 6, Service-Type = Framed, NAS-Port-Type = Ethernet What would be the proper syntax for something like this: gilpinaAuth-Type := EAP, Password == PAM or gilpinaAuth-Type := EAP, Password == Unix ...so that the server checks the password against an external source, rather than a password hard-coded into the users file? Thanks! Justin McNutt Network Systems Analyst - Expert DNPS, Mizzou Telecom (573) 882-5183 One IP to rule them all, one IP to find them, One IP to bring them all, and in the darkness BIND them, In the land of Ether, where the packets fly. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: EAP-MD5: Password sources
McNutt, Justin M. wrote: Okay, new question: Now that I have the NAS talking to the RADIUS server properly, I need the RADIUS server to use something other than hard-coded passwords when it authenticates using Auth-Type := EAP. Here's an example from /usr/local/etc/raddb/users: gilpina Auth-Type := EAP Port-Priority = Platinum, Tunnel-Private-Group-Id = 201, Tunnel-Type = 13, Tunnel-Medium-Type = 6, Service-Type = Framed, NAS-Port-Type = Ethernet What would be the proper syntax for something like this: gilpinaAuth-Type := EAP, Password == PAM or gilpinaAuth-Type := EAP, Password == Unix There are 2 types of EAP authentications that are currently supported by Freeradius 1. EAP-MD5 2. EAP-TLS The one which you tested is EAP-md5. It is just similar to CHAP authentication. It works only with PLAIN TEXT passwords. So if you have plain text password stored in files, database or LDAP, then it works. EAP-TLS is Certificate based authentication. -- (( )) | |.| HereUAre !! |_| (( Raghu )) - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
EAP-MD5/Password
Title: shinbiro mail edior
Hi.
I use "FreeRADIUS Version 0.5, for host i686-pc-linux-gnu, built on
Mar 7 2002 at 02:11:01"
I edit users file the following.
DEFAULT Auth-Type :=3D EAP=
Fall-Through =3D 1
Also, I edit radiusd.conf
eap {=
bsp;=
; default_eap_type =3D md5
=
timer_expire =
=3D 60
=
md5 {=
; }
}
authorize { preprocess=
# counter#&=
nbsp; attr_filter
