*TLS* Session caching in v3.0.9

[Alan DeKok]

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.

  OK.

> 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.

  Alan DeKok.