Rocksolid Light

Welcome to Rocksolid Light

mail  files  register  newsreader  groups  login

Message-ID:  

Machines take me by surprise with great frequency. -- Alan Turing

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

SubjectAuthor
o Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions James Ralston

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

<mailman.95.1714432644.2322.kerberos@mit.edu>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=1163&group=comp.protocols.kerberos#1163

  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: Mon, 29 Apr 2024 19:16:58 -0400
Organization: TNet Consulting
Lines: 144
Message-ID: <mailman.95.1714432644.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>
<aa9da132addeca21c08a0b3c2b1dc0653a608443.camel@redhat.com>
<CAEkxbZsfmBjohrjVNo9DvRUAB3yv1KZ3YjiBt2Dc4uNhf1U-oA@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="22226"; 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=L1tRa5tD;
dkim=pass (1024-bit key,
unprotected) header.d=pobox.com header.i=@pobox.com header.a=rsa-sha256
header.s=sasl header.b=qcLGPtjq
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=Wd/5HLEqKlOTHcsRp0Oxhe7aIBd+xfZhxLXzLmGAOlJjbg6tk78Q3t3f9Xdravy6Z8sd8XjIQP0B/ZvnqS5uS2NWeSXYc/ItnhESwAFZwRLKTxTuI4EnI2gQXkBf5/tcihVbCOrVkupNwUt/N3IgrrYIrSfSaqFZ56KOzsgZX2CKhcHz0mTUptPqLmEN5SvCoXyF6dtaLFJLC0LJ81QvcP7IuQ7ASzwT9axiJTTzxvpM/K4F1D+COLfTZMy5h1HfGljqXiM53o4/Eszaz8WiW8i0FgqzS5w4+S7Ygz0R4AuG1fgUH4rYs+uJFJqIbsrXCMsil86epE86r4qf3UMZPA==
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=mrP2ckkYxbMpdsbB5L8JGvmbsAz5sXFbJNsyLyBloII=;
b=CVn40nDjX9raY203Jrw/UbmYha+XpMrK0Z0ny7yPoPl9DdgzJCPrQ2ryxZB8QBT2VT3oaOGwALhl7taoyoQl32KE5YVYq2f7PnT9wWMi9mvnoB7ddEt0J6xx0aMh3POPRJT1V5Uei9Ae0u0LbhORpv3nciF4rT9gJqrlXhkuSQdo7iWskJp8qWu+g1V/8WRAwhOn3rghW5wycbTpaPkUZDL61Cn/LhFtZJCGCTwwYs2UjQdsNPy0YY+5j1Mdar2nWjGdb5ZtSgn6cmjZetsrSN9TWhV5yHW7PAUYuv1itUnlA9Fb3XfWjIYLTe6oqdRfIfyrb2zzdcFPZNbB9jF47A==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
173.228.157.52) 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=mrP2ckkYxbMpdsbB5L8JGvmbsAz5sXFbJNsyLyBloII=;
b=L1tRa5tD1Pgt08PXT7t/FSidE780EW4UCwcjt0rKRj++I3CZNjPJzVePzq373vU92XF5ngSMchcCUBI2eJK5hH5uXKGjTAQ+MLNb2e7fVg9gSHyZCoiLAqn8ACNzrzD2IfAXN3GtsUOggBhGUC+jcJSqMwRTJiTOEUQAEIjqGHU=
Authentication-Results: spf=pass (sender IP is 173.228.157.52)
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
173.228.157.52 as permitted sender) receiver=protection.outlook.com;
client-ip=173.228.157.52; helo=pb-smtp20.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=XOCf7bOxE
pFeAlse3MwhxfvkJGXTNJcARyRiI4S3Eeo=; b=qcLGPtjqhsR6hUAUyJIiNofR+
2E0gEMFZcOTuqNEgB1FXC0MDWwUMl9yFoSseyiZBxEn2lRp/XPGcNBKRnv1PYFm5
DSgmEPamx6J3loiMxELW+PMVvfYdD4AUpiB+PCSz7Nc074Zf9lNCptxZLtaVtEXa
pcAV5RhSKvxFjYfs3g=
X-Gm-Message-State: AOJu0Yw3Y4cMy3SUBeIswsXyoiUEwAPi01muYDrmMgYtiZ6g90ipwTw1
D2no8Tnw8Wm6GwVveqypnLTzMIiE0iCCtlkFU7C4CVngcsFuoZ5qjXuFWQ9ErpMzzzngo1lM98c
qr7Pwp80JgRISgH15klCH+h5zmmY=
X-Google-Smtp-Source: AGHT+IF568IUs6v9/1sxYYMDLdsfQMQnregT3m/b+b6bIuxroqkea5TeUq9tVNHvda2Tp69aDfZGzcqeDxltxxw6sUE=
X-Received: by 2002:a17:906:5d1:b0:a52:5460:a1c6 with SMTP id
t17-20020a17090605d100b00a525460a1c6mr6668931ejt.48.1714432630489; Mon, 29
Apr 2024 16:17:10 -0700 (PDT)
In-Reply-To: <aa9da132addeca21c08a0b3c2b1dc0653a608443.camel@redhat.com>
X-Gmail-Original-Message-ID: <CAEkxbZsfmBjohrjVNo9DvRUAB3yv1KZ3YjiBt2Dc4uNhf1U-oA@mail.gmail.com>
X-Pobox-Relay-ID: 9C6CAD88-067E-11EF-98C7-F515D2CDFF5E-52429198!pb-smtp20.pobox.com
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE3D:EE_|CH0PR01MB6891:EE_
X-MS-Office365-Filtering-Correlation-Id: a6edb77f-e712-4a17-bfdc-08dc68a2844e
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;
ARA:13230031|7093399003|61400799018|48200799009|376005;
X-Microsoft-Antispam-Message-Info: xG6PQBp509fp1nZ6TCOBYs8y6ALBTQ1SQq24ZSLQuwJdk
KJKy/zFc5OofQnbePXoZN736S7R1K04fDKpT91cUV5EEf
MP54L8kzdL4HHT0LEtKw1lUBQ5kiJReWeY9gXsHnXjNgC
5RLgjvkMBFEopBXxrphtlGH+DW9HoAUW6o7R9uCt2/sXy
WnC+3XWjWZ8u/qrId05R6tYGZ8+HAwm0LtDz1ALl//qT5
jn2oarvf5QP3+NMEwjL2yA8aD5/Yq7D+DA9h8VXM+QpP9
BDm89DjP0igd+0Rk3AScmQ/Pf4wL8bzmvRp5n6wR4mftY
qFaOFaINdA1UD5q4c2OO1GW4bT7SuhrDceDTvgVV7FA0L
9KoO0L/PzO4wkVKePFtk7jGZPFOoC4sA7BmjdQ8U5isR2
D6pnS7Y6YELGBzvE+Xsg41YEoF+ebsiLPtMXpoxaf4A8R
2iLyyWHarJpHSRdcDBxBmk/G64UduYOw8SrCcFpEe6oJB
olH+a/wyjTDIoCD6hWNbQzLaFAIytGzWfKnpaptVlcyaP
JDOlSu6RigArtIC8cAaLcq0Q8eaZdzNbJE3EaUaTmBhvW
XahwBPtx9Y0xj2qa+i119zGlEwHKbnc5BVa+Y6K6fLgjU
l0vum52O7a2MgQyvhkkHpYNZ5Dn6+LOdd2yZ0K3uhYRqq
EFlDNI8juWubcsTbLR3Ma+pNXbXlDY2NlSh/8oz9dkfo0
myzKjsMu+Z7G2BusBg2VHVvlEj516rzS70sxRQLAEbiC/
lGCruMQWCVzpOukgh6scFGxqgYJiZxIGvQ7LwnbeLa+n9
GMTjirjXQN8qGdR0bSRF03FnjEiUtEcr5S6Jx+AHxQhn4
ZZ+I/ctJkrhNPDxTkq3SygHs/fsbphIXUc2S78zPasbwJ
PkPPwf2gA6s3ogGvDdaDshZkO+O6OTHx8RR7zyPIyieMy
+Vhz93/6a/A6s4GtLpePngjycNnbmkH2o4sT+K6ErCeby
O9qbgb1avnX+VsW/goEooZ06j4TYuFG2IHGYItL8fF1H5
O7igMeGPGqxhiS0dKweH8B2C1QNinp5Lwk9UfBuQKgrA4
hlg/Zgufe+OVa5CgJFnzljZUmrKH31f6Wlp6NgaNMH/CU
sF9hrwWiR3oW6CRGOi9Qum1l3ytSAQj5aY3ooRyVqXw2C
SSeAcHkAxHwzaRAgXElIf5gBTr0BLP9fRktPbtKu00J2a
MnFnta6l/3n3DcT1dE2Jzq6f/VJ+4mtnKQwlQ5xuhUZ1e
8YDgNBts/w6lE1gAiHIvaTxbJSKFGhjQz3KYpwgMl/30l
xch6jY+eVeVwQUtb8VxcqsFJsEh3ZbNBn34ZMF9Eeo5pH
4meDlVXW7/hAB6X2svXoPKo98AYmWW4p7vxRH6EN//lwb
hlMghaxabjB3zJT3OQA8hb3sl3nYGC7bnQaxzMnX6MlvE
yvHazzgNWec=
X-Forefront-Antispam-Report: CIP:173.228.157.52; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:pb-smtp20.pobox.com; PTR:pb-smtp20.pobox.com; CAT:NONE;
SFS:(13230031)(7093399003)(61400799018)(48200799009)(376005); 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: 29 Apr 2024 23:17:19.1949 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: a6edb77f-e712-4a17-bfdc-08dc68a2844e
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EE3D.namprd03.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH0PR01MB6891
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.mit.edu id
43TNHMQn1624566
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: <CAEkxbZsfmBjohrjVNo9DvRUAB3yv1KZ3YjiBt2Dc4uNhf1U-oA@mail.gmail.com>
X-Mailman-Original-References: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
<202404152356.43FNu4Wj009470@hedwig.cmf.nrl.navy.mil>
<Zh3JEbB0IfDztgSQ@tamriel.snowman.net>
<CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
<aa9da132addeca21c08a0b3c2b1dc0653a608443.camel@redhat.com>
 by: James Ralston - Mon, 29 Apr 2024 23:16 UTC

