Alan DeKok <[email protected]>; 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
_______________________________________________
Emu mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/emu
