>
> 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
