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

[Sam Whited <[e-mail]>]

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.

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

—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