Re: [kitten] Kerberos preauth negotiation techniques

Nathaniel McCallum <> Tue, 17 February 2015 17:58 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7957D1A896A for <>; Tue, 17 Feb 2015 09:58:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.912
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ed3cZ4rW7R50 for <>; Tue, 17 Feb 2015 09:58:22 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A1B811A1EE8 for <>; Tue, 17 Feb 2015 09:58:22 -0800 (PST)
Received: from ( []) by (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 ( []) by (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: <>
From: Nathaniel McCallum <>
To: Nico Williams <>
Date: Tue, 17 Feb 2015 12:58:19 -0500
In-Reply-To: <20150217173713.GI5246@localhost>
References: <> <> <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
Archived-At: <>
Subject: Re: [kitten] Kerberos preauth negotiation techniques
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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:

    ptypes SEQUENCE (SIZE(1..MAX)) OF Int32,
    supports SEQUENCE (SIZE(1..MAX)) OF PAKESupport,

PAKESupport ::= SEQUENCE {
    etype Int32,

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.


> 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