Hi Jonathan,
On 05/11/2021 15:34, Jonathan Hoyland wrote:
Hi Simo,
As I said in my email to Sam, my language here was sloppy, I meant
that the channel binding is included in the key derivation process,
and thus the output keys will be related to each other.
The term channel bindings has two different meanings using in very
similar contexts, which leads to great confusion and is why I prefer
the term compound authentication (see Chapter 4.4 of my thesis)
<https://pure.royalholloway.ac.uk/portal/files/33074422/2018HoylandJGPhD.pdf>.
A channel binding is a "name" of a channel as you say, but it is also
used to mean using one channel to authenticate another.
Very specifically if channel `a` is bound to channel `b` then that
means that if channel `b` is securely authenticated then channel `a`
was formed honestly (i.e. even if all of the long term key material
for channel `a` has been leaked, I can be sure that my channel `a`
peer is the same actor as my channel `b` peer.)
Channel bindings that aren't bound to a specific session are less
secure than ones that are, so yes, you can use them, but that doesn't
mean they have the security properties you need.
The purpose of binding a protocol to an underlying TLS session is to
leverage some of the security guarantees offered by the TLS layer.
If those guarantees are never necessary because the over-the-top
protocol is always perfectly secure, just run the protocol on the wire
and drop the TLS complication.
If those guarantees are at least sometimes necessary then you need to
securely bind the two channels together.
Channel binding does more than simply guarantee that the messages were
the same, it also guarantees that the identity of the actors at each
layer remains the same, and that the keys derived in each layer match.
With an appropriately designed channel binding you can use TLS's
protection against MITM attacks to protect insecure protocols run over
the top.
Having now looked at SCRAM a little bit, using the TLS channel binding
guarantees that some malicious server isn't passing the client's
messages off to another server and performing a malicious
authentication there.
Using a unique string from SCRAM means that messages from some other
protocol won't be compatible.
If you don't require a unique string I could write a new protocol
SCRAM++ with cross-compatible messages, but different security
guarantees, and use that to compromise SCRAM clients.
Obviously that's a patently malicious example, but it's perfectly
possible that some new version of SCRAM produces messages that an old
version of SCRAM misinterprets.
It's even highly likely that a server that supports old versions of
SCRAM for backwards compatibility would use the same key material for
all versions.
I've been reading this exchange and I still struggle to understand what
do you think the issue is. But more importantly, what are the possible
fixes? If you can propose specific modifications to how
draft-ietf-kitten-tls-channel-bindings-for-tls13 should be constructing
channel binding for TLS 1.3, then maybe we can make some progress on this.
Best Regards,
Alexey
Requiring a unique string makes the messages totally unrelated.
I don't find the arguments "It's always been insecure in the past" or
"We have bad APIs" especially compelling.
Regards,
Jonathan
On Fri, 29 Oct 2021 at 14:55, Simo Sorce <s...@redhat.com
<mailto:s...@redhat.com>> wrote:
Hi Jonathan,
On Thu, 2021-10-28 at 18:46 +0100, Jonathan Hoyland wrote:
> Hi Ruslan,
>
> Yes, two distinct TLS connections having the same exporter key
would be
> really bad, but I'm specifically talking about two runs of some
protocol
> bound to a single TLS session.
> A single TLS session will return the same key (modulo rekeying,
resumption
> etc.) if you call the Exporter API with the same label.
> This means that the channel bindings it produces, which will
then be used
> to derive the keys of the higher layer protocol, will produce
related keys.
>
> The key reason for making the binding retrieval context-specific
is to make
> sure that different protocols run in the same TLS session
produce disjoint
> keys.
Note, Channel Bindings are *not* a key and should never used as such,
so I think you are using a false premise here.
Channel Bindings are, at most, a unique value associated with a
session
(keep in mind that often Channel Bindings do not even bind to a
specific session, see 'tls-server-end-point' which is used in
preference in many cases within HTTPS endpoints because of the way
server termination is built in some scalable architectures).
> When someone tries to copy a message from a SCRAM handshake into
some
> GSS-API run on a single TLS connection I want to be sure that it
will be
> rejected, without having to understand exactly how every version
of SCRAM
> and GSS-API ever (including ones that will be drafted in the
future) works
> (not to mention every other protocol past, present, and future
that uses
> the same string.)
Both SCRAM and GSS-API are authentication mechanisms that use shared
keys for authentication. Both protocols are inherently resistant to
message swapping because the chances of producing a message on one
protocol that can be successfully decrypted/HMACed on the other are
astronomically low (they must be or the protocols are broken).
Channel bindings are just a way to tie those authentications to the
specific channel used underneath. I can't see how using the same value
for both protocols can lead to any compromise (see again 'tls-server-
end-point', where there isn't even a "same" channel guarantee, or
previous CBs where the binding was done to an IP address or other
clear
text session value).
If passing an arbitrary channel binding values could suddenly (and
predictably?) allow one protocol to be swapped for the other or have
one protocol generate derived session keys that are usable with the
other, it would mean those authentication mechanisms (SCRAM,GSS-
API,...) are completely broken, as that would mean the keys and
derivations used in those protocols are not providing the necessary
security guarantees.
> In the same way that we include strings in the TLS key schedule
to ensure
> that handshake messages can't be confused with each other or
with earlier
> versions of TLS, or even with Exported Authenticators, or MLS,
or any other
> protocol that uses keys, we should use channel bindings to separate
> protocols run over the top of TLS.
Yes, this is done because those messages are not further confounded
with additional private keys, but the situation is substantially
different when you talk about authentication mechanism that
already use
additional key material, key derivation and random challenges.
HTH,
Simo.
> Regards,
>
> Jonathan
>
> On Wed, 27 Oct 2021 at 19:39, Ruslan N. Marchenko
<ruffer...@gmail.com <mailto:ruffer...@gmail.com>>
> wrote:
>
> > Hi Jonathan,
> >
> > Am Mittwoch, dem 27.10.2021 um 18:02 +0100 schrieb Jonathan
Hoyland:
> > > 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.
> >
> > Sorry maybe I'm missing something but why would two unrelated
protocols
> > have same key? The binding is derived from TLS session key, if two
> > unrelated TLS sessions are having the same key this is the
problem by
> > itself, and binding material is not amplifying it, just
falling to the
> > same problem bucket. And if they are related (eg resumed) then
protocol
> > muxing should perhaps be part of applicaiton stack and it
should still
> > be happy with a common security context.
> >
> > > 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.
> > >
> > There's a difference in telling TLS stack "give me binding of that
> > type" - which is pretty much high level abstract call, and
asking TLS
> > to perform key derivation (export) for specific label - which
requires
> > speaking native TLS implementation api. Now that we have a
bunch of TLS
> > implementations and several abstractions and all other binding
types
> > are independent of the higher protocol - it may be challenging
changing
> > the API to make the binding retrieval context-specific. Not
that it is
> > impossible to make such change, but why?
> >
> >
> >
> >
> _______________________________________________
> Kitten mailing list
> kit...@ietf.org <mailto:kit...@ietf.org>
> https://www.ietf.org/mailman/listinfo/kitten
<https://www.ietf.org/mailman/listinfo/kitten>
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
