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

Stefan Metzmacher <metze@samba.org> Tue, 22 August 2017 11:22 UTC

Return-Path: <metze@samba.org>
X-Original-To: kitten@ietfa.amsl.com
Delivered-To: kitten@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01CB113296D for <kitten@ietfa.amsl.com>; Tue, 22 Aug 2017 04:22:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Level:
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=samba.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM789L_-QQIZ for <kitten@ietfa.amsl.com>; Tue, 22 Aug 2017 04:22:28 -0700 (PDT)
Received: from hr2.samba.org (hr2.samba.org [IPv6:2a01:4f8:192:486::147:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00A52132983 for <kitten@ietf.org>; Tue, 22 Aug 2017 04:22:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=samba.org; s=42627210; h=Date:Message-ID:From:To:CC; bh=IMtXt/cOv+uupWL3wvT4Xy0fB5v8zkCdeRIrwO3CQyk=; b=E6zInAqzF8JJ3nsDdjDb7SQD+2 ssAzoVYHpB5XL6XQ01/kdFjMZc9dfBWRpaHbLTFzIr+ejiArSUkaL85XMuB31ZSh5zO7itMtnb/j2 d13z3Q47fZIcqttxdmoBL9udrD9cMP4E0lcL2cLlWovVUkExTc3fb2iP7kjELZ3dvo7A=;
Received: from [127.0.0.2] (localhost [127.0.0.1]) by hr2.samba.org with esmtpsa (TLS1.2:ECDHE_RSA_CHACHA20_POLY1305:256) (Exim) id 1dk7GK-0000Ff-Nk; Tue, 22 Aug 2017 11:22:24 +0000
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>
References: <f33d5f68-1fdc-c1bc-c702-70b054880bb4@samba.org> <649fa812-aacf-80b6-1976-a719eca60fc2@mit.edu>
From: Stefan Metzmacher <metze@samba.org>
Openpgp: id=A3D192CE44EF412517BCED646A739B025C6B98D4
Message-ID: <33c431f5-c36b-c321-de3f-65977d8aa898@samba.org>
Date: Tue, 22 Aug 2017 13:22:20 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <649fa812-aacf-80b6-1976-a719eca60fc2@mit.edu>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="ekBvUkojEbgPnP1TM4GaMURMxphjcdcDG"
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/ntG7eh7qhYNYknjP9jl5JshJB_A>
Subject: Re: [kitten] Checking the transited list of a kerberos ticket in a transitive cross-realm trust situation...
X-BeenThere: kitten@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Common Authentication Technologies - Next Generation <kitten.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/kitten>, <mailto:kitten-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/kitten/>
List-Post: <mailto:kitten@ietf.org>
List-Help: <mailto:kitten-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/kitten>, <mailto:kitten-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 22 Aug 2017 11:22:34 -0000

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