On Tue, Apr 16, 2024 at 1:46 PM Simo Sorce <simo@redhat.com> wrote:

> The correct action is for you to ask the Domain Administrators to
> mark the target hosts as ok for delegation, it is unclear why MIT
> Kerberos should make it easy to override Realm policies.

I think the core issue here is that RFC4120§2.8 was unclear in
defining the ok-as-delegate flag. Quoting RFC4120§2.8, emphasis mine:

* The ticket flags … *MAY* have the ok-as-delegate flag set
* A client *CAN* use the presence of this flag to *HELP* it decide
* It is acceptable to *IGNORE* the value of this flag

All of these statements are wishy-washy statements that provide no
concrete guidance for server/client implementers:

* Should server implementations set this flag by default unless
administrators specifically elect to disable it, or should server
implementations clear this flag by default unless administrators
specifically elect to enable it?

* Should client implementations honor this flag by default unless
administrators specifically elect to ignore it, or should client
implementations ignore this flag by default unless administrators
specifically elect to honor it?

* Given heterogeneous environments where there are likely to be
multiple independent client implementations, how should this feature
be deployed at a client and server level in order to minimize
interoperability issues?

In light of the failure of RFC4120§2.8 to answer any of these
difficult questions, I would argue that the MIT Kerberos behavior is
reasonable (arguably, the most reasonable): servers do not set the
flag by default, and clients do not honor the flag by default. This
leaves it up to individual sites to determine whether the additional
control this feature offers is desired, and if so, how to deploy it
without breaking things.

