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@lists.freeradius.org [mailto:freeradius- users-bounces+panos=comp.lancs.ac.uk@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@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@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