Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

Small is beautiful.

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

SubjectAuthor
o honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flagJames Ralston

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

<mailman.85.1713219587.2322.kerberos@mit.edu>

  copy mid

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

  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: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
Extensions flag?
Date: Mon, 15 Apr 2024 18:19:22 -0400
Organization: TNet Consulting
Lines: 77
Message-ID: <mailman.85.1713219587.2322.kerberos@mit.edu>
References: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@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="32552"; 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=DWZai/Gc;
dkim=pass (1024-bit key,
unprotected) header.d=pobox.com header.i=@pobox.com header.a=rsa-sha256
header.s=sasl header.b=Dnfc/8nX
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=KS+bSPBJPvEkkuORqqIfMLjOr/Z091RiPZfBfy6E9qAs3BVoG1st41duCSk8ej8cXbvUkghZeBYgQ4YiVYbHmzZurZZ0T1ihjfqJQVcCiuECB84ykCvKLMNmp/TCAUBcDbJ59eWLMidjL3ztUvE+L80Ofha63rCLtM14qxjG+PPSahl579HrLnVY/9u8cdWT7rqSxXPiwXv36FRgYzQhx05uMs91h6arjoBDGznPqcbYXSBybaEqtP2Sy7OrFCkVU8ZbGCOxZ3acODHl7T72PlHumTpLtuiZKLJSdj8ViQEx5ondeEDCMHz05yfCAmF9pimieySBf8ZyoAqaPPuYvg==
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=cMApWvO0q8qd8yZK2dcSwCam3Xjqp7eYVHdI6iDo2A8=;
b=BBmeH+FYaeqNfet4G0S4OgD5ipFN+uD+mWRgW0aTJdzScXjlfuDAvpTohvD2gwgbFsPSRAM9p/nJntKdZZK1EmmYJQJ/bCeDRcBJb4oqph2VHlcP7HrM5AjcKE7fI2g9Ai0Jq3q7aW6GFWXReWrdnLe8NcowJIZ4+W7/VddpDKQP2/4D+Ny/+1etZl3Ma8gHr2JblpilGcXeQMHBAF4a4+7XnfUjQvvsPgdA/Pcur4XyibA9NSByhhd+yw3fuDSQxY25rqkEUjNJ7+HZw9Cd0hnuPfJoJDDDodBZxJeDrpIfMyuX5UdVPGrlpVBfZ4Cj+2uaVtT0bkcRNVplDJFNXQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
173.228.157.53) 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=cMApWvO0q8qd8yZK2dcSwCam3Xjqp7eYVHdI6iDo2A8=;
b=DWZai/GcNzcGs8BSL9PpGcNmYIuC2LQ+H8GXTE3cMvwturLelfL+ke+mbMJV3EewrNLBIIs1RAJDVGaUiJ4R02zt4wNHD0L/tSQ6eTOPqvp9LIXAztVDtZmUxFXBJ+Hs3nIYTp/JjOnjQuQf4RsF02nFmwfxHrERwpj5NVYKbvQ=
Authentication-Results: spf=pass (sender IP is 173.228.157.53)
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.53 as permitted sender) receiver=protection.outlook.com;
client-ip=173.228.157.53; helo=pb-smtp21.pobox.com; pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=pobox.com; h=
mime-version:from:date:message-id:subject:to:content-type
:content-transfer-encoding; s=sasl; bh=cMApWvO0q8qd8yZK2dcSwCam3
Xjqp7eYVHdI6iDo2A8=; b=Dnfc/8nXvdKlTWljYndWHabwHe7q3TGr3uDAcoMje
c03UUoM7IpwgMmPL/ZpGxBXP9BcBspsxnk66CaVs02HAMx5EKxhyRJHw7o1qaLVu
P5WkF351Ax6fxuUu8U1jYUARpFMb7DuxTpnN9HE9qtm4zloo0d0WdFtEpepLHhX3
AA=
X-Gm-Message-State: AOJu0YyUsocITCSgPZi/fGUp+ImXJMb2LYgmjqf+gR+Hs+/UiAvML5Un
hPUXNFFGtcnQpQMg9YJWifxbP2ZAxT+IUVr44QF1h9TiUtc0gkW/f2xmS8sJfMyhyG40rjLw9Gb
mIw9gE42Hoaqfh/l35tZSZke+DRk=
X-Google-Smtp-Source: AGHT+IGrW1l+F4qwHxyk92wrt7cNzy9zbFyxd2O9BAqxmP/4hWMzY+2BtEZS390ogquDkjEQ8yUa7yZQZoNDUKR7p/M=
X-Received: by 2002:a17:907:1b1d:b0:a52:182c:f6cf with SMTP id
mp29-20020a1709071b1d00b00a52182cf6cfmr8385913ejc.32.1713219573953; Mon, 15
Apr 2024 15:19:33 -0700 (PDT)
X-Gmail-Original-Message-ID: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
X-Pobox-Relay-ID: 3E1C0F2A-FB76-11EE-AC7E-A19503B9AAD1-52429198!pb-smtp21.pobox.com
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: SJ5PEPF000001D1:EE_|BL3PR01MB7210:EE_
X-MS-Office365-Filtering-Correlation-Id: 82a6ecb6-efd5-426c-d148-08dc5d9a24cc
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: 1vz9uTtww2ol954hVaC1E16MYqkbt7FNSuD3Mt7RP5+cM8dHhowl/Qf/jhejqpE/iz7wKNS0YGHyqZIHqWJ5F55dsDiJBcPHw/OKIgtyqszHsbvihsj/tKMK3JCROZ7Q1IzQkb2vLEsqDvXeseBBNMck3WToGeWRcLNmLLyndFreyWztJew8GCwTtL3zarpOCJzKIa2tIFqdB391DF/CuIqr9+zW38kIwPs/VJPVNh9cW/czHlYsB1YvIb3ZFx/uF53XYRAs1TvRjlsjzDvp31iob0/aPEjK2bAyOEq1X25rhS1A6lh8Md7v+E9mlqZrB3eKEEQ6NXGKTsrpKGNsDPp61pAoTD7NMpr2dVt/EuGSnV+6Vgcl0QQEmdJgn5qYiNIzt7UP9ahWFcyU+Ov2vCMyWRNfRETWtkkpLmj7VmexDV8yF9JOGu0Dj/5//IQW/iHQqeUO5cOUGLRYEvAdcZ610IMWfCXsSrYB+HA9ELgELlX1uq1n8tc5a/wChtrEszxaV/XzS8ellEyMDB8EMvog9fQVcgT/39XdtzxxqTSt1Z9jaE5itPZ0Sj09o6ogghXMn5i3wk5EWYXM5tTNQ59sLbTRwfiaxWd1HaRzhwLJif5DQv5fCBfJJ84Qw4Po7ROrj6kItuUPqvnchwnyjanc9fr+2qdhkmBPl4WuNvsJUKKwCuaSBuCzCwedJdEOPKJijXMavphFfgpORRdgeO9pr4gR+Vtz4jSnCyfNDmD4nUFXJ2knUZdc7c6Hv/54WEVX1pHhO64tcsNZ7Stc+B6MH/X1gmCGqWY4WwwYGSY=
X-Forefront-Antispam-Report: CIP:173.228.157.53; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:pb-smtp21.pobox.com; PTR:pb-smtp21.pobox.com; CAT:NONE;
SFS:(13230031)(48200799009)(376005)(61400799018)(7093399003); 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: 15 Apr 2024 22:19:40.1954 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 82a6ecb6-efd5-426c-d148-08dc5d9a24cc
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: SJ5PEPF000001D1.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BL3PR01MB7210
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.mit.edu id
43FMJjXa506592
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: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
 by: James Ralston - Mon, 15 Apr 2024 22:19 UTC

