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

Nico Williams <nico@cryptonector.com> Thu, 21 November 2019 22:39 UTC

Return-Path: <nico@cryptonector.com>
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 E5D6C1201A3 for <kitten@ietfa.amsl.com>; Thu, 21 Nov 2019 14:39:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cryptonector.com
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 tpWnvkVkaYvM for <kitten@ietfa.amsl.com>; Thu, 21 Nov 2019 14:39:37 -0800 (PST)
Received: from bumble.birch.relay.mailchannels.net (bumble.birch.relay.mailchannels.net [23.83.209.25]) (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 CA67112016E for <kitten@ietf.org>; Thu, 21 Nov 2019 14:39:36 -0800 (PST)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id C01A9E0FEB; Thu, 21 Nov 2019 22:39:22 +0000 (UTC)
Received: from pdx1-sub0-mail-a70.g.dreamhost.com (100-96-92-164.trex.outbound.svc.cluster.local [100.96.92.164]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 01645E0E52; Thu, 21 Nov 2019 22:39:21 +0000 (UTC)
X-Sender-Id: dreamhost|x-authsender|nico@cryptonector.com
Received: from pdx1-sub0-mail-a70.g.dreamhost.com ([TEMPUNAVAIL]. [64.90.62.162]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384) by 0.0.0.0:2500 (trex/5.18.5); Thu, 21 Nov 2019 22:39:22 +0000
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|nico@cryptonector.com
X-MailChannels-Auth-Id: dreamhost
X-Broad-Decisive: 407ad6495d511f67_1574375962583_2397112492
X-MC-Loop-Signature: 1574375962583:3236055638
X-MC-Ingress-Time: 1574375962582
Received: from pdx1-sub0-mail-a70.g.dreamhost.com (localhost [127.0.0.1]) by pdx1-sub0-mail-a70.g.dreamhost.com (Postfix) with ESMTP id AA0B5AACEF; Thu, 21 Nov 2019 14:39:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=mF5AQPTIFF1rtI p2Cd5T2IYWnek=; b=I4+GC6S1LGzubA+WC99eI2SIzQ7gf8IyBxZy3zrhEFWylf m985RLtA6+OAUfeNOEJ3n8St/5emjkeMUoZQ1ENaP3/j2Ze89f9Lbr9UIj2ppq9V cuw/AkjEqHpunWSxgqaq0d9JOCUNGq49Ic0qfjWiDec6/85EbjJlznyKt+9a4=
Received: from localhost (sdzac10-108-1-nat.nje.twosigma.com [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by pdx1-sub0-mail-a70.g.dreamhost.com (Postfix) with ESMTPSA id 35CFDAACEC; Thu, 21 Nov 2019 14:39:12 -0800 (PST)
Date: Thu, 21 Nov 2019 16:39:09 -0600
X-DH-BACKEND: pdx1-sub0-mail-a70
From: Nico Williams <nico@cryptonector.com>
To: Stefan Metzmacher <metze=40samba.org@dmarc.ietf.org>
Cc: 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>
Message-ID: <20191121223908.GC26241@localhost>
References: <33c431f5-c36b-c321-de3f-65977d8aa898@samba.org> <007c29e8-02b9-4f48-f67e-881cb0985d64@mit.edu> <69d80d24-d461-1652-3cfb-e55d90d31fbf@samba.org> <ec067a72-313e-1878-33a0-a3259d2979d5@mit.edu> <1503578184.3428.19.camel@redhat.com> <db882372-aa1d-e58e-4c94-a268539bd2ee@samba.org> <1503596189.3428.26.camel@redhat.com> <F363B51E-FDF7-4C91-9ABD-B623B5CE97BC@dukhovni.org> <8f68cfb0-2d6b-d86f-4ff0-a9282aa0bf55@samba.org> <cb0d7433-9e23-5bce-4e06-1213bf88cade@samba.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <cb0d7433-9e23-5bce-4e06-1213bf88cade@samba.org>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/EBV8qEXrT64r7y0Je6MdanC9XGs>
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.29
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: Thu, 21 Nov 2019 22:39:39 -0000

On Tue, Sep 24, 2019 at 02:05:05AM +0200, Stefan Metzmacher wrote:
> resuming this old thread...
> https://lists.samba.org/archive/samba-technical/2017-August/122422.html
> 
> >> Does the Kerberos library know whether whether the application is going
> >> to look at PACs and SIDs or just use the client principal name?  I am
> >> guessing it does not.  Thus in Samba, one might need a dedicated
> >> krb5.conf configuration file that disables the transit check.  Other
> >> applications should still apply transit check even if a PAC happens
> >> to be present, as AFAIK it may well remain unused.
> > 
> > My idea was that Samba would use
> > gss_set_cred_option(GSS_KRB5_CRED_NO_TRANSIT_CHECK_X) to indicate
> > the the transited list should not be checked.
> 
> I implemented GSS_KRB5_CRED_NO_TRANSIT_CHECK_X for
> MIT, Heimdal (both upstream and Samba) and make use of
> it in Samba.

Hi,

The right design for this is to use name attributes, not credential
options.  Credential options should be banished altogether.

To see why consider an acceptor application that wishes to examine the
transit path (or whatever other attribute) an authenticated initiator
principal took to reach the acceptor.  What credential should the
acceptor inspect?  There is none to inspect, not for the initiator (not
even if they delegated a credential, since that one might not have
transited any realms).  The only way to inspect the transit path taken
by the initiator is to inspect its name, as that's all we have for it.
This is one reason we added name attributes.

Correspondingly and symmetrically, the right way to request some
behavior on the side where the credential is available, is to associate
that request with the desired_name for which the credential is acquired.

Credential options are not standardized, but name attributes are.
Please use those.

Consider this my code review for the Heimdal PR.

I understand that this is probably a big change, and that this request
may seem hostile (email being such a dry medium).  I'm willing to help
you make this change, both for Heimdal and MIT -- I'll help with the
code, and I'd be happy to have a conference call or exchange further
emails.

Nico
--