Incorrect delegation state shown on acceptor side by context flags

[Vipul Mehta]

Hi,

It seems there is a bug in MIT kerberos gss source code where the
delegation state is set in context flags on acceptor side.

I am using a keytab on server side to acquire credentials with in memory
credential cache : *cred->usage == GSS_C_BOTH*
Client has *delegation flag set to false* but has a *forwardable TGT*.

On context establishment on server side :

*A)* If we use it it like :
*gss_accept_sec_context(&min_stat,
context,
server_creds,
&recv_tok,
GSS_C_NO_CHANNEL_BINDINGS,
&client,
&doid,
&send_tok,
ret_flags,
NULL, /* ignore time_rec */
NULL); *
This will work fine and *ret_flags* will have delegation bit false.

*B)* But if we use it like :
*delegated_gss_cred = NULL;
gss_accept_sec_context(&min_stat,
context,
server_creds,
&recv_tok,
GSS_C_NO_CHANNEL_BINDINGS,
&client,
&doid,
&send_tok,
ret_flags,
NULL, /* ignore time_rec */
&delegated_gss_cred); *

Then, it will set delegation bit in *ret_flags* to true.

.....................................................................................
If we look down the code in *accept_sec_context.c*, it has :

* if (delegated_cred_handle != NULL &&
deleg_cred == NULL && /* no unconstrained delegation */
cred->usage == GSS_C_BOTH &&
(ticket->enc_part2->flags & TKT_FLG_FORWARDABLE)) {
/*
* Now, we always fabricate a delegated credentials handle
* containing the service ticket to ourselves, which can be
* used for S4U2Proxy.
*/
major_status = create_constrained_deleg_creds(minor_status, cred,
ticket, &deleg_cred,
context);
if (GSS_ERROR(major_status))
goto fail;
ctx->gss_flags |= GSS_C_DELEG_FLAG;
}
*

*[ case A ] : *( delegated_cred_handle = address of(NULL) ) == NULL
*[ case B ] : *( delegated_cred_handle = address of(NULL pointer) ) != NULL

So, for case B, the above if() condition will be true and it will set the
context delegation flag to true on acceptor side though delegation flag is
false on initiator side.

--
Regards,
Vipul

[Greg Hudson]

On 05/17/2013 07:33 AM, Vipul Mehta wrote:
> So, for case B, the above if() condition will be true and it will set the
> context delegation flag to true on acceptor side though delegation flag is
> false on initiator side.

This is how our constrained delegation (S4U2Proxy) support works. I
don't see anything in RFC 2743 or RFC 2744 which requires the flag
states to be identical on the initiator and acceptor context.

[Greg Hudson]

On 05/17/2013 10:56 AM, Vipul Mehta wrote:
> So, on acceptor side, how do i know that initiator has delegated the
> credentials if i can't rely on context delegation flag ?

The GSSAPI doesn't distinguish between different kinds of credential
delegation. But if you use GSS_C_ACCEPT rather than GSS_C_BOTH acceptor
credentials, then constrained delegation won't be used, and you will be
able to tell whether traditional Kerberos ticket forwarding was used.

> What about the java implementation of GSS ? Looks like there it works fine.

Does it support constrained delegation? If it doesn't, then the
behavior difference isn't surprising.

[Vipul Mehta]

So, on acceptor side, how do i know that initiator has delegated the
credentials if i can't rely on context delegation flag ?

What about the java implementation of GSS ? Looks like there it works fine.

--
Regards,
Vipul

[Vipul Mehta]

On Fri, May 17, 2013 at 8:31 PM, Greg Hudson <ghu...@mit.edu> wrote:

> The GSSAPI doesn't distinguish between different kinds of credential
> delegation. But if you use GSS_C_ACCEPT rather than GSS_C_BOTH acceptor
> credentials, then constrained delegation won't be used, and you will be
> able to tell whether traditional Kerberos ticket forwarding was used.
>

> In my case it is like acceptor can use delegated credentials or its own
credential for initiation on the basis of certain conditions, so GSS_C_BOTH
is required. Now there seems to be no way to check whether client has
delegated the credential or not.

> > What about the java implementation of GSS ? Looks like there it works
> fine.
>

> Does it support constrained delegation? If it doesn't, then the
> behavior difference isn't surprising.
>

> As far as i know about constrained delegation is that only a set of
acceptors are allowed to use the delegated credential within the domain. No
idea if this feature is supported by java, may be it is not. Would it be
too much if you can add a condition that context delegation flag on
acceptor side should not be set if client hasn't delegated the credential ?
It seem to be logical too, in the implementation, this flag is set only if
acceptor can acquire valid delegated credential.

--
Regards,
Vipul

[Vipul Mehta]

One more question, what is the exact use of context delegation flag if it
doesn't need to be same on initiator and acceptor side.

--
Regards,
Vipul

[Nico Williams]

On Mon, May 20, 2013 at 5:20 AM, Vipul Mehta <vipulme...@gmail.com> wrote:
> One more question, what is the exact use of context delegation flag if it
> doesn't need to be same on initiator and acceptor side.

The initiator gets to ask for credential delegation.

The acceptor gets to receive delegated credentials.

The acceptor also gets to impersonate the initiator principal to the
extent that the credential issuers prefer. The acceptor doesn't
really get to tell much about this case: since the extent to which it
can impersonate the initiator could vary by the time of the day,
phases of the moon, ...

Nico
--