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