Re: [kitten] [TLS] Fwd: Last Call: <draft-ietf-kitten-tls-channel-bindings-for-tls13-09.txt> (Channel Bindings for TLS 1.3) to Proposed Standard

["Ruslan N. Marchenko" <[e-mail]>]

Hi Jonathan,

Am Dienstag, dem 26.10.2021 um 17:32 +0100 schrieb Jonathan Hoyland:
> Hi Sam, all,
> 
> I'd like to again raise the issues I pointed out in
> https://mailarchive.ietf.org/arch/msg/kitten/13pPj4E3-gYwpbu2K844uI1BPoU/
> .
> This draft hasn't received enough security analysis, and further, I
> pointed out a specific security issue that remains unaddressed.
> 
> Using the same label for different protocols produces trivial
> collisions, and thus it is perfectly possible that a message meant for
> GSS-API is identical in both form and key to a message for SCRAM, and
> thus there is strong potential for confusion.
> I'm not familiar with either of these protocols, so maybe they have
> internal reasons why this example doesn't work, but that misses the
> much larger and more significant point. 
> Any future protocol that uses the same label will potentially be
> confusable, and further updates to GSS-API now must ensure that they
> don't form valid SCRAM messages, and vice versa.
> 
> There isn't even a one-to-one relationship between GSS-API / SCRAM
> runs. This channel binding design doesn't protect against messages
> being swapped between two GSS-API runs on a single TLS connection.
> Again, whether that is a specific problem for GSS-API is totally
> irrelevant.
> Another protocol that uses this draft may well be vulnerable, and thus
> this is just leaving a huge security landmine in TLS channel bindings. 
> 
> At an absolute minimum this draft should include "A TLS session using
> this RFC to produce a binding for any purpose MUST NOT generate more
> than one per session. If a second exporter using this protocol is
> required the TLS session MUST be rekeyed."
> 
Can you please elaborate a bit more on this particular attack vector?
What exactly information it may leak/compromise and how?

The reason I'm asking is that application is the one glueing together
TLS and authentication sessions, however application does not always
have access to internals of either one(tls), or another(auth) or even
both. Therefore asking application to transfer context between
authentication and transport APIs may not always be feasible or even
possible.

Regards,
Ruslan