> > Can you clear something up for me with inner/outer identity. The outer > identity is in the User-Name attribute , it's a standard RADIUS
yep > attribute... Inner identity is encoded in the EAP message, and is pulled yep > out by the EAP module prior to internal proxying and set as the > User-Name attribute (which should overwrite the User-Name attribute in > the request) ? yep > > And it's standard practice to leave the outer identity as anonymous, as varies. some supplicants just set outer==inner e.g. winXP. > the only communication between the NAS and the Supplicant is EAP based > when using EAPOL, and so the NAS would have to understand EAP to be able > to extract the User-Name string and write it into the Access-Request > packet ? In fact, since the inner identity is normally sent in an encrypted EAP flow, the NAS would have to break the encryption to access it. Basically the NAS can't see the inner User-Name > > So although the NAS must send an EAP-Identity-Request when the client > connects it's not required to understand the EAP-Identity-Response ? Correct. One final thing to add - the EAP standard specifies that in the final Access-Accept, the radius server (which DOES know the inner User-Name) should copy it to a User-Name attribute in the Access-Accept - so, the radius server tells the NAS what the user is. This is *slightly* complicated because by default, FreeRadius proxies the inner EAP to itself, so when it sends that Access-Accept it sends it to itself; and you need to "use_tunneled_reply" to actually get that back to the NAS. That is: NAS: Access-Request [EMAIL PROTECTED] SRV: Access-Challenge NAS: Access-Request [EMAIL PROTECTED] SRV: Access-Challenge NAS: Access-Request SRV: <ok, I've got all the EAP - proxy to myself> SRV(outer): Access-Request [EMAIL PROTECTED] SRV(inner): Access-Accept [EMAIL PROTECTED] SRV: <ok, copy tunneled reply to outer and...> SRV: Access-Accept [EMAIL PROTECTED] Hope that helps. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html