I am apparently using the Caching improperly in regards to configuration in eap.conf. The first authentication works great (EAP-PEAP-MSChapv2) and DB lookups. The second time (with caching enabled) it appears to only be adding the User-Name attribute to the reply. I see the comments in the file "eap.conf" but they don't go very far into explaining how to get certain attributes saved INTO the cache or pulled out of it. Does anyone have an example of how to use this "Cached-Session-Policy" which is applied to the cached session? eap.conf cache section reads: The "Cached-Session-Policy" is the name of a policy which should be applied to the cached session. This policy can be used to assign VLANs, IP addresses, etc. It serves as a useful way to re-apply the policy from the original Access-Accept to the subsequent Access-Accept for the cached session. What exactly am I supposed to store into the attribute "Cached-Session-Policy"? Is this referring to a policy within the file "policy.conf" that will run and extract attributes according to the function there or is it something else? The notes also say: # You probably also want "use_tunneled_reply = yes" when using fast session resumption. And I have turned that on everywhere I could find, but it doesn't appear to be even saving the 1st values of Tunnel-Private-Group-Id. Debug output: First time that responds correctly given a VLAN. [snipped] [peap] Using saved attributes from the original Access-Accept Tunnel-Private-Group-Id:0 = "316" Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 User-Name = "jd187" [peap] Saving response in the cache [eap] Freeing handler ++[eap] returns ok WARNING: Empty post-auth section. Using default return values. # Executing section post-auth from file /services/freeradius/etc/raddb//sites-enabled/dvlan-1x-working } # server dvlan-1x-test1 Sending Access-Accept of id 157 to 128.61.2.253 port 1645 Tunnel-Private-Group-Id:0 = "316" Tunnel-Type:0 = VLAN Tunnel-Medium-Type:0 = IEEE-802 User-Name = "jd187" MS-MPPE-Recv-Key = 0xbdc694a560b3fc4e37385fe08bb9876e11d215add69317c704fa374f462bcb0a MS-MPPE-Send-Key = 0xa039b0c10a7ef3511a68cdd837f13747c7a4adcb86dc5d73a8506f0105a9ced4 EAP-Message = 0x03080004 Message-Authenticator = 0x00000000000000000000000000000000 Finished request 7. Going to the next request After attempting a second auth which appears to bypass the logic to assign a VLAN but doesn't appear to be adding it to the response from the cache at all. [snipped] [peap] processing EAP-TLS [peap] eaptls_verify returned 7 [peap] Done initial handshake [peap] eaptls_process returned 7 [peap] EAPTLS_OK [peap] Session established. Decoding tunneled attributes. [peap] Peap state send tlv success [peap] Received EAP-TLV response. [peap] Success [peap] Adding cached attributes to the reply: User-Name = "jd187" [eap] Freeing handler ++[eap] returns ok WARNING: Empty post-auth section. Using default return values. # Executing section post-auth from file /services/freeradius/etc/raddb//sites-enabled/dvlan-1x-working } # server dvlan-1x-test1 Sending Access-Accept of id 161 to 128.61.2.253 port 1645 User-Name = "jd187" MS-MPPE-Recv-Key = 0x0d398b0ed22899753eac37c8b308afb8a600a4be2b35d4260470148c6f4774cc MS-MPPE-Send-Key = 0x570045c77b56ef4d327189610f20f358038cea5bda215ded4ca32eefd2a72cf2 EAP-Message = 0x03040004 Message-Authenticator = 0x00000000000000000000000000000000 Finished request 11.
On 04/20/2011 10:13 PM, John Douglass wrote:
What exactly am I supposed to store into the attribute "Cached-Session-Policy"? Is this referring to a policy within the file "policy.conf" that will run and extract attributes according to the function there or is it something else?
Based on a quick glance at the source: You store anything you want, and then you write policy to act on it. The server doesn't do anything specific with the attribute beyond storing it and allowing you to read it. For example: post-auth { if (reply:Cached-Session-Policy =~ /group=(.+),building=(.+)/) { update reply { My-Vlan = "%{sql:...some sql based on the %{1} and %{2} values}" } } else { # do your policy work, then update reply { Cached-Session-Policy := "group=staff,building=admin" } } }
The notes also say:
# You probably also want "use_tunneled_reply = yes" when using fast session resumption.
And I have turned that on everywhere I could find, but it doesn't appear to be even saving the 1st values of Tunnel-Private-Group-Id.
Hmm. AFAICT from the source, the common TLS code (used by EAP-TLS and PEAP/TTLS too) will only cache User-Name, Stripped-User-Name and Cached-Session-Policy. Arbitrary valuepairs aren't stored in the cache. In some respects, this makes sense - you might set the VLAN based on the switch they're on; you need to re-calculate those values because you can't guarantee that session resumption takes place on the same switch. Basically, if you set reply variables based on some kind of lookup (e.g. SQL) the safe option is to store the "key" in Cached-Session-Policy, then set the reply variables (vlan etc.) in post-auth based on the key.
Awesome Phil, that was exactly the kind of example that is awesomely useful :) I see that by default the username is stored along with this. [peap] Adding cached attributes to the reply: User-Name = "jd187" Cached-Session-Policy = "vlan=316" Do you know exactly how the session resumption is determined? In the debug output I see: [peap] eaptls_process returned 3 [peap] EAPTLS_SUCCESS [peap] Session established. Decoding tunneled attributes. [peap] Peap state TUNNEL ESTABLISHED [peap] Skipping Phase2 because of session resumption [peap] SUCCESS Would ANY authentication for "jd187" get the cached applied or does freeradius have some concept of uniqueness when it comes to different sessions by the same user? The documentation (in eap.conf states): # The cache contains the following information: # # session Id - unique identifier, managed by SSL # User-Name - from the Access-Accept # Stripped-User-Name - from the Access-Request # Cached-Session-Policy - from the Access-Accept # # # On session resumption, these attributes are copied from the cache, and placed into the reply list. So I am assuming that session id is some combination of attributes that uniquely describe a single particular connection/authentication (I would hope). In my environment, if the cache is purely based off username, this would break our entire system. Figured I would bring this to see if anyone has any insight on how this session ID is created, managed, and applied to the subsequent session/authentications. I'll be running some experiments on this early next week but figured I might ask if anyone has any ideas on how/when the caching is applied (as configured by the eap.conf variables). Thanks in advance, - John Douglass, Georgia Tech On 04/20/2011 07:18 PM, Phil Mayers wrote:
On 04/20/2011 10:13 PM, John Douglass wrote:
What exactly am I supposed to store into the attribute "Cached-Session-Policy"? Is this referring to a policy within the file "policy.conf" that will run and extract attributes according to the function there or is it something else?
Based on a quick glance at the source: You store anything you want, and then you write policy to act on it. The server doesn't do anything specific with the attribute beyond storing it and allowing you to read it.
For example:
post-auth { if (reply:Cached-Session-Policy =~ /group=(.+),building=(.+)/) { update reply { My-Vlan = "%{sql:...some sql based on the %{1} and %{2} values}" } } else { # do your policy work, then update reply { Cached-Session-Policy := "group=staff,building=admin" } } }
The notes also say:
# You probably also want "use_tunneled_reply = yes" when using fast session resumption.
And I have turned that on everywhere I could find, but it doesn't appear to be even saving the 1st values of Tunnel-Private-Group-Id.
Hmm.
AFAICT from the source, the common TLS code (used by EAP-TLS and PEAP/TTLS too) will only cache User-Name, Stripped-User-Name and Cached-Session-Policy. Arbitrary valuepairs aren't stored in the cache.
In some respects, this makes sense - you might set the VLAN based on the switch they're on; you need to re-calculate those values because you can't guarantee that session resumption takes place on the same switch.
Basically, if you set reply variables based on some kind of lookup (e.g. SQL) the safe option is to store the "key" in Cached-Session-Policy, then set the reply variables (vlan etc.) in post-auth based on the key. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
John Douglass wrote:
Would ANY authentication for "jd187" get the cached applied or does freeradius have some concept of uniqueness when it comes to different sessions by the same user?
It's SSL session resumption. The previous SSL session can get re-used, based on secrets known only by the cache in FreeRADIUS, and by the user who originally authenticated via that SSL session.
So I am assuming that session id is some combination of attributes
No. The session Id is an SSL thing that is handled internally by OpenSSL. But it *is* unique to each session.
Figured I would bring this to see if anyone has any insight on how this session ID is created, managed, and applied to the subsequent session/authentications. I'll be running some experiments on this early next week but figured I might ask if anyone has any ideas on how/when the caching is applied (as configured by the eap.conf variables).
I recommend *not* trying to understand all of the internal details of how this works. A lot is going on inside of FreeRADIUS and OpenSSL, and it's simply not worth your time to look. It works, and it works *properly*. Dozens of people have spent years designing the various pieces so that all of the possible concerns are addressed. Alan DeKok.
On 04/22/2011 05:00 PM, John Douglass wrote:
Awesome Phil, that was exactly the kind of example that is awesomely useful :)
I see that by default the username is stored along with this.
[peap] Adding cached attributes to the reply: User-Name = "jd187" Cached-Session-Policy = "vlan=316"
Do you know exactly how the session resumption is determined? In the debug output I see:
As Alan has mentioned, it's SSL/TLS session resumption, as PEAP (and TTLS, in fact) are built on top of TLS-over-EAP. Basically once you've done a "full" PEAP authentication once (including full TLS - exchange certs, negotitate crypto - then a full inner auth e.g. MSCHAP) the same client/server pair can resume the session in a cryptographically secure manner, which is both quicker and fewer round-trips. In FreeRADIUS case, it just uses the OpenSSL library to store some additional data in the server "session", namely the values you've seen. Specifically: it is *only* that client/server pair that can resume a session, since they are the only entities which have the TLS shared secret negotiated in the initial full exchange. It's not some sort of "anything with the same username" thing - it's specific to TLS-based EAP methods, built on top of TLS session resumption.
So I am assuming that session id is some combination of attributes that uniquely describe a single particular connection/authentication (I would
No: it's an SSL variable, you don't see or control it, or really need to worry about it.
participants (3)
-
Alan DeKok -
John Douglass -
Phil Mayers