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

Dave Cridland <dave@cridland.net> Tue, 09 November 2021 13:00 UTC

Return-Path: <dave@cridland.net>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EA5B3A0A70 for <kitten@ietfa.amsl.com>; Tue, 9 Nov 2021 05:00:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cridland.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xChjV7leB1jY for <kitten@ietfa.amsl.com>; Tue, 9 Nov 2021 05:00:12 -0800 (PST)
Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96463A0A6C for <kitten@ietf.org>; Tue, 9 Nov 2021 05:00:11 -0800 (PST)
Received: by mail-wr1-x42a.google.com with SMTP id u18so32818069wrg.5 for <kitten@ietf.org>; Tue, 09 Nov 2021 05:00:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cridland.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0Z1kuwGTaNKc0lr7SY1Fij4PaUU+Uj4fTPjez8ShacA=; b=J1+rN8VZIAzTe+qc/uR4jVVHS/MRYuvafGGnl/RqalQ730RM42EFmYSiqUVYbCJrCM 7wN+QbZgRzFMZukIS8OyNJexQuX5riTl53PsoMTEfhvBFHaonRPbDkaoU9oetELZnj27 hmLA6UEMb9LTQJfUtHbuPReYT7qddHbTGZXyw=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0Z1kuwGTaNKc0lr7SY1Fij4PaUU+Uj4fTPjez8ShacA=; b=OTkX7fplGptbV4Iwr1oT1J70YMzeYmJ2SdXPE0EOP5x49dNQ2oilTD3KphbTGDGuSl faxCSHMxxgEov1mwSgJsSBGO7faAs+OD+lfMRHLIKQmtZ3TNgyDkTed6d7bxDDGlQJFR 49zTbiisQw65L8x8VmsLrN0+5s2jQigML8+Ye9nbY28XmzriWMv1zzOqg2Lhf38TKSgO VYrnPDdlGGpXWhzFEkWVH/Q/Bpu6+5mOT4i0pAJ10/8Ret+Y9ne2yrne05JSpWWDkRdG GGB7vKTzTS94wuHSxDU6IkP8CVMMDOq1bHKm2uAJrC2e8ucXG9aE/jN9CxEyNy/vtMxZ wHeg==
X-Gm-Message-State: AOAM533WYCY+jGtv/rUd0O2p5ilUHRn4UkJopmgouxA6PRYS5xad8+eI Q1CRuswSJGUIVHZ2DYq/kZMiEBt9kUIzchs8957Z/pwSwxw=
X-Google-Smtp-Source: ABdhPJzUYV8N06d5R7NSiJKjeZPittv1jgzAoC6EykR6ad+a/lv9NRViEJNW0Z34HpqZmK6e2A3GmpWBs7S/8ihHisg=
X-Received: by 2002:a5d:6dab:: with SMTP id u11mr8999913wrs.46.1636462809197; Tue, 09 Nov 2021 05:00:09 -0800 (PST)
MIME-Version: 1.0
References: <163311243544.13917.11736165165419008870@ietfa.amsl.com> <20211001190002.GC98042@kduck.mit.edu> <CABcZeBPQG82xJdwMrmj4-=9aJymo1xts=D6VZedBW5X9k+34cQ@mail.gmail.com> <92ed26c1-bfde-43c1-93f4-2bbdbd4f6ec1@www.fastmail.com> <CAChr6Sw6Rs42DfS8KgD3qasPcWM_gGZhWN5C4b7W7JsPy0wDzw@mail.gmail.com> <8796f867-12b8-41f8-b124-82b3ab0e2d32@www.fastmail.com> <CAChr6SyKAnBcE9t68coGGXFt9WPLuDuWtVKoCXrK+QrwAVtPXw@mail.gmail.com> <f1bcd676-13ad-49b3-a8e8-8a272e0124e3@www.fastmail.com> <CABcZeBNo0gKjNZOKPYJYraioaw6G=z5ibTqh-o9GkWsDkfDmSQ@mail.gmail.com> <c4d6f2e5-0712-42a6-aef5-0cbada7e149e@www.fastmail.com> <CABcZeBM6y-6ZqaLGZ=8qr+uBnWOOgczhcx=ruy5S=n-YrHweKg@mail.gmail.com> <ca676a77-b2c9-4926-9842-d1d6587206ed@www.fastmail.com> <CACykbs11rHUweXmR1NSU0N2rRjcQ8Sf1S+DY2LO7T+e6cLt+5w@mail.gmail.com>
In-Reply-To: <CACykbs11rHUweXmR1NSU0N2rRjcQ8Sf1S+DY2LO7T+e6cLt+5w@mail.gmail.com>
From: Dave Cridland <dave@cridland.net>
Date: Tue, 09 Nov 2021 12:59:58 +0000
Message-ID: <CAKHUCzz5ErY0xuBXVRuoNeZ3RS-7MwKrGH37kgZ=qwyqb-CgOg@mail.gmail.com>
To: jonathan.hoyland@gmail.com
Cc: Sam Whited <sam@samwhited.com>, KITTEN Working Group <kitten@ietf.org>, "<tls@ietf.org>" <tls@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/uT_QLJCw6mFRMVb2AJq_8iFMbTg>
Subject: 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
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Nov 2021 13:00:17 -0000

On Tue, 26 Oct 2021 at 17:33, Jonathan Hoyland
<jonathan.hoyland@gmail.com> wrote:
> 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.

As I understand your case, you're suggesting that if the same channel
binding is used on multiple authentication runs within the same TLS
session, there may be cases where this may result in weakening of the
bound authentication.

It is not clear to me that this is the case. The channel binding data
is known to both parties of the TLS session for the duration of the
TLS session, so it doesn't seem likely that reusing it could actually
cause problems here.

Most SASL or GSS-API based protocols do not allow multiple
authentications within a single connection, and therefore TLS session,
but there are exceptions.

I think the exceptions are:
* IMAP with draft-newman-imap-unauth - a three year old I-D not
published as an RFC.
* LDAP (and X.500 DAP) both allow multiple consecutive binds.

The suggestion you propose in the quote above is that a single message
could be replayed within one TLS session.

Replay resistance is generally baked into SASL and GSS-API mechanisms,
rather than the channel binding itself. This includes, for example,
SCRAM - replaying one of the messages would result in a failed
authentication whether or not TLS channel binding were to be used.
Some mechanisms are replayable - PLAIN being one - but these both
assume that the TLS session remains confidential, and also they do not
include channel binding information anyway. But there are SASL
mechanisms that have been proposed in the past that do not provide
replay resistance but do include a TLS channel binding. In these
cases, then, your attack is possible and hinges on the reuse of a TLS
channel binding.

The result would be that - on some IMAP and LDAP servers - an
authenticated user could reauthenticate as themselves.

Now, all this does assume that an attacker cannot break a TLS session
during the duration of a TLS session; that is, that we assume TLS
sessions maintain confidentiality, integrity, and authenticity during
the session at least. If this is not the case, then it's game over
anyway, on a number of levels, and your proposed attack (which, I
reiterate, is entirely unproven) makes no difference.

What we do not assume however is that the certificate remains
sacrosanct during this. Again, SASL mechanisms often (and again, this
includes SCRAM) handle their own mutual authentication, so not only
does the client authenticate to the server but the server has to prove
its identity to the client. Assuming ephemeral keying, then, an
attacker compromising the server's certificate doesn't actually make
as much difference as you'd think here. At this point I'm reaching the
edges of my knowledge, but I believe that although the identity as
authenticated by the server's certificate could be spoofed if the
certificate were compromised, ephemeral keying would still protect the
session and SASL mutual authentication would still authenticate the
server later.

Overall, therefore, I have to ask you to find some kind of concrete
attack. "Reusing an exported key within the same TLS session" does not
appear to form the core of an attack as you suggest.

Dave.