Hello all, I have a client machine that authenticates to FreeRadius using EAP-TTLS over Access_Point_1 just fine. When I roam the client to Access_Point_2 and tries to authenticate again to FreeRadius, session resumption seems to be failing with the following error. Wed Sep 22 22:35:16 2010 : Debug: SSL Connection Established Wed Sep 22 22:35:16 2010 : Debug: SSL Application Data Wed Sep 22 22:35:16 2010 : Info: [ttls] eaptls_process returned 3 Wed Sep 22 22:35:16 2010 : Info: [ttls] Skipping Phase2 due to session resumption Wed Sep 22 22:35:16 2010 : Info: [ttls] WARNING: No information in cached session! Wed Sep 22 22:35:16 2010 : Info: [eap] Freeing handler Wed Sep 22 22:35:16 2010 : Info: ++[eap] returns reject Wed Sep 22 22:35:16 2010 : Info: Failed to authenticate the user. Wed Sep 22 22:35:16 2010 : Info: Using Post-Auth-Type Reject Wed Sep 22 22:35:16 2010 : Info: +- entering group REJECT {...} Wed Sep 22 22:35:16 2010 : Info: [attr_filter.access_reject] expand: %{User-Name} -> anonymous One thing to note on the above is that there is no cached information, which seems strange as the client was authenticated some minutes over Access_Point_1. The other thing is that user authentication fails completely and the client resides to restart EAP-TTLS from the start that finishes successfully. Do you have any ideas/pointes on how to fix this make session resumption to work propery? Thanks a lot in advance, Panos
Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
I have a client machine that authenticates to FreeRadius using EAP-TTLS over Access_Point_1 just fine. When I roam the client to Access_Point_2 and tries to authenticate again to FreeRadius, session resumption seems to be failing with the following error.
[snipped]
One thing to note on the above is that there is no cached information, which seems strange as the client was authenticated some minutes over Access_Point_1. The other thing is that user authentication fails completely and the client resides to restart EAP-TTLS from the start that finishes successfully.
The session cache stores what is in the *reply* packet of the inner request (if that makes sense). In your eap.conf file, you refer to a virtual server to palm off requests to once the EAP layer has been peeled off. In that virtual server say in the authorize{} section: ---- update reply { User-Name := "%{request:User-Name}" } ---- Now you will find on resumption the username appears magically; session resumption is a feature of SSL/TLS and so the user-name is not accessible; hence the need to dig into the cache. I also recommend that you also do: ---- update outer.request { User-Name := "%{request:User-Name}" } ---- This means that when the authentication fails (as a quirk of the inner session, post-auth{} and the whole reply packet is no available when an inner request Reject's) you have access to the username that was used. Cheers -- Alexander Clouter .sigmonster says: And on the eighth day, we bulldozed it.
Hi Alexander, all Thanks a lot for your reply. Please see my comments below...
Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
I have a client machine that authenticates to FreeRadius using EAP-TTLS over Access_Point_1 just fine. When I roam the client to Access_Point_2 and tries to authenticate again to FreeRadius, session resumption seems to be failing with the following error.
[snipped]
One thing to note on the above is that there is no cached information, which seems strange as the client was authenticated some minutes over Access_Point_1. The other thing is that user authentication fails completely and the client resides to restart EAP-TTLS from the start that finishes successfully.
The session cache stores what is in the *reply* packet of the inner request (if that makes sense).
Hmm, yes I think I do. So the server keeps the reply of an authentication and therefore if a client has authenticated successfully before, there should be a valid entry of his identity in the cache so that Phase 2 of TTLS in my case would be skipped.
In your eap.conf file, you refer to a virtual server to palm off requests to once the EAP layer has been peeled off. In that virtual server say in the authorize{} section: ---- update reply { User-Name := "%{request:User-Name}" } ----
Now you will find on resumption the username appears magically; session resumption is a feature of SSL/TLS and so the user-name is not accessible; hence the need to dig into the cache.
Residing in the cache, seems reasonable since it is a feature of SSL/TLS. What I don't get is that since this is a standard EAP-TTLS authentication, shouldn't resumption be working out of the box? So, if full authentication *succeeds* for a client once, then there should be a cache entry reflecting that so that he won't have to perform full EAP-TTLS communication if he requests access within the lifetime that the cache entry is valid (in eap.conf terms ; lifetime = 24 # hours). In my tests thought I get "Info: [ttls] WARNING: No information in cached session!".
I also recommend that you also do: ---- update outer.request { User-Name := "%{request:User-Name}" } ----
This means that when the authentication fails (as a quirk of the inner session, post-auth{} and the whole reply packet is no available when an inner request Reject's) you have access to the username that was used.
Oh.. wait a minute, unless you mean that there is no way for the inner session, post-auth{} to know the contents of the server's reply in a previous authentication, which seems like a design flow. Would adding the outer.request part that you suggested add an entry in the cache for a successful auth of the inner session? Cheers, Panos
Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
Hmm, yes I think I do. So the server keeps the reply of an authentication and therefore if a client has authenticated successfully before, there should be a valid entry of his identity in the cache so that Phase 2 of TTLS in my case would be skipped.
FreeRADIUS asks the OpenSSL library to store some 'opaque' data so that if a session can be resumed, then OpenSSL will make this data available to FreeRADIUS which will convert it back into RADIUS attributes (for the inner 'reply' message). When FreeRADIUS grumblesthere is nothing in the cache session, it usually means "inner auth succeeded but you have no idea who the user is"; as typically all you want OpenSSL to return (from the *opaque* string of bytes) to FreeRADIUS is the 'User-Name'. Remember your inner User-Name does not match your outer one (which should be '@example.com'); if you do VLAN assignment based on inner username (rather than MAC address) then you need this data.
Residing in the cache, seems reasonable since it is a feature of SSL/TLS. What I don't get is that since this is a standard EAP-TTLS authentication, shouldn't resumption be working out of the box?
Well for it to work you really need to ask OpenSSL to store something like the User-Name otherwise you will find for the first (non-resumption) authentication things work, but for the second one authentication succeeds but the *authorisation* fails as your unlang/users policy has no idea what VLAN to assign as you need to know the inner User-Name attribute.
In my tests thought I get "Info: [ttls] WARNING: No information in cached session!".
As if you read what I said, you are *not* telling the inner virtual server to return in the reply packet the inner username.
I also recommend that you also do: ---- update outer.request { User-Name := "%{request:User-Name}" } ----
This means that when the authentication fails (as a quirk of the inner session, post-auth{} and the whole reply packet is no available when an inner request Reject's) you have access to the username that was used.
Oh.. wait a minute, unless you mean that there is no way for the inner session, post-auth{} to know the contents of the server's reply in a previous authentication, which seems like a design flow.
*sigh* Think about what is going on and that RADIUS is a *stateless* system. If you want state, put that state into a persistant database.
Would adding the outer.request part that you suggested add an entry in the cache for a successful auth of the inner session?
Reading what I wrote would probably help more.... Just do as I suggested in my previous email and look at the output of 'freeradius -X'. Cheers -- Alexander Clouter .sigmonster says: Alex Haley was adopted!
participants (2)
-
Alexander Clouter -
Panagiotis Georgopoulos