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:[email protected]] > > Hi, > > > > * Panagiotis Georgopoulos <[email protected]> [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 > > > > - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
