MIT Kerberos using invalid in-memory credential cache
ghudson at mit.edu
Mon Jan 11 12:02:46 EST 2021
On 1/7/21 3:11 AM, Vipul Mehta wrote:
> 1) How is default credential picked up when GSS_C_NO_CREDENTIAL is
> specified in gss_init_sec_context() ? How is in-memory credential cache
> used here ?
The default ccache is used, which is generally not a memory credential
cache. krb5_gss_init_sec_context_ext() calls kg_get_defcred() which
calls krb5_gss_acquire_cred() with default arguments.
> 2) If the GSS credential passed to gss_init_sec_context() does not
> match the specified mechanism type then GSS_C_NO_CREDENTIAL is the
> value returned from gssint_get_mechanism_cred(). Why it does not simply
> fail here as client didn't pass matching oid and cred ?
I'd call that a long-standing bug. The same was true for
gss_accept_sec_context() until commit
> One more qus - How to create SPNEGO output token from
gss_init_sec_context using krb5 gss credential ?
You can't; you have to acquire a SPNEGO credential, which will acquire a
krb5 credential internally (and possibly other mech credentials). You
can use gss_set_neg_mechs() to determine which mechs can be negotiated
with the SPNEGO credential.
There have been proposed extensions to allow a mech credential to be
used with SPNEGO, but none have been implemented in MIT krb5. One old
proposal is a gss_acquire_cred_with_cred() function, which could allow
an arbitrary cred to be turned into a SPNEGO cred. Another proposal,
implemented recently in Heimdal, is to decide that as a negotiation
mechanism, SPNEGO directly uses union creds and can be invoked with
arbitrary claimant credentials.
More information about the krbdev