[19616] in Kerberos_V5_Development
Re: [kitten] Checking the transited list of a kerberos ticket in a
daemon@ATHENA.MIT.EDU (Stefan Metzmacher)
Tue Aug 22 07:22:47 2017
To: Greg Hudson <ghudson@mit.edu>, heimdal-discuss@h5l.org,
"krbdev@mit.edu Dev List" <krbdev@mit.edu>,
"kitten@ietf.org"
<kitten@ietf.org>,
Samba Technical <samba-technical@lists.samba.org>
From: Stefan Metzmacher <metze@samba.org>
Message-ID: <33c431f5-c36b-c321-de3f-65977d8aa898@samba.org>
Date: Tue, 22 Aug 2017 13:22:20 +0200
MIME-Version: 1.0
In-Reply-To: <649fa812-aacf-80b6-1976-a719eca60fc2@mit.edu>
Content-Type: multipart/mixed; boundary="===============3568845625162226920=="
Errors-To: krbdev-bounces@mit.edu
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============3568845625162226920==
Content-Type: multipart/signed; micalg=pgp-sha1;
protocol="application/pgp-signature";
boundary="ekBvUkojEbgPnP1TM4GaMURMxphjcdcDG"
This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--ekBvUkojEbgPnP1TM4GaMURMxphjcdcDG
Content-Type: multipart/mixed; boundary="1Jq3uhOUVJeqdDqdtiu1CHtnVVjhmLVNO";
protected-headers="v1"
From: Stefan Metzmacher <metze@samba.org>
To: Greg Hudson <ghudson@mit.edu>, heimdal-discuss@h5l.org,
"krbdev@mit.edu Dev List" <krbdev@mit.edu>, "kitten@ietf.org"
<kitten@ietf.org>, Samba Technical <samba-technical@lists.samba.org>
Message-ID: <33c431f5-c36b-c321-de3f-65977d8aa898@samba.org>
Subject: Re: [kitten] Checking the transited list of a kerberos ticket in a
transitive cross-realm trust situation...
References: <f33d5f68-1fdc-c1bc-c702-70b054880bb4@samba.org>
<649fa812-aacf-80b6-1976-a719eca60fc2@mit.edu>
In-Reply-To: <649fa812-aacf-80b6-1976-a719eca60fc2@mit.edu>
--1Jq3uhOUVJeqdDqdtiu1CHtnVVjhmLVNO
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
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.
>=20
> 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?
>=20
> Well, it's mandatory in RFC 4120 section 2.7:
>=20
> Application servers MUST either do the transited-realm checks
> themselves or reject cross-realm tickets without
> TRANSITED-POLICY-CHECKED set.
>=20
> It would be okay to skip this check on application servers if the ticke=
t
> 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
--1Jq3uhOUVJeqdDqdtiu1CHtnVVjhmLVNO--
--ekBvUkojEbgPnP1TM4GaMURMxphjcdcDG
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAEBAgAGBQJZnBPwAAoJEA219WEoab1W7ZkP/R4ybDP/6hHErWxelv6iWg/p
WJGqKTuR3b91apRwylE3eu/lKvxmJWYsWTe00LiwS0fXX7JoIMrCvDXnDs0vzZ7f
Y7ZFXlJQZR2ufbljEBW5KX7e4Q67APE1SrOGN0QNSlGdnRRDNGZQkO9c5StfCbyg
CY3LARkSpKdxNZTQVWbdXZsOoIMXPD6MW+QVxmPNhrNnPzXBygdxKAdDMlzybStw
8yU0/4w200DL7oNBx9N6nJjH6StMY9hp3Y8L7SFr6l6m2/g7HuhvIJEepetdmDLD
Hxb6Cp6Kerfw/iGUh7eliLY7zNP3UsHr8Rxc3XKFu1pz7wiJw4kgCYR2/xWQxWPr
2TPNv98z1MBCrlZdZF+iO1bLkO7ofBRP+uTHfVUurZcvveX0fAnQqVCBUcIcLxsz
nJZzTUTljKKHmjGiyl86jFHULv+PCe9qi8WOfI2M+a7YuWTeRmT4Ku5ff9MwN7yS
Ff9SfpT5GkBq3lQg8HMuueCffApYn38E8y9ij6fmykxzXe3otCftUBsBHm79JM/U
fYRStFTchxlsjMmZFbmje1PitAk0iTJ3itFADBOoXddIiIdq7T6RgegKySvwuf+X
euqExik6WkNAybGcJSDeTGiKM+hfwA+USwgJysA1LkHr88AWZYWxjzYQizRKnNta
kMrqvJG/CLNJi3APvUFj
=8r6C
-----END PGP SIGNATURE-----
--ekBvUkojEbgPnP1TM4GaMURMxphjcdcDG--
--===============3568845625162226920==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
krbdev mailing list krbdev@mit.edu
https://mailman.mit.edu/mailman/listinfo/krbdev
--===============3568845625162226920==--
