MIT Kerberos using invalid in-memory credential cache

[Greg Hudson]

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
79c34ed3d829ee9e3fa64aa5b3b90b4e37514cf7.

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