Message-ID:

I dunno, I dream in Perl sometimes... -- Larry Wall in <8538@jpl-devvax.JPL.NASA.GOV>

devel / comp.protocols.kerberos / Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?

<mailman.88.1713251029.2322.kerberos@mit.edu>

https://www.rocksolidbbs.com/devel/article-flat.php?id=540&group=comp.protocols.kerberos#540

copy link Newsgroups: comp.protocols.kerberos

Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!tncsrv06.tnetconsulting.net!.POSTED.mailman.mit.edu!not-for-mail
From: ralston@pobox.com (James Ralston)
Newsgroups: comp.protocols.kerberos
Subject: Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
Extensions flag?
Date: Tue, 16 Apr 2024 03:03:29 -0400
Organization: TNet Consulting
Lines: 102
Message-ID: <mailman.88.1713251029.2322.kerberos@mit.edu>
References: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
<202404152356.43FNu4Wj009470@hedwig.cmf.nrl.navy.mil>
<Zh3JEbB0IfDztgSQ@tamriel.snowman.net>
<CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="mailman.mit.edu:18.7.21.50";
logging-data="26132"; mail-complaints-to="newsmaster@tnetconsulting.net"
To: kerberos@mit.edu
DKIM-Filter: OpenDKIM Filter v2.11.0 unknown-host (unknown-jobid)
Authentication-Results: mailman.mit.edu;
dkim=pass (1024-bit key, unprotected) header.d=mitprod.onmicrosoft.com
header.i=@mitprod.onmicrosoft.com header.a=rsa-sha256
header.s=selector2-mitprod-onmicrosoft-com header.b=shLzt21M;
dkim=pass (1024-bit key,
unprotected) header.d=pobox.com header.i=@pobox.com header.a=rsa-sha256
header.s=sasl header.b=ZJkL0DQ+
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=hLAZS71BeWrRBBewr174vcI6T07X2ibtaDLXsXqu0vpnVtOzWa8ruvCdwwTbxkOvL46SdZnoJPe206VTC54+O9E2LzZTdvnMkNgm5+oWiVveME7MK10vUvgrJK7EAYi/DEGIJOyudezmOTOFwCrKe79Zn25PFBqio7niwBXQPZXDUBsyVwB2P8cH+/Qb7ldmQo85p5h0WtWY7zUyDVr6nGcxc5afL1uoD3UgKEdVSw6nrTMw1dBwL43Kzxxt315fDhIdMb+m6QHRXr3HVp6CJw9HUsTRouCtOeUy5RTupssvhwcxPsAf9zmpt0r+hBktXxwB9OogqfaZrCeY/s4Pzg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1;
bh=uHWPpOhqu3PsJRuWSE3s0BJ1lGjpWimKesJYgBUp6uQ=;
b=TJbHdcGafUKuALKuaZj9e8kBKBlTFxOs54apjCYZ70vwsuoTLX3Aki+heDE/cZuXW21VJM6mw2UlGrn8vUHQVidwe/1Y6Jeq6opjSCqcmo732QSiwlmoU56lZHajk0+g4aJESoK5tundgVwaBySfYATev3tMG2qxWlhFCxp95//nqRmJhLNhHqkVyVS/gk9GcUziMYxoxz1rn9zXWoAj28qQGgyr2neN7q29eOBzEcnAPF02243z1S7jqd0xJWCK8HxIcuPgbT8ToVZqv7P5iEMZlxvNkwr9kkI7sppruht+KN7xiOLXCJkR/kziZv7bLWcg+qJ4KlBO/QCl4mNfGg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
64.147.108.70) smtp.rcpttodomain=mit.edu smtp.mailfrom=pobox.com; dmarc=pass
(p=none sp=none pct=100) action=none header.from=pobox.com; dkim=pass
(signature was verified) header.d=pobox.com; arc=none (0)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=mitprod.onmicrosoft.com; s=selector2-mitprod-onmicrosoft-com;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=uHWPpOhqu3PsJRuWSE3s0BJ1lGjpWimKesJYgBUp6uQ=;
b=shLzt21MwazYxJbWMAZJ1dT76ilI3jFy4EPBwSli3xNEBNdSTG9yhML+Eia11cscTp/5r+XfbyRPw8/C6sVWfMgAfUxbQth3rhJQW4wKvyq22RT0lYvZ//xxyMPtTePKqPk2fAUR/Xsz3ekdpeE6unFV4ZbwGgc5s3ttE8g9f9c=
Authentication-Results: spf=pass (sender IP is 64.147.108.70)
smtp.mailfrom=pobox.com; dkim=pass (signature was verified)
header.d=pobox.com;dmarc=pass action=none header.from=pobox.com;
Received-SPF: Pass (protection.outlook.com: domain of pobox.com designates
64.147.108.70 as permitted sender) receiver=protection.outlook.com;
client-ip=64.147.108.70; helo=pb-smtp1.pobox.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=
mime-version:references:in-reply-to:from:date:message-id:subject
:to:content-type:content-transfer-encoding; s=sasl; bh=vf1VIvZ9U
otnPQan7dLfjn3CwE7k88x2cvD/sxzrf08=; b=ZJkL0DQ+x3ZxlfmALOsmVrbEJ
sV/aNJTfPc0RbOi2hCn8vdPZyrXwq9JkDH4wHWk0W/8DaL1s+ERsXy1rfVSDghwO
Fuj96xraLgWH61V7Zs0UoMGQ6D9q/iczIhOqeZz07vGlN8v+cPepbtVfBEkWQa6L
39+GGXF7rtcx4PTXuQ=
X-Gm-Message-State: AOJu0Yw2XKd2fErKCWmJp6Wj8oHoaa4oVKzbKdY4JmMmdyh/DA/O71aR
qkATSdsNwdbYiB6w08L8kCakzm5p9amiA+w5JgoEo+/9HQcfUzbeV7XbZR8oDYHOTm6V/IcYBAR
bTpF16gmKCYk1yj3SNcxFZiXRKRU=
X-Google-Smtp-Source: AGHT+IFye0RnULAQ9C1vfSjpLL534slqbaycYLPeH0o7VSh/4FtE5UYwarkCNwMkaSek/wuitVLh0r2DSnJtibqWucM=
X-Received: by 2002:a17:906:484:b0:a46:65fd:969d with SMTP id
f4-20020a170906048400b00a4665fd969dmr6658577eja.71.1713251021764; Tue, 16 Apr
2024 00:03:41 -0700 (PDT)
In-Reply-To: <Zh3JEbB0IfDztgSQ@tamriel.snowman.net>
X-Gmail-Original-Message-ID: <CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
X-Pobox-Relay-ID: 75E2B19A-FBBF-11EE-A9F5-78DCEB2EC81B-52429198!pb-smtp1.pobox.com
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CH2PEPF00000148:EE_|DM8PR01MB7157:EE_
X-MS-Office365-Filtering-Correlation-Id: b2b78632-8dd7-4cf1-890c-08dc5de35b5d
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-SenderADCheck: 0
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 6CXzOv+vvyHJDErimua3torXRjsnNLmIleE9cEcL1FkcUTsRI+qZoKbKiilAsx4V+um7AMWcIFgoFjCFRc4t2x/8c+xePJAzWvLuQGBze20HU0AP7yF6gA4tuRZBOr9Kb1rWb15sBX637LeypAl2ZpR300eIhQP5EvSMoAEWfAOIjlQSgiA6loS1U2nnLPmAM71uPoykX7e8qEedtWfTttCQN/2hPykplyn8z7cjcMVHVPDG+yCCyB/pE6+MVJkOZXzpQhnuEKiKqZVDTEvzHQ2V5TiZd06nt4Aorw6Vg9cnCvB8FRqhcfmLIeXDWKcZDr8qPO/OvJR+IOG2qVSLXB860QTeWJYmKqbYCDhLdSyS8LS1yczWyk7XnxzD1nC9K/U2wlE/r7kY93/rIGzbYRaNXj47Z76jrXtGy8YsLa34BKHRG2l9d4k9PzQCBPLbnbITzX1HZbSq7nDePGd2IqjwtpiQq35DRQx5HvSb7GgytEq0EypxHbyvb2MJ55lYyNEnZ40NRzD7IKaNfkocNyjKRMq3VsyDr+3OcBVIBNu2jj0dZhttM4zbsyQKdy2MC9nj9uXqDPu+HytvIPdukJNsMlUuWamlYqdMX7ic9gU456U+eiKnjzW/PhMHsOnszmc9JpoDnxR0DPzzvsyiyVwmLLfOue22GRurDEWAdpeLYad0oaGBR6aGRxq5qNodKETaNziqKCgPx/JpktTusniZOi8aez1cJD2+1ArlEsbVmwVXD82TtEiieLGAfcNV
X-Forefront-Antispam-Report: CIP:64.147.108.70; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:pb-smtp1.pobox.com; PTR:pb-smtp1.pobox.com; CAT:NONE;
SFS:(13230031)(376005)(7093399003)(61400799018)(48200799009); DIR:OUT;
SFP:1102;
X-ExternalRecipientOutboundConnectors: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-OriginatorOrg: mitprod.onmicrosoft.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Apr 2024 07:03:45.0802 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: b2b78632-8dd7-4cf1-890c-08dc5de35b5d
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: CH2PEPF00000148.namprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR01MB7157
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.mit.edu id
43G73lO6611896
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/options/kerberos>,
<mailto:kerberos-request@mit.edu?subject=unsubscribe>
List-Archive: <http://mailman.mit.edu/pipermail/kerberos/>
List-Post: <mailto:kerberos@mit.edu>
List-Help: <mailto:kerberos-request@mit.edu?subject=help>
List-Subscribe: <https://mailman.mit.edu/mailman/listinfo/kerberos>,
<mailto:kerberos-request@mit.edu?subject=subscribe>
X-Mailman-Original-Message-ID: <CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
X-Mailman-Original-References: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
<202404152356.43FNu4Wj009470@hedwig.cmf.nrl.navy.mil>
<Zh3JEbB0IfDztgSQ@tamriel.snowman.net>

