Session Resumption fails

[Panagiotis Georgopoulos]

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