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

[Jonathan Hoyland <[e-mail]>]

Hi Ruslan,

Without digging into the guts of GSS-API and SCRAM I can't give you a
concrete attack, the issue is that all our assumptions about protocol
security assume that different protocols use totally separate key material.
For example if I have one protocol that signs arbitrary blobs and another
that requires me to sign a challenge to prove I know a private key then
even if they're both perfectly secure on their own they are totally broken
in composition.
This separation of keys is one of the core reasons for the use of HKDFs, it
lets us take some source randomness and use it to generate independent keys.

Designing a channel binding that explicitly suggests people use the same
key material for different things is bad practice and poor protocol design.
Pretty much every attack is on the table if you have multiple protocols
using the same keys, message forgery, improper authentication, key leakage,
etc.
The reason for separation of keys is to simply rule out this entire class
of vulnerability.
If you don't separate the keys then whenever you make any change to any
protocol you have to consider its security in composition with every other
protocol, including ones that you don't know about or that haven't been
written yet.

Using different labels for different purposes shouldn't require anything
complicated, as it's just changing the input literals to the API call.
You just need to use different strings based on the configuration.
If keeping a counter of the number of calls to the API is really hard it
might be easier to just pick a big enough random number to make collisions
sufficiently unlikely.

Using the second approach lets you achieve a higher level of security, but
is perhaps overkill if you don't include attackers that can break TLS /
steal certificates in your threat model.
I totally accept that passing state between layers can be tricky, but if
you need the security then I think the correct solution is to design the
API carefully, rather than to implement something insecurely.
As it so happens implementing my second suggestion specifically doesn't
require any access to TLS internals.
The authentication session needs to make two calls to the `Exporter` API
but doesn't require anything more of the TLS connection.

Regards,

Jonathan






On Tue, 26 Oct 2021 at 20:58, Ruslan N. Marchenko <[e-mail]>
wrote:

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