Not getting delegation credential from gss_accept_sec_context()

[Greg Hudson]

On 10/08/2014 10:29 AM, Xie, Hugh wrote:
> We are using version 1.9.1. When I turn on backback in debugger, I see the gss_accept_sec_context was in turn called internally inside spnego_mech.c that pass a NULL verifier_cred_handle krb5_gss_accept_sec_context_ext. Anyway I can resolve this issue? Here are the full backtrace:

It's hard to get much information out of this backtrace because so much
is obscured by the optimizer.  Based on the version number and the fact
that the backtrace contains SPNEGO functions, I think the following is
happening:

* You call gss_acquire_cred(&min_stat, GSS_C_NO_NAME, GSS_C_INDEFINITE,
GSS_C_NO_OID_SET, GSS_C_BOTH, &state->server_creds, NULL, NULL).  In
1.10 and later, this would get creds for all mechanisms, but in 1.9 it
only gets creds for the default mechanism, which is krb5.

* You call gss_accept_sec_context with the client's token and the
resulting cred.  The mechglue detects that this is a SPNEGO token and
searches for a SPNEGO cred within the verifier cred, but doesn't find
one since it only contains a krb5 cred.  In 1.10 this would result in an
error, but in 1.9 it results in passing a null verifier cred to SPNEGO's
gss_accept_sec_context.  SPNEGO negotiates the krb5 mech, calls back
into the mechglue and into krb5, which uses a default verifier cred and
doesn't receive delegated creds.

Upgrading to 1.10 or later would resolve this problem, but you can also
work around this in 1.9 by explicitly passing a desired_mechs paremeter
to gss_acquire_cred.  The mech set should contain at least the SPNEGO
OID, or perhaps SPNEGO and krb5.  You'll have to define the SPNEGO OID
yourself since we don't declare it in the public headers; the six bytes
of the SPNEGO OID are "\053\006\001\005\005\002".