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@" and 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
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
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=, 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 ) at event.c:2174
#5 0x80019fe6 in thread_pool_addrequest (request=0x80280840,
fun=0x80006b10 ) 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
> > 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: SRV(outer): Access-Request [EMAIL PROTECTED] SRV(inner): Access-Accept [EMAIL PROTECTED] SRV: 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
