Re: [kitten] Kerberos preauth negotiation techniques

[Nathaniel McCallum <[e-mail]>]

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.

> > 3. the server principal
> > 4. all padata sent or received

I forgot to mention:
5. The long term key used in the PAKE


> > 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
> > 
> > _______________________________________________
> > Kitten mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/kitten
> 
>