Problems with "virtual_server" for EAP-pwd
Hi all! For our eduroam setup we use FreeRADIUS to authenticate EAP-TTLS, PEAP as well as EAP-pwd requests. For each of these EAP types you have to configure the "virtual_server" which deals with the tunneled authentication (which is a little odd with respect to EAP-pwd because it isn't a tunneled method). Within the "inner-tunnel*" virtual servers we connect to an LDAP server to get the user credentials and RADIUS attributes that are associated with a specific user. Furthermore, we call a policy in the authorize section that is defined in policy.d/ that simply checks whether a certain attribute is set to "yes" or "no". The check basically looks like this: if ( ...<some check>... ) { reject } This works nicely with the inner-tunnel virtual servers that are used for EAP-TTLS and PEAP. It basically looks like this if the check yields a reject: 11) if (...<some check>...) { (11) [reject] = reject (11) } # if (...<some check>...) = reject (11) } # policy XXXX = reject (11) } # authorize = reject (11) Using Post-Auth-Type Reject (11) # Executing group from file /etc/freeradius/sites-enabled/inner-tunnel (11) Post-Auth-Type REJECT { ... (11) } # Post-Auth-Type REJECT = updated (11) } # server inner-tunnel (11) Virtual server sending reply This reject is forwarded to the outer session and this works as expected. However, it doesn't work with the inner-tunnel virtual server that we use for EAP-pwd. Please note that the configuration is virtually identical (except that you obviously don't need inner authentications methods for EAP-pwd). You basically get debugging output that looks like this: (2) if (...<some check>...) { (2) [reject] = reject (2) } # if (...<some check>...) = reject (2) } # policy XXXX = reject (2) } # authorize = reject (2) eap_pwd: } # server inner-tunnel-eap-pwd (2) eap_pwd: Got tunneled reply code 0 It looks like the eap_pwd module doesn't receive the reject generated within the authorize section of the inner-tunnel virtual server. Please note that EAP-pwd authentication per se works without any problems. Furthermore, I perfectly understand that only the authorize section of the inner-tunnel virtual server is used by EAP-pwd anyhow (it's simply used to retrieve credentials). However, it's not clear to me why the exact same configuration works for EAP-TTLS / PEAP but not for EAP-pwd because other things that we do within the authorize section (like setting RADIUS attributes that are used in the outer session etc.) work. I was thinking about working around the problem by doing something like update outer.session-state { ... } to generate a reject within the outer session. Do you have any suggestions what the right way would be to work around this? Apart from a workaround, do you think this could be a bug in the EAP-pwd module? I tried to read the source code but I'm not a programmer and I couldn't figure out how the EAP-pwd module works differently from the EAP-TTLS and PEAP modules with respect to how it works with inner-tunnel virtual servers. Any help would be highly appreciated. Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Clausthal Univ. of Technology E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld
P.S.: I'm sorry, I forgot to write that we're using FreeRADIUS 3.0.12. Am 27. März 2017 4:16:35 nachm. schrieb Christian Strauf <strauf@rz.tu-clausthal.de>:
Hi all!
For our eduroam setup we use FreeRADIUS to authenticate EAP-TTLS, PEAP as well as EAP-pwd requests. For each of these EAP types you have to configure the "virtual_server" which deals with the tunneled authentication (which is a little odd with respect to EAP-pwd because it isn't a tunneled method). Within the "inner-tunnel*" virtual servers we connect to an LDAP server to get the user credentials and RADIUS attributes that are associated with a specific user. Furthermore, we call a policy in the authorize section that is defined in policy.d/ that simply checks whether a certain attribute is set to "yes" or "no". The check basically looks like this:
if ( ...<some check>... ) { reject }
This works nicely with the inner-tunnel virtual servers that are used for EAP-TTLS and PEAP. It basically looks like this if the check yields a reject:
11) if (...<some check>...) { (11) [reject] = reject (11) } # if (...<some check>...) = reject (11) } # policy XXXX = reject (11) } # authorize = reject (11) Using Post-Auth-Type Reject (11) # Executing group from file /etc/freeradius/sites-enabled/inner-tunnel (11) Post-Auth-Type REJECT { ... (11) } # Post-Auth-Type REJECT = updated (11) } # server inner-tunnel (11) Virtual server sending reply
This reject is forwarded to the outer session and this works as expected. However, it doesn't work with the inner-tunnel virtual server that we use for EAP-pwd. Please note that the configuration is virtually identical (except that you obviously don't need inner authentications methods for EAP-pwd). You basically get debugging output that looks like this:
(2) if (...<some check>...) { (2) [reject] = reject (2) } # if (...<some check>...) = reject (2) } # policy XXXX = reject (2) } # authorize = reject (2) eap_pwd: } # server inner-tunnel-eap-pwd (2) eap_pwd: Got tunneled reply code 0
It looks like the eap_pwd module doesn't receive the reject generated within the authorize section of the inner-tunnel virtual server. Please note that EAP-pwd authentication per se works without any problems. Furthermore, I perfectly understand that only the authorize section of the inner-tunnel virtual server is used by EAP-pwd anyhow (it's simply used to retrieve credentials). However, it's not clear to me why the exact same configuration works for EAP-TTLS / PEAP but not for EAP-pwd because other things that we do within the authorize section (like setting RADIUS attributes that are used in the outer session etc.) work. I was thinking about working around the problem by doing something like
update outer.session-state { ... }
to generate a reject within the outer session. Do you have any suggestions what the right way would be to work around this? Apart from a workaround, do you think this could be a bug in the EAP-pwd module? I tried to read the source code but I'm not a programmer and I couldn't figure out how the EAP-pwd module works differently from the EAP-TTLS and PEAP modules with respect to how it works with inner-tunnel virtual servers. Any help would be highly appreciated.
Kind regards, Christian Strauf -- Dipl.-Math. Christian Strauf Clausthal Univ. of Technology E-Mail: strauf@rz.tu-clausthal.de Rechenzentrum Web: www.rz.tu-clausthal.de Erzstraße 18 Tel.: +49-5323-72-2086 Fax: -992086 D-38678 Clausthal-Zellerfeld
Hi,
P.S.: I'm sorry, I forgot to write that we're using FreeRADIUS 3.0.12.
run it in full debug mode (radiusd -X) and look at the packet flow for the client. you will see the key differences bewteen an inner-tunnel method (eg PEAP) and EAP-PWD - I think you'd face the same issue with EAP-TLS - as you already says, and the debug output will show the flow - inner-tunnel is not called because its not used for that method - look at the eap module config that does all this - for TTLS and PEAP you tell the server about inner-tunnel, so it uses it..... alan
run it in full debug mode (radiusd -X) and look at the packet flow for the client. you will see the key differences bewteen an inner-tunnel method (eg PEAP) and EAP-PWD - I think you'd face the same issue with EAP-TLS - as you already says, and the debug output will show the flow - inner-tunnel is not called because its not used for that method - look at the eap module config that does all this - for TTLS and PEAP you tell the server about inner-tunnel, so it uses it..... Well, that's exactly my point. You do have to configure an inner tunnel for EAP-pwd and the authorize section of the inner tunnel is actually called and you can do stuff within the authorize section of the inner tunnel, however, when you do something that updates the request with a reject, that reject is not used by the outer session. Or maybe I'm misunderstanding what you mean.
Christian
On Mar 27, 2017, at 10:14 AM, Christian Strauf <strauf@rz.tu-clausthal.de> wrote:
For our eduroam setup we use FreeRADIUS to authenticate EAP-TTLS, PEAP as well as EAP-pwd requests. For each of these EAP types you have to configure the "virtual_server" which deals with the tunneled authentication (which is a little odd with respect to EAP-pwd because it isn't a tunneled method).
The comments in the configuration for EAP-PWD explain why this is done. They also explain how it works.
Within the "inner-tunnel*" virtual servers we connect to an LDAP server to get the user credentials and RADIUS attributes that are associated with a specific user.
The documentation for the EAP-PWD method says that for it's inner-tunnel, only the "authorize" section is run, and the only purpose of the "authorize" is to obtain the password for the user. i.e. the inner-tunnel reply isn't used for anything. So you shouldn't get any RADIUS attributes associated with a user.
It looks like the eap_pwd module doesn't receive the reject generated within the authorize section of the inner-tunnel virtual server. Please note that EAP-pwd authentication per se works without any problems. Furthermore, I perfectly understand that only the authorize section of the inner-tunnel virtual server is used by EAP-pwd anyhow (it's simply used to retrieve credentials). However, it's not clear to me why the exact same configuration works for EAP-TTLS / PEAP but not for EAP-pwd
The EAP-TTLS "inner-tunnel" behaves in one way, and is documented as behaving that way. The EAP-PWD "inner-tunnel" behaves in a different way, and is documented as behaving that way. That should be clear.
because other things that we do within the authorize section (like setting RADIUS attributes that are used in the outer session etc.) work. I was thinking about working around the problem by doing something like
update outer.session-state { ... }
to generate a reject within the outer session.
Or, as per the EAP-PWD documentation... just don't return a password in the inner tunnel?
Do you have any suggestions what the right way would be to work around this?
Read the documentation and believe it. Don't configure the server based on how you *think* it might work. Configure the server based on how it *actually* works, and how it's documented as working.
Apart from a workaround, do you think this could be a bug in the EAP-pwd module?
It's behaving as documented.
I tried to read the source code but I'm not a programmer and I couldn't figure out how the EAP-pwd module works differently from the EAP-TTLS and PEAP modules with respect to how it works with inner-tunnel virtual servers. Any help would be highly appreciated.
The behaviour difference is documented. If you want to get reply attributes for a user, put the rules into the "post-auth" section of the outer tunnel. Alan DeKok.
Hi Alan,
i.e. the inner-tunnel reply isn't used for anything. So you shouldn't get any RADIUS attributes associated with a user. thanks for clearing that up.
Or, as per the EAP-PWD documentation... just don't return a password in the inner tunnel? Ok, thanks for the advice. Can you point me to the doc that you're referring to? I only found
http://networkradius.com/doc/3.0.10/raddb/mods-available/eap/pwd.html and it says that the the whole authorize section is processed (see bottom of the doc) which led me to believe that unlang passages are processed as well. Sorry for the confusion.
If you want to get reply attributes for a user, put the rules into the "post-auth" section of the outer tunnel. We get a "known good" password from an OpenLDAP server in the inner tunnel. The same LDAP search for the user id to retrieve the "known good" password also yields other RADIUS attributes. Do I understand you correctly that one shouldn't use the returned other attributes to update the outer session? Would that be a misuse of the EAP-pwd inner tunnel authorize section?
Thanks for shedding light on this. Kind regards, Christian
On Mar 27, 2017, at 11:38 AM, Christian Strauf <strauf@rz.tu-clausthal.de> wrote:
Ok, thanks for the advice. Can you point me to the doc that you're referring to?
See the comments in the EAP module, the "pwd" section.
I only found
http://networkradius.com/doc/3.0.10/raddb/mods-available/eap/pwd.html
and it says that the the whole authorize section is processed (see bottom of the doc) which led me to believe that unlang passages are processed as well. Sorry for the confusion.
All of the "authorize" section is processed, *but* only the Cleartext-Password is taken from the output.
If you want to get reply attributes for a user, put the rules into the "post-auth" section of the outer tunnel. We get a "known good" password from an OpenLDAP server in the inner tunnel. The same LDAP search for the user id to retrieve the "known good" password also yields other RADIUS attributes.
Then do that in the "authorize" section. EAP-PWD is more like EAP-MD5 than it's like PEAP.
Do I understand you correctly that one shouldn't use the returned other attributes to update the outer session?
I didn't say that. It does work. There is no magic in the server. You can always update an outer session from an inner one.
Would that be a misuse of the EAP-pwd inner tunnel authorize section?
<shrug> If it works... Alan DeKok.
All of the "authorize" section is processed, *but* only the Cleartext-Password is taken from the output. Ok, makes sense and that's also the way I understood the comment in the configuration file.
Then do that in the "authorize" section. EAP-PWD is more like EAP-MD5 than it's like PEAP. Yes, indeed. I intended to minimise the amount of LDAP searches by copying the RADIUS attributes from the inner tunnel LDAP search (which is mandatory in our scenario to retrieve the known good password) to the outer session so that I wouldn't have to search in the outer session once and then another time in the inner tunnel. The copying of the attributes works nicely.
Do I understand you correctly that one shouldn't use the returned other attributes to update the outer session?
I didn't say that. It does work. There is no magic in the server. You can always update an outer session from an inner one. Ok, that's good. This means that I only need to move the policy snippet from the inner tunnel authorize section to a different section (as you suggested earlier). By asking I just wanted to make sure that updating the outer session from the EAP-pwd inner tunnel section is ok.
Thanks for your help, I think I can fix my problem with your advice. Cheers, Christian
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Christian Strauf