Credential cache searching, ccapi and file caches
lxs at MIT.EDU
Wed Jul 14 18:09:18 EDT 2004
On Jul 14, 2004, at 4:58 PM, Sam Hartman wrote:
>>>>>> "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.
Yes, because I had been assuming that making existing clients pick up
the new behavior was a requirement.
> 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.
I'm not really worried about the GSSAPI since its sufficiently
specified and abstracted from the krb5_ccache type and
krb5_get_credentials() that we can fix things for all the callers
without breaking anyone.
I am concerned that unless the krb5_get_credentials() is explicit about
what it does that the krb5 callers will still try to use
krb5_cc_get_principal() to get the client principal name. In many of
the applications the calls to krb5_cc_get_principal() aren't anywhere
near the calls to krb5_get_credentials(). I bet people would be
tempted to just change the client principal to a NULL and expect to
pick up the new behavior.
I'd prefer a new function name whose name implies the new behavior.
This would also have the advantage that folks could test for the
presence of the function in configure and change what their code does
depending on whether the feature is there. Otherwise they have to do a
complicated test of the behavior of krb5_get_credentials() (ick).
If we have a new function then I don't see why we need to change what a
krb5_ccache is at all, because the new function can just take a new
cache collection type or inherit the cache collection from the
krb5_context depending on whether or not we want to support having
multiple cache collections (CCAPI doesn't support this). Then we
wouldn't need to retrofit the new behavior into an existing type which
already has an established meaning in developers' minds.
Not changing the behavior of the krb5_ccache type also has the
advantage that any other crazy things these apps do with the
krb5_cc_*() functions won't hurt them. We just don't have good enough
API documentation to get mad at what they're doing.
> 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.
I would not characterize the confusing behavior I described as
Alexandra Ellwood lxs at mit.edu
MIT Information Services & Technology http://mit.edu/lxs/www/
More information about the krbdev