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

[Stefan Metzmacher <[e-mail]>]

Hi Greg,

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

Ok, should I just use a different oid (I can allocate one from the Samba pool)
and submit the changes to MIT without the "wait for heimdal first" tag?

It would be great to have that in MIT and we can also apply it to
Samba's fork of Heimdal and have most Samba setups covered.

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

Same here, I just wanted to find ways to make Nico happy.

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

Yes, it seems way to complex.

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

Ok. I can also implement that in addition to the GSS_KRB5_CRED_NO_TRANSIT_CHECK_X
option.

Thanks for the feedback!
metze