Force update of TLS cache
In our EAP-PEAP sessions, the typical conversation length is 10 packets. We have TLS caching enabled, but I noticed the TLS cache is populated during packet 4, which is before processing has started on the tunneled authentication. Is it possible to force an update of the cache entry from the inner-tunnel server e.g. to add attributes that are only available at this stage? I attempted to call an update by doing this in the inner-tunnel server: update control { Cache-TTL := 0 } cache_tls_session This caused authentications to fail with "cache_tls_session (fail)" and no further information is given. Is it possible to do this? Thanks, Jonathan
On Feb 29, 2016, at 8:34 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
In our EAP-PEAP sessions, the typical conversation length is 10 packets. We have TLS caching enabled, but I noticed the TLS cache is populated during packet 4, which is before processing has started on the tunneled authentication.
The session is cached when the TLS connection has been established.
Is it possible to force an update of the cache entry from the inner-tunnel server e.g. to add attributes that are only available at this stage? I attempted to call an update by doing this in the inner-tunnel server:
update control { Cache-TTL := 0 } cache_tls_session
This caused authentications to fail with "cache_tls_session (fail)" and no further information is given. Is it possible to do this?
It's better to update the cache in the outer post-auth section. The cache key is more likely to be the same. Alan DeKok.
On 29/02/16 14:01, Alan DeKok wrote:
On Feb 29, 2016, at 8:34 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
In our EAP-PEAP sessions, the typical conversation length is 10 packets. We have TLS caching enabled, but I noticed the TLS cache is populated during packet 4, which is before processing has started on the tunneled authentication.
The session is cached when the TLS connection has been established.
Is it possible to force an update of the cache entry from the inner-tunnel server e.g. to add attributes that are only available at this stage? I attempted to call an update by doing this in the inner-tunnel server:
update control { Cache-TTL := 0 } cache_tls_session
This caused authentications to fail with "cache_tls_session (fail)" and no further information is given. Is it possible to do this?
It's better to update the cache in the outer post-auth section. The cache key is more likely to be the same.
Just tried that. It fails like this: (9) Running section post-auth from file /etc/raddb/sites-enabled/eduroamlocal-auth (9) post-auth { ... (9) update control { (9) &control:Cache-TTL := 0 (9) } # update control (noop) (9) cache_tls_session (fail) (9) } # post-auth (fail) Have we got the syntax wrong? Thanks, Jonathan
On 29/02/16 14:50, A.L.M.Buxey@lboro.ac.uk wrote:
Hi,
(9) } # update control (noop) (9) cache_tls_session (fail)
fail? when you compiled FR, did you have all the required dependencies in place for using the cache features?
Yes, TLS caching is enabled and working provided we don't try to force an update
what have you modified in cache_tls module? is it enabled?
cache cache_tls_session { driver = "rlm_cache_rbtree" key = &TLS-Session-Id ttl = 3600 update { &session-state:TLS-Session-Data := &session-state:TLS-Session-Data &session-state:TLS-Session-Id := &TLS-Session-Id &session-state: += &session-state:[*] &session-state:Inner-User-Name := &session-state:Inner-User-Name } } I don't think all of the lines in the update{} block are required - we were experimenting with what we could put into the cache. Thanks, Jonathan
On Feb 29, 2016, at 10:09 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
cache cache_tls_session { driver = "rlm_cache_rbtree" key = &TLS-Session-Id
Which is the *outer* TLS-Sesson-Id. i.e. you can't use the module inside of the TLS tunnel, because the TLS-Session-Id doesn't exist. That's why the module is failing. So... you've got to copy it: server inner-tunnel { ... update request { TLS-Session-Id := &outer.request:TLS-Session-Id } ... cache_tls_session }
I don't think all of the lines in the update{} block are required - we were experimenting with what we could put into the cache.
Anything. They're just attributes. Alan DeKok.
On 29/02/16 15:22, Alan DeKok wrote:
On Feb 29, 2016, at 10:09 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
cache cache_tls_session { driver = "rlm_cache_rbtree" key = &TLS-Session-Id
Which is the *outer* TLS-Sesson-Id.
Thanks - hadn't realised this.
i.e. you can't use the module inside of the TLS tunnel, because the TLS-Session-Id doesn't exist. That's why the module is failing.
So... you've got to copy it:
I added code as you suggested. It seems to be unable to copy the TLS-Session-Id attribute. The following was executed in inner post-auth section, but also choked with the same result when being executed in the inner authorize section. (8) update request { (8) TLS-Session-Id skipped: No values available (8) } # update request (noop) (8) cache_tls_session (fail) Any suggestions? Thanks, Jonathan
On Feb 29, 2016, at 10:59 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
I added code as you suggested. It seems to be unable to copy the TLS-Session-Id attribute. The following was executed in inner post-auth section, but also choked with the same result when being executed in the inner authorize section.
(8) update request { (8) TLS-Session-Id skipped: No values available (8) } # update request (noop) (8) cache_tls_session (fail)
Any suggestions?
The TLS-Session-Id is available once the TLS session is set up. You should be able to update the "default" virtual server to see when the attribute is available. Or, the debug output should tell you when it's created. Alan DeKok.
On 29/02/16 16:02, Alan DeKok wrote:
On Feb 29, 2016, at 10:59 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
I added code as you suggested. It seems to be unable to copy the TLS-Session-Id attribute. The following was executed in inner post-auth section, but also choked with the same result when being executed in the inner authorize section.
(8) update request { (8) TLS-Session-Id skipped: No values available (8) } # update request (noop) (8) cache_tls_session (fail)
Any suggestions?
The TLS-Session-Id is available once the TLS session is set up. You should be able to update the "default" virtual server to see when the attribute is available. Or, the debug output should tell you when it's created.
The debug log shows that TLS-Session-Id is created in packet 4, in the outer authorize section. (4) Auth-Type eduroameap { (4) eduroameap - Peer sent packet with EAP method PEAP (25) (4) eduroameap - Calling submodule eap_peap to process data (4) eap_peap - Continuing EAP-TLS (4) eap_peap - Peer indicated complete TLS record size will be 134 bytes (4) eap_peap - Got complete TLS record, with length field (134 bytes) (4) eap_peap - [eap-tls verify] = ok (4) eap_peap - <<< recv handshake [length 70], client_key_exchange (4) eap_peap - TLS Accept: SSLv3 read client key exchange A (4) eap_peap - <<< recv change_cipher_spec [length 1] (4) eap_peap - <<< recv handshake [length 16], finished (4) eap_peap - TLS Accept: SSLv3 read finished A (4) eap_peap - >>> send change_cipher_spec [length 1] (4) eap_peap - TLS Accept: SSLv3 write change cipher spec A (4) eap_peap - >>> send handshake [length 16], finished (4) eap_peap - TLS Accept: SSLv3 write finished A (4) eap_peap - TLS Accept: SSLv3 flush data (4) eap_peap - &TLS-Session-Id = 0xd63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd (4) eap_peap - &config:TLS-Session-Cache-Action = Write (4) eap_peap - &session-state:TLS-Session-Data = 0x308181020101020203010402c0140420d63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd04308c351e2af2cf67325937428ddc4e980826c350e2c63e6bb223db447765639cff4f5136f51eef36248c64f295aafdff71a106020456d46a63a2040202012ca412041046 (4) Running Autz-Type Session-Cache-Write from file /etc/raddb/sites-enabled/tls-cache (4) Autz-Type Session-Cache-Write { (4) update control { (4) &control:Cache-TTL := 0 (4) } # update control (noop) (4) cache_tls_session - No cache entry found for "\326=\332';7\310\3516ֻ\246e\273\317L\261A7\t\325A9\020\377\340q\025\002\033i\315" (4) cache_tls_session - Creating new cache entry (4) cache_tls_session - &session-state:TLS-Session-Data := &session-state:TLS-Session-Data -> 0x308181020101020203010402c0140420d63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd04308c351e2af2cf67325937428ddc4e980826c350e2c63e6bb223db447765639cff4f5136f51eef36248c64f295aafdff71a106020456d46a63a2040202012ca412041046522065617020307831393664383930 (4) cache_tls_session - &session-state:TLS-Session-Id := &TLS-Session-Id -> 0xd63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd (4) cache_tls_session - &session-state: += &session-state:TLS-Session-Data -> 0x308181020101020203010402c0140420d63dda273b37c8e936d6bba665bbcf4cb1413709d5413910ffe07115021b69cd04308c351e2af2cf67325937428ddc4e980826c350e2c63e6bb223db447765639cff4f5136f51eef36248c64f295aafdff71a106020456d46a63a2040202012ca412041046522065617020307831393664383930 (4) cache_tls_session - Committed entry, TTL 3600 seconds (4) cache_tls_session - Removing &control:Cache-TTL (4) cache_tls_session (ok) (4) } # Autz-Type Session-Cache-Write (ok) This appears to be working so far. Referencing it in inner authorize or inner post-auth fails. I can't see why it would be inaccessible. We're referencing it like this, as you suggested: update request { TLS-Session-Id := &outer.request:TLS-Session-Id } And it does this: (6) update request { (6) TLS-Session-Id skipped: No values available (6) } # update request (noop) I don't understand why the attribute is not available later on in the same session. Thanks, Jonathan
On Feb 29, 2016, at 11:26 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
The debug log shows that TLS-Session-Id is created in packet 4, in the outer authorize section.
OK, so it should be available in the request. You may have to copy it to session-state, so it's available in later packets.
And it does this:
(6) update request { (6) TLS-Session-Id skipped: No values available (6) } # update request (noop)
I don't understand why the attribute is not available later on in the same session.
Because it's not being added to the session-state attributes. Again, "request" is PER PACKET. "session-state" is for the SESSION. Adding something to the request in packet 4 means ti's not available in the request in packet 6. That's what the session-state is for. The default config should probably add TLS-Session-Id to session-state. I'll take a look. But for you, you'll have to do it manually. Alan DeKok.
On 29/02/16 16:30, Alan DeKok wrote:
On Feb 29, 2016, at 11:26 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
The debug log shows that TLS-Session-Id is created in packet 4, in the outer authorize section.
OK, so it should be available in the request.
You may have to copy it to session-state, so it's available in later packets.
And it does this:
(6) update request { (6) TLS-Session-Id skipped: No values available (6) } # update request (noop)
I don't understand why the attribute is not available later on in the same session.
Because it's not being added to the session-state attributes. Again, "request" is PER PACKET. "session-state" is for the SESSION.
Adding something to the request in packet 4 means ti's not available in the request in packet 6. That's what the session-state is for.
The default config should probably add TLS-Session-Id to session-state. I'll take a look. But for you, you'll have to do it manually.
OK, thanks. Sorry to keep coming back to you - I'm having trouble getting TLS-Session-Id into session-state. I'm using this unlang snippet to do the assignment: update session-state { TLS-Session-Id := &TLS-Session-Id } I've placed it in various places in the outer server, immediately after the eap module has been called in authorize{}, immediately after the eap module has been called in authenciate{}, and inside and outside the Auth-Type eap subsection inside authenticate{}. I would think it should be available immediately after the eap module has done its thing. All of these positions cause it to fail with the following error: (6) update request { (6) TLS-Session-Id skipped: No values available (6) } # update request (noop) Thanks, Jonathan
On Mar 1, 2016, at 9:15 AM, Jonathan Gazeley <Jonathan.Gazeley@bristol.ac.uk> wrote:
I'm using this unlang snippet to do the assignment:
update session-state { TLS-Session-Id := &TLS-Session-Id }
That's a start.
I've placed it in various places in the outer server, immediately after the eap module has been called in authorize{}, immediately after the eap module has been called in authenciate{}, and inside and outside the Auth-Type eap subsection inside authenticate{}. I would think it should be available immediately after the eap module has done its thing.
TLS-Session-Id should be available after it's created in packet 4. You should add the "update" section after the "eap" module in "authenticate". i.e. when the packet is an Access-Challenge.
All of these positions cause it to fail with the following error:
(6) update request { (6) TLS-Session-Id skipped: No values available (6) } # update request (noop)
Yes, TLS-Session-Id won't be available in the request in packet 6. Because TLS-Session-Id will be in session-state. What you want is to restore it from session-state if it exists there, otherwise copy it from request to session state if it exists there. Again, none of this is magic. You MUST write down what you have, and what you want. Then work out how to get there from here. A random approach of "adding things to configuration sections" WILL NOT WORK. authorize { ... if (&session-state:TLS-Session-Id) { update request { TLS-Session-Id := &session-state:TLS-Session-Id } } eap ... } authenticate { Auth-Type eap { eap if (!&session-state:TLS-Session-Id && TLS-Session-Id) { update session-state { TLS-Session-Id := request:TLS-Session-Id # just to make it clear } } } ... }
participants (3)
-
A.L.M.Buxey＠lboro.ac.uk -
Alan DeKok -
Jonathan Gazeley