Enctype configuration

[ghudson@MIT.EDU]

I'm soliciting ideas on enctype configuration changes for 1.8.  Tom
has a skeletal early project page at:

  http://k5wiki.kerberos.org/wiki/Projects/Enctype_config_enhancements

The primary deliverable here is the ability to modify the default list
of enctypes without completely replacing it.  So the first question is
what syntax to introduce for that.  OpenSSL has one but it's probably
too complicated for our purposes.  Tom proposed one in the project
page which is probably fine.

A secondary deliverable is making such modifications easier.  We
currently have four basic families of enctypes: des, des3, rc4, and
aes.  For each family we have 1-3 entries on the default enctypes list
and some anciliary enctypes which you wouldn't generally want to use
(e.g. rc4-hmac-exp and des-cbc-raw).  To remove DES from today's
default list in Tom's proposed syntax, you would have to write:

  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4

and if you're paranoid about the non-default DES enctypes, you might
decide to write:

  DEFAULT -des-cbc-crc -des-cbc-md5 -des-cbc-md4 -des-cbc-raw -des-hmac-sha1

We could make this easier through some kind of globbing, or through
syntaxes for adding or disabling enctypes based on algorithmic
components ("exclude anything using DES", "exclude anything using
MD5").  Alternatively, we could formally define the four enctype
families and allow inclusion and exclusion by family.  The presence of
undesirable enctypes like rc4-hmac-exp complicates the issue a bit; if
an configuration option says "include the RC4 family" then we wouldn't
want to add 40-bit RC4 to the list, but if an option says "exclude the
RC4 family" we would definitely want to exclude it.  Of course, these
undesirable enctypes aren't on the default list in the first place, so
perhaps there's no real issue.

If we're going to address the secondary deliverable at all, I would
lean towards using the families option, because it gives the
administrator less rope than globbing or algorithmic component
matching.

Finally, there is a third, ancillary issue, which is the
supported_enctypes variable tells kadmin what key/salt combinations to
create keys for from a user's password.  Because the variable includes
salt types as well as enctypes, it would be complicated to directly
apply any new syntax to this variable.

What I would like to see happen here is for us to stop supporting salt
type configuration.  Ken suggested some time ago that we should just
generate a random explicit salt for every new principal.  If we make
that change, supported_enctypes can become a straight enctype list
using the same syntax as the other three enctype variables.  For
backward compatibility, we would have to accept and ignore :salttype
specifiers after enctypes, of course.  It would take a little extra
time to implement this, but it would also carry side benefits.