*TLS* Session caching in v3.0.9
aland at deployingradius.com
Fri Sep 4 20:38:06 CEST 2015
On Sep 4, 2015, at 12:16 PM, Jason Alderfer <jha2 at emu.edu> wrote:
> Testing with v3.0.x. What I found:
> 1. In order to get TLS sessions to be cached without needing to enable
> use_tunneled_reply = yes, I had to put the following in the "authorize"
> section of "default" so that it came before the eap module was called.
> Otherwise eap didn't find anything to cache.
> 2. With the above in place, caching appears to work correctly. All
> expected attributes are in the cache, and on session resumption they are
> read correctly from the cache, however they are not sent back in the final
> reply. See below.
You're not putting anything into session-state. So when you're taking the reply attributes from the &session-state, nothing is there.
There's a lot of moving parts here.
a) attributes which need to be saved across multiple Access-Challenges MUST be put into the "session-state" list.
b) you must set Cached-Session-Policy some time BEFORE the session finishes, so that the TLS session is cached, with the policy.
c) on session resumption, the Cached-Session-Policy is read from the cache and put back into the reply list. The "inner tunnel" isn't executed.
d) if the next packet is an Access-Accept, you can key off of Cached-Session-Policy in the post-auth section, to set your reply attributes
e) if the next packet is an Access-Challenge, you MUST copy Cached-Session-Policy to &session-state, so that it can be used in the next Access-Accept
This is simpler in the v3.1.x branch. You can set a virtual server to run on TLS session cache read / write / delete. You can then cache the TLS session anywhere, and you can cache any kind of attribute from any list. The hard-coded processing of v2 and v3.0 is gone.
It's more complicated to set up, but ultimately easier to understand and to use.
More information about the Freeradius-Users