Re: [kitten] Kerberos preauth negotiation techniques

[Simo Sorce <[e-mail]>]

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 :)

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York