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

[Greg Hudson <[e-mail]>]

On 08/22/2017 07:22 AM, Stefan Metzmacher wrote:
>> I'm not sure about "any KDC in the trust chain trusts the next hop."
>> RFC 4120 doesn't think about cross-realm relationships in terms of
>> trust.  Simply having cross-realm keys with another realm doesn't
>> necessarily imply that the other realm is trustworthy.

> At least it allows the other realm to issue cross-realm referral
> tickets, which the local realm will most likely convert into service
> tickets which can be used by a principal of the other realm to
> access services in the local realm.

To authenticate, yes; whether that provides any access depends on the
services in the local realm.

> And the client principal names (including client realm) in the
> cross-realm ticket can contain any value, which is fully controlled
> by the other realms KDCs.

Yes, which makes it the local realm's job (either at the KDC or the
application server) to decide whether the other realm's KDC should be
able to claim that client realm name.  Completely trusting the foreign
realm is one option, but that option mostly restricts cross-realm
relationships to foreign realms of equal or greater privilege.  (I say
"mostly" because a KDC can trivially deny a ticket from the foreign
realm which purport to authenticate a client in the local realm.  So one
might be willing to trust a foreign realm to authenticate clients in all
non-local realms if one doesn't grant much privilege to any non-local
user anyway.)

> Would be acceptable then if I implement
> gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) for
> MIT and Heimdal in order to let an application service to skip the check
> if they know what they're doing by checking trusting there KDC and doing
> the PAC verification.

I think we should first consider whether it would be sufficient for MIT
krb5 to suppress the rd_req transited check if the
TRANSITED-POLICY-CHECKED flag is set in the ticket.  MIT and Heimdal
KDCs both appear to perform the transited check and set the flag by default.

An application server always trusts its local KDC, but that trust isn't
useful for cross-realm relationships if the TRANSITED-POLICY-CHECKED
flag isn't in the ticket.  Clients can, in general, suppress the KDC
transited check with the DISABLE-TRANSITED-CHECK flag; therefore, a
ticket issued by the local KDC without the TRANSITED-POLICY-CHECKED flag
asserts nothing about the acceptability of the KDC path.

I am not sufficiently familiar with PACs to know whether PAC
verification is a fitting alternative to a transited policy check.