Message-ID:

The solution of this problem is trivial and is left as an exercise for the reader.

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.90.1713317464.2322.kerberos@mit.edu>

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

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: ken...@cmf.nrl.navy.mil (Ken Hornstein)
Newsgroups: comp.protocols.kerberos
Subject: Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
Extensions flag?
Date: Tue, 16 Apr 2024 21:30:52 -0400
Organization: TNet Consulting
Lines: 143
Message-ID: <mailman.90.1713317464.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>
<202404170130.43H1UpOg023445@hedwig.cmf.nrl.navy.mil>
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="7249"; mail-complaints-to="newsmaster@tnetconsulting.net"
Cc: kerberos@mit.edu
To: James Ralston <ralston@pobox.com>
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=Ln1aT3da;
dkim=pass (2048-bit key,
unprotected) header.d=nrl.navy.mil header.i=@nrl.navy.mil header.a=rsa-sha256
header.s=s2.dkim header.b=K+pqAWNk
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=c4a4it2sLMUgsTGlOc12emloEi+trGxDScXqlIGjs3gHN8oG66fZmjJdD9iyd6GAd2WREkLbEKzg96bAh4D/DFIZ4nJTjUUi/W14XQxAd01uVI+bGQ5jDCU9EgKg+3F3nTBpCMYxxUp5e1jRwdde2Ehn61TYdD/ypl1yTAC1ZS7gJxrRzBfgkz0/qov3c7eOR9tPHvyu5drxtGZEYiJTHwMf9iqV/oUWjWQ0eRGV6pzO4qs1MvkmAH3QlbFMKpLgwBjNT0WDyVqZj1ptTGvlC4VAuzXeuqVgcoHASdMOkCdrPgIieI5Nm7HADkKtu76kGMvlYOS7ho45ZRZq/EZ+zQ==
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=JxajhBT4Uxj6KkMD5LwuX0H2KDg42vQd8RT4+SlA94k=;
b=BDY/e7XPN7A9OvW3FUA6qPRw/KXt2V947cwnkm9Qdroh9EypDGEITSEGq0EWCMTbr8LMe7pZ48pB09MdwxI8rZG6827h7Q/tD+c32B1OPuJwj3GJAqmJRE2lrzapP4F7HIxC80U/5hqDiLyxfGKP9qkIMgcR4iVR6WhhvVou0VQeEhrbtcSKuulEVxxHpqRahjHIQRqihrhnixRKFvTnE8E//TaeYu5V7PBODo06f3w9DKEPHGOmqTyeWRnxdxkF6HtqabyELqqAdB+Grli8/0LULDaNtQnSIfPPbyG/PyUuDegCMOblT8PV6omtFUl8c/DjBs0J4lkr338mri0grw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is
140.32.59.234) smtp.rcpttodomain=mit.edu smtp.mailfrom=cmf.nrl.navy.mil;
dmarc=pass (p=reject sp=reject pct=100) action=none
header.from=cmf.nrl.navy.mil; dkim=pass (signature was verified)
header.d=nrl.navy.mil; 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=JxajhBT4Uxj6KkMD5LwuX0H2KDg42vQd8RT4+SlA94k=;
b=Ln1aT3daX4XC1ahhjHQBcv3kb0MANJ2aO/PGKEnCi0rGKJ/Cs3hDGfGpvKsf6nw5abTy6adN2soYRiRk+vZ3lSJtw5B/AXHiB6j8K+X9S5c/IYwoPIPzxdX3zE7MQYoueGrIIastC2UK1nOJkx69N9JJlsrrhuwebxA0QTei/u8=
Authentication-Results: spf=pass (sender IP is 140.32.59.234)
smtp.mailfrom=cmf.nrl.navy.mil; dkim=pass (signature was verified)
header.d=nrl.navy.mil;dmarc=pass action=none header.from=cmf.nrl.navy.mil;
Received-SPF: Pass (protection.outlook.com: domain of cmf.nrl.navy.mil
designates 140.32.59.234 as permitted sender)
receiver=protection.outlook.com; client-ip=140.32.59.234; helo=mf.dren.mil;
pr=C
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nrl.navy.mil;
h=message-id : from :
to : cc : subject : in-reply-to : references : mime-version : content-type
: content-transfer-encoding : date; s=s2.dkim;
bh=JxajhBT4Uxj6KkMD5LwuX0H2KDg42vQd8RT4+SlA94k=;
b=K+pqAWNkdUejlGACBKX+ldI9qPw3YrcUCy8gc7KT7hcky+rthRdmjg2r+Sx10334Iobv
yGro8/Ary4aW35A62TZdQyCwOHUNqRHZy8SVK0M4/Vy2O6Eoj9YtuBWiU3URVy7HsamF
BCSGT+INwvZur00VsZButDPyNw+CQEeZim/W9aapQpkzWkSwCzQRcUpua0ZylOE1IhDw
UaD3R09aFUMrMW20nCu+Lh3Gn1Q55VCsWkvIzFpGXxUGO7ij/nbYQIwYSLchZ8u67SWU
M3sT+VZ76wsF0ktpoBDIP7rZUfFOLGzJyjqWUIXO61MtJoi2eZqX5kjusNUHjlRZroKR og==
In-Reply-To: <CAEkxbZvn=3G3MVossM0aRC3pFd+JCX13ugUo6BwyKqaKtv--xg@mail.gmail.com>
X-Face: "Evs"_GpJ]],xS)b$T2#V&{KfP_i2`TlPrY$Iv9+TQ!6+`~+l)#7I)0xr1>4hfd{#0B4
WIn3jU;bql;{2Uq%zw5bF4?%F&&j8@KaT?#vBGk}u07<+6/`.F-3_GA@6Bq5gN9\+s;_d
gD\SW #]iN_U0 KUmOR.P<|um5yP<ea#^"SJK;C*}fMI;Mv(aiO2z~9n.w?@\>kEpSD@*e`
X-NRLCMF-Spam-Score: () hits=0 User Authenticated
X-NRLCMF-Virus-Scanned:
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: CY4PEPF0000EE30:EE_|PH7PR01MB8076:EE_
X-MS-Office365-Filtering-Correlation-Id: 07a678b1-a38e-4ad9-d110-08dc5e7e06b9
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: zIoYcQw5oQnXvEZY4RnkDB3fSIJJDfrlb1FImsrQL9c7M
leqGtrheGr2J9CdYFujj9g/SCtS/ScEYQ3NmnNdnSfNk2
pWmseo6HOoC9MbBfYjoGsFrtiTWj8F6wcFSSnM2Lm1Lr8
NnSAO0tn6vT0HGNJ9TCkNtJ8MkTXF6PeeKmuAYhZIXaZE
okYXezIACaRyXlz5o5gxiEhe7Tq/CH9ShlCwPkdKTPjl8
0OWFdy+eMjNw8nGj7qoCEHdygJ8CKUf8i6s1jmC9gZ4uQ
URYSnSoUoj6ZeEDdKiV8AhTNH9QIwLGeFKu33giCXy391
hJ6zLyMG8/S5Ubv93Xgsqj3AIBjdu5K7RNIMx1kxh+rMJ
40ehexUHMWlzy4Dx8TfMsQMQwo60KumThzhgrjI1xpcWL
/3ts5/Lx7uztT07Jp+uZ58NuV+mgMDsBmmKHsJFV0L/Hs
l9xIA3t+cQbANxWtqFqZTZepE/IIFTTaQFE3ofivFhnKI
xPaf3W83oyWE9NowjAqWu9dr7NeG9WSYFYuu3V1lrRlOt
Wofrgm3kMBBFb0MxNKAWWEWDzWO+V0f0Zvs7XidMelObn
JjNLRdWFTCOJjrh2+3u0dkUZEnNKLOKvlbu7yVnKooiIQ
qXJ1frzhA+z5CdoRFzeSNaNmHbJdZS2DgoeVZF7XPyyVW
UaYgYJSYb/lcrgXOXDA66v6hUKkXTSGGnfoJlyOr7l6ah
LO17HIHOxy5jMxgR1QNnWNuNlHCflhkDUTblRqaFHdEnn
+m716YnhA9KnGMeDQFlI4BekXkojSgD0f9CowCtuoDAAR
y9triqWFDw+B7osTTGGG1512+KiDmXO6ADkN+BQowwm7M
uR2pQJHw6jyiSyr5uCvhrHj9IX+JGnepaO6GdoZI/mE9A
vXDPFYrDYBYDdcILF6H3EDT8z4At0LPFByFL0ybs3TimF
yvwWHH0jjezeXERyYUqX5uiJqKrJuNx82vJUs1rSflyGS
58kGCEvoosx9kQFBOnKeAwa2wcsX0C31HnybuW57DBoIn
1iwx868PIZICAfnV/THgLgtPef6cYHo2P7SFcaqv8SfiG
xeRzQrX0eFujHeulqfgqcOdINUk/fqtrb4eOzcqIETgC1
gBWhOD4FPK6Nce7Ca7qciysrB5CD9Wf3Tf/eG/Zz4vGL8
8Bd4oujgl2zDARUNARILvVjAdKD871kqKf0n1y6BVGNSE
5RbvCupOwDpQdY2YkFqaovKkNPAIHM9yj0eWWmvOlsXcd
3hPKTG2WAlvOduy5NydVoNztS6ZKmakDa0BCJFEocido5
LUvfBo80VGZSdDCePT8xC0RaBoNrN9nMPj+8LSK
X-Forefront-Antispam-Report: CIP:140.32.59.234; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:mf.dren.mil; PTR:mfe.dren.mil; CAT:NONE;
SFS:(13230031)(48200799009)(376005)(61400799018); 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: 17 Apr 2024 01:30:54.9278 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 07a678b1-a38e-4ad9-d110-08dc5e7e06b9
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: CY4PEPF0000EE30.namprd05.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR01MB8076
X-MIME-Autoconverted: from quoted-printable to 8bit by mailman.mit.edu id
43H1V0rx948372
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: <202404170130.43H1UpOg023445@hedwig.cmf.nrl.navy.mil>
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>

by: Ken Hornstein - Wed, 17 Apr 2024 01:30 UTC

>> 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.

Okay, THAT makes more sense.

>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.

Well, I figured out what is going on there ... see below.

>> 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.

Simo already explained the thinking there, but I think the thing you're
not considering is that not all services require delegated credentials.
Yes, in your environment (and ours) delegated credentials for host
principals is essential, but you don't normallty need that for other
types of credentials. I haven't run into Simo's experience of badly
coded applications delegating credentials when they shouldn't, but I could
believe it happens. It does make sense to be able to control this
centrally based on KDC configuration (that's one of the advantages
to _having_ a KDC). And, well .. one thing I guess I do not understand
is, exactly, what is your problem with turning on that setting on your
KDC? If this is just a cri de cœur about lousy AD admins, fair enough;
I can understand your pain there (most AD admins really don't know how
Kerberos works, sadly).

Speaking about the OK-AS-DELEGATE flag, the ONLY thing that does is set
the flag in the ticket which the client uses as a hint (it is free to
ignore that hint). I cannot speak for the AD TRUSTED_FOR_DELEGATION flag
as a whole; it's possible it does something else than set the OK-AS-DELEGATE
ticket flag.

However, we use MIT Kerberos for our KDC and we occasionally use the
MacOS X ssh client and it delegates credentials just FINE for us without
the use of OK-AS-DELEGATE, so I was curious as to what was going on there.
I did some digging into the MacOS X Heimdal code, and here's what I found.

- The OpenSSH code is mostly the same for our purposes in terms of the
Kerberos support; use of the -K flag turns on the right flags for
credential delegation (in addition to GSSAPI authentication support).

- In the gss_init_sec_context() code path I found this little snippet:

/*
* If the credential doesn't have ok-as-delegate, check if there
* is a realm setting and use that.
*/
if (!ctx->kcred->flags.b.ok_as_delegate && ctx->ccache) {
krb5_data data;

ret = krb5_cc_get_config(context, ctx->ccache, NULL,
"realm-config", &data);
if (ret == 0) {
/* XXX 1 is use ok-as-delegate */
if (data.length < 1 || ((((unsigned char *)data.data)[0]) & 1) == 0)
req_flags &= ~(GSS_C_DELEG_FLAG|GSS_C_DELEG_POLICY_FLAG);
krb5_data_free(&data);
}
}

So if there is NOT a delegation flag on the ticket, the realm-config
entry is checked. If the first byte has the least-significant bit
set, the all of the delegation flags are cleared. I suspect this is
what you're hitting.

So, what sets that realm configuration? As far as I can tell, that
ONLY happens inside of kinit. Specifically, this code block:

if (ok_as_delegate_flag || windows_flag || use_referrals_flag) {
unsigned char d = 0;
krb5_data data;

if (ok_as_delegate_flag || windows_flag)
d |= 1;
if (use_referrals_flag || windows_flag)
d |= 2;

data.length = 1;
data.data = &d;

krb5_cc_set_config(context, ccache, NULL, "realm-config", &data);
}

So if you are using the --ok-as-delegate flag _or_ the --windows flag
to kinit, you get this behavior. Are you using one of those? I can't
find another code path that sets this behavior. However, I tried
reproducing this here and setting --windows on kinit still lets me
delegate credentials using the vendor ssh, so I think I missed
something.

>> 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.

I will confess that we supply to our users Kerberos kits which are
all MIT sources, including OpenSSH, for this exact reason; there's too
much weird variance like this. But you don't have to "rip out" the
vendor Kerberos code; it runs along side it. We do provide MacOS X
kits as well (the code signing is a pain, but doable).

--Ken

Subject	Author
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions	Ken Hornstein