Has anyone else struggled with ssh clients being unable to delegate
Kerberos credentials to a remote host because the Kerberos library
that the ssh client uses implements the MS-SFU Kerberos Protocol
Extensions and therefore honors the TRUSTED_FOR_DELEGATION flag of the
target host?

More generally: does anyone know exactly what Microsoft was thinking
when they dreamed up this flag?

As far as we can tell, for reasons we still have been unable to
fathom, Microsoft decided that simply permitting credential delegation
based on whether the TGT has the forwardable flag set was
insufficient. Instead, Microsoft implemented a new flag in the MS-SFU
Kerberos Protocol Extensions, TRUSTED_FOR_DELEGATION. The flag is a
property of the service principal of the *target* host: if the target
host does not have the TRUSTED_FOR_DELEGATION flag set in the
userAccountControl attribute of the host’s machine account in Active
Directory, then if the Kerberos library that the ssh client uses
honors the MS-SFU Kerberos Protocol Extensions and honors the
TRUSTED_FOR_DELEGATION flag, it will refuse to delegate the user’s
credentials to the target host, *even* if all other settings would
permit credential delegation.

Because MIT Kerberos doesn’t honor the TRUSTED_FOR_DELEGATION flag (or
any part of the MS-SFU Kerberos Protocol Extensions?), our folks who
use only Linux systems have never noticed an issue. But we have an
increasing number of Mac users who wish to ssh from their Macs to
Linux hosts, and since Macs use Heimdal, which *does* implement the
MS-SFU Kerberos Protocol Extensions and therefore honors the
TRUSTED_FOR_DELEGATION flag, Mac users cannot ssh to Linux hosts and
delegate their credentials. Because we use NFS-mounted home
directories with RPCGSS security, this means that Mac users get
"Permission denied" errors when accessing their home directories if
they use gssapi-with-mic or gssapi-keyex ssh authentication to Linux
hosts: they can login via gssapi-with-mic or gssapi-keyex, but without
the credential, they cannot access their home directories.

