Subject: Re: [kitten] New s2k and exposing the strength (iteration count) part of s2kparams

From: Jeffrey Hutzelman <[email-masked]>
Date: Mon, 02 Dec 2013 16:38:52 -0500

On Mon, 2013-12-02 at 15:04 -0600, Nico Williams wrote:
> ISTM that we should:
> 
> 1) Expose the iteration count of the otherwise-opaque s2k params, and
> standardize it, renaming it a strength indication and leaving its
> interpretation as mechanism-specific.  I.e., from now on all new
> enctypes with s2kparams will have theirs start with a four-octet,
> network byte order unsigned measure of strength.

I don't think that's necessary.  The s2k parameters aren't really
opaque; they're enctype-specific and pseudo-opaque at the Kerberos
protocol layer, in the same way that PA-DATA and authorization data are.
IMHO it works better that way, because it means we can carry such things
end-to-end without all of the intermediate pieces having to understand
them.  This has brought us extensibility that otherwise would have been
impossible, and even some that we previously thought _was_ impossible
(e.g. ticket extensions using a magic enctype).

It might be useful for Kerberos libraries, admin tools, and KDC
implementations to include interfaces for managing s2k parameters.
However, I don't think doing so requires that we mandate that future
enctypes use a particular format for s2k parameters, or use a single
linear "strength" parameter.  Future S2K algorithms may have arbitrary
numbers of parameters, and while it may be possible and even desirable
to compute a single "strength indication" from those parameters, the
operation is not likely to be reversible, which means that s2k params
will need to encode the actual individual parameters.

> 2)  It'd be nice if we could add memory-hard s2k functions.  I'm not
> sure what NIST is prepared to consider here.  I guess anything
> provably not weaker than PBKDF2 should be acceptable, but I'm not sure
> how to construct such a thing (XOR of two s2ks is not necessarily
> provably not weaker than either of the s2ks; consider the case where
> they are the same s2k!).
> 
> For a memory- and compute-hard s2k the strength measure might be
> composed of two numbers, one indicating memory strength and the other
> indicating compute strength.

Oh, look; you've just made my point for me. :-)

-- Jeff

---

From: Nico Williams <[email-masked]>
Date: Mon, 2 Dec 2013 16:02:03 -0600

On Mon, Dec 02, 2013 at 04:38:52PM -0500, Jeffrey Hutzelman wrote:
> > 2)  [...]

Maybe I should start writing backwards :)  (Hey look, I'm responding
backwards!)

> > network byte order unsigned measure of strength.

I conflated two things, actually: on-the-wire representation, and
logical representation.  Let me clarify my proposal in light of that:

 - every new enctype shall have a 32-bit unsigned integer strength
   measure

 - I don't care how that's represented on the wire (but I think it'd be
   convenient to stick to my original proposal above)

> protocol layer, in the same way that PA-DATA and authorization data are.

They are most definitely opaque (OCTET STRING) because they are enctype-
specific and layers above the enctype musn't interpret them, which means
that...

...in practice what has happened is that this opaqueness has been an
impediment to exposing these parameters in any interfaces (CLIs, GUIs,
BUIs, APIs) other than configuration, and changing the default therefore
results in non-interoperability (e.g., can't use ktutil to add password-
derived keys to a keytab -- I know, that's almost a useful authorization
feature, except it's neither).

Yes, we could preserve opaqueness of s2kparams at all layers above the
enctype and yet manage to add suitable interfaces.  But we've had a
decade and we haven't.  I think that's evidence that the original
approach hasn't worked well.  We should either hardcode the s2kparams or
provide at least one knob that all can share.

> (e.g. ticket extensions using a magic enctype).

In theory I agree, in practice I don't.

> implementations to include interfaces for managing s2k parameters.

It most definitely would be.  It hasn't happened.  We've had a decade.
Perhaps if we make such interfaces a requirement implementors will get
to it?  I doubt it...  There's no Internet standard-compliance police.

> will need to encode the actual individual parameters.

I understand this quite well.  I don't think that argument will cause
implementors to finally add the missing interfaces.  Therefore I'd
rather settle for a much-more-likely-to-succeed compromise.  A single
synthetic strength measure is *clearly* problematic (you and I, and
others on this list too, have commiserated over SASL's SSF many a time,
so you know I agree), but for s2kparams it's much more workable and less
dangerous than for mechanisms that involve negotiations (which is half
the source of SSF's problems).

Nico
--