This community is for technical, feature, configuration and deployment questions.
For production deployment issues, please contact the TAC! We will not comment or assist with your TAC case in these forums.
Please see How to Ask the Community for Help for other best practices.
Does anyone have a handy guide to explain how to engineer Session Resume timeouts, and how that plays into other timeouts like NAS Session-Timeout?
And 'Default Master key Generation Period of 1 day' - what are some factors to consider when setting that. Just because it's default doesn't mean it's the right value.
PEAP has the Fast Reconnect option too - how does that come into play?
It would be nice to have a diagram that shows how these EAP optimisations all fit together - preferably from someone who has spent testing this and can relate it to a real world example.
Currently I understand that Session Resume is primarily a feature that one SHOULD enable to reduce the impact on the External Identity Source (usually AD). And this sounds great in theory, but it comes at the expense of security - i.e. having up-to-date information that might be relevant during authentication - e.g. the other day I had 2 hour Session Resume enabled (ISE default) and then I wondered why authentication still passed, even though I disabled the user in AD. I want to know if there are other such caveats when using these optimisations.
And also, what is the difference between enabling EAP-TLS Session Resume under Settings/Protocols vs Policy/Policy Elements/Results/Authentocation/Allowed Protocols (see below)?
Solved! Go to Solution.
As always, the document is a gold mine of knowledge. Would you say that Session Resume and Stateless Session Resume are mutually exclusive features?
Session Resume: AAA server stores the state of the TLS session and doesn't try to create a new TLS negotiation
Stateless Session Resume: AAA server sends client a ticket and nothing is stored on the server.
Seems to me that if you enable both features then Stateless is dependent on the client supporting that feature. Having the Session Resume configured is then just a safety net, in case your clients don't send that ticket to trigger the stateless session resume.
Would that be a fair assessment?
Not sure if ISE logic requires Session Resume to be enabled before applying Stateless Session Resume. For stateless resume, yes it does require client support it--negotiation is at TLS layer. Per RFC 5077,
"The client indicates that it supports this mechanism by including a SessionTicket TLS extension in the ClientHello message. The extension will be empty if the client does not already possess a ticket for the server. "
In stateless resume, ISE is tracking the Master Ticket validity, and also checks the session ticket validity of the client.
In basic EAP TLS session resume, ISE maintains the tunnel keys and cipher used to establish the tunnel communication in the cache for each session. Client does not require specific support.
I am looking at your BRKSEC-3699-reference document - and I see on slide 124 that the default Master Key Generation Period is "1 week". It does not, however, discuss the pros/cons of changing that value - nor does it have any recommendations as to what we might want that value to be. Unfortunately, it is also one of your hidden slides, so you don't address it during your presentation. Would it be possible to get some guidance? I cannot seem to find any that is readily available...
I'm sure many administrators would appreciate a blog/document explaining the security and technical implications of using either Session Resume or Stateless with Cisco ISE.
Enabling TLS Resumption may be intuitive from an optimization point of view, but not from a security point of view. For example if enabling TLS Resumption makes MITM attacks simpler, that should be expressed.