Confused about ssl caching
Hello all! I am using freeradius 3.0.17 (waiting on .19 is on the testbed right now) and I am a bit confused about the ssl cache. I am authentication users in WiFi against LDAP (as a database, i.e. the correct way) and also assigning VLANs based on the UserClass, all working fine: if ( "%{toupper:%{control:GIFB-UserClass[*]}}" =~ /(M|P|A|R)/ ) { update reply { &Tunnel-Type = "VLAN" &Tunnel-Medium-Type = "IEEE-802" &Tunnel-Private-Group-id = "701" &Aruba-User-Vlan = 701 } updated } else { update reply { &Tunnel-Type = "VLAN" &Tunnel-Medium-Type = "IEEE-802" &Tunnel-Private-Group-id = "700" &Aruba-User-Vlan = 700 } updated } GIFB-UserClass is a local attribute pulled from LDAP. This works fine, no problems here. Now: in tls-common it says: # 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. Here is where my confusion starts and searching the web and the list archive only increased it. Do *I* need to do anything here to get the correct VLAN to the user on session resumption or is it just *magic* and will work automagically? Or do I need to add the Xeap.authenticate and Xeap.authorize policies somewhere? I'd like to understand the mechanism before playing with it. Grüße, Sven.
On Jul 16, 2019, at 7:17 AM, Sven Hartge <sven@svenhartge.de> wrote:
I am using freeradius 3.0.17 (waiting on .19 is on the testbed right now) and I am a bit confused about the ssl cache.
I am authentication users in WiFi against LDAP (as a database, i.e. the correct way) and also assigning VLANs based on the UserClass, all working fine: ...
That's good.
GIFB-UserClass is a local attribute pulled from LDAP. This works fine, no problems here.
Now: in tls-common it says:
# 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.
Here is where my confusion starts and searching the web and the list archive only increased it.
Do *I* need to do anything here to get the correct VLAN to the user on session resumption or is it just *magic* and will work automagically?
The rest of the documentation says: # 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 So VLAN information is *not* in the cache.
Or do I need to add the Xeap.authenticate and Xeap.authorize policies somewhere?
No.
I'd like to understand the mechanism before playing with it.
You need to set Cached-Session-Policy in the original authentication session. Then, when the session resumes, the server will automatically populate the 3 attributes mentioned above. You can then use those attributes to do VLAN assignment. The reason for the confusion is that the session resumption generally is missing *lots* of information. The original authentication has a real User-Name available, certificates, etc. The resumed session has only the outer User-Name, and no certificates. Because it's authenticating the user with a cached session key, not a certificate or password. The result is that if you want to apply policies to the resumed session, you generally can't. Because the User-Name, etc. are all missing. In order to fix that, FreeRADIUS uses the Cached-Session-Policy. Which lets you control what policy is applied. We can't cache all of the attributes from the original Access-Accept, because they include things like Session-Timeouts, which will change over time. The good news is that in v4, you have much more control over what attributes are cached and when. So you can just say "cache VLN for session resumption", and it will work. Alan DeKok.
On 16.07.19 18:35, Alan DeKok wrote:
On Jul 16, 2019, at 7:17 AM, Sven Hartge <sven@svenhartge.de> wrote:
Do *I* need to do anything here to get the correct VLAN to the user on session resumption or is it just *magic* and will work automagically?
The rest of the documentation says:
# 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
So VLAN information is *not* in the cache.
Or do I need to add the Xeap.authenticate and Xeap.authorize policies somewhere?
No.
I'd like to understand the mechanism before playing with it.
You need to set Cached-Session-Policy in the original authentication session.
Then, when the session resumes, the server will automatically populate the 3 attributes mentioned above. You can then use those attributes to do VLAN assignment.
OK, understood. But: How? And what? My searches just found some old discussion from 2011 not really providing any example and soon trailing off and many discussions about the generic cache module, which is a completely different thing.
The reason for the confusion is that the session resumption generally is missing *lots* of information. The original authentication has a real User-Name available, certificates, etc. The resumed session has only the outer User-Name, and no certificates. Because it's authenticating the user with a cached session key, not a certificate or password.
The result is that if you want to apply policies to the resumed session, you generally can't. Because the User-Name, etc. are all missing. In order to fix that, FreeRADIUS uses the Cached-Session-Policy. Which lets you control what policy is applied.
We can't cache all of the attributes from the original Access-Accept, because they include things like Session-Timeouts, which will change over time.
Understood and quite logical, in concept. But what I am missing is a concrete example how a configuration would look, if you excuse my thickness. Also, side note here: the native Debian packages in Debian 9 and 10 have tls-caching disabled at the source level because of CVE-2017-9148. Which means without recompilation you can't use this feature. Grüße, Sven.
On Jul 16, 2019, at 1:49 PM, Sven Hartge <sven@svenhartge.de> wrote:
But: How? And what?
After looking into it, the answer is "badly" :(
But what I am missing is a concrete example how a configuration would look, if you excuse my thickness.
It's pretty non-intuitive.
Also, side note here: the native Debian packages in Debian 9 and 10 have tls-caching disabled at the source level because of CVE-2017-9148. Which means without recompilation you can't use this feature.
Debian also ships version of FreeRADIUS which are *years* out of date. Instead of using a recent release, they patch one from may years ago. Updated packages are available at: http://packages.networkradius.com Updated documentation and more friendly configuration is available at: https://github.com/FreeRADIUS/freeradius-server/commit/a3c46544b38ab46218c38... You'll have to use the v3.0.x code from GitHub in order to get simpler TLS session caching. Alan DeKok.
On 17.07.19 15:01, Alan DeKok wrote:
On Jul 16, 2019, at 1:49 PM, Sven Hartge <sven@svenhartge.de> wrote:
But: How? And what?
After looking into it, the answer is "badly" :(
So better wait for a later version before trying. I don't want to knock 20,000 users offline in a vain attempt to maybe optimize something which may not even need optimizing.
But what I am missing is a concrete example how a configuration would look, if you excuse my thickness.
It's pretty non-intuitive.
At least I wasn't totally blind in my disability to understand where to even start to use this feature. I've been staring at the configuration, the documentation (which essentially said the same as the comment in the configuration) and the code and had no idea when and how to use "Cached-Session-Policy". Do I set it to the name of the policy used to add the VLAN attributes? Do I just add the resulting attributes directly? Is it a string or an array?
Also, side note here: the native Debian packages in Debian 9 and 10 have tls-caching disabled at the source level because of CVE-2017-9148. Which means without recompilation you can't use this feature.
Debian also ships version of FreeRADIUS which are *years* out of date. Instead of using a recent release, they patch one from may years ago.
Which is why I roll my own packages with current versions, just using the Debian packages as a base.
Updated documentation and more friendly configuration is available at:
https://github.com/FreeRADIUS/freeradius-server/commit/a3c46544b38ab46218c38...
You'll have to use the v3.0.x code from GitHub in order to get simpler TLS session caching.
I see, this makes more sense now. Grüße, Sven.
W dniu 2019-07-17 15:21, Sven Hartge napisał(a):
even start to use this feature. I've been staring at the configuration, the documentation (which essentially said the same as the comment in the configuration) and the code and had no idea when and how to use "Cached-Session-Policy". Do I set it to the name of the policy used to add the VLAN attributes? Do I just add the resulting attributes directly? Is it a string or an array?
Hi Sven I'm using Cached-Session-Policy and its part of my working configuration (i changed only vlan to number to better view) - this idea to use regexp is taken from some source (i dont remember where it was - maybe somewhere in networkradius.com?). It works as expected. Regards, Leszek # # inner tunnel server #-------------------- post-auth { update reply { &Cached-Session-Policy := "rid=%{wsb:SELECT nextval('rid_seq')}cui=%{control:WSB-CUI}vlan=500" ... # # outer server for requests from nas # #----------------- post-auth { if(&reply:Cached-Session-Policy) { if(&reply:Cached-Session-Policy =~ /rid=(.+)cui=(.+)vlan=(.+)/) { update reply { &Class := "%{1}" &Chargeable-User-Identity := "%{2}" &Tunnel-Private-Group-ID := "%{3}" ... # # outer server for requests from eduroam proxy servers # #----------------- post-auth { if(&reply:Cached-Session-Policy) { if(&reply:Cached-Session-Policy =~ /rid=(.+)cui=(.+)vlan=(.+)/) { if(&request:Chargeable-User-Identity) { update reply { &Chargeable-User-Identity := "%{2}" # remove User-Name etc. ...
On 18.07.19 03:07, Leszek Komor wrote:
I'm using Cached-Session-Policy and its part of my working configuration (i changed only vlan to number to better view) - this idea to use regexp is taken from some source (i dont remember where it was - maybe somewhere in networkradius.com?). It works as expected.
So Cached-Session-Policy is just a non-magic string and you parse the values you need later out of it via whatever method is suitable, a regexp in your case. Got it. Grüße, Sven.
participants (3)
-
Alan DeKok -
Leszek Komor -
Sven Hartge