Keytab-based initiator creds design

[Nico Williams]

I've a very different proposal to make:

1) Introduce persistent (/var) and ephemeral (/run) locations for
per-user keytabs and such:

 - /{var, run}/krb5/user/$USER/keytab
 - /{var, run}/krb5/user/$USER/ccache
 - /{var, run}/krb5/user/$USER/default_principal
 - ...

There should be an env var specifying alternative locations.  The
search order should be:

 - env var, if present, always wins
 - ephemeral location
 - persistent location
 - traditional default ccache location (/tmp/krb5cc_<uid>) (this needs to
   be possible to disable in krb5.conf)

2) When gss_acquire_cred() is called with desired_name !=
GSS_C_NO_NAME then acquire a TGT if necessary for the given desired
name, or, if desired_name == GSS_C_NO_NAME, then acquire a TGT for the
default principal.  A default principal is: the default principal of
the user's ccache, if it exists, or the one found in the
default_principal file, or the principal of the first keytab entry in
the per-user keytab.

In fact, some of this logic could be buried deep in libkrb5
(krb5_get_cred*()) rather than in the mechanism.

3) When gss_init_sec_context() is called with then call
gss_acquire_cred with desired_name == GSS_C_NO_NAME, try to determine
the correct client principal name to use for the given target name,
then acquire a credential handle for that name, else acquire a
credential handle for GSS_C_NO_NAME.

4) Always write the credential acquired with a keytab to a ccache if
possible, but use a memory ccache if there are errors writing to the
file/dir/ccapi ccache.

Benefits:

 - this is fairly simple to understand and probably to implement
 - this can work for non-GSS krb5 apps too
 - configurable w/o env vars, but none are required to make it work
 - low surprise factor: no per-user keytab -> no credential acquisition
   with keytab
 - transparent to apps, and even to users if a pam_krb5 should want to
   setup a keytab for the user in the ephemeral location
   (a "user" might be an account for application automation, rather than
   for a human being who is present to interact, in which case the user
   may well have a keytab in the persistent location, but a ccache in the
   ephemeral location)
 - daemons that run with distinct UIDs can have distinct configurations
 - daemons can also have distinct configurations via env vars should
   they not run with distinct UIDs

Nico
--