krb5_gic_init_creds_keytab and session key enctypes

[ghudson@MIT.EDU]

In April, I committed a change from Stef Walter to make
krb5_get_init_creds_keytab use the enctypes from the keytab in its
request, like Heimdal does.  This seemed like a no-brainer, but
unfortunately it has some unintended consequences.

The goal of this change is to constrain the enctypes of the reply key.
In a pure MIT deployment scenario, this is generally unnecessary,
because the keytab almost always matches the KDB entry for enctypes.
With an AD KDC, it is more often necessary because the enctypes for
the keytab are selected when the keytab is extracted, and not recorded
in the KDC's principal entry.

Unfortunately, the AS request's etype sequence constrains not only the
reply key, but also the ticket session key.  If the server principal
of the AS request doesn't appear to support any of the enctypes in the
client's keytab, the AS request will spuriously fail.  In this
scenario, RFC 4120 doesn't enable the client to convey its full
preferences (e.g. "I can only accept an AES-128 reply key, but I
support a bunch of session key enctypes"), so the client has a choice
of bad assumptions.  It can send its preference list of session key
enctypes and hope that the KDC will pick a reply key in its keytab, or
it can send its preference list of reply key enctypes and hope that
the server principal supports one of them for a session key.

Now, 99% of the time, the server principal of an AS request is a
krbtgt principal.  In the real world, I would expect this problem to
crop up for realms which are migrating off DES, have stopped creating
DES keys for new services, but haven't yet updated their local krbtgt
principals to contain anything besides a DES key.  In this case, the
KDC could perhaps make more optimistic assumptions about session key
enctype support than it does for other server principals.  It
certainly knows all of its own permitted session key enctypes.  But it
doesn't necessarily know what session key enctypes are supported by
other KDCs in the realm.

So here are the options I can see:

1. Ignore the problem.  Tell anyone who runs into it to add more
enctypes to their krbtgt principal (with cpw -randkey -keepold).

2. Revert the gic_keytab change.  Continue to tell anyone who runs
into the original problem with to get a keytab with the right
enctypes.

3. Make the KDC ignore the keys in krbtgt/localrealm and assume that
krbtgt tickets support all of the KDC's permitted enctypes.  In
mixed-KDC-version scenarios, this could cause a KDC to issue tickets
which a different KDC in the realm can't process.

4. As in (3), but only as a last ditch effort if an AS request would
otherwise fail because the client and krbtgt enctype lists don't
match.

I'm going to work on (4) for now since it's the least likely to
present real-world problems as far as I can tell.  It's a little more
complicated than I would like, but I don't see a way around that.