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

Please see my comments inline.

Regards,

Jonathan

On Wed, 27 Oct 2021 at 22:13, Sam Whited <[e-mail]> wrote:

> I've been trying to figure out exactly what you mean before replying and
> have been struggling to do so, so I apologize if I'm misunderstanding
> your emails, but I believe this isn't a problem unless you use the
> channel binding itself as keying material for something. The I-D
> specifically has a section where it says *not* to do that for this
> reason. This is supposed to be a generic mechanism that lets you
> invalidate a session or token if a TLS session changes, that's all. Any
> further use of the CB value would have the problems you describe, and
> therefore they are forbidden.
>
> You are correct in as much as using a channel binding as a key directly
would be bad, one of the requirements of channel bindings in RFC 5056 is
that even if the binding itself is leaked the security of the protocol
shouldn't be undermined.
My assumption is that running GSS-API or SCRAM over TLS is supposed to
provide a security benefit over just running it over an unsecured
connection.
If you view a channel binding as simply the "name" of the TLS channel, and
are simply requiring that the client and server are using the same TLS
channel then the current design achieves that.
However, you lose most of the other security benefits of running the
protocols over TLS.
Specifically you can no longer assume that an honest server cannot be
tricked into producing messages it shouldn't i.e. becoming an oracle.

I was sloppy with my language in my earlier message, it's true that the
channel binding is not key material, it is material that is included in key
derivation to ensure independent runs of the protocol have independent key
spaces.
The idea IMO of using a channel binding is to have a one-to-one binding
between the lower protocol and the upper protocol such that the pair of
protocols together have a globally independent key space, i.e. that it is
impossible for an attacker to cause distinct pairs of runs of the protocols
to have cryptographically related keys.
Under the current designs, multiple runs of GSS-API over a single TLS
session would use related keys.
Not only this, SCRAM runs would _also_ produce related keys.

This is supposed to be a generic mechanism, so we need to consider
composability, i.e. how it works when run alongside other unknown
protocols.
The only global state we maintain across all protocols (at least IETF-wise)
is through IANA registries.
To ensure that runs of different protocols have independent keys we use
context strings, to ensure that runs are one-to-one we use either counters
or nonces.


On the other hand, if an XMPP session's authn and some sort of authz
> token are both using this CB mechanism and are bound to the same TLS
> session that is not a problem. If the session changes they both would
> become invalid. if it doesn't, they both remain valid and do not leak
> any information about each other that wasn't already public.
>
> I don't think this is correct in general, although as I have mentioned, it
may be true for the current implementation of GSS-API / SCRAM, this is not
guaranteed to remain the case and doesn't account for future protocols and
updates to current ones, which is vital for generic mechanisms.
You have to guarantee that no future protocol will have the same message
format, or leak any information derived using the same keys.


I believe there is value in having a generic channel binding, even if
> it's so generic that this means it can't be used as a secret value
> itself. Maybe I'm misunderstanding what you're saying though?
>
> You are right, you can't use channel bindings (in this context) as secret
values (although channel bindings must be derived from secret values, which
is something I write about in excruciating detail in my thesis.)
Having a generic channel binding mechanism is great, I totally support
that, we just need to consider that a single TLS session may be used for
more than one thing, and that channel bindings should keep each of those
things separate.

—Sam
>
> On Wed, Oct 27, 2021, at 13:02, Jonathan Hoyland wrote:
> > 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
> >>
> >>
>
> --
> Sam Whited
>