Re: [kitten] SPAKE and non-deterministic RFC 3961 checksums

[Simo Sorce <[e-mail]>]

On Sat, 2017-09-23 at 14:05 -0500, Benjamin Kaduk wrote:
> On Wed, Sep 20, 2017 at 11:09:29AM -0400, Simo Sorce wrote:
> > On Mon, 2017-09-18 at 20:59 -0500, Benjamin Kaduk wrote:
> > > On Sun, Sep 17, 2017 at 01:24:51AM -0400, Greg Hudson wrote:
> > > > 
> > > > The potential remedies I can think of fall into these bins:
> > > > 
> > > > 1. Don't change the SPAKE design.  Instead, update RFC 3961 to
> > > > specify
> > > > that new checksum types must be deterministic, and specify that
> > > > SPAKE
> > > > preauth can't be used with single-DES keys.  Aside from the
> > > > standards-space cost of pushing our problem down into a lower
> > > > layer, the
> > > > prohibition against using SPAKE with single-DES keys could make
> > > > it
> > > > harder for clients to be configured to refuse encrypted
> > > > timestamp
> > > > preauth on a pre-realm basis.  That is perhaps not a large cost
> > > > as
> > > > Kerberos implementations are moving away from single-DES
> > > > support
> > > > anyway.
> > > > 
> > > > 2. A relatively quick fix: use PRF instead of checksum.  (Or
> > > > PRF+,
> > > > in
> > > > which case we have to decide how much length of output we
> > > > want.)  I
> > > > think PRF has the requisite properties, but I would want to
> > > > think
> > > > on it
> > > > more.
> > > 
> > > This is probably the most appealing option, provided we can
> > > accurately
> > > state which properties we need (and they are provided by PRF(+)).
> > 
> > Why is this more appealing than just saying no to DES ?
> > Do we have any concern we may get future enc types that have non-
> > deterministic checksums ?
> 
> There's two aspects that push me this way: first, from a standards process
> point of view, now we have to also Update a core protocol spec and hope
> that people remember to check our new document whenver they try to make
> a new enctype/checksum type.  While it's unlikely that a hyptoehtical
> future document would actually get through the full process with such an
> error, it does add to the burden on future work in this space.  The second
> concern relates to implementations, in that there will need to be some sort
> of logic to handle the interaction of single-DES and SPAKE preauth.  If
> we were in a place where implementations were actively removing the code
> for single-DES support, I would not see this as an issue, but my understanding
> is that we're still several years (at least!) away from completely removing
> the code (as opposed to just not using it by default).  Even though we
> know that no one ought to be using the two things together, our code still
> has to come up with something to do in that case, and if we get the logic
> wrong things could break badly.

Why not simply state in the spake document that single-DES MUST NOT be
supported ?

> > > > 3. We could use a hash (it doesn't need to be keyed)
> > > > independent of
> > > > RFC
> > > > 3961.  The hash algorithm could be specified in the group
> > > > profile,
> > > > perhaps, but I believe the rejected-optimistic-challenge case
> > > > poses
> > > > a
> > > > difficulty for that design.
> > > 
> > > The hash algorithm could also be negotiated independently (so
> > > that in
> > > practice, e.g., sha256 is always used, at least in the initial
> > > deployments).
> > > For the rejected-optimistic case there is still an issue, but if
> > > the
> > > KDC
> > > only supports O(2) hash algorithms during a hash transition, then
> > > the
> > > amount of state needed in the cookie is bounded by a number that
> > > might
> > > be smaller than the number of supported groups (but then again,
> > > might
> > > not).
> > 
> > The nice thing about using the enctypes is that as new ones will
> > come
> > out with new, stronger checksums, we'll get those automatically,
> > without adding a new thing to negotiate ...
> 
> That is a good point, about the required checksum being matched in
> perceived strength, and that holding as an invariant in the future.
> 
> > > > 4. The most open-ended option is to back up and reconsider the
> > > > purpose
> > > > of the transcript checksum, which is to bind at least the
> > > > public
> > > > keys
> > > > into key derivation.  The current transcript also binds in
> > > > group
> > > > negotiation and the initial factor challenge.  I can't
> > > > immediately
> > > > think
> > > > of an alternative design which doesn't require the KDC to store
> > > > a
> > > > lot of
> > > > information in the cookie.
> > > 
> > > I agree that we are likely to end up with something resembling a
> > > "transcript hash", even if it does not directly use a hash
> > > primitve.
> > 
> > I have to say that between PRF and a separate Hash I would rather
> > use a
> > separate hash.
> 
> Hmm, so no we have a split on 2 vs. 3, unless we can somehow make 1
> more
> appetizing.  Do we have the collective will to make single-DES
> actually
> go away entirely and force any continued users to either run custom
> solutions
> or stay on old software?

I say that if you are on old software you have bigger problems to deal
with than not being able to use SPAKE, and having SPAKE actively
disallow a knowingly broken enctype is not a bad thing at all. It gives
you one more lever to get off of DES.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc