Session Resumption fails

Alexander Clouter alex at digriz.org.uk
Fri Sep 24 13:15:10 CEST 2010


Hi,

* Panagiotis Georgopoulos <panos at 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/msg00163.html
 
> 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 at 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.



More information about the Freeradius-Users mailing list