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