Agree 100% Alan. Now is the time to fix this.
-----Original Message-----
From: Emu <emu-boun...@ietf.org> on behalf of Alan DeKok
<al...@deployingradius.com>
Date: Wednesday, February 20, 2019 at 9:03 AM
To: John Mattsson <john.matts...@ericsson.com>
Cc: "emu@ietf.org" <emu@ietf.org>
Subject: Re: [Emu] Notes on session resumption with TLS-based EAP methods
> On Feb 20, 2019, at 8:53 AM, John Mattsson <john.matts...@ericsson.com> wrote:
> 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"
OK, but that's still resuming a user session. Even if the name of the thing
changed.
> 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)
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.
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
_______________________________________________
Emu mailing list
Emu@ietf.org
https://www.ietf.org/mailman/listinfo/emu
