Credential cache searching, ccapi and file caches

[Alexandra Ellwood]

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

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


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

Unfortunately there are some more creative uses of 
krb5_cc_get_principal():

Some third party apps use the client principal returned by 
krb5_cc_get_principal() to pass into krb5_fwd_tgt_creds() rather than 
parsing the client principal out of the service ticket.  So with the 
searching code turned on, these apps would use the service ticket from 
the automatic searching to connect and then forward the TGT whose 
client principal is the default principal for the cache.  ssh, telnet 
and kermit are all examples of apps that do this.

There are also a some third party apps which use 
krb5_cc_get_principal() to get the name of the client principal to 
check for certain attributes (such as comparing the name to the user's 
username).  These applications then subsequently call 
krb5_get_credentials(), but only after they have checked the principal 
returned by krb5_cc_get_principal().  kermit is an example of this.

I suspect that with more googling I could find more creative usages of 
krb5_cc_get_principal(), but I think I'll leave it as an exercise to 
the reader. :-)


Anyway, can someone think of a way around this problem?  I don't see 
how we can get the searching code in anywhere before 
krb5_get_credentials() since we wouldn't know what service ticket to 
get.


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