Re: [kitten] Kerberos preauth negotiation techniques

Nathaniel McCallum <npmccallum@redhat.com> Tue, 17 February 2015 17:58 UTC

Return-Path: <npmccallum@redhat.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 7957D1A896A for <kitten@ietfa.amsl.com>; Tue, 17 Feb 2015 09:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.912
X-Spam-Level:
X-Spam-Status: No, score=-5.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=0.999, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ed3cZ4rW7R50 for <kitten@ietfa.amsl.com>; Tue, 17 Feb 2015 09:58:22 -0800 (PST)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 A1B811A1EE8 for <kitten@ietf.org>; Tue, 17 Feb 2015 09:58:22 -0800 (PST)
Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t1HHwLTQ019049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 17 Feb 2015 12:58:21 -0500
Received: from vpn-50-159.rdu2.redhat.com (vpn-50-159.rdu2.redhat.com [10.10.50.159]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t1HHwJZT020961 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 17 Feb 2015 12:58:20 -0500
Message-ID: <1424195899.2645.36.camel@redhat.com>
From: Nathaniel McCallum <npmccallum@redhat.com>
To: Nico Williams <nico@cryptonector.com>
Date: Tue, 17 Feb 2015 12:58:19 -0500
In-Reply-To: <20150217173713.GI5246@localhost>
References: <x7da90k47ox.fsf@equal-rites.mit.edu> <1424189675.2645.23.camel@redhat.com> <20150217173713.GI5246@localhost>
Content-Type: text/plain; charset="UTF-8"
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.26
Archived-At: <http://mailarchive.ietf.org/arch/msg/kitten/btNzvHzR2LViUiVduNCiU7F6LNw>
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 17:58:24 -0000

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

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,
    ...
}

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. 
Generally this relates to key size and protects large keys from being 
generated by small curves.

I'm open to alternatives.

> However, a single popular use case for negotiable groups will make 
> (2) utterly inapplicable, and that's the best case for not 
> considering (2), IMO.

+1

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

Nathaniel