[krbdev.mit.edu #8248] gss_store_cred() with proxy credentials fails ungracefully

[Greg Hudson via RT]

There are two ways to get proxy credential objects with the krb5 mech: 
with gss_acquire_cred_impersonate_name() or with 
gss_accept_sec_context() with a GSS_C_BOTH acceptor cred.  In either 
case, the proxy cred has the subject name as its "name" field, the 
service name as the "impersonator" field, and a memory ccache 
containing the service TGT, a ticket from the subject to the service, 
and a "proxy_impersonator" config entry containing the service name.

Ticket #7046 (which went into krb5 1.11) made proxy credentials 
storable and retrievable using gss_store_cred_into() or 
gss_krb5_copy_ccache() followed by gss_acquire_cred().  Trying to do 
the same with gss_store_cred() does not work without a lot of help from 
the caller, for the reasons discussed in ticket #8010.  What normally 
happens in 1.11 and later is (assuming the overwrite_cred and 
default_cred flags are both true; otherwise gss_store_cred() fails 
outright):

* gss_store_cred() writes creds from the memory ccache into the service 
ccache, including a second copy of the service TGT and the 
proxy_impersonator config entry.

* The next time gss_acquire_cred() is used with the service ccache, the 
proxy_impersonator config entry causes it to be treated as a proxy cred 
ccache, although with the service name instead of the subject name in 
the name field.

* The next time gss_acquire_cred_impersonate_name() is used, it fails 
with G_BAD_USAGE, because kg_compose_deleg_cred() doesn't like seeing a 
delegated cred as the proxy cred.  The error message is "Credential 
usage type is unknown" which is totally wrong--although really, it's 
not possible to write a non-confusing message for this case since it 
arises due to buggy behavior.

It's not clear whether or not this use case should work as written, in 
the absence of a collection.  Even with a collection, do we want proxy 
cred ccaches taking up the collection slot where a normal cred with TGT 
for the same client principal could live?  Regardless, we should at 
least fail more gracefully; transforming the service ccache into a kind 
of mutant proxy cred ccache is not reasonable behavior.

See also:

http://mailman.mit.edu/pipermail/kerberos/2015-September/020967.html