[kitten] Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation...

Greg Hudson ghudson at mit.edu
Mon Aug 2 13:24:03 EDT 2021

On 8/2/21 10:49 AM, Stefan Metzmacher wrote:
> To summarize the discussion we had active directory DCs do transited
> checking (even without a PAC) and fails to issue service tickets
> if the check fails, so any service ticket is already checked,
> but without TKT_FLG_TRANSIT_POLICY_CHECKED being added to the
> ticket.

I just want to acknowledge here that we're taking on technical debt
because the non-conformant party is perceived to be inflexible.

> The initial solution I proposed was:
> 	gss_set_cred_option(acceptor_creds, GSS_KRB5_CRED_NO_TRANSIT_CHECK_X)
> But it seems gss_set_cred_option() is not accepted because it's
> a deprecated.

Personally I'm fine with this.

> 1. An additional cred_store element could be passed to
>    gss_acquire_cred_from() in order to set the
>    GSS_CF_NO_TRANSIT_CHECK flag on acceptor_creds

This is similar to a cred option.  I don't see any strong advantages of
one over the other.

> 2. I think someone had the idea of using gss_set_sec_context_option()

This seems hard to do without (per-thread) global state.  Even if we
bring in gss_create_sec_context() from some versions of the channel
bindings draft, the mechglue doesn't know mechanism will be used to
accept the context, so it would have to store OID/value pairs in the
mechglue context and replay them to the mech context once it finds out
which kind of mech context to create.  (And hope that all of the context
option values are flat byte strings, not structures containing pointers
to objects whose lifetimes might have expired between the
set_cred_option() call and the first accept_sec_context() call.)

Doing this with global state seems strictly worse than communicating the
flag via the cred.

> 3. Implement a krb5.conf option similar to "dns_canonicalize_hostname"
>    or "ignore_acceptor_hostname" from MIT

I would argue for this to be a per-realm option if we do this, since
it's a statement about a particular realm's KDCs being non-conformant.

More information about the krbdev mailing list