Re: [kitten] Kerberos preauth negotiation techniques

Nico Williams <> Wed, 18 February 2015 16:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8AF961A1EE9 for <>; Wed, 18 Feb 2015 08:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.666
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id lSjImNjLWyvE for <>; Wed, 18 Feb 2015 08:28:03 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 26E571A889C for <>; Wed, 18 Feb 2015 08:28:03 -0800 (PST)
Received: from (localhost []) by (Postfix) with ESMTP id B69EB438082; Wed, 18 Feb 2015 08:28:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to;; bh=Gu/F+mS0/+tmpq JlF5sVodvOCPY=; b=sKTzEfBBzkJYQkswmMM9F4o3gk7m4GyO//FPc3cWuuxMRj tl/0i/d0QfYSFT5x0jzPu+hD6LpVhfa4TgdaEux6mlg2XLddAOYLQslyVdXov8fw k/ETKc1BmsibZTQqJC5NsprtvHM9QwD0Lg7Qod/geJ0ag42GiKcMFpv/aNrsc=
Received: from localhost ( []) (Authenticated sender: by (Postfix) with ESMTPA id CA204438080; Wed, 18 Feb 2015 08:28:01 -0800 (PST)
Date: Wed, 18 Feb 2015 10:28:00 -0600
From: Nico Williams <>
To: Nathaniel McCallum <>
Message-ID: <20150218162755.GQ5246@localhost>
References: <> <> <20150217173713.GI5246@localhost> <> <20150217195815.GJ5246@localhost> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.5.21 (2010-09-15)
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: Wed, 18 Feb 2015 16:28:04 -0000

On Tue, Feb 17, 2015 at 04:40:00PM -0500, Nathaniel McCallum wrote:
> In the current code, the actual key is generated by a hash of:
> 1. the shared EC point: K
> 2. the client principal
> 3. the server principal
> 4. all padata sent or received
> Currently, we do not truncate hashes to fit key size. So the hash 
> output must exactly match the expected size of the key. This is the 
> reason MD5 is enabled (to support 128bit keys). This is not a long 
> term plan. However, we should not allow, for instance, SHA1 to be used 
> to generate a 256bit key.

Requiring that hash function outputs match enctype key sizes is
terrible.  Use a KDF, it's what it's there for; Kerberos has one.

> Given the above, hashes are supported per etype.

Don't do it that way :)

> > Why is etype not a sequence?
> Because this contains the lists of supported groups and hashes for 
> that specific etype.

See above and preceding reply.

> We don't need to send enctypes. This is already sent in etypes.


> Having them all be orthogonal is how I originally designed it. But I 
> changed it given the above considerations. Small hashes/ECs should not 
> be used to generate larger keys.

That's not right.  Smaller amounts of entropy can be used to generate
larger keys.  We do it all the time.  It's what KDFs are for.

Granted, one should not use *too* small an amount of entropy, but this
is about setting a proper security floor.

The client (and the AS) should set a security floor, say, 128-bit,
192-bit, or 256-bit.  It should probably also set a ceiling (since we
have no ciphers stronger than 256-bit, there's no point using groups at
much higher security levels).

Above the security floor, anything goes.  Use a KDF to overcome
impedance mismatches.

> I think you mean 1 with the optimization (3) being optional. I only 
> wish to add that it should be optional for clients but required for 
> servers.