[19976] in Kerberos_V5_Development

home help back first fref pref prev next nref lref last post

Re: [kitten] Checking the transited list of a kerberos ticket in a

daemon@ATHENA.MIT.EDU (Greg Hudson)
Fri Sep 27 11:02:06 2019

To: Stefan Metzmacher <metze=40samba.org@dmarc.ietf.org>, <kitten@ietf.org>,
        Viktor Dukhovni <viktor1dane@dukhovni.org>,
        Samba Technical
	<samba-technical@lists.samba.org>,
        "krbdev@mit.edu Dev List"
	<krbdev@mit.edu>,
        "heimdal-discuss@sics.se" <heimdal-discuss@sics.se>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <bfaf6ce7-5cb1-8d42-5b49-11b5e1c0b18f@mit.edu>
Date: Fri, 27 Sep 2019 11:01:18 -0400
MIME-Version: 1.0
In-Reply-To: <d50c2b41-d0de-b47a-b47b-781fe4b1abe3@samba.org>
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: krbdev-bounces@mit.edu

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 3.1.5.4, 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.

> 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 .
_______________________________________________
krbdev mailing list             krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev

home help back first fref pref prev next nref lref last post