Keytab-based initiator creds design

[Simo Sorce]

On Fri, 2012-06-08 at 15:35 -0400, Greg Hudson wrote:
> 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)

Why do you need a new env var ?

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

Maybe we should just use the first principal in the keytab and add
additional stuff only if that is found to not be enough in the field,
after all applications can specify a name, so it is not that important.

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

Well the DIR type has the same feature
The MEMORY ccache doesn't, but then why is that interesting ?
You do not need substitutions if you specify a MEMORY ccache via
KRBCCNAME

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

Indeed, I would avoid that at first, and only add the option if there
are real good reasons to do so.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York