Session Resumption fails

[Panagiotis Georgopoulos]

Hi Alexander, all

	Thanks a lot for your reply. Please see my comments below...


> Panagiotis Georgopoulos <panos at 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