Subject: Re: [Emu] Notes on session resumption with TLS-based EAP methods

From: John Mattsson <[email-masked]>
Date: Wed, 20 Feb 2019 13:53:55 +0000

Alan DeKok <[email-masked]>; wrote:

>The issue with session resumption is much larger than just the EAP method.  This subject should ideally be discussed in the "Security Considerations" section of the new EAP-TLS draft.

I agree

>i.e. We should define precisely what a "session" is.
>
>Right now, the draft talks about "session resumption", without clearly defining it.  The *implicit* definition is a TLS session.  But the issue of resuming with different EAP methods shows there's more to it than that.

draft-ietf-emu-eap-tls13 is actually very careful to not talk about "session resuption", it talks about "resumption". The reason is that "session" is not well defined and probably not the same in TLS and EAP. In TLS 1.2 or earlier, "session resumption" clearly resumed a session. TLS 1.3 partly uses "session resumption" as something depracated:

   "Session resumption with and without server-side state as well as the PSK-based cipher suites of earlier TLS versions have been replaced by a single new PSK exchange."

As well as slang for the new resumption mechanism:

   "Although TLS PSKs can be established out of band, PSKs can also be established in a previous connection and then used to establish a new connection ("session resumption" or "resuming" with a PSK)."

And according to RFC 8446, resumption in TLS 1.3 creates a new session

   "The PSK binder value forms a binding between a PSK and the current handshake, as well as between the session where the PSK was established and the current session"

   "NewSessionTicket"

My understanding is that

   - session resumption with EAP-TLS 1.2 would resume the same TLS session (same TLS SessionID) but create a new EAP session (different EAP Session-Id).

   - resumption with EAP-TLS 1.3 would create a new TLS session (SessionID is depracated) and create a new EAP session (different EAP Session-Id)

/John

---

From: Alan DeKok <[email-masked]>
Date: Wed, 20 Feb 2019 09:03:07 -0500

> On Feb 20, 2019, at 8:53 AM, John Mattsson <[email-masked]> wrote:

  OK, but that's still resuming a user session.  Even if the name of the thing changed.

>   - resumption with EAP-TLS 1.3 would create a new TLS session (SessionID is depracated) and create a new EAP session (different EAP Session-Id)

  That's nice, but really misses my point.

  Whatever it's called in EAP-TLS 1.3, resumption *does not* use the same authentication credentials as the first session.  This creates a "time of use, time of check" security bug that's welded into the protocol.

  This security bug was completely missed in RFC 5216.  This new draft should rectify that error.

  i.e. using an NAI of "example.org" in the first session, and "example.com" in the second session.

  Not only is this entirely permitted by the current spec, it's not even discussed as an issue.  And it means that the protocol is open to a large number of time of use, time of check" security bugs which could cause serious breaches of networks.

  We can't paper over security issues by saying "it's not session resumption, it's a new session".  Well, whatever.  The NEW session should get the same authorization as the OLD session, but the information used to do that authorization doesn't exist in the NEW session!  Or if it does exist, it can be different!

  That's a show-stopper, TBH.

  Alan DeKok.

---

From: "Cappalli, Tim (Aruba Security)" <[email-masked]>
Date: Wed, 20 Feb 2019 14:08:36 +0000

Agree 100% Alan. Now is the time to fix this.

-----Original Message-----
From: Emu <[email-masked]> on behalf of Alan DeKok <[email-masked]>
Date: Wednesday, February 20, 2019 at 9:03 AM
To: John Mattsson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [Emu] Notes on session resumption with TLS-based EAP methods

  Alan DeKok.

_______________________________________________
Emu mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/emu