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

[Stefan Metzmacher]

Am 21.08.2017 um 16:05 schrieb Greg Hudson:
> On 08/18/2017 08:35 AM, Stefan Metzmacher wrote:
>> While thinking about this I can't see any value in checking the
>> transited list of the ticket. As that list is always under the
>> control of the KDC that issued the ticket. And the service
>> trusts it's own KDC anyway, as well as any KDC in the trust
>> chain trusts the next hop. The only reason for this list
>> might be debugging.
> 
> 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.

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.

I guess that's what RFC 4120 means by "The presence of trusted KDCs in
this list does not provide any guarantee; an untrusted KDC may have
fabricated the list."

>> Is there any reason to keep the krb5_check_transited() (in Heimdal)
>> and krb5_check_transited_list() (in MIT) is their current form?
> 
> Well, it's mandatory in RFC 4120 section 2.7:
> 
>    Application servers MUST either do the transited-realm checks
>    themselves or reject cross-realm tickets without
>    TRANSITED-POLICY-CHECKED set.
> 
> It would be okay to skip this check on application servers if the ticket
> has the TRANSITED-POLICY-CHECKED flag.  Heimdal appears to do this but
> MIT krb5 does not; I'm not sure why as that behavior dates to before my
> time.

The fact that it's mandatory according to the RFC doesn't mean it
gains anything for the application server. But if other's believe
that the check helps, I'm fine with that.

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.

metze

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20170822/ce2e1f8c/signature.sig>