Re: [kitten] Kerberos preauth negotiation techniques

[Nathaniel McCallum <[e-mail]>]

On Wed, 2015-02-18 at 09:35 -0500, Simo Sorce wrote:
> On Wed, 2015-02-18 at 09:22 -0500, Nathaniel McCallum wrote:
> > On Wed, 2015-02-18 at 09:03 -0500, Simo Sorce wrote:
> > > On Tue, 2015-02-17 at 16:40 -0500, Nathaniel McCallum wrote:
> > > > 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
> > > I wonder ^^^ if this is problematic when canonicalization is
> > > requested ?
> > > 
> > > Simo.
> > 
> > I'm not sure. I hash whatever is in krb5_kdc_req.client.
> 
> Ok, as long as client and server are using the same name it is fine, 
> but it should probably be spelled out clearly that this is not the 
> canonical principal name but whatever name the client used.
> 
> > > > 3. the server principal
> > > > 4. all padata sent or received
> > 
> > I forgot to mention:
> > 5. The long term key used in the PAKE
> 
> Thanks, I thought something was amiss here :)

Two private things go into the final key hash:
1. the shared EC point derived from the key exchange: K
2. the long term key

Successfully attacking #1 breaks either the PAKE method or the DDH 
assumption.

Nathaniel