Credential cache searching, ccapi and file caches

[Sam Hartman]

>>>>> "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
not true.

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
    Alexandra> faster.

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
not addressing.

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


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

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
    Alexandra> collection.

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
Kerberos?

--Sam