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)
Hi, * Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> [2010-09-24 16:09:18+0100]:
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.
Trivially solved with some unlang. You actually need the User-Name in the outer layer, otherwise you would be unable to do any user-based authorisation (if that sort of thing is important).
When I test it I'll get back to you as I am guessing this interests more people.
In your 'post-auth' section add (and have some CUI action too): ---- post-auth { .... if ((request:Chargeable-User-Identity)) { update reply { # md5(cui_hash_key + user@realm) Chargeable-User-Identity := "%{md5:%{config:local.MY.cui_hash_key}%{reply:User-Name}}" } if (request:Chargeable-User-Identity != "\\000") { if (request:Chargeable-User-Identity != reply:Chargeable-User-Identity) { update reply { Reply-Message := "CUI Mismatch" } reject } } } # protect the guilty update reply { User-Name !* ANY } .... } ---- Cheers -- Alexander Clouter .sigmonster says: I brought my BOWLING BALL -- and some DRUGS!!
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
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'.
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? Most would suggest you look at section 3 of RFC2548... *sigh*
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....
Read Section 5.1 of RFC2865 before jumping to conclusions with no evidence...
Any easier solution?
I could think of some, but most are unprintable. Cheers -- Alexander Clouter .sigmonster says: For every vision there is an equal and opposite revision.
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
Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
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.
It's worth always running tcpdump on the RADIUS server and looking at what is spat out on the wire; can be easier than trawling the FreeRADIUS output when you need to compare two authentication runs. Handy as a initial pass to give you a hint at what is wrong.
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?
Remote 'eap' from the inner server, I think this is linked to your pap/mschap modules noop'ing as the request is already primed for passing to the eap module as eap is added additional MS-MPPE keys. If you need an inner-eap (say for EAP-GTC, but then we would need Alan to apply a patch to make GTC useful</grumble>) then you should place that *after* pap/chap/mschap iirc. Here is my inner-auth (the ldap bits I left there as you might be interested in them, however others might like the outer:Cleartext-Password 'override' and want to also palm the error handling): ---- server auth { authorize { if ((outer.request:EAP-Message)) { update outer.request { User-Name := "%{request:User-Name}" } update reply { User-Name := "%{request:User-Name}" } } validate_username suffix if ((outer.request:EAP-Message) && Realm != "%{config:local.MY.realm}") { update outer.reply { Reply-Message := "Realm is '%{Realm}' on Inside" } reject } # if the password is passed to us use it, otherwise yank it from LDAP if ((outer.request:Cleartext-Password)) { update control { Cleartext-Password := "%{outer.request:Cleartext-Password}" } } else { ldap-login # some accounts are glitched and do not have a UP :( if (ok && !(control:Cleartext-Password)) { update outer.reply { Reply-Message := "No eDirectory UP" } reject } } pap chap mschap update reply { Auth-Type := "%{control:Auth-Type}" } } authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MSCHAP { mschap } } } ---- Cheers -- Alexander Clouter .sigmonster says: The road to Hades is easy to travel. -- Bion
Hello Alexander, all, Please see inline. (snip)
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.
It's worth always running tcpdump on the RADIUS server and looking at what is spat out on the wire; can be easier than trawling the FreeRADIUS output when you need to compare two authentication runs. Handy as a initial pass to give you a hint at what is wrong.
I am running wireshark :-)
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?
Remote 'eap' from the inner server, I think this is linked to your pap/mschap modules noop'ing as the request is already primed for passing to the eap module as eap is added additional MS-MPPE keys.
So mschapv2 in the inner tunnel adds keys for the first time (I see an entry about that on the log) and you are saying that the eap adds additional keys? Why does it do that without checking if keys already exist as attributes in the packet? By the way it seems that the pair of keys added by mschapv2 are shorter than the eap ones and I am removing the mschav2 with the update reply as above in a post-auth.
If you need an inner-eap (say for EAP-GTC, but then we would need Alan to apply a patch to make GTC useful</grumble>) then you should place that *after* pap/chap/mschap iirc.
Here is my inner-auth (the ldap bits I left there as you might be interested in them, however others might like the outer:Cleartext-Password 'override' and want to also palm the error handling): ---- server auth { authorize { if ((outer.request:EAP-Message)) { update outer.request { User-Name := "%{request:User-Name}" } update reply { User-Name := "%{request:User-Name}" } }
validate_username
suffix
if ((outer.request:EAP-Message) && Realm != "%{config:local.MY.realm}") { update outer.reply { Reply-Message := "Realm is '%{Realm}' on Inside" } reject }
# if the password is passed to us use it, otherwise yank
it
from LDAP if ((outer.request:Cleartext-Password)) { update control { Cleartext-Password := "%{outer.request:Cleartext-Password}" } } else { ldap-login
# some accounts are glitched and do not have a UP :( if (ok && !(control:Cleartext-Password)) { update outer.reply { Reply-Message := "No eDirectory UP" } reject } }
pap chap mschap
update reply { Auth-Type := "%{control:Auth-Type}" } }
authenticate { Auth-Type PAP { pap } Auth-Type CHAP { chap } Auth-Type MSCHAP { mschap } } }
That is very interesting! I think though from the above, the only thing that I need is your first if in my authorize section (right?). However the problem now does not seem to lie in the fact that openssl does not add entries in the cache, I see the following in every coming request ; #Debug: SSL: adding session 5705534d65ddd08de3b8649528274c1bc4e3d648bef7b643ffaf0f647afcac73 to cache ... what I never ever see though is to try and do session resumption (i.e. see "Skipping Phase2 due to session resumption"). How can I fix/debug that? Is anyone using session resumption successfully in 2.1.10? Thanks a lot, Panos
Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
#Debug: SSL: adding session 5705534d65ddd08de3b8649528274c1bc4e3d648bef7b643ffaf0f647afcac73 to cache
... what I never ever see though is to try and do session resumption (i.e. see "Skipping Phase2 due to session resumption"). How can I fix/debug that?
Is anyone using session resumption successfully in 2.1.10?
Sorry for the late reply, just tested it now and it works fine for me in 2.1.10. ---- Found Auth-Type = EAP # Executing group from file /etc/freeradius/sites-enabled/lanwarden +- entering group EAP {...} [EAP] Request found, released from the list [EAP] EAP/ttls [EAP] processing type ttls [ttls] Authenticate [ttls] processing EAP-TLS [ttls] eaptls_verify returned 7 [ttls] Done initial handshake [ttls] <<< TLS 1.0 ChangeCipherSpec [length 0001] [ttls] <<< TLS 1.0 Handshake [length 0010], Finished [ttls] TLS_accept: SSLv3 read finished A [ttls] (other): SSL negotiation finished successfully SSL Connection Established SSL Application Data [ttls] eaptls_process returned 3 [ttls] Skipping Phase2 due to session resumption [ttls] Adding cached attributes to the reply: User-Name = "ac56@soas.ac.uk" Stripped-User-Name = "" [EAP] Freeing handler ++[EAP] returns ok [snipped] [detail.lanwarden] expand: /var/log/freeradius/radacct/detail.lanwarden.%Y%m%d -> /var/log/freeradius/radacct/detail.lanwarden.20101005 [detail.lanwarden] /var/log/freeradius/radacct/detail.lanwarden.%Y%m%d expands to /var/log/freeradius/radacct/detail.lanwarden.20101005 [detail.lanwarden] expand: %t (%{Packet-Src-IP-Address}:%{Packet-Src-Port} -> %{Packet-Dst-IP-Address}:%{Packet-Dst-Port}) -> Tue Oct 5 10:19:28 2010 (172.16.3.124:32768 -> 212.219.238.4:1812) ++[detail.lanwarden] returns ok } # server lanwarden Sending Access-Accept of id 23 to 172.16.3.124 port 32768 Session-Timeout = 30 Termination-Action = RADIUS-Request MS-MPPE-Send-Key = <trim> Tunnel-Medium-Type:0 = IEEE-802 Tunnel-Type:0 = VLAN Operator-Name = "1soas.ac.uk" Message-Authenticator = 0x00000000000000000000000000000000 Acct-Interim-Interval = 600 User-Name = "ac56@soas.ac.uk" MS-MPPE-Recv-Key = <trim> EAP-Message = 0x03030004 Tunnel-Private-Group-Id:0 = "" Finished request 11. ---- Cheers -- Alexander Clouter .sigmonster says: Robustness, adj.: Never having to say you're sorry.
Hi Alexander, all, Please see below...
Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> wrote:
#Debug: SSL: adding session 5705534d65ddd08de3b8649528274c1bc4e3d648bef7b643ffaf0f647afcac73 to cache ... what I never ever see though is to try and do session
resumption
(i.e. see "Skipping Phase2 due to session resumption"). How can I fix/debug that?
Is anyone using session resumption successfully in 2.1.10?
Sorry for the late reply, just tested it now and it works fine for me in 2.1.10.
(snip)
Thanks for your reply Alexander, that is very helpful. After a lot of days over weeks of testing I found it impossible to make session resumption to work on 2.1.10 no matter the changes I did in my configuration files :-/ I am not sure, but judging from the outcome it seems that the exact version of OpenSSL I am running is to blame here. The machine I am running FR on, was running OpenSSL 0.9.8g and when I moved to 0.9.8k session resumption started working. I am still debugging this though... What version of OpenSSL are you running on your FR? (By the way, from a previous post in the list it is suggested that if both server and client run OpenSSL version 0.9.8j or later then stateless session resumption can be supported. Incidentally my end-client still runs 0.9.8g) I am having use_tunneled_reply enabled and now I do not have to do update reply to let SSL know about the User-Name of the inner-tunnel as the aforementioned option does it form me. However, as I have mentioned in the past, in my Access-Accept reply I see *two* pairs of MPPE keys (Send and Rec twice), and I have to remove them in post-auth of inner-tunnel with the following : update reply { MS-MPPE-Recv-Key !* 0x00 MS-MPPE-Send-Key !* 0x00 } Am I guessing right that you don't experience the above because you use LDAP? I am still trying to figure out why the extra pair of keys appear in the packet and whether I could configure FR not to add them in the first place instead of removing them.... I will try also to check if session resumption works in EAP-TLS in my current setup to see what happens. Thanks for your feedback. Cheers, Panos PS. If you care for a debug output here it is : http://pastebin.com/M0EQTi4q (i highlighted the relevant bits for easier read)
participants (2)
-
Alexander Clouter -
Panagiotis Georgopoulos