hi
> An entry for an EAP user can look like this (say): > > "joe" Auth-Type := eap, User-Password == "hello" > Session-Timeout = 300 > > (side note: is the Auth-Type := eap part really necessary? I would expect > not since the eap module apparently adds the Auth-Type attribute to the > config list regardless of what's included in the user entry) it's not. set it to system or local before. it's more correct to let it be set by authorize section. eap module in authorize will do so if it finds relevant eap-message included. > The users file man page says this about the == operator (applied to the > User-Password attribute above): > > "Attribute == Value" > As a check item, it matches if the named attribute is present in the > request, AND has the given value. Not allowed as a reply item. > > And RFC 2269 says : > > [Note 1] An Access-Request that contains either a User-Password or > CHAP-Password or ARAP-Password or one or more EAP-Message attributes > MUST NOT contain more than one type of those four attributes. > > I take this to mean that the EAP-Message attribute and User-Password > attribute are mutually exclusive, i.e. you can never have a User-Password > attribute in a request if it has an EAP-Message attribute. yes, they are: in the access-request. that's logical: user-password as an attribute is only necessary when you use PAP. if CHAP is used, CHAP-Password attribute is used instead, when EAP is used, EAP-Message is used (since the method can contain more than just a "password"), etc. that's so far very consistent. the only problem you have is that you are generally confusing User-Password check item in the user configuration with the attributes sent in the Access-Request (which is not further suprising, since the names are the same). The fact is that the Radius server never sends Access-Requests except for proxying and the User-Password never appears in the Access-Requests containing EAP-Message since it is only used locally. thus, the both can not appear in the Access-Requests at the same time, which is perfectly RFC conform. now, for the probable reason: in EAP/MD5 you as a server receive the EAP/Identity and issue the EAP/MD5-Challenge (both contained in the EAP-Message attribute). then you get the answer back and this has to be verified against some shared secret. you CAN probably stock this secret in some special file, some new check item or something else. the guys simply re-used User-Password. remark: CHAP-Password would have been perhaps more logical since EAP/MD5 is almost identical to CHAP with MD5 *BUT* unfortunately CHAP-Passwords *are* sent in the Access-Replies and are thus not local check items. that's my understanding of the whole story. they just needed place where to put the password in. > The above user profile does indeed work on 0.8.1 for EAP-MD5. But it > shouldn't work, as far as I can see, since we have a check item > (User-Password) which does not technically match any attribute in the > request (User-Password isn't even present, since the request contains an > EAP-Message). The request should not make it past the authorization stage. > Any comments? it doesn't match any attributes in the request. BUT: the EAP-Message is present and thus the message is treated by EAP-module (the Auth-Type is explictly set to := EAP if EAP-Message is found). the latter happens to look for the password in the User-password check item of the user configuration. now, try to find an RFC which prescribes where EAP-Message verificator gets the user's password from. you probably won't since it's an implementation issue and IETF is all about protocols. ciao artur -- Artur Hecker artur[at]hecker.info - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
