Session Resumption fails

Fri Sep 24 23:33:14 CEST 2010

Hello Alexander, all,

	I wish it was that simple! It seems that when I do
"use_tunneled_reply = yes" and although the authentication with FR succeeds,
the 4-way handshake between the client (wpa_supplicant 0.7.3) and the access
point (hostapd 0.7.2) fails with wpa_supplicant reporting : 

State: ASSOCIATED -> 4WAY_HANDSHAKE
WPA: RX message 1 of 4-Way Handshake from 00:14:6c:2d:00:85 (ver=2)
RSN: msg 1/4 key data - hexdump(len=22): dd 14 00 0f ac 04 bc cf 0e 3e 42 3c
4f c5 2c 18 fc 7d 5e 39 b2 8a
WPA: PMKID in EAPOL-Key - hexdump(len=22): dd 14 00 0f ac 04 bc cf 0e 3e
42 3c 4f c5 2c 18 fc 7d 5e 39 b2 8a
RSN: PMKID from Authenticator - hexdump(len=16): bc cf 0e 3e 42 3c 4f c5 2c
18 fc 7d 5e 39 b2 8a
RSN: no matching PMKID found
EAPOL: Successfully fetched key (len=32)
WPA: PMK from EAPOL state machines - hexdump(len=32): [REMOVED]
RSN: added PMKSA cache entry for 00:14:6c:2d:00:85
RSN: no PMKSA entry found - trigger full EAP authentication
RSN: Do not reply to msg 1/4 - requesting full EAP authentication RX
ctrl_iface - hexdump_ascii(len=4):
     50 49 4e 47                                       PING
RX EAPOL from 00:14:6c:2d:00:85
RX EAPOL - hexdump(len=25): 02 00 00 15 01 f2 00 15 01 68 65 6c 6c 6f 2d 50
41 4e 4f 53 2d 41 50 2d 32
EAPOL: Received EAP-Packet frame

	It seems that the Access Point realizes that the identity in FR's
reply has changed (from the outer identity to the inner one) and somehow the
client doesn't like this and doesn't reply to the 1st message of the 4th way
handshake. Instead it sends an EAPOL start message and a full authentication
restarts with the same outcome.. and then again and again.

	It seems that using unlang to change the reply to the outer identity
of the initial request is not just for not revealing the privacy of the
client but seems to be mandatory....

	Any easier solution?

	Thanks a lot,
	Panos

NB. for what is worth : 

.	Wpa supplicant output : http://pastebin.com/4xSPt0k3  
.	Hostapd output : http://pastebin.com/Xnb0TF2q  
.	FreeRadius output: http://pastebin.com/p1V1XEVm  

> -----Original Message-----
> From: freeradius-users-
> bounces+panos=comp.lancs.ac.uk at lists.freeradius.org [mailto:freeradius-
> users-bounces+panos=comp.lancs.ac.uk at lists.freeradius.org] On Behalf Of
> Panagiotis Georgopoulos
> Sent: 24 September 2010 16:09
> To: 'FreeRadius users mailing list'
> Cc: 'Alexander Clouter'
> Subject: FW: Session Resumption fails
> 
> 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)
> >
> 
> 
> 
> -
> List info/subscribe/unsubscribe? See
> http://www.freeradius.org/list/users.html