> Delegating a whole TGT is generally a bad idea, and often clients
> are misconfigured to broadly forward it everywhere. That is why
> Microsoft took back control in the hands of administrators. It is
> not a bad thing, and if your setup has been vetted such that TGT
> delegation is an acceptable risk, then it should be easy to get it
> fixed the proper way, by getting your domain admins to set the right
> flag on the permitted target hosts.

The issue is not that this feature exists; the issue is that until
recently, we simply *did not know* that this feature exists. And why
would we?

* Windows admins never had any reason to be aware of this feature,
because they use remote desktop to login to remote Windows hosts
from other Windows hosts.

* Linux admins never had any issues with delegating credentials from a
Linux host to another Linux host, because MIT Kerberos clients
ignore the flag by default.

* We assumed that the inability to delegate credentials from Windows
host to Linux hosts via PuTTY was a PuTTY implementation issue,
because that was the only instance where we saw delegation failing.
And PuTTY, at least with default logging, showed no warning/error
messages. Furthermore, because so few people were regularly logging
into Linux hosts from Windows hosts (people who did this often
simply requested a Linux workstation), it wasn’t worth the
time/effort to investigate further.

This state continued for the better part of a decade. It was only
when we began to officially support Mac desktops, and ssh clients on
those Macs also failed to delegate credentials (the same as PuTTY on
Windows), that we began to suspect there was a deeper issue at play.

