Credential cache searching, ccapi and file caches

[Sam Hartman]

>>>>> "Alexandra" == Alexandra Ellwood <lxs at MIT.EDU> writes:

    Alexandra> While I was looking at replying to Sam's mail I ended
    Alexandra> up looking at the library code and noticed something
    Alexandra> about the way people use krb5_cc_get_principal():

    Alexandra> When you init a krb5 or GSS context, the library picks
    Alexandra> up the value of KRB5CCNAME (or the CCAPI system default
    Alexandra> cache) to determine which tickets to use.  It then uses
    Alexandra> krb5_cc_get_principal() to figure out what the client
    Alexandra> principal is and requests a service ticket with that
    Alexandra> client principal by calling krb5_get_credentials().
    Alexandra> This krb5_cc_get_principal/krb5_get_credentials
    Alexandra> mechanism of getting service tickets is used by kadmin,
    Alexandra> kpasswd, gss_init_sec_context(), krb5_mk_req(),
    Alexandra> krb5_sendauth() and a substantial number of third-party
    Alexandra> apps (eg: sidecar, ssh, samba, etc).  I suspect we will
    Alexandra> have to continue to support it.

Yes.  I'd really hoped to put off this discussion for a bit, but as I
think about the problem more I'm not sure that's a good idea.  It may
be that our solution to the krb5_cc_get_principal problem will
influence which approach for library integration is correct.



    Alexandra> I assume that what we intended to do was to put the TGT
    Alexandra> searching code in krb5_get_credentials() and use the
    Alexandra> client principal the caller got from
    Alexandra> krb5_cc_get_principal() as a hint (ie: try this one
    Alexandra> first) rather than a template.  As a result, the
    Alexandra> returned service principal would not necessarily have
    Alexandra> the same client principal as the one passed into
    Alexandra> krb5_get_credentials().  For most of the code I found
    Alexandra> on the web, this seems like it would work fine.

I'd actually assumed you'd modify krb5get_credentials to accept a null
client principal, modify gss_init_sec_context and all the applications
in our tree.


This would mean that some applications would not support credential
searching explicitly, but everything that continued to work would
still work.  It would also mean that in the new world order, correct
applications would have to call less functions (no
krb5_cc_get_principal), which I consider a change for the better.  

Finally, if an application did want a particular client principal it
would use the relatively intuitive interface of requesting that
principal explicitly.

Your approach works as well.  It has the advantage of causing all
applications to support the new behavior immediately.  It has the
disadvantage of providing confusing behavior to the applications.  For
example, this might create significant problems for applications like
SASL libraries that use the default principal as part of an
authorization name.  You could get into situations where part of a
protocol uses one name based on the applications expectation from
krb5_cc_get_principal and another part of the protocol uses the name
from the ticket.  If we preserve the current behavior then things will
either work or fail cleanly.


--Sam