Re: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation
Nico Williams <nico@cryptonector.com> Mon, 06 May 2019 06:54 UTC
Return-Path: <nico@cryptonector.com>
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 C3B5D12008D for <kitten@ietfa.amsl.com>; Sun, 5 May 2019 23:54:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 UukEu7V0Sjn4 for <kitten@ietfa.amsl.com>; Sun, 5 May 2019 23:54:45 -0700 (PDT)
Received: from bird.maple.relay.mailchannels.net (bird.maple.relay.mailchannels.net [23.83.214.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392C112003E for <kitten@ietf.org>; Sun, 5 May 2019 23:54:44 -0700 (PDT)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 1C6365C4DD1; Mon, 6 May 2019 06:54:44 +0000 (UTC)
Received: from pdx1-sub0-mail-a49.g.dreamhost.com (unknown [100.96.28.64]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id CAFDE5C5153; Mon, 6 May 2019 06:54:43 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a49.g.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.17.2); Mon, 06 May 2019 06:54:44 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Harbor-Abiding: 77f8afc72c422f1e_1557125683913_1552231218
X-MC-Loop-Signature: 1557125683913:453305882
X-MC-Ingress-Time: 1557125683912
Received: from pdx1-sub0-mail-a49.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a49.g.dreamhost.com (Postfix) with ESMTP id 88792825C0; Sun, 5 May 2019 23:54:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:subject:message-id:references:mime-version:content-type :in-reply-to; s=cryptonector.com; bh=ltj54eDoSAKELEQoYsrlIfboeLk =; b=qg2GFbKV4+uNXnIpsDqI5JLraOvy5mgWjqHeZU31i2U3xpTeop4UrnYayxZ 3ZqNG2aZyjZUpxf5K6LDQpUcHPxB/xJBbGf7MosavmNNYtNY7djtDIvqP4uBdVqM 0y7KKmrdrONIZ9ReDHOwc9AA3C62k+StPfPorTuvTiP1NaKU=
Received: from localhost (unknown [24.28.108.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a49.g.dreamhost.com (Postfix) with ESMTPSA id 050348342B; Sun, 5 May 2019 23:54:42 -0700 (PDT)
Date: Mon, 06 May 2019 01:54:40 -0500
X-DH-BACKEND: pdx1-sub0-mail-a49
From: Nico Williams <nico@cryptonector.com>
To: kitten@ietf.org
Message-ID: <20190506065439.GG21049@localhost>
References: <20190506063408.GF21049@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190506063408.GF21049@localhost>
User-Agent: Mutt/1.9.4 (2018-02-28)
X-VR-OUT-STATUS: OK
X-VR-OUT-SCORE: 0
X-VR-OUT-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgeduuddrjeeigdduudeiucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuggftfghnshhusghstghrihgsvgdpffftgfetoffjqffuvfenuceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujggfsehttdertddtredvnecuhfhrohhmpefpihgtohcuhghilhhlihgrmhhsuceonhhitghosegtrhihphhtohhnvggtthhorhdrtghomheqnecukfhppedvgedrvdekrddutdekrddukeefnecurfgrrhgrmhepmhhouggvpehsmhhtphdphhgvlhhopehlohgtrghlhhhoshhtpdhinhgvthepvdegrddvkedruddtkedrudekfedprhgvthhurhhnqdhprghthheppfhitghoucghihhllhhirghmshcuoehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmqedpmhgrihhlfhhrohhmpehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmpdhnrhgtphhtthhopehnihgtohestghrhihpthhonhgvtghtohhrrdgtohhmnecuvehluhhsthgvrhfuihiivgeptd
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/_srknLSuVs4X5a1ijLDtaMoe-NY>
Subject: Re: [kitten] GSS & krb5 mutual auth flags aren't -- they are about key confirmation
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: Mon, 06 May 2019 06:54:47 -0000
On Mon, May 06, 2019 at 01:34:09AM -0500, Nico Williams wrote: > Did I miss any mechanisms? Yes: OAuth/SAML mechanisms. Any OAuth/SAML > [...] Also: IAKERB. Omitting key confirmation for IAKERB is a lot like omitting it for Kerberos, even though IAKERB necessarily needs more than one round trip. Also, any multi-round trip mechanism that can use something like TLS session resumption tickets to shorten subsequence security context establishments can be like Kerberos and support omission of key confirmation. I tend to think that PROT_READY is a much more fruitful way to optimize GSS mechanisms security context establishment. It also forces one to think long and hard about the security semantics and properties of "early data". The only protocols I can imagine where a single context establishment token is desirable and useful are stateless blind logging protocols. I know of no such protocols. But even if there were any, the overhead of sending {init_context_token, wrap_token} messages all the time would surely drive the protocol designer to opt for a more stateful design so that most messages can be just {context_ID, wrap_token}. Nico --
- [kitten] GSS & krb5 mutual auth flags aren't -- t… Nico Williams
- Re: [kitten] GSS & krb5 mutual auth flags aren't … Nico Williams
- Re: [kitten] GSS & krb5 mutual auth flags aren't … Martin Rex
- Re: [kitten] GSS & krb5 mutual auth flags aren't … Nico Williams
- Re: [kitten] GSS & krb5 mutual auth flags aren't … Martin Rex
- Re: [kitten] GSS & krb5 mutual auth flags aren't … Robbie Harwood