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