Keytab-based initiator creds design

[Greg Hudson]

I misunderstood Nico's proposal.  It's a little simpler and much more 
collection-friendly than I had thought.  Let me try to summarize again:

1. In krb5_get_credentials/krb5_tkt_creds, if we can't get a TGT from 
the default ccache [collection], then we try to get a TGT using the 
per-user default keytab, using the per-user keytab's default principal 
if no client principal is known, storing the result in the default 
ccache [collection].  Note that we do NOT use the system default keytab 
for this.  (There would also need to be changes in gss_acquire_creds for 
this.)

2. In krb5_rd_req with no keytab, use the per-user default keytab if it 
exists, and the system default keytab otherwise.  (There would also need 
to be changes in gss_acquire_creds for this.)

3. The default ccache name (currently FILE:/tmp/krb5cc_UID) is augmented 
to be a search list of parameterized ccache names.

This proposal is really three completely separate features making use of 
these new underlying elements:

1. The per-user default keytab (as distinct from the previous notion of 
default keytab, which is now called the system default keytab):
* A new environment variable (distinct from KRB5_KTNAME)
* A new profile relation (distinct from default_keytab_name) containing 
a search path
* A new build-configured default search path (distinct from 
/etc/krb5.keytab)

2. The default principal of a per-user keytab:
* This could be defined as the principal of the first (or last) entry in 
the keytab
* Otherwise, a separate search list (as noted, I'm skeptical of this 
option since the association between the keytab and its default 
principal becomes weak)
* We could still support $KRB5_KEYTAB_PRINCIPAL for this, but its 
existence wouldn't be a cue to do keytab-based initiation, just a way of 
overriding the default choice.

3. A facility for searching a list of parameterized ccache or keytab 
names, where the parameters can be (at least) uid/username and session 
PID.  For this to work with ccaches, we need the concept of ccache 
container existence.

My concerns are (much smaller list than in my last summary):

* The concept of ccache container existence only seems meaningful for
FILE ccaches, as FILE is the only ccache type with a hierarchical 
namespace.  Because of this, I am a little dubious about the third feature.

* If the client keytab default principal isn't simplified to just "the
first principal in the client keytab", and instead comes from a file in
a parallel search path, then there is a lot of potential for getting a
default principal which wasn't intended to be associated with a client
keytab.