krb5_gic_init_creds_keytab and session key enctypes

[Nico Williams]

Have you tried making krb5_get_init_creds_keytab() use PA-ENC-TSTAMP?
I would think that the reply key must be [derived from] the same (and,
therefore, of same enctype) as the [precursor for the] key that was
used for the encrypted timestamp.  I don't think RFC4120 says this is
so, but it makes sense, and I suspect KDCs do in fact work this way
(it's Sunday night; I'm not going to check right now, although at a
glance Heimdal does seem to do this but looking at
finish_process_as_req(), MIT perhaps not), and if not, then darn it,
they should.  The the request etypes can then continue to be the
default_tkt_enctypes.

But let's suppose that that doesn't work universally well.  Then
simply take the default_tkt_enctypes and re-order it so that all the
enctypes for which the service has keys in its keytab come first (but
preferably still with the same relative order as in the original
default_tkt_enctypes) and the others (if any) come last (also
preserving the original relative ordering between them).  I believe
MIT and Heimdal KDCs by default honor the order of preference in the
request etypes.

You could also try both of these approaches, pre-auth + re-ordering
the request etypes so keytab enctypes come first.

Nico
--