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@digriz.org.uk] Hi,
* Panagiotis Georgopoulos <panos@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