Keytab-based initiator creds design

[Sam Hartman]

>>>>> "Sam" == Sam Hartman <hartmans at MIT.EDU> writes:

>>>>> "Greg" == Greg Hudson <ghudson at MIT.EDU> writes:
    Greg> I misunderstood Nico's proposal.  It's a little simpler and much more
    Greg> collection-friendly than I had thought.  Let me try to summarize
    Greg> again:

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

    Sam> I'm not sure how I feel about overloading the per-user initiator keytab
    Sam> with any conceptual per-user acceptor keytab.
    Sam> I don't understand why use these keys for services running as x are
    Sam> particularly corrilated to get tickets automagically for clients running
    Sam> as x.

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.
Presumably /etc/krb5.keytab would be an element in the acceptor keytab
search list but not the initiator keytab search list.

I guess that as vendors we'll have to figure out whether by default the
user and session-specific initiator keytabs appear in the acceptor
search list (and MIT will have the to decide the default for that), but
we can always add entries if we get it wrong. Or sites can override or
whatever.

--Sam