Skip Menu |
 

Subject: gss_store_cred() with proxy credentials fails ungracefully
Download (untitled) / with headers
text/plain 2.1KiB
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