Re: EAP-MD5: Password sources

[Artur Hecker]

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: EAP-MD5: Password sources

[McNutt, Justin M.]

> 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

[Raghu]

"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