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.