Keytab-based initiator creds design

[Sam Hartman]

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

Presumably we also need to work through the cases where cc_select or the
application gives us a principal to use.


we also need to discuss auto-renewal.
Once we start talking about cc_select and  application-supplied
identity, we need to ask what happens when the default ccache cannot
store multiple principals and it already has some tickets.
Nico's proposal to me over the phone is that you fail in that case just
as you do now.


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

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


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

This is the best thing since sliced bread.