Re: terminating EAP tunnels, proxy and realms
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
Re: terminating EAP tunnels, proxy and realms
Arran Cudbard-Bell wrote: ... It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP, and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2. Ah cool, thats actually really useful . Does only one packet need to be proxied per EAP authentication ? Yes. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
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 ([EMAIL PROTECTED]) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
RE: terminating EAP tunnels, proxy and realms
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 ? No, that's correct. 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. 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. I'm surprised at that, IIRC (and I did write the code originally :-) the tests use the same name for inner and outer. Still, it would probably be best if you raised a ticket with JANET Customer Services as this is a bit OT for this list. best regards, josh. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Alan, I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP. Set Proxy-To-Realm := LOCAL for the realms you want to terminate locally. Make sure that this is done before the eap module is run in the authorise section. Then, put the following in the users file to proxy the inner request to another realm: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm = oldservers I've already had these rules in user. The final hint was to set authhost = LOCAL in proxy.conf. Now it works as expected. Thanks a lot to all who helped, especially to Alan of course! -Andreas -- Andreas Liebe/Darmstadt University of Technology/+49 6151 16-3150/3050(FAX) signature.asc Description: This is a digitally signed message part - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
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 ([EMAIL PROTECTED]) Authentication, Authorisation and Accounting Officer Infrastructure Services | ENG1 E1-1-08 University Of Sussex, Brighton EXT:01273 873900 | INT: 3900 - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Alan DeKok wrote:
Arran Cudbard-Bell wrote:
So the eap module extracts the attributes encoded in the eap message ? I
can see that working for EAP GTC and EAP PAP but not MschapV2 ?
It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP,
and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2.
With the new virtual server support, it's now possible to have the
inner tunnel session run through it's own virtual server, independent of
the outer tunnel session. Just set Virtual-Server = foo via update
control, and the inner tunnel session will be run through server foo.
30 lines of code changed: incredible new flexibility.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Yes :)
I was just looking at the protocol filters, they look interesting and
will make a lot of people on the list happy ...
Just finished building on my 32bit machine and ..
++? if (%{NAS-IP-Address} == 127.0.0.1) - TRUE
++- entering if (%{NAS-IP-Address} == 127.0.0.1)
expand: %{Packet-Src-IP-Address} - 139.184.14.161
Segmentation fault
*sigh*
bt
radius_update_attrlist (request=0x80280840, cs=0x8004c798,
input_vps=0x8016bc60, name=0x8004c7f0 request)
at evaluate.c:854
854 if ((from_list[i]-operator == T_OP_EQ) ||
(gdb) bt
#0 radius_update_attrlist (request=0x80280840, cs=0x8004c798,
input_vps=0x8016bc60, name=0x8004c7f0 request)
at evaluate.c:854
#1 0x80014afa in modcall (component=1, c=0x8016bdb0,
request=0x80280840) at modcall.c:396
#2 0x8001141a in indexed_modcall (space=value optimized out, comp=1,
idx=0, request=0x80280840) at modules.c:413
#3 0x80006c30 in rad_authenticate (request=0x80280840) at auth.c:540
#4 0x8001f096 in radius_handle_request (request=0x80280840,
fun=0x80006b10 rad_authenticate) at event.c:2174
#5 0x80019fe6 in thread_pool_addrequest (request=0x80280840,
fun=0x80006b10 rad_authenticate) at threads.c:836
#6 0x80015c5f in main (argc=2, argv=0xbfb42524) at radiusd.c:716
Same as on the apples !!!
Are you compiling with GCC ?
If you are compiling on GCC with the default configuration options ...
then it can only be my config ... it's the only constant... and a bug in
a source *somewhere*, just in a very obscure place. :\
Would you like the core dumps from the 32bit machine ?
---
Arran
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Arran Cudbard-Bell wrote:
I was just looking at the protocol filters, they look interesting and
will make a lot of people on the list happy ...
rlm_protocol_filter? I put that in 2 years ago, and I didn't think
anyone was using it...
Just finished building on my 32bit machine and ..
++? if (%{NAS-IP-Address} == 127.0.0.1) - TRUE
++- entering if (%{NAS-IP-Address} == 127.0.0.1)
expand: %{Packet-Src-IP-Address} - 139.184.14.161
Segmentation fault
Fixed, thanks.
Alan DeKok.
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Alan DeKok wrote: Arran Cudbard-Bell wrote: I was just looking at the protocol filters, they look interesting and will make a lot of people on the list happy ... rlm_protocol_filter? I put that in 2 years ago, and I didn't think anyone was using it... Well it's a little obscure, it's not included in the default radiusd.conf file ? I guess if it's just working off EAP-Type then it's functionality can be replicated in unlang ... I've just seen a few requests with people saying how can I limit EAP to xyz. 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) ? 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 ? So although the NAS must send an EAP-Identity-Request when the client connects it's not required to understand the EAP-Identity-Response ? Thanks, Arran - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Hi Helmut, Is there a way to terminate the EAP regardless of the outer identity? why do you want this. The EAP Tunnel should terminate on the last RADIUS where the user belongs. On your RADIUS only the EAP-Tunnels for your users should be terminating. I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP. Any idea how to do this? Thanks, -Andreas - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Andreas Liebe wrote: Hi Helmut, Is there a way to terminate the EAP regardless of the outer identity? why do you want this. The EAP Tunnel should terminate on the last RADIUS where the user belongs. On your RADIUS only the EAP-Tunnels for your users should be terminating. I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP. Any idea how to do this? Simple answer ... you can't . - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Andreas Liebe wrote: I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP. Set Proxy-To-Realm := LOCAL for the realms you want to terminate locally. Make sure that this is done before the eap module is run in the authorise section. Then, put the following in the users file to proxy the inner request to another realm: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm = oldservers 2.0.0 should have a much more fine-grained way to control this. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Alan DeKok wrote: Andreas Liebe wrote: I do not want to terminate the EAP tunnels for the foreign realms, but I have to terminate the local one (@tu-darmstadt.de and NULL) as I have to forward the requests to a set of internal radius servers not capable of speaking EAP. Set Proxy-To-Realm := LOCAL for the realms you want to terminate locally. Make sure that this is done before the eap module is run in the authorise section. Then, put the following in the users file to proxy the inner request to another realm: DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Proxy-To-Realm = oldservers 2.0.0 should have a much more fine-grained way to control this. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html So the eap module extracts the attributes encoded in the eap message ? I can see that working for EAP GTC and EAP PAP but not MschapV2 ? - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Alan DeKok wrote: Arran Cudbard-Bell wrote: So the eap module extracts the attributes encoded in the eap message ? I can see that working for EAP GTC and EAP PAP but not MschapV2 ? It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP, and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2. Ah cool, thats actually really useful . Does only one packet need to be proxied per EAP authentication ? With the new virtual server support, it's now possible to have the inner tunnel session run through it's own virtual server, independent of the outer tunnel session. Just set Virtual-Server = foo via update control, and the inner tunnel session will be run through server foo. 30 lines of code changed: incredible new flexibility. Yes look forward to trying it ;) Built on failover partner and same result , so deffinately not a hardware error, points to either the architecture or the compiler... - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Arran Cudbard-Bell wrote: So the eap module extracts the attributes encoded in the eap message ? I can see that working for EAP GTC and EAP PAP but not MschapV2 ? It works for GTC, PAP, and MS-CHAPv2. The server can terminate PEAP, and proxy the inner EAP-MSCHAPv2 session as plain MS-CHAPv2. With the new virtual server support, it's now possible to have the inner tunnel session run through it's own virtual server, independent of the outer tunnel session. Just set Virtual-Server = foo via update control, and the inner tunnel session will be run through server foo. 30 lines of code changed: incredible new flexibility. Alan DeKok. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
terminating EAP tunnels, proxy and realms
Hi all,
we're using FreeRadius 1.1.6 to give access to our WLAN with EAP-TTLS.
Worked great so far.
No we want to participate in inter University roaming (eduroam) and thus
have to proxy some requests a parent server. Everything works great
except regarding the outer identity.
If it's just anonymous everything is ok, but if it's
anonymous@somerealm and somerealm is configured in proxy.conf the
EAP-Request ist proxied instead of terminated. This is correct by
configuration but not wanted.
Is there a way to terminate the EAP regardless of the outer identity?
Here's an example:
User-Name = [EMAIL PROTECTED]
Calling-Station-Id = 00-18-DE-B5-3A-E2
...
EAP-Message =
0x0201001e01616e6f6e796d6f75734074752d6461726d73746164742e
6465
Message-Authenticator = 0x7a211176339c3e2ee9f7a0fe56864b2a
...
rlm_realm: Looking up realm tu-darmstadt.de for User-Name =
[EMAIL PROTECTED]
rlm_realm: Found realm tu-darmstadt.de
rlm_realm: Adding Stripped-User-Name = anonymous
rlm_realm: Proxying request from user anonymous to realm
tu-darmstadt.de
rlm_realm: Adding Realm = tu-darmstadt.de
rlm_realm: Preparing to proxy authentication request to realm
tu-darmstadt.
de
modcall[authorize]: module suffix returns updated for request 6
rlm_eap: Request is supposed to be proxied to Realm tu-darmstadt.de.
Not doing EAP.
modcall[authorize]: module eap returns noop for request 6
...
How can I bypass proxy authentication for EAP-Messages?
This is the setup in users:
...
# matches request without any realm (local)
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Realm !* NULL,
Proxy-To-Realm := MyRealm
User-Name = `%{User-Name}`,Fall-Through = Yes
# matches requests going explicitly to tu-darmstadt.de (local)
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Realm == tu-darmstadt.de,
Proxy-To-Realm := MyRealm
User-Name = `%{User-Name}`,Fall-Through = Yes
# matches requests going parent radius
DEFAULT FreeRADIUS-Proxied-To == 127.0.0.1, Realm == DEFAULT,
Proxy-To-Realm := Parent
User-Name = `%{User-Name}`,Fall-Through = Yes
...
Thanks a lot,
-Andreas
--
Andreas Liebe/Darmstadt University of Technology/+49 6151 16-3150/3050(FAX)
signature.asc
Description: This is a digitally signed message part
-
List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
Re: terminating EAP tunnels, proxy and realms
Hello Andreas, No we want to participate in inter University roaming (eduroam) and thus have to proxy some requests a parent server. Everything works great except regarding the outer identity. If it's just anonymous everything is ok, but if it's anonymous@somerealm and somerealm is configured in proxy.conf the EAP-Request ist proxied instead of terminated. This is correct by configuration but not wanted. Is there a way to terminate the EAP regardless of the outer identity? why do you want this. The EAP Tunnel should terminate on the last RADIUS where the user belongs. On your RADIUS only the EAP-Tunnels for your users should be terminating. Read http://www.dfn.de/content/fileadmin/1Dienstleistungen/GWIN/sonstiges/Konfiguration-freeradius.pdf it is for DFN-Roaming, but it is the same as EDUROAM. regards Helmut - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
