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

[Stefan Metzmacher <[e-mail]>]

Am 09.08.21 um 10:59 schrieb Stefan Metzmacher:
> 
> 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.

I just found the "reject_bad_transit" option that's already implemented for the MIT kdc,
but I guess we want an extra option, correct?

Do we want the new "no_transit_check" option to be used via:
krb5_appdefault_boolean()?

That would allow the following combinations in MIT:

1:
 [appdefaults]
     app = {
        SOME.REALM = {
             no_transit_check = true
        }
     }

2:
 [appdefaults]
     app = {
        no_transit_check = true
     }

3:
 [appdefaults]
     SOME.REALM = {
        no_transit_check = true
     }

4:
 [appdefaults]
      no_transit_check = true


While heimdal falls back to 2 additional options:

5:
  [realms]
     SOME.REALM = {
        no_transit_check = true
     }

6:

  [libdefaults]
      no_transit_check = true


metze