by: James Ralston - Tue, 16 Apr 2024 07:03 UTC

On Mon, Apr 15, 2024 at 7:56 PM Ken Hornstein <kenh@cmf.nrl.navy.mil> wrote:

> I'm a LITTLE confused as to what you're describing here. As I
> understand you, the TRUSTED_FOR_DELEGATION flag doesn't appear on
> the wire and only in the account properties.

Yes. Apologies; I should have been more precise: when Microsoft AD is
acting as the KDC, whether AD sets the the OK-AS-DELEGATE flag in the
TGS-REP is determined by whether the userAccountControl attribute in
Active Directory of the host for which a service ticket is being
requested has the TRUSTED_FOR_DELEGATION flag set. If
TRUSTED_FOR_DELEGATION is set, OK-AS-DELEGATE is set in the TGS-REP;
otherwise, OK-AS-DELEGATE is not set in the TGS-REP.

> the [MIT Kerberos] library already provides an option to ignore that
> [the OK-AS-DELEGATE] flag and it seems that by default it DOES
> ignore that flag)

I think the enforce_ok_as_delegate is the option you’re referring to?

The man page claims it is disabled by default (unless an application
specifically requests it). That matches our experiences.

Heimdal appears to implement the same option (enforce_ok_as_delegate),
but although the upstream source claims the default is false (do not
enforce), Macs seem to enforce it by default. So either Apple has
changed that default in the code, or else they are overriding the
default somewhere in the Kerberos configuration.

