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.