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

[Nico Williams <[e-mail]>]

On Mon, Dec 02, 2013 at 04:38:52PM -0500, Jeffrey Hutzelman wrote:
> On Mon, 2013-12-02 at 15:04 -0600, Nico Williams wrote:
> > 2)  [...]
> 
> Oh, look; you've just made my point for me. :-)

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

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

> 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.

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.

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

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

> It might be useful for Kerberos libraries, admin tools, and KDC
> 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.

> 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.

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