[OpenAFS-devel] configurable cryptosystem support

[Jeffrey Hutzelman]

On Thu, 18 Jan 2007, Marcus Watts wrote:

> > BTW, I do wish you would configure in terms of the standard enctypes,
> > rather than configuring the underlying algorithms.
>
> That creates a whole bunch of problems.  Like, what do you mean
> "standard" enctypes?

I mean that you should use the names listed for each enctype in the IANA
registry at http://www.iana.org/assignments/kerberos-parameters.

> What about "non-standard" enctypes?

There are no registered enctypes which have valid names.

> The checksum types are in even worse disarray.  One of the more
> horrendous problems I had with rxk5 was in selecting the appropriate
> checksum type to go with a given keytype.

With a couple of exceptions needed to support legacy software, the correct
checksum type to use is always the one that is indicated as mandatory to
implement by the definition of the enctype you are using.  Specification
of this cksumtype is a required part of an enctype profile.  I agree it is
unfortunate that there is no common API for mapping an enctype to its
corresponding cksumtype.

In particular...

> The most useful checksum
> typed turned out to be CKSUMTYPE_HMAC_SHA1_DES3, because
> it's universally implemented and doesn't actually use des3
> so doesn't care what key type.

You cannot safely do this, because a keyed checksum can only be used with
its corresponding enctype, _even if it appears not to use the key_.  The
reason is that one of the required inputs is a key of the correct type,
and compliant implementations may be unwilling or unable to combine a
keyed checksum with the wrong enctype, even if it would work.



> The most useful distinction I would have gained with finer grain configuration
> is the ability to separately enable 17 and 18.  Almost all other
> choices I might have mader are either irrelevant or worse.  Out of etypes
> 4 5 6 7 16, only 16 is useful for des3.  Out of 1 2 3 8, 1 and 3
> are clearly necessary, 2 is silly but harmless, 8 is interesting but
> doesn't exist in heimdal, and all of these are basically insecure on
> account of limited keysize.  jaltman was asking that 1 2 3 8 be disabled
> wholesale at least by default in openafs.  Out of 23 24, jaltman already
> made the case for just not bothering with 24.

See, if you had used names instead of numbers, I'd know which algorithms
you were talking about.

-- Jeff