In terms of Windows, Microsoft’s Kerberos implementation seems to
enforce compliance with the OK-AS-DELEGATE flag. (PuTTY on Windows
will not delegate a credential unless the target host has the
TRUSTED_FOR_DELEGATION flag set in AD.) Perhaps there is a way to
disable this behavior, but we have not yet found a way to do so.

> the RFC provides what I would consider a cognizant explanation:
>
> https://datatracker.ietf.org/doc/html/rfc4120#section-2.8

Microsoft provides a similar explanation, but it is still an
unsatisfying one, because it does not speak to our issue: if denying
the ability to delegate a credential (in order to protect it from
exposure to a possibly-untrustworthy host) forces the user to instead
acquire a credential directly from the possibly-untrustworthy host
(thereby exposing the user’s actual password), then this is not a
security improvement. And while I acknowledge that RFC4120 is 19 years
old and a lot has changed since it was originally published, neither
the RFC authors nor Microsoft seems to have considered/predicted this
scenario.

On Mon, Apr 15, 2024 at 8:40 PM Stephen Frost <sfrost@snowman.net> wrote:

> I'd *strongly* encourage you to ignore what OSX comes with in terms
> of Kerberos "support" and push to move everything away from what OSX
> ships with and to instead use MIT Kerberos. In my experience, this
> is far from the only issue you're going to run into with the hacked
> up Kerberos from OSX and they don't seem to care to properly
> maintain it.

It has been our experience that ripping out a vendor-supplied
library/package and replacing it with an in-house version almost
always has a higher long-term cost than simply living with whatever
warts the vendor-supplied library/package has. So we are reluctant to
take this approach unless there is truly no other choice.

But this segues back to my original question: how are other sites that
use Microsoft AD as their KDCs handling this?

Are other sites ensuring that the TRUSTED_FOR_DELEGATION flag is set for
Linux hosts, so that all various Kerberos libraries (including ones
that enforce OK-AS-DELEGATE by default) will correctly delegate
credentials to Linux hosts?

Are other sites configuring their Kerberos libraries (on a per-OS
basis) to ignore the OK-AS-DELEGATE flag?

Have few other sites that use Microsoft AD as their KDC even run into
this, because they don’t have services (e.g. home directories mounted
via NFSv4+RPCGSS) that require a Kerberos credential, and therefore
don’t need to forward Kerberos credentials to the remote host when
making an ssh connection to it?

My read of the MIT Kerberos kdc.conf man page is that ok-as-delegate
is not one of the flags in default_principal_flags that defaults to
enabled. So heterogeneous sites that use MIT Kerberos as their KDCs
(not AD) should also be seeing this issue.

At least so far, we *think* the best course of action is to always set
the TRUSTED_FOR_DELEGATION flag for Linux hosts in AD, so that
credential delegation won’t depend on whether the Kerberos library
that any specific host uses pays attention to the OK-AS-DELEGATE flag.
And this does seem to be the intention of the TRUSTED_FOR_DELEGATION /
OK-AS-DELEGATE flags: it’s advice to Kerberos clients that it’s OK to
delegate credentials to the target host, which is exactly what we want
to happen.

The only thing we’re not completely sure about is whether setting the
TRUSTED_FOR_DELEGATION flag in AD will have other security
ramifications that aren’t clear from Microsoft’s documentation. Which
is why I was hoping that others on this list have already been down
this particular road and could offer advice.

Subject	Author
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions	James Ralston