Re: [kitten] Kerberos preauth negotiation techniques

[Nathaniel McCallum <[e-mail]>]

On Tue, 2015-02-17 at 13:58 -0600, Nico Williams wrote:
> 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.

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.

Given the above, hashes are supported per etype.

I currently do something similar for the groups. An elliptic curve 
group can only be used for an etype if its field size is >=1.75x the 
key size. For example, P-224 can be used for generating 128bit keys, 
but not for 256bit keys.

Given the above, groups are supported per etype.

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

Because this contains the lists of supported groups and hashes for 
that specific etype.

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

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.

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

What we can do and what we should do are different things. We can make 
large keys from small seeds. But I think allowing this makes for 
unclear security situations. I would prefer limiting the parameters 
for an etype to only those which do not degrade the security 
expectations of that etype.

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

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.

Nathaniel