(The irony here is that the only way for Mac users to login to Linux
hosts and actually have a home directory is if they perform
gssapi-with-mic/gssapi-keyex authentication and then manually run
kinit, or else use an ssh authentication mechanism that performs kinit
explicitly as part of the authentication (password or
keyboard-interaction auth). If Microsoft’s goal for the
TRUSTED_FOR_DELEGATION flag was to prevent users from passing their
credentials to a remote host that might be operated by a grey-hat or
otherwise not-completely-trusted administrator, then congratulations:
by attempting to prevent exposure of the credential to that
not-completely-trusted admin, you’ve only guaranteed that users must
now expose their *actual passwords* instead.)

Once we finally figured out that it was the TRUSTED_FOR_DELEGATION
flag that was preventing Mac users from passing credentials, we asked
our Active Directory administrators to grant our Linux admins the
ability to set the TRUSTED_FOR_DELEGATION flag for Linux hosts, so
that we can set the flag when we create a new Linux host and join it
to AD. But our AD admins are balking, because Microsoft’s
documentation is abysmally unclear in explaining the greater security
ramifications of setting the TRUSTED_FOR_DELEGATION for a host.

Our tentative conclusion at this point is that the
TRUSTED_FOR_DELEGATION flag was a fantastically stupid idea on
Microsoft’s part and the correct course of action is to work-around
its existence as best we can: by ensuring that the flag is set on the
AD host machine account on every Linux host which accepts remote ssh
logins. As far as we can discern, the only thing this will enable is
the ability for anyone to delegate a forwardable Kerberos credential
to the host—which is exactly what we want.

Have we misunderstood the goal of the TRUSTED_FOR_DELEGATION flag?
Does anyone know of any security ramifications of enabling it that we
have not considered?

(As a side note, if MIT Kerberos ever decides to implement/honor the
TRUSTED_FOR_DELEGATION flag, we fervently hope that the implementation
also creates a new krb5.conf flag to ignore it; e.g.,
honor_trusted_for_delegation_die_die_die.)

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor