FW: Session Resumption fails

[Panagiotis Georgopoulos]

Hello all,

	I am resending this to the list as the debugging output was more
than 100KB and the message was rejected. 

	Alexander who was copied in my email, kindly provided feedback
already. In short, "use_tunneled_reply = yes" should be able to solve the
problem with session resumption in FR 2.1.10, although I understand that
break the end client's privacy as it reveals its identity to the NAS.

	When I test it I'll get back to you as I am guessing this interests
more people. 

	Cheers,
	Panos


Debug output here : http://pastebin.com/7u1tjbYE 



> -----Original Message-----
> From: Panagiotis Georgopoulos [mailto:panos at comp.lancs.ac.uk]
> Sent: Friday, September 24, 2010 04:17
> To: 'FreeRadius users mailing list'; 'Alexander Clouter'
> Subject: RE: Session Resumption fails
> 
> Hi Alexander, all
> 
> 	Thanks a lot for your reply, it helped my understanding of what is
> occurring. Please see below for my comments.
> 
> >
> > 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).
> >
> > 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}"
> > }
> > ----
> 
> I am afraid your suggestion though to add the above in my inner-tunnel
virtual
> server didn't solve the problem. After having searched the archives of the
> list, I found out that this is an OpenSSL bug and there is a fix in
FreeRadius
> 2.1.10 for it.
> 
> I just compiled 2.1.10 and I verify that I don't see resuming sessions
failing
> with this no information in the cache :
> 
> Info: [ttls] Skipping Phase2 due to session resumption
> Info: [ttls] WARNING: No information in cached session!
> 
> However, I am not seeing the correct behaviour either :-/
> 
> I am seeing the server adding information in the cache :
> 
> - Debug:   SSL: adding session
> 1d6029bbddba233cd443d692b968df093237d9ad982f9ccc8a2defcd3edeb243 to cache
> - Info: [ttls]     (other): SSL negotiation finished successfully
> - Debug: SSL Connection Established
> 
> .. but it *never* says that it tries to e.g. skip phase 2 and try
resumption
> (as I was seeing with FR 2.1.8).
> 
> However in some occasions it says :
> 
> - Info: [ttls] WARNING: No information to cache: session caching will be
> disabled for this session.
> - Debug:   SSL: Removing session
> 69c204b29e84878591c19645ed74c1ff4b656c30f66adad78d268df65d2e1d14 from the
> cache
> 
>  Does anyone have any pointers/suggestions? Anyone who managed to do
session
> resumption with 2.1.10?
> 
> 	Thanks a lot in advance,
>       Panos
> 
> 
> Ps. By the way, you can find attached my radiusd debugging output with a
> client trying to authenticate over different NASs. All authentications
> succeed, and info in the cache is stored, but FR never resumes a session.
> (nb. in the attached debug, I am restarting my NASs first before the
client
> starts roaming from one NAS to the other using EAP-TTLS)
>