Confused about ssl caching

Sven Hartge sven at svenhartge.de
Tue Jul 16 19:49:39 CEST 2019


On 16.07.19 18:35, Alan DeKok wrote:
> On Jul 16, 2019, at 7:17 AM, Sven Hartge <sven at 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freeradius.org/pipermail/freeradius-users/attachments/20190716/67608762/attachment.sig>


More information about the Freeradius-Users mailing list