Credential cache searching, ccapi and file caches
hartmans at MIT.EDU
Tue Jul 13 19:19:29 EDT 2004
>>>>> "Alexandra" == Alexandra Ellwood <lxs at MIT.EDU> writes:
Alexandra> On Jul 13, 2004, at 5:16 PM, Miro JuriÅ¡iÄ
Alexandra> I believe what Sam is talking about is making the one
Alexandra> ccache per client principal constraint more fundamental
Alexandra> to the CCAPI (possibly by unifying the principal and
Alexandra> name attributes of a ccache) and making the krb5_ccache
Alexandra> type equivalent to the CCAPI cache collection so that
Alexandra> we don't have to change any code in the krb5 library or
Alexandra> in KLL/Kerberos.app.
Alexandra> The primary problem I have with this is one of name
Alexandra> confusion. I don't think there should be two things
Alexandra> named "ccache" where one is actually a subset of the
Alexandra> other. Our APIs are hard enough to understand
Alexandra> already. :-)
I acknowledge this problem.
Alexandra> Another problem I have with Sam's proposal is that it
Alexandra> seems to be trying to make the krb5_cc_*() API fit
Alexandra> better with the existing file format rather than
I'm trying to design a krb5 library API that is clean for the way in
which the krb5 library wants to interact with tickets and is efficient
for all operations we need.
Alexandra> designing an API which is clean and efficient for the
Alexandra> caller. For instance, one of the really common
Alexandra> operations in Kerberos.app is to display a list of the
Alexandra> client principals for which the user has TGTs and the
Alexandra> state of each TGT (lifetime, flags, etc). In Sam's
Alexandra> proposed design, Kerberos.app would have to iterate
Alexandra> through all the creds in the file-based krb5_ccache,
Alexandra> including the service tickets. If the user has managed
Alexandra> to get themselves 10 TGTs and 100 service tickets (yes,
Alexandra> we've seen this) then this search is going to be
Alexandra> needlessly slow.
Hmm. I had assumed that you could get krb5_cc_retrieve_cred to return
all matching credentials not just the first one. Apparently this is
Would extending the krb5 ccache interface to be able to search for all
credentials matching specified criteria be sufficient along with an
iterator to enumerate all tgts in a krb5_ccache?
Alexandra> Sam proposes adding an iterator to loop over the client
Alexandra> principals, but unless it returns the TGTs, it won't
Alexandra> help Kerberos.app get the ticket lifetime. So
Alexandra> Kerberos.app will still have to walk the whole list of
Alexandra> credentials. Obviously this can be solved with caching
Alexandra> or other optimizations, but I'd much prefer for the
Alexandra> looping code that separates the tickets for a given
Alexandra> client principal from the rest of the tickets to be
Alexandra> inside the krb5_cc_*() functions so that we can make
Alexandra> optimizations to it in the future and make everything
I agree.. I proposed the wrong iterator.
Alexandra> Also, does the krb5 library actually currently take
Alexandra> advantage of multiple TGTs for client principals in its
Alexandra> ccaches? Much of the code I've looked at calls
Alexandra> krb5_cc_get_principal() to get the client principal
Alexandra> which will only return the default principal in a file
Alexandra> based ccache. If the support isn't there, it seems to
Alexandra> me that the krb5 library already has to be modified all
Alexandra> over the place to search across multiple TGTs trying to
Alexandra> get a service ticket.
This is roughly the same as the first issue I specifically said I was
Alexandra> I'd much prefer the krb5_cc_*() API to gain the concept
Alexandra> of a cache collection which loops over krb5_ccaches.
Alexandra> If we added this support then all the existing callers
Alexandra> of the krb5_cc_*() functions would just manipulate the
Alexandra> krb5_ccache pointed to by the system default ccache
Alexandra> (KRB5CCNAME) and have no idea that there is actually a
Alexandra> cache collection, but modern callers could loop over
Alexandra> all the ccaches available to search for a TGT. If we
Alexandra> did this then we could slowly work over all the places
Alexandra> in the krb5 library where we deal with ccaches and make
Alexandra> them smart rather than having to audit the whole thing
Alexandra> immediately to make sure that the new behavior of
Alexandra> krb5_ccaches won't break things.
Alexandra> Note that I am not trying to say we would need to
Alexandra> support looping over multiple ticket files. We could
Alexandra> put the whole "cache collection" into the single ticket
Alexandra> file. What I'm not sure of is whether you could do
Alexandra> this without changing the ticket file format (which
Alexandra> would suck).
You can, although changing the default principal may end up being
challenging to implement. I think we should carefully consider how
multiple TGTs will interact with file based caches used by other
Alexandra> It's also possible that we could create a
Alexandra> meta-data file that points to all the file caches so
Alexandra> that file caches would work a lot like CCAPI
Alexandra> caches. This is attractive because it means that
Alexandra> kdestroy wouldn't get more complicated and we wouldn't
Alexandra> need to change what KRB5CCNAME means (ie: that the
Alexandra> string after FILE: is still actually a ticket file
Alexandra> containing the system default client principal).
I think it all depends on what you believe KRB5CCNAME points to now.
I think it points to all the tickets that are currently available to
the application. You think it points to the system default tickets.
Up until now they've been the same thing, so it's been somewhat
So far I have no reason to prefer one view over another.
Alexandra> Now before everyone points out that all sorts of krb5
Alexandra> functions take krb5_ccaches, I'd like to point out that
Alexandra> the only sane "search for a TGT to get a service
Alexandra> ticket" algorithms I've seen proposed all have the
Alexandra> concept of a user or programmer-settable ccache that
Alexandra> you try first. If you don't have one, and you have two
Alexandra> sets of tickets which give you different privileges
Alexandra> (say lxs at ATHENA.MIT.EDU and lxs/root at ATHENA.MIT.EDU),
Alexandra> then you have no way of telling the krb5 library which
Alexandra> one you'd prefer it to use.
Isn't this the system default principal? In terms of changing this
for a specific application, you can force the client principal to be
some value when you get credentials.
Alexandra> So what I would do is in
Alexandra> all the places where a function takes a krb5_ccache,
Alexandra> treat that one as the one whose client principal it
Alexandra> should try first. If that client principal doesn't
Alexandra> work, *then* search across the rest of the cache
Which cache collection? The collection containing the ccache passed
into that function? If so, I agree it would work. I actually think
it would be more confusing to programmers than if krb5_ccache
represented a cache collection.
I agree it would work.
To summarize there seem to be several open
issues. My original proposal had some efficiency problems; I agree
that the operations Kerberos.app needs to perform must be efficient
and the krb5_cc_* interface must change until these operations can be
performed efficiently. It also needs to be possible for Kerberos.app
to map the operations into its object model, but I think this will
fall out of making the operations efficient.
There's another question of API cleanlyness. I actually think it is
reasonable clean to have an object in the krb5 library represent a
cache collection and don't think it is problematic for that object to
be the krb5_ccache. I think the only problem is the potential naming
confusion. I believe this is a completely aesthetic judgment and
don't believe I could successfully argue which approach is cleaner.
Perhaps we should look at the following factors? Which approach would
be easier to implement? How would the two approaches interact with
people trying to write applications portable to Heimdal and to MIT
More information about the krbdev