Credential cache searching, ccapi and file caches

[Alexandra Ellwood]

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 
"working."  :-)

--lxs
-----------------------------------------------------------------------
Alexandra Ellwood                                           lxs at mit.edu
MIT Information Services & Technology           http://mit.edu/lxs/www/
-----------------------------------------------------------------------