Re: [kitten] Kerberos preauth negotiation techniques

[Nico Williams <[e-mail]>]

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.

True.

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

Sure.

Nico
--