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

Greg Hudson <ghudson@mit.edu> Mon, 02 August 2021 17:24 UTC

Return-Path: <ghudson@mit.edu>
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 7F30B3A10C7 for <kitten@ietfa.amsl.com>; Mon, 2 Aug 2021 10:24:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no
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 hPURNhDoRcDx for <kitten@ietfa.amsl.com>; Mon, 2 Aug 2021 10:24:10 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 8C70C3A10C1 for <kitten@ietf.org>; Mon, 2 Aug 2021 10:24:10 -0700 (PDT)
Received: from [18.30.9.158] ([18.30.9.158]) (authenticated bits=0) (User authenticated as ghudson@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 172HO4iI015024 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT); Mon, 2 Aug 2021 13:24:04 -0400
To: Stefan Metzmacher <metze@samba.org>, Nico Williams <nico@cryptonector.com>
Cc: kitten@ietf.org, Samba Technical <samba-technical@lists.samba.org>, "krbdev@mit.edu Dev List" <krbdev@mit.edu>
References: <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> <20191121223908.GC26241@localhost> <22f96c93-0217-0b2b-d7e1-684f9269fba4@samba.org> <20191122224526.GA28614@localhost> <8b72197d-2fcc-5b4f-4392-12d53d1ec624@samba.org> <5bcc2951-afdf-0849-5c16-f542afe214a1@samba.org> <3d693bdd-9a4c-7135-318e-593e18e52cd0@mit.edu> <9062428f-f26d-4f10-b71f-f54464df2ff4@samba.org> <c388e3f9-bf85-8ffd-3640-b27e0552a96a@samba.org>
From: Greg Hudson <ghudson@mit.edu>
Message-ID: <276401e2-5d09-29d2-be1b-5e876f49c0eb@mit.edu>
Date: Mon, 02 Aug 2021 13:24:03 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <c388e3f9-bf85-8ffd-3640-b27e0552a96a@samba.org>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/kitten/yOKH1ajnq3A3av1_nR5xBTBgO5s>
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: Mon, 02 Aug 2021 17:24:13 -0000

On 8/2/21 10:49 AM, Stefan Metzmacher wrote:
> To summarize the discussion we had active directory DCs do transited
> checking (even without a PAC) and fails to issue service tickets
> if the check fails, so any service ticket is already checked,
> but without TKT_FLG_TRANSIT_POLICY_CHECKED being added to the
> ticket.

I just want to acknowledge here that we're taking on technical debt
because the non-conformant party is perceived to be inflexible.

> The initial solution I proposed was:
> 
> 	gss_set_cred_option(acceptor_creds, GSS_KRB5_CRED_NO_TRANSIT_CHECK_X)
[...]
> But it seems gss_set_cred_option() is not accepted because it's
> a deprecated.

Personally I'm fine with this.

> 1. An additional cred_store element could be passed to
>    gss_acquire_cred_from() in order to set the
>    GSS_CF_NO_TRANSIT_CHECK flag on acceptor_creds

This is similar to a cred option.  I don't see any strong advantages of
one over the other.

> 2. I think someone had the idea of using gss_set_sec_context_option()

This seems hard to do without (per-thread) global state.  Even if we
bring in gss_create_sec_context() from some versions of the channel
bindings draft, the mechglue doesn't know mechanism will be used to
accept the context, so it would have to store OID/value pairs in the
mechglue context and replay them to the mech context once it finds out
which kind of mech context to create.  (And hope that all of the context
option values are flat byte strings, not structures containing pointers
to objects whose lifetimes might have expired between the
set_cred_option() call and the first accept_sec_context() call.)

Doing this with global state seems strictly worse than communicating the
flag via the cred.

> 3. Implement a krb5.conf option similar to "dns_canonicalize_hostname"
>    or "ignore_acceptor_hostname" from MIT

I would argue for this to be a per-realm option if we do this, since
it's a statement about a particular realm's KDCs being non-conformant.