FW: Session Resumption fails

[Panagiotis Georgopoulos]

Forgot to mention that my FR's full log is here :
http://pastebin.com/VWEaYAhP 

Cheers,
Panos


> Hello Alexander, all,
> 
> 	Please see my comments inline...
> 
> 
> > From: Alexander Clouter [mailto:alex at digriz.org.uk]
> > Hi,
> >
> > * Panagiotis Georgopoulos <panos at comp.lancs.ac.uk> [2010-09-24
> > 22:33:14+0100]:
> > >
> > > 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 :
> > >
> > /me does not recall saying enable 'copy_request_to_tunnel = yes'.
> 
> With or without copy_request_to_tunnel enabled the outcome is the same
> I am afraid, i.e. although full EAP-TTLS authentication succeeds the
> end-client (not NAS) restarts EAP-TTLS authentication, when session
> resumption and use_tunneled_reply are enabled on FreeRadius.
> 
> (NB. when session resumption is off and use_tunneled_reply=no the full
> communication goes fine and the client completes the 4-way handshake
> after NAS gets EAP-Success).
> 
> 
> > > State: ASSOCIATED -> 4WAY_HANDSHAKE
> > > [snipped unread log]
> > > 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.
> > >
> > Have you considered comparing the difference in the RADIUS packets
> > going to-and-fro in both cases; the one where authentication works
> and the
> > one where it does not?  What do you see?
> >
> 
> Yes I did, although I mostly concentrated on the 4-way handshake of the
> client because this is where it is failing compared to without session
> resumption. The end-client does not follow up the 1st message of the 4-
> way handshake of the NAS, but decides to restart the full
> authentication.
> 
> (btw I was a bit more quick to send my previous email, because of the
> impeding release of 2.1.10 where it was said that with session
> resumption and use_tunneled_reply the session resumption should work,
> but in my tests it wasn't. I wanted to see whether there was a quick
> fix to be added to 2.1.10 before it gets released).
> 
> As to the packet communication between the NAS and FreeRadius, there is
> a change in the last packet (EAP-success) sent from FR to the NAS
> compared to when authentication succeeds. Firstly it has as User-Name
> attribute of the inner identity of the initial request and not the
> outer one (which shouldn't cause the problem according to rfc 2865) and
> secondly, it has MS-MPPE-Send-Key and MS-MPPE-Recv-Key *twice* which I
> am guessing is causing the problem (rfc2548 as pointed out by
> Alexander, helped me realize that). Why do they appear twice there, I
> 've got no idea.
> 
> Anyway, so what I thought to do is to go to the post-auth section of my
> inner-server and add the following to remove the MS-MPPE-Send-Key and
> MS-MPPE-Recv-Key attributes added by the inner-server and let the
> default add its own.
> 
> 	update reply {
> 		MS-MPPE-Recv-Key !* 0x00
> 		MS-MPPE-Send-Key !* 0x00
> 	}
> 
> Is the logic behind this fine or do you reckon it might break something
> else in the future?
> 
> The above solved the problem, in a sense, as now the end-client (pc)
> authenticates just fine and finishes the 4-way handshake with the NAS.
> However, session resumption still does not work. The server does add a
> cache entry with the following :
> 
> #Debug:   SSL: adding session
> 5705534d65ddd08de3b8649528274c1bc4e3d648bef7b643ffaf0f647afcac73 to
> cache
> #Info: [ttls]     (other): SSL negotiation finished successfully
> #Debug: SSL Connection Established
> 
> ..but it does this every time a client tries to authenticate and it
> never tries to really skip phase 2. I would really appreciate any ideas
> on how I should fix this.
> 
> Thanks a lot in advance,
> Panos
> 
> 
> 
>