> Note that if ticket delegation is needed solely to allow jumping
> from hosts to host, you should be able to achieve the same result
> via agent forwarding, it would be a safer option.

We use automounted NFS sec=krbp (AUTH_GSS security) home directories
everywhere, so users *must* possess a credential in order to access
their home directories. So even if we permitted publickey
authentication, it would not solve the issue of needing a credential
on the target host.

> But all that said I would like to note that it is certainly
> inappropriate to call people names before fully understanding the
> scope of a security measure, just because it is a little
> inconvenient.

Speaking as a Linux administrator in a heterogeneous environment where
our Linux hosts rely on Microsoft Active Directory, I assure you that
I have been calling Microsoft names for quite some time. ;-)

(Don’t even get me started about AD’s continued lack of support for
aes256-cts-hmac-sha384-192 or aes128-cts-hmac-sha256-128, when it’s
approaching 10 years since RFC8009 defined them, and Microsoft knows
that the legacy SHA-1 AES encryption types are increasingly giving
sites that are under the gun for FIPS compliance fits.)

I suspect that Microsoft was the main proponent of adding §2.8 to
RFC4120, and they cared little about clarifying behavior in the face
of heterogeneous KDC/client Kerberos implementations, because they
knew exactly how *they* intended to implement it for their KDC and
client.

And I stand by my criticism: silently denying the ability to delegate
credentials behind an obscure flag in the userAccountControl attribute
of the target host, in environments where it is *necessary* to possess
a valid credential on the target host, simply results in users
exposing their actual passwords to the target host (GSSAPI
authentication + kinit on the command line, or keyboard-interaction
authentication).

This is akin to password complexity / password change interval
restrictions that are so Draconian that users cannot remember their
passwords, and resort to writing their passwords on sticky notes that
they attach to their monitors.

> As for users that type their passwords onto random hosts, that is a
> user education problem in general

Not in this case, because these aren’t random hosts; they are hosts
that we (our site-wide IT team) build, deploy, and administer.

> but that can be addressed simply by forcing the use of 2FA
> authentication on the user's part

We already employ MFA for keyboard-interactive ssh logins, and for
console logins.

> preferably via a hardware token and pkinit

We have a subset of systems which must comply with DISA STIGs and for
which we must employ PKINIT using smart cards. For those systems, we
are grateful for all of the work you and others have put into sssd to
enable Linux hosts to perform PKINIT with AD as the KDC.

But for our systems that do not require PKINIT… due to our profoundly
negative experiences with hardware tokens, one of our requirements
when selecting an MFA implementation was software-based TOTP/HOTP with
fully-supported Android/iOS apps (a la Google Authenticator, although
we went with a different solution). Our solution doesn’t use PKINIT,
but instead performs an additional challenge once [non-PKINIT]
password authentication has already succeeded.

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

1
server_pubkey.txt

rocksolid light 0.9.81
clearnet tor