On Sep 4, 2015, at 12:16 PM, Jason Alderfer <jha2@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.