Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt

Luke Howard <lukeh@padl.com> Mon, 06 April 2020 23:03 UTC

Return-Path: <lukeh@padl.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 E2F1A3A0E89 for <kitten@ietfa.amsl.com>; Mon, 6 Apr 2020 16:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=padl.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 E5sTJDy803HP for <kitten@ietfa.amsl.com>; Mon, 6 Apr 2020 16:03:12 -0700 (PDT)
Received: from us.padl.com (us.padl.com [216.154.215.154]) (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 8D94D3A0E84 for <kitten@ietf.org>; Mon, 6 Apr 2020 16:03:12 -0700 (PDT)
Received: by us.padl.com with ESMTP id 036N2WL5015128; Mon, 6 Apr 2020 23:02:37 GMT
DKIM-Filter: OpenDKIM Filter v2.11.0 us.padl.com 036N2WL5015128
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=padl.com; s=default; t=1586214158; bh=ElXPyBjSGj4Wx4yJUYziO61hQgyBRmqcl9Tz2MwtLUs=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=uU8PBZE3id2WFq7MRzIxyuxZtuORAnMB857w1myx28LHYF+r+tDP3MgjZXVLuYJhV DV4pj1HwrRSodQzgHmlLxvoBIShc14EJfklnZX9OJzPjuRJrhlgLGuEBKqu5rTYSJC FUEBqzgalfJMoVBGx8S9emZGci4kGwqnV9NqbHnulT8j1CqbZV/NrkccHp94OCt7IT XaK155Wu9L+pkb8ZAVLpua4/I23pYoISoTKHPFzn+/BzCyDEjGly7yuf2pfIT8oEcv aK/QnD9qijYFVY6vdbYs45udJTFhdCYp9XTrwCqC3RviWcIqNisAwy8s5Wj40DS00O IPhmBfIn+zCpw==
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
From: Luke Howard <lukeh@padl.com>
In-Reply-To: <20200406154326.GL18021@localhost>
Date: Tue, 07 Apr 2020 09:02:32 +1000
Cc: "kitten@ietf.org" <kitten@ietf.org>, Jeffrey Altman <jaltman@auristor.com>, Greg Hudson <ghudson@mit.edu>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FF77E7BE-2CE7-47A9-9B91-A4CA5C4C5A61@padl.com>
References: <158604472122.27168.16112727090339772628@ietfa.amsl.com> <B2497A4F-81B3-42F9-AED1-CFECF1D9F7C0@padl.com> <20200405234929.GD18021@localhost> <20200406004444.GE18021@localhost> <DB682CC6-808B-45A6-998E-9EFBF50702B0@padl.com> <20200406154326.GL18021@localhost>
To: Nicolas Williams <nico@cryptonector.com>
X-Mailer: Apple Mail (2.3445.104.11)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/NWt-EfkltsheXiRTIpwrTBUcTSQ>
Subject: Re: [kitten] New Version Notification for draft-howard-gss-sanon-01.txt
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 Apr 2020 23:03:14 -0000

>> Happy to add this, but is it much of an attack? Both parties are
>> anonymous, so (as we discovered with GS2) this mechanism is completely
>> superfluous unless you intend to use a message protection service (or
>> PRF), which will fail in a replay attack.
> 
> For pure GSS/SAnon apps it probably makes no difference, but it might
> for future stacks combining SAnon with other things.

Fixed in draft and implementation. It is (as we discussed off-list) a MIC of the empty string.

> There's two options: the mech_dh method (add a directory) and
> leap-of-faith (learn the keys once, keep reusing them.
> 
> You wanted to leave the mech_dh thing out of scope, so let's do that.
> 
> In Sun's mech_dh there were pluggable name service switch modules for
> the "publickey" DB, with files, nisplus, and ldap shipping in Solaris.
> That was... a long time ago.  Today we'd use DNS w/ DNSSEC (DANE).
> 
> The leap-of-faith thing would work like this: the initiator uses
> well-known anon names to set up a security context with some acceptor,
> then inquires the resulting initiator and acceptor names, and later sets
> up new contexts using the same keys (which might not work if the private
> keys are gone).  To make this work at all we'd need a bit on the wire
> for indicating that you want the keys to be less-ephemeral.

Given mech_ecdh will be a new mechanism with a new OID (and GUID!), then we can change the wire format to include a flags field.

Thanks again for the input!

Cheers,
Luke