Keytab-based initiator creds design

[Greg Hudson]

On 06/10/2012 12:56 PM, Sam Hartman wrote:
> The more I think about this, the more I think that I'm uncomfortable
> with the above, but would strongly support something close: there is an
> initiator keytab search list and an acceptor keytab search list. The
> vendor gets to define these, although presumably there would be
> defaults.

Right.  IRC discussion on Friday also suggested a rough consensus for 
making the new type of default keytab specific to initiation.  So, to 
summarize:

* libkrb5 provides a way of finding the default client keytab.  To avoid 
surprise, none of the existing discovery methods for keytabs are used.

* We use the default client keytab to get creds for GSS initiators when 
applicable.  If no client principal is known, the first (or maaybe last) 
principal in the client keytab is assumed.  The resulting creds are 
cached in the default ccache [collection].  A cache created using a 
keytab remembers what keytab it was created from and we attempt to 
refresh it with the keytab.

And then, parameterized search lists for the default keytab, default 
client keytab, and default ccache.  That's really a completely separate 
feature, but I should have time to do both.  There will need to be a 
separate round of discussion on the semantics of keytab/ccache search lists.

On another note, I'm not sure it makes sense to implement any part of 
keytab initiation in krb5_get_credentials/krb5_tkt_creds_* (as opposed 
to just in the gss-krb5 mech).  krb5_get_credentials doesn't use the 
default ccache, so it doesn't really make sense for it to use the 
default client keytab.  Also, doing it in krb5_get_credentials wouldn't 
actually help for FAST armor ccaches (since the FAST code just uses 
krb5_cc_*), so I'm not sure there are any use cases more interesting 
than krlogin.