Confused about ssl caching

[Alan DeKok]

On Jul 16, 2019, at 7:17 AM, Sven Hartge <sven at 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.