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

Stefan Metzmacher metze at samba.org
Thu Nov 21 09:26:10 EST 2019

Hi Greg,

> On 9/25/19 4:09 AM, Stefan Metzmacher wrote:
>> I just realized that verifying the PAC gains no additional protection.
>> As the client realm, client principal and transited fields is
>> in the encrypted part of the ticket, which is encrypted with the machine
>> trust password.
> I don't think this follows.  It's true that the PAC, client principal,
> and transited list are all coming from the service's KDC with integrity
> protection, but the question is to what degree the KDC is vouching for
> that information.
> If the TRANSITED-POLICY-CHECKED flag is not set in the ticket, the
> service should assume that the KDC applied no policy to the transit
> path.  In practice, the DISABLE-TRANSITED-CHECK request flag, together
> with MS-KILE, means that it is easy to get most KDCs not to
> apply policy.  Without policy controls, any realm in the transitive
> closure of cross-realm keys can issue tickets for clients in any other
> realm (except perhaps the service realm itself).
> The PAC contents, on the other hand, may be subject to policy controls.

Yes, the PAC contents, but also the realm of the principal names are
subject to policy controls (the SID-Filtering).

I've used a modified Samba KDC (realm W4EDOM-L4.BASE) to generate
tickets with invalid names (crealm: FAKEPRINC.PUBLIC)
and tested the reaction of Windows KDC (realm: W2012R2-L4.BASE) when
they received such a Ticket over a forest trust, where realm
FAKRPRINC.PUBLIC is not configure as valid realm (upn-suffix) the for
the trust boundary.

krb5-without-pac-fake-realm-03.pcap.gz has no PAC in the ticket for
TGS-REQ in frame 9. The crealm: FAKEPRINC.PUBLIC is rejected with
ERR_POLICY in frame 10.

krb5-with-pac-fake-realm-03.pcap.gz has a valid PAC (with the correct
names and signatures) but an altered crealm. This is also rejected with

So the policy check are not bound to the PAC, which means we can always
use GSS_KRB5_CRED_NO_TRANSIT_CHECK_X if we're member of an active
directory domain.

>> I implemented GSS_KRB5_CRED_NO_TRANSIT_CHECK_X for
>> MIT, Heimdal (both upstream and Samba) and make use of
>> it in Samba.
> [...]
>> So we need to push it Heimdal first in order to avoid
>> conflicts later.
>>From past discussions I would not expect the Heimdal project to take
> action on a patch in an email attachment sent to the discussion list.  I
> would suggest making a pull request at
> https://github.com/heimdal/heimdal .

I was able to finish all the tests and have a branch here:

I'll add a reference to this discussion into some commit messages
and create a pull request shortly.

Are there any remaining problems, which would prevent
GSS_KRB5_CRED_NO_TRANSIT_CHECK_X from being excepted in MIT?
(Other than waiting for the Heimdal commit in order to get the OID value


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20191121/2145a284/attachment-0001.bin

More information about the krbdev mailing list