Re: [kitten] Kerberos preauth negotiation techniques

[Nico Williams <[e-mail]>]

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.

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

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

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

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

Nico
--