Keytab-based initiator creds design

[Greg Hudson]

I'm going to try to reframe Nico's proposal (as modified by subsequent 
discussion) in more abstract terms, and then list some concerns.

* In krb5_get_credentials/krb5_tkt_creds, if we can't get a TGT from the 
default ccache or the cache collection, then we try to get a TGT using 
the client keytab, using the client keytab default principal if no 
client principal is known, storing the result in the client keytab ccache.

This system relies on several new UI and API elements:

1. The client keytab (as distinct from the acceptor keytab):
* A new environment variable (e.g. KRB5_CLIENT_KTNAME)
* A new profile relation containing a search path
* A new build-configured default search path
* Within the search path, a syntax for expanding parameterized keytab 
names, where the parameters can be (at least) uid/username and session PID
* Perhaps new krb5 (and maybe gss-krb5) APIs to set the client keytab 
name for a context

2. The client keytab default principal:
* We could simplify by saying this is just the principal of the first 
entry in a client keytab
* Otherwise, all of the above elements again

3. The client keytab ccache:
* A new environment variable
* A new profile relation containing a search path
* A new build-configured default search path (distinct from the client 
keytab default search path)
* Within the search path, a syntax for expanding parameterized ccache names
* A new concept of "container existence" for a ccache name, so that we 
can decide whether to use each ccache name in the search list
* Perhaps new krb5 (and maybe gss-krb5) APIs to set the client keytab 
ccache name for a context

My concerns about Nico's proposal and variations of it are:

* I don't see how to make it work with cache collections (if a daemon 
uses multiple principals from a client keytab, via desired_name or 
cc_select).  Recall that we don't have first-class cache collections; 
instead we just have a global "the collection", whose contents are 
partly determined by the default ccache name for the library context. 
So we can't just say there's a separate collection for caches derived 
from the client keytab in a different place.  It might wind up that the 
only way to make that case work is to stuff multiple client TGTs into 
the same ccache, which would be a little sad after going to so much 
effort to avoid that with cache collections.

* The concept of ccache container existence only seems meaningful for 
FILE ccaches, as FILE is the only ccache type with a hierarchical namespace.

* The concept of the client keytab ccache is inherently a bit confusing. 
  Calling this a "per-user ccache" as Nico did does not help at all, 
since the existing UI concept of the default ccache already has a 
per-user default.

* 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.

* The number of new UI/API elements is very large.  Contrary to Nico's 
assertion, I don't think this is at all simple to document or implement.

 From discussion, I think the main thing Nico is trying to achieve, 
relative to my proposal, is to minimize the need for environment 
variables in the cases where (1) each daemon is running with a separate 
uid (and therefore needs a separate keytab), or (2) the configuration 
requires per-session client keytabs and/or client ccaches.  There may be 
simpler ways to achieve at least (1), such as parameterizing the 
default_keytab_name profile variable.

The other potential benefit is that by introducing new UI elements for 
each aspect of the system, the surprise factor is inherently reduced to 
zero.  You can't accidentally draw from the default keytab, or 
accidentally write to the default ccache, if the new feature isn't using 
those elements.