Re: [kitten] Kerberos preauth negotiation techniques

Nico Williams <nico@cryptonector.com> Tue, 17 February 2015 19:58 UTC

Return-Path: <nico@cryptonector.com>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 004AA1A884E for <kitten@ietfa.amsl.com>; Tue, 17 Feb 2015 11:58:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.666
X-Spam-Level:
X-Spam-Status: No, score=-1.666 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
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 vFmbO5dSyr1o for <kitten@ietfa.amsl.com>; Tue, 17 Feb 2015 11:58:20 -0800 (PST)
Received: from homiemail-a107.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) by ietfa.amsl.com (Postfix) with ESMTP id 9BB4C1A1AFA for <kitten@ietf.org>; Tue, 17 Feb 2015 11:58:20 -0800 (PST)
Received: from homiemail-a107.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTP id 63AA62004F4DE; Tue, 17 Feb 2015 11:58:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=Bc3OZ7Vef793AW TTZR/RS/zsTE0=; b=vw9aTFdJaQQ3qtPxgG1d8M1pZQyHK8RgEHY0kyWziJFCcR U0eRly/Qf5DZPGRMzu8LkOcn5gFdytzFn+R6xl20PYHgEaoiQppO1BzYFiYAmmvJ v2fG5lW3CVVdvqWGiz5w04Q6jI2b/QB6tiUZL6FfjPGzRM/6htAgsMMh9SCu0=
Received: from localhost (108-207-244-174.lightspeed.austtx.sbcglobal.net [108.207.244.174]) (Authenticated sender: nico@cryptonector.com) by homiemail-a107.g.dreamhost.com (Postfix) with ESMTPA id 0951A2004F4CA; Tue, 17 Feb 2015 11:58:19 -0800 (PST)
Date: Tue, 17 Feb 2015 13:58:19 -0600
From: Nico Williams <nico@cryptonector.com>
To: Nathaniel McCallum <npmccallum@redhat.com>
Message-ID: <20150217195815.GJ5246@localhost>
References: <x7da90k47ox.fsf@equal-rites.mit.edu> <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost> <1424195899.2645.36.camel@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1424195899.2645.36.camel@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/_D9vaV8mzLgFDGT8_wyhnurp4Oo>
Cc: kitten@ietf.org
Subject: Re: [kitten] Kerberos preauth negotiation techniques
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 17 Feb 2015 19:58:22 -0000

On Tue, Feb 17, 2015 at 12:58:19PM -0500, Nathaniel McCallum wrote:
> On Tue, 2015-02-17 at 11:37 -0600, Nico Williams wrote:
> > On Tue, Feb 17, 2015 at 11:14:35AM -0500, Nathaniel McCallum wrote:
> > > I see 1 and 3 as the only good options. Having to register group 
> > > parameters instead of using OIDs is a deal-breaker in my book.
> > 
> > I also prefer not to have to add registration of groups.  I'm not 
> > sure that I want to have any support for negotiable group parameters 
> > though, if that's what you meant.  I'd rather have well-known curves 
> > (groups) suitable for discrete codepoint assignments regardless of 
> > whether we have/need a registry.
> 
> That was not what I meant. I meant parameters of the exchange. Current 
> parameters are:
> * PAKE method (currently: SPAKE and JPAKE; needs registration)
> * Group (currently: only standardized elliptic curve groups)
> * Hash (currently: MD5, SHA1, SHA2-*)

[I covered that elsewhere.]  Assuming these are all orthogonal (they
should be), then pseudo-enctypes work, but need a registry.  OIDs are
much better (though larger) because we can then outsource the registry
to CFRG and friends.

> Currently, I advertise these as:
> 
> PAKEInfo ::= SEQUENCE {
>     ptypes SEQUENCE (SIZE(1..MAX)) OF Int32,
>     supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport,
>     ...
> }
> 
> PAKESupport ::= SEQUENCE {
>     etype Int32,
>     groups SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER,
>     hashes SEQUENCE (SIZE(1..MAX)) OF OBJECT IDENTIFIER,
>     ...
> }

Why is etype not a sequence?

> The drawback to this approach is that groups or hashes supported by 
> multiple enctypes get listed multiple times. However, this also 
> captures that some groups/hashes are only usable for some enctypes. 

If all of these are orthogonal (they should be) then we should just send
sequences (sets, really, but ASN.1 SEQUENCEs) of enctypes, PAKEs, groups
(curves; we're not likely to bother with non-EC DH, right?), and hash
functions (and/or KDF??).

> Generally this relates to key size and protects large keys from being 
> generated by small curves.

I don't see why that should be a problem.  It should be possible to
generate a key for AES-256 from a 128-bit shared secret.  That's one
reason for PRFs/KDFs: so we can resolve such impedance mismatches.

> > On the whole I prefer (3).  I agree that it's an optimization that 
> > could come later though.  But it's also an optimization that clients 
> > could implement immediately (with the fallback penalty); it's only 
> > the AS where more work is needed.
> 
> Having implemented it, the AS side is easy. The client is harder. That 
> is at least the case on the MIT codebase. I suspect it is true of all 
> implementations.

Interesting.  All the better.  Let's go with (3), with the optimization
being optional.  Some clients will do (1), and that's OK.

Nico
--