Re: [kitten] SASL, how to choose the type of channel binding?
Dave Cridland <dave@cridland.net> Wed, 29 April 2020 08:17 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 CCAF43A053E for <kitten@ietfa.amsl.com>; Wed, 29 Apr 2020 01:17:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 MHPjbmf12tzt for <kitten@ietfa.amsl.com>; Wed, 29 Apr 2020 01:17:23 -0700 (PDT)
Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 363463A0524 for <kitten@ietf.org>; Wed, 29 Apr 2020 01:17:23 -0700 (PDT)
Received: by mail-wr1-x42c.google.com with SMTP id g13so1355744wrb.8 for <kitten@ietf.org>; Wed, 29 Apr 2020 01:17:23 -0700 (PDT)
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=/WL/aEHoCMwvymj15dXIHFOXXF6ZrSNRvO3Pc9D1cqA=; b=Q616FgR4XVL66KlE1fUFVPt5wwwg41OdsqjxabnmmSaPmcI37giuvIBQIY9dvBHM6H XmQpe3IiUwDzhICUrhSz50flM9jbJ1IRRE57B3bPZKTPfyDMin3K8lVFpEvtRA+49LBd TkKK4yCyT0KbLaUayWl5wVmr/lUtmi2xl9HK8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/WL/aEHoCMwvymj15dXIHFOXXF6ZrSNRvO3Pc9D1cqA=; b=KbIt9ptuGaboQMuqU8LS09x388z9tXJp9lkm415+7GHQtKg6we7qrgy3kajLbQM4Cx KZcck09WtWD3bot1K8DKm4Qwo0FOo4zWL22Gquf1R5HsQdCJqQMoPHqH5R02lGH/hcEJ smFgsgtE1aLINJPcCYDcOCWC0f2HvK9csvw47SRbDG2FymUevD+spDZCMTnQl6XfAr+b VVSnXeq09uNSCsyVkEGWf6zoMiv5Yo7DLY559omlSCrHSKRVnPJRFhdojiSC/7LbohqG xqQ7z9AyrgDBfzh8CfofCsnOmC7Ckyj44nYc5s25yxKHh6q1ddT/C+qz71XLnPD6tqXN KqMA==
X-Gm-Message-State: AGi0PubdjCXao0dAVY1ARr1FUdrHH00KEFG+2NK6gog333chNInu1Meb IBuVyMpb7L/rd9+4+MUxNBYkLdavswDFK3xKFpNn9afDVOkGRw==
X-Google-Smtp-Source: APiQypKvQz2zf9lw+ausHTqa2gv4KC/BRlZpFE55rUp0UmJAWH71pZr3tAXwFm1/twgKXoaoMCfcEITdkEVrbtzem5k=
X-Received: by 2002:adf:e403:: with SMTP id g3mr38196524wrm.121.1588148241362; Wed, 29 Apr 2020 01:17:21 -0700 (PDT)
MIME-Version: 1.0
References: <5E8F1ED9.1020108@openfortress.nl> <87zhb4jzhv.fsf@latte.josefsson.org> <CAKHUCzyLpcnBWbe8-kaDgE-6NFWSe_3SkxewaJ6kYFmD-dRiDA@mail.gmail.com> <87h7x3kyxu.fsf@latte.josefsson.org>
In-Reply-To: <87h7x3kyxu.fsf@latte.josefsson.org>
From: Dave Cridland <dave@cridland.net>
Date: Wed, 29 Apr 2020 09:17:10 +0100
Message-ID: <CAKHUCzwwHYa-5NQTXdHFJmViPrbL9j+yuYYFRqONxufJyvgZrA@mail.gmail.com>
To: Simon Josefsson <simon@josefsson.org>
Cc: "kitten@ietf.org" <kitten@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000c708cb05a4699355"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/DDPMzXWJoNMtWjamNp7JkT88P60>
Subject: Re: [kitten] SASL, how to choose the type of channel binding?
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: Wed, 29 Apr 2020 08:17:27 -0000
On Tue, 28 Apr 2020 at 23:50, Simon Josefsson <simon@josefsson.org> wrote: > Dave Cridland <dave@cridland.net> writes: > > > On Tue, 21 Apr 2020 at 22:33, Simon Josefsson <simon= > > 40josefsson.org@dmarc.ietf.org> wrote: > > > >> Rick van Rein <rick@openfortress.nl> writes: > >> > >> > Hello, > >> > > >> > I can see that the GS2 negotiates *whether* to use channel binding, > but > >> > how can a client and server agree on *which* form to use? > >> > >> Practically it is hard-coded to 'tls-unique' that, alas, has security > >> issues. See RFC 7627. GS2 does not provide any facility to (reliably) > >> negotiate which channel binding type to use, that negotiation has to > >> come from the SASL application protocol or out-of-band. See section 5.2 > >> of the document. I don't recall any SASL application protocols that > >> provide this feature -- does anyone know of any example? > >> > > > > No, but the XMPP community uses channel bindings quite heavily (or at > > least, more so than anywhere else I've noticed). > > > > If you feel like throwing a XEP (or an I-D) toward the XSF on negotiation > > of channel bindings (should be a simple stream feature), you might find > > some interest there. > > I have started to think that this complexity of SCRAM/GS2 was a bad > idea. Providing a half-baked negotiation mechanisms for a security > critical component invites problems. I would be happier if this feature > was removed, and that the channel binding type negotiation happens > implicitly at SASL mechanism negotiation time. This is what happens in > practice today when SCRAM/GS2 always means tls-unique. If nobody knows > examples of, or intend to use, this feature, I think we should > discourage it before someone uses it. I'm actually not entirely sure what you mean by `this` in several cases here (in my defence, I've been doing a lot of JavaScript recently), so please forgive me if you think I've misunderstood you - I probably have. Within the XMPP world, SCRAM-SHA1 and SCRAM-SHA1-PLUS are MTI mechanisms. There are existing examples of libraries which cannot support tls-unique due to underlying access to the binding information being unavailable. These sometimes do not do channel binding at all, and sometimes use the tls-endpoint binding instead. The lack of explicit negotiation makes for entertaining cases here. Example: https://github.com/igniterealtime/Smack/commit/1f1bc236fd6650fba2f9e59e2aa03969b0700402 So this horse has left the station - it would be more beneficial to have a way that the server could advertise what channel bindings it supports, in my opinion, even if this mandates it would have to accept those binding types across any advertised mechanisms. That in turn isn't too bad, since the design of GS2 means that channel binding data is explicitly passed to the server, which is then trusted to verify it (rather than synthesize it anew). This means that an unknown channel binding can be accepted blind, in extremis. I don't like this design, I have to say, but it does have the advantage here. Without explicit advertising, though, a client is forced to assume (or just guess, or even make up a channel binding type on the spot). Dave.
- [kitten] SASL, how to choose the type of channel … Rick van Rein
- Re: [kitten] SASL, how to choose the type of chan… Rick van Rein
- Re: [kitten] SASL, how to choose the type of chan… Luke Howard
- Re: [kitten] SASL, how to choose the type of chan… Simon Josefsson
- Re: [kitten] SASL, how to choose the type of chan… Dave Cridland
- Re: [kitten] SASL, how to choose the type of chan… Rick van Rein
- Re: [kitten] SASL, how to choose the type of chan… Simon Josefsson
- Re: [kitten] SASL, how to choose the type of chan… Dave Cridland