EAP session resume

[Arne Bier]

Hello

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)?

[Craig Hyps · Accepted solution]

I cover this in BRKSEC-3699 available on ciscolive.com (reference version).  The stateless option is fairly new and allows session resume to work even when reauth happens to different PSN.

[Arne Bier]

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?

[Craig Hyps]

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.

Craig

[MNBob]

Craig,

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

[Nadav]

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.

[Alex Pfeil]

For the Enable Stateless Session Resume, would 24 hours be ok for the setting?  Would one week be too high?

[Arne Bier]

Hi @Alex Pfeil  - did you get any other responses to your question?  What did you end up implementing?

cheers

Arne

[ajc]

Hi Arne,

Have you used this feature? if it so, what would be your feedback on that?

thanks

[Charlie Moreton]

Resurrecting a 2-year old + thread that has an accepted solution limits the number of people that will take a look at it. The best thing to do is to start a new thread.

Tagging @Arne Bier for visibility

[Johannes Luther]

I plan to implement stateful and stateless TLS session resumption for EAP-TLS.
From my point of view, the defaults for the Session / Ticket lifetimes are ok (2 hours). Of course, the drawback of this setting is, that there is a time windows of maximum 2 hours before a certificate revocation may be enforced.

However, I don't understand the setting for stateless session resumption "Proactive session ticket update will occur after <PERCENT> of Time to Live has expired". In ISE 3.0 this defaults to 90%. This is configurable in the allowed protocols policy.

The documentation is not very clear regarding this switch (at least I didn't find anything) and RFC 5077 does not state anything regarding this.

Is this setting the "hint of the lifetime of the ticket" (ticket_lifetime_hint field) as stated in chapter 5.6 of RFC 5077? I cannot think of anything else.

The description in the ISE admin guide is not very accurate:

Proactive Session Ticket update: Enter the value as a percentage to indicate how much of the Time To Live (TTL) must elapse before the session ticket is updated. For example, if you enter the value 60, the session ticket is updated after 60 percent of the TTL has expired.

From my point of view the description is wrong, because it implies updates the session ticket. However the ISE does not hold any session ticket in stateless TLS session resumption. Any thoughts on this?