Re: terminating EAP tunnels, proxy and realms
Gah, my message bounced owing to change of email address... Arran wrote:
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 attribute... Inner identity is encoded in the EAP message, and is pulled 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) ?
Correct.
And it's standard practice to leave the outer identity as anonymous, as 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 ?
Nope; see RFC 3579 for the gory details: "the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute" The use of "anonymous" is simply to preserve privacy; it's not a technical requirement of any EAP method (that I know of). An interesting tangent: note that "end-user identity hiding" is simply a "requirement" of RFC 4017 ("EAP Method Requirements for Wireless LANs"), which I think is a shame.
So although the NAS must send an EAP-Identity-Request when the client
connects it's not required to understand the EAP-Identity-Response ?
For the reason given above, it *does* need to understand the EAP-Identity-Response. But that's about it! The NAS is a pretty dumb device. josh.
Josh Howlett wrote:
Gah, my message bounced owing to change of email address...
Arran wrote:
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 attribute... Inner identity is encoded in the EAP message, and is pulled 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) ?
Correct.
And it's standard practice to leave the outer identity as anonymous, as 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 ?
Nope; see RFC 3579 for the gory details:
"the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute"
See thats what I suspected, else how could the User-Name attribute be populated in the access requests... And indeed as the RFC states, the User-Identity needs to be set in the access requests for none EAP aware proxies. I suspect FreeRADIUS may count as one of these, as for all intensive purposes as it provides no mechanism to proxy arbitrary segments of an EAP conversation on inner identity alone. Unless I missed something ?
The use of "anonymous" is simply to preserve privacy; it's not a technical requirement of any EAP method (that I know of).
An interesting tangent: note that "end-user identity hiding" is simply a "requirement" of RFC 4017 ("EAP Method Requirements for Wireless LANs"), which I think is a shame.
So although the NAS must send an EAP-Identity-Request when the client
connects it's not required to understand the EAP-Identity-Response ?
For the reason given above, it *does* need to understand the EAP-Identity-Response. But that's about it! The NAS is a pretty dumb device.
josh.
Reason why I was asking is because most of the tests on the JRS test website seem to break when you base the reply in FreeRADIUS, on the inner identity as opposed to the outer identity. So FreeRADIUS will copy all the attributes from the last attribute request into the internally proxied request, and base the reply to the NAS, on the attributes coming back as the result of the internal proxy. I have to do it like this else I get lots of duplicate reply attributes and things overwriting other things when they shouldn't. PEAP seems to work ok, but all the other TTLS tests break. Trying to track down what the issue is... I'll post some debug traces when i've moved the latest CVS to our "production" server. -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
And indeed as the RFC states, the User-Identity needs to be set in the access requests for none EAP aware proxies. I suspect FreeRADIUS may count as one of these, as for all intensive purposes as it provides no mechanism to proxy arbitrary segments of an EAP conversation on inner identity alone.
I'm not sure why that matters. the *NAS* sets User-Name in the Access-Request. The proxying server doesn't have to do anything.
Reason why I was asking is because most of the tests on the JRS test website seem to break when you base the reply in FreeRADIUS, on the inner identity as opposed to the outer identity.
The "post-auth" section is run in the outer identity, so you can re-write the reply to be whatever you want. Alan DeKok.
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
And indeed as the RFC states, the User-Identity needs to be set in the access requests for none EAP aware proxies. I suspect FreeRADIUS may count as one of these, as for all intensive purposes as it provides no mechanism to proxy arbitrary segments of an EAP conversation on inner identity alone.
I'm not sure why that matters. the *NAS* sets User-Name in the Access-Request. The proxying server doesn't have to do anything.
Well it needs to be able to read an identity of *some* kind, else how would it know where to proxy the packets to . Just saying it's not technically EAP aware in proxying mode, it doesn't matter, just academic discussion :)
Reason why I was asking is because most of the tests on the JRS test website seem to break when you base the reply in FreeRADIUS, on the inner identity as opposed to the outer identity.
The "post-auth" section is run in the outer identity, so you can re-write the reply to be whatever you want.
Yes but it still needs to grab various attributes from the SQL database, and I thought a different query was run for post-auth ... as in the one that logs reply packets ;) ? Maybe i'll move the defaults stuff to post-auth, as defaults set attributes using = , so can't overwrite anything set ealier in Authorize.... just fill in the blanks.
Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
-- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
Arran Cudbard-Bell wrote:
I'm not sure why that matters. the *NAS* sets User-Name in the Access-Request. The proxying server doesn't have to do anything.
Well it needs to be able to read an identity of *some* kind, else how would it know where to proxy the packets to .
The NAS doesn't proxy the packets by user name. It just sends them to the locally configured RADIUS server. The NAS doesn't really set the user name, either. It just copies it from the EAP packet sent by the supplicant.
Yes but it still needs to grab various attributes from the SQL database, and I thought a different query was run for post-auth ... as in the one that logs reply packets ;) ?
Hmm... that may need fixing. Alan DeKok.
Yes but it still needs to grab various attributes from the SQL database, and I thought a different query was run for post-auth ... as in the one that logs reply packets ;) ?
Hmm... that may need fixing.
Alan DeKok.
Yes, would be nice, though then you would have to be able to pass arguments to modules... Or create a new section called post-auth-logging .. Which reminds me, return codes :P ? Listening on authentication address 139.184.14.180 port 1812 as server primary Listening on accounting address 139.184.14.180 port 1813 as server primary Ok first bug, Global clients aren't being copied across to virtual servers, even when no clients are specified in the virtual server. With SQL based and static declarations. This is with one virtual server, no default server. -- Arran Cudbard-Bell (A.Cudbard-Bell@sussex.ac.uk) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900
participants (3)
-
Alan DeKok -
Arran Cudbard-Bell -
Josh Howlett