Hi, * Panagiotis Georgopoulos <panos@comp.lancs.ac.uk> [2010-09-24 04:17:16+0100]:
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.
A quick history lesson of this... That bug was more linked to OpenSSL actually authenticating sessions it should not if I remember correctly. https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=15 https://bugs.freeradius.org/bugzilla/show_bug.cgi?id=21 As a result, as the OpenSSL folk were being awkward and claiming without explaination that FreeRADIUS was at fault, Alan added a check to only accept session resumption if there is some cached information returned. Then, along came Andreas Hartmann, who in spite of us all saying "give up, it's openssl at fault and no one is helping out" stumbled upon: http://lists.freeradius.org/mailman/htdig/freeradius-users/2010-June/msg0016...
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 :-/
[snipped]
Does anyone have any pointers/suggestions? Anyone who managed to do session resumption with 2.1.10?
Fri Sep 24 03:03:10 2010 : Debug: Module: Linked to module rlm_eap Fri Sep 24 03:03:10 2010 : Debug: Module: Instantiating module "eap" from file /usr/local/etc/raddb/eap.conf Fri Sep 24 03:03:10 2010 : Debug: eap { Fri Sep 24 03:03:10 2010 : Debug: default_eap_type = "md5" Fri Sep 24 03:03:10 2010 : Debug: timer_expire = 60 Fri Sep 24 03:03:10 2010 : Debug: ignore_unknown_eap_types = no Fri Sep 24 03:03:10 2010 : Debug: cisco_accounting_username_bug = no Fri Sep 24 03:03:10 2010 : Debug: max_sessions = 4096 Fri Sep 24 03:03:10 2010 : Debug: } [snipped] Fri Sep 24 03:03:10 2010 : Debug: Module: Linked to sub-module rlm_eap_ttls Fri Sep 24 03:03:10 2010 : Debug: Module: Instantiating eap-ttls Fri Sep 24 03:03:10 2010 : Debug: ttls { Fri Sep 24 03:03:10 2010 : Debug: default_eap_type = "md5" Fri Sep 24 03:03:10 2010 : Debug: copy_request_to_tunnel = no Fri Sep 24 03:03:10 2010 : Debug: use_tunneled_reply = no Fri Sep 24 03:03:10 2010 : Debug: virtual_server = "inner-tunnel" Fri Sep 24 03:03:10 2010 : Debug: include_length = yes Fri Sep 24 03:03:10 2010 : Debug: }
use_tunneled_reply = yes
Fri Sep 24 03:03:10 2010 : Info: Ready to process requests. rad_recv: Accounting-Request packet from host 2001:db93::2 port 37783, id=15, length=102 Acct-Status-Type = Accounting-Off Acct-Authentic = RADIUS NAS-IPv6-Address = 2001:db93::2 NAS-Identifier = "panosAP-MR2" Called-Station-Id = "00-1C-F0-9D-22-FF:panos_secure2" Acct-Terminate-Cause = NAS-Reboot Fri Sep 24 03:03:21 2010 : Info: # Executing section preacct from file /usr/local/etc/raddb/sites-enabled/default Fri Sep 24 03:03:21 2010 : Info: +- entering group preacct {...} Fri Sep 24 03:03:21 2010 : Info: ++[preprocess] returns ok
Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute NAS-Port was not found in request, unique ID MAY be inconsistent Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute Client-IP-Address was not found in request, unique ID MAY be inconsistent Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute NAS-IP-Address was not found in request, unique ID MAY be inconsistent Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute Acct-Session-Id was not found in request, unique ID MAY be inconsistent Fri Sep 24 03:03:21 2010 : Info: [acct_unique] WARNING: Attribute User-Name was not found in request, unique ID MAY be inconsistent Fri Sep 24 03:03:21 2010 : Info: [acct_unique] Hashing ',,,,' Fri Sep 24 03:03:21 2010 : Info: [acct_unique] Acct-Unique-Session-ID = "bfabf462b52fda97".
As a non-SSL resumption issue, this is going to cause you pain. I recommend in your 'acct_unique' module, the value of 'key' is changed to something like (obviously change to what you think is best): ---- acct_unique { key = "User-Name, Acct-Session-Id, NAS-IP-Address, NAS-Port, NAS-IPv6-Address, Packet-Src-IP-Address, Packet-Src-IPv6-Address, Called-Station-Id, Calling-Station-Id" } ---- The use of 'Client-IP-Address' is actually a bug...in FreeRADIUS (as it is a depreated attribute).
Fri Sep 24 03:03:58 2010 : Debug: Going to the next request Fri Sep 24 03:03:58 2010 : Info: Ready to process requests. rad_recv: Access-Request packet from host 2001:db94::2 port 53023, id=1, length=189 User-Name = "anonymous" NAS-IPv6-Address = 2001:db4::2 NAS-Identifier = "panosAP-TD4" NAS-Port = 1 Called-Station-Id = "00-1B-2F-2C-AE-45:panos_secure" Calling-Station-Id = "00-1B-2F-2C-AD-D9" Framed-MTU = 1400 NAS-Port-Type = Wireless-802.11 Connect-Info = "CONNECT 54Mbps 802.11g" EAP-Message = 0x02c6000e01616e6f6e796d6f7573 Message-Authenticator = 0xbc939da0f8f0ae045e3b34aacc8b8f4e
A non-SSL issue again, you *MUST* make your username 'user@realm' (or for TTLS '@realm' for the outer layer, and you should *force* Reject now, before it is too late, 'realm-less' logins. I guess this is works-in-progress for an eduroam deployment? If you do not force a realm on the outer layer, your users locally will be able to use 'eduroam' but the moment they leave the campus it stops working. The simpliest solution and only solution is to reject realmless (NULL) EAP authentications *now*.
Fri Sep 24 03:05:03 2010 : Info: # Executing section post-auth from file /usr/local/etc/raddb/sites-enabled/inner-tunnel } # server inner-tunnel Fri Sep 24 03:05:03 2010 : Info: [ttls] Got tunneled reply code 2 Reply-Message = "Hello, bob" MS-MPPE-Encryption-Policy = 0x00000001 MS-MPPE-Encryption-Types = 0x00000006 MS-MPPE-Send-Key = 0x0e862e8c86b378eefa940cf437a147f8 MS-MPPE-Recv-Key = 0xd701a18f6107c06a01b07b6dd677f587 EAP-Message = 0x03030004 Message-Authenticator = 0x00000000000000000000000000000000 User-Name = "bob" Fri Sep 24 03:05:03 2010 : Info: [ttls] Got tunneled Access-Accept Fri Sep 24 03:05:03 2010 : Info: [ttls] Saving response in the cache Fri Sep 24 03:05:03 2010 : Info: [ttls] WARNING: No information to cache: session caching will be disabled for this session. Fri Sep 24 03:05:03 2010 : Debug: SSL: Removing session 1d6029bbddba233cd443d692b968df093237d9ad982f9ccc8a2defcd3edeb243 from the cache
Yes, editing your 'eap' module so that 'use_tunneled_reply = yes' should solve all this. Cheers -- Alexander Clouter .sigmonster says: fortune: cpu time/usefulness ratio too high -- core dumped.