GSS-krb5 and enctype lists, revisited

[Ken Raeburn]

Okay, Tom and Sam and I talked about this a while today, and here's
the idea we've come up with for the short term:

We track config-file (or compiled-in) default_tgs_enctypes and
application-supplied list separately in krb5_context.  When getting an
intermediate TGT, from the ccache or from a KDC, use the config-file
version only; when getting the ultimate application ticket (even if
it's a TGT for a user running a kvno-like program), prefer the
application-supplied list if any.  Distinguish the two with some
context flag, or an added argument to some internal API (unspecified,
I'm about to go look into that).

Then we should be able to acquire and use AES TGT session keys to get
GSS-supported tickets.

Eventually, as Sam described, we'll deprecate the separate
default_tgs_enctypes and default_tkt_enctypes, and just go with one
default_etypes list.  (With permitted_enctypes probably staying a
separate, unordered list acting as a filter on the other lists and
other lookups?)

We may have problems with this when we start relying on KDC referrals.
(You send a request to your KDC for a {3DES, RC4, DES} ticket for
ftp/fooserver, and it sends you back a cross-realm TGT, needlessly
restricted in enctype by the list of enctypes supported by the GSS
code, because it can't distinguish between the enctypes supported by
the application protocol, and the enctypes supported by the krb5 code
for talking to the KDC.)  But we can burn that bridge when we get to
it...

Ken