RetroBBS - comp.protocols.kerberos - Re: Query regarding S4U2Self protocol extension

Re: Query regarding S4U2Self protocol extension

<mailman.3.1627401043.4484.kerberos@mit.edu>

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

copy link Newsgroups: comp.protocols.kerberos

Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!tncsrv06.tnetconsulting.net!.POSTED.pch.mit.edu!not-for-mail
From: vipulmehta.1989@gmail.com (Vipul Mehta)
Newsgroups: comp.protocols.kerberos
Subject: Re: Query regarding S4U2Self protocol extension
Date: Tue, 27 Jul 2021 12:09:47 +0530
Organization: TNet Consulting
Lines: 74
Message-ID: <mailman.3.1627401043.4484.kerberos@mit.edu>
References: <CAMeQEL8+JGoqgh-j62duJBMLLoOKVPEZRWbC4mxLtdB-3ggwtw@mail.gmail.com>
<42a3d4b0-3461-5342-bf83-83475f3a0473@mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Injection-Info: tncsrv06.tnetconsulting.net; posting-host="pch.mit.edu:18.7.21.50";
logging-data="26112"; mail-complaints-to="newsmaster@tnetconsulting.net"
Cc: kerberos@mit.edu
To: Greg Hudson <ghudson@mit.edu>
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=SpEcmdJ3Aw35wJLqRze3btEKV7zl0mCmS73PFRXR8OtppECgxneIxQvBIZJZZI418pox8HBnbj6wduJtl1RFFsNC9ieulmw0L2K5TnCaBgFXS4KMaXTHrO+lW//AEJCeXAgOBM7t/OEQtttYL1r+6R9dqgTTb3w+RZWg2rbCzc1YIjfvg9H2ibRUU6CV6DLmzIpwIeHljrztbm62DHLnhvBGbsGx8Jyd2995e81KIr/6Ht1EAhql3Bwk13+v9uKWl4Zg5yn7W5Wj4nxO2wh6FPvViFsj3iEaMc8RsMpsaAv2zyRkU1JOb8BfHpeYber1pg1N996RFegXOljerjewIA==
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-SenderADCheck;
bh=2sPaG2IH87cj0jsC6qzhxg48U37vstoblyfoGa8+IgU=;
b=oL4VAnbs/MCxf3knT2MD2M9p7jwsfAsO4AZmV/OyBQvQbYospUIdmJ1XVAVKJs31ZN/UHIQT+AxfUHA9oyrO82NczJCAsw/dwAJh3y5tjIfIu3FW9G2NqDGf/mb2FwCIKmbPkrWEsq3paAPbOgNgChq/pduibW5nnNfRI5qxIhk3oFyvpmRGzj4YUOhRkuW9hh/z1+lQw5D7QHJVHp8Uli34efApIbjG6tH+ohQD0O3MRQdyKWisgFD7x2nw5q/RFlp4FmTDcxAnrOiDT2HBhY2st+KLunnmVg74ZTlKIOSTjnK9SkC8mdiwmfWJqZuSaZ0HYKVKmHrx7/i4XOnkRQ==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
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=2sPaG2IH87cj0jsC6qzhxg48U37vstoblyfoGa8+IgU=;
b=nQXlXfcUJFT5FEc+vV2lHiaQZj16kb78WgowBoJ/AwKYeVpHVPR6QwVhj4fOqkDxbk1WBkPPu/763H/jIrhUGfF/Z0ynXel1KiJjzacmUOLZrDqJtDApALWSJwHbJcB9xluacfKGKeWzFPrhLTEjuH5LwqZxt6YeRHjIpC1tJfY=
Authentication-Results: spf=pass (sender IP is 209.85.166.49)
smtp.mailfrom=gmail.com; mit.edu; dkim=pass (signature was verified)
header.d=gmail.com; mit.edu;
dmarc=pass action=none header.from=gmail.com;
Received-SPF: Pass (protection.outlook.com: domain of gmail.com designates
209.85.166.49 as permitted sender) receiver=protection.outlook.com;
client-ip=209.85.166.49; helo=mail-io1-f49.google.com;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=2sPaG2IH87cj0jsC6qzhxg48U37vstoblyfoGa8+IgU=;
b=MIeBWvScakLDanP+4X9g+1qsbIqBrlEwUlGiUR4JLWR+tXXfjo4HzbQC+7rBTT4b2D
rLxZhNgfl/dD/JjRYFd2y3x4NYWS7JfsRXDnCpVx9783DtwJWuYxgm1TDX0iFBmgcAdF
NqsWqJI02xoeKCHthwgUDnnWuNgxOIXgHy0NzRjr1bQf+smghf+Ri1POXwn8qNAGmLG4
IZ6zPW/nRwVFvAZaJkDxw+pvUod2vcBnvpem+pilw1Z4wcFo/uCUDGPFjRxJHNq+GMtF
UkuS7vng9kaf8Ew5C2NwB4yw6lpi8fTkZf+Y0vbRnzHoTVqfT82kHoZv2qa6L4S2rmc0
zj8w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=2sPaG2IH87cj0jsC6qzhxg48U37vstoblyfoGa8+IgU=;
b=TZ29aUea7zd8q+gWyb2n4+HJZ1vH8s8h1CfZsbK8BLyYndzbw2ymdv6Y8TGdDuPh76
LAUcUQd9ZvdqSjabnjEzGh+tI68T/kz4s8OtLgAH5wxT/UYbi102vb/Sl4FHP8on/fIj
MpgS+ZUSmKWltqrna7MAfNsEVxeuIefZxkPn1mXQwoINioS9r63LWFMEo25GjlXrTQTC
If7DNZGbthny7tBhUY9H1h4lsADAJd4NQxf+YBEpIpaq/+/Y50es2gzYbnHDclixvBwu
vfPG2ERmDafSZs6CJK4U/dKQfSBuBd60ruSfymLoJM1pzA4nZRqipz1xWi764eDQAo6g
dU/g==
X-Gm-Message-State: AOAM533efsGFp3UjQLUMytglgQbmzrX87vxoTaJICtYNlb7ookVF+0HT
uNlCr2+Ys+Ed+Rfj4B9ooXplbPB4iH7/UxdEWwv1gRRodUA=
X-Google-Smtp-Source: ABdhPJyyrvOq0t665ghvd/5cq0/o9IwfoEMQO74prXKo/4xKlCOpp1975QB0NO9BeMrK+EPFb1xpxwzbBAAj9P41MkI=
X-Received: by 2002:a02:cf31:: with SMTP id s17mr20424416jar.46.1627367998290;
Mon, 26 Jul 2021 23:39:58 -0700 (PDT)
In-Reply-To: <42a3d4b0-3461-5342-bf83-83475f3a0473@mit.edu>
X-EOPAttributedMessage: 0
X-EOPTenantAttributedMessage: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b:0
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 54a460d8-a6b3-4539-3607-08d950c95aa6
X-MS-TrafficTypeDiagnostic: DM6PR01MB5420:
X-LD-Processed: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b,ExtAddr
X-MS-Exchange-AtpMessageProperties: SA
X-MS-Exchange-Transport-Forked: True
X-Microsoft-Antispam-PRVS: <DM6PR01MB542049E3113ED535B22BE232FFE99@DM6PR01MB5420.prod.exchangelabs.com>
X-MS-Oob-TLC-OOBClassifiers: OLM:8273;
X-MS-Exchange-SenderADCheck: 0
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: tSDLEtJcGUfH2UCVLwlN8JQEG41bzgvm6BDxPhlmHMvI7QIZoDD5EC8Kps0NiJpRXm8YHppx2NWOnKL4MbBQ5gzN0oLAf4m2hzqUd6mK7xQk4S78bnofb9LFRTHxPvIvttBmAWJr88v3/C1eAqOTp4Gy3NCzTld67jmCl6SwuIQ6qBn6ou43ikoTciHGj17yfQCmrwI7tW3OJOZcjUCZTxaLIFllIoHnnQ+HmrJ1vSPSyzBemhUTwlQnz2cO4VANIppAICmZjAJe1u+9ThJvDhxWGkAtAtWE/iRdDITcOewrFPSmj4Q3sbFIddCzcSybCIjLmPN7WQWZIJxTlKbwEgwGMGOLMTykZzg24yl7YLqkBQj6+5eZgJsPGTVVNpKMNqnW+yqLKPcxVkMayzfoh0Qt/el7mf1r+O6McSlH9U4LpDzeSyToiV0NX0vQY6humYyUdMmM0rCxZ9ggiKBew9ALP68FTLCveDrCdrL8IHcaIdQ9N946l33dM0HvcBW0bnISAxcT6iV+YL+IKvE1WvBfZigpDwPtAmvnURuzVegc73tXgMtbpFTh2kf4ltRuFTb+O8LBJjKYyNHHTqfmM3fLfNh9+WXLJScnAOHNAPXQGd4MsYCPIkHLt3bKmRd0lX2QUcyAqzL3nFyhxPRl7spHYeHjsi6dfXq2YwrA1gWALj4TWy5GmyFu4NFD2tA4XxkpDxzwq2Zhm5Co2dDMHQ==
X-Forefront-Antispam-Report: CIP:209.85.166.49; CTRY:US; LANG:en; SCL:1; SRV:;
IPV:NLI; SFV:NSPM; H:mail-io1-f49.google.com;
PTR:mail-io1-f49.google.com; CAT:NONE;
SFS:(4636009)(136003)(346002)(376002)(396003)(39860400002)(86362001)(166002)(356005)(83380400001)(5660300002)(76482006)(53546011)(498600001)(966005)(33964004)(45080400002)(786003)(316002)(42186006)(6862004)(8676002)(4326008)(6666004)(82202003)(26005)(2906002)(73392003)(336012)(68406010)(70586007)(55446002)(7596003)(7636003);
DIR:OUT; SFP:1102;
X-Auto-Response-Suppress: DR, OOF, AutoReply
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jul 2021 06:39:58.9096 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 54a460d8-a6b3-4539-3607-08d950c95aa6
X-MS-Exchange-CrossTenant-Id: 64afd9ba-0ecf-4acf-bc36-935f6235ba8b
X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT008.eop-nam11.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-FromEntityHeader: Internet
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR01MB5420
X-OriginatorOrg: mitprod.onmicrosoft.com
X-Mailman-Approved-At: Tue, 27 Jul 2021 11:50:42 -0400
X-Content-Filtered-By: Mailman/MimeDel 2.1.6
X-BeenThere: kerberos@mit.edu
X-Mailman-Version: 2.1.6
Precedence: list
List-Id: The Kerberos Authentication System Mailing List <kerberos.mit.edu>
List-Unsubscribe: <https://mailman.mit.edu/mailman/listinfo/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>

by: Vipul Mehta - Tue, 27 Jul 2021 06:39 UTC

Need a clarification:
MIT KDC will set the forwardable flag in S4U2Self ticket in following cases
(provided account is not sensitive and not part of secure group):
1) ok_to_auth_as_delegate is true
or
2) ok_to_auth_as_delegate is false and Service TGT has forwardable flag set

Am I correct here ?

One more thing:
If msDS-AllowedToDelegateTo is non-empty and TrustedToAuthForDelegation is
false then the forwardable flag must be set to false. Isn't this behavior
different between MIT KDC and Windows KDC as MIT KDC does not check
msDS-AllowedToDelegateTo list.

Just copy pasting microsoft doc statement:
"If the TrustedToAuthenticationForDelegation parameter on the Service 1
principal is set to:
TRUE: the KDC MUST set the FORWARDABLE ticket flag ([RFC4120] section 2.6)
in the S4U2self service ticket.
FALSE and ServicesAllowedToSendForwardedTicketsTo is nonempty: the KDC MUST
NOT set the FORWARDABLE ticket flag ([RFC4120] section 2.6) in the S4U2self
service ticket.<18>
If the DelegationNotAllowed parameter on the principal is set, then the KDC
SHOULD NOT set the FORWARDABLE ticket flag ([RFC4120], section 2.6) in the
S4U2self service ticket.<19>"

On Tue, Jul 27, 2021 at 12:44 AM Greg Hudson <ghudson@mit.edu> wrote:

> On 7/23/21 4:38 PM, Vipul Mehta wrote:
> > I did some testing with Windows KDC and it will set forwardable flag in
> > S4U2Self service ticket in either of the following cases:
> >
> > 1) TrustedToAuthForDelegation is set to true in Service A account.
> >
> > 2) Service A TGT used in S4U2Self has forwardable flag set and
> > msDS-AllowedToDelegateTo list is empty on Service A account.
> > I am not able to understand why msDS-AllowedToDelegateTo needs to be
> empty
> > in the 2nd case.
> >
> > Is the behavior of MIT KDC the same as Windows KDC ?
>
> We have an analog of the TrustedToAuthForDelegation flag, called
> ok_to_auth_as_delegate. We don't check for an empty
> allowed-to-delegate-to list.
>
> > Service ticket used in S4U2Proxy need not be forwardable if resource
> > based constrained delegation is used i.e.
> > principalsAllowedToDelegateTo option is
> > configured on Service B.
>
> Note that, as of 2019, the forwardable flag must be set on the evidence
> ticket if the delegation is authorized in both directions (on the
> intermediate service and the target service). We implemented this
> counterintuitive behavior in the MIT KDC for consistency.
>
> There is some reason to think this might be changing. This article
> (noted by Isaac):
>
>
> https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3
>
> talks about a protection measure that "unifies the logic for
> Resource-Based Constrained Delegation (RBCD) with the original
> constrained delegation." We have asked Microsoft for clarification.
>

--
Regards,
Vipul

"Love may fail, but courtesy will previal." -- A Kurt Vonnegut fan

devel / comp.protocols.kerberos / Re: Query regarding S4U2Self protocol extension

devel / comp.protocols.kerberos / Re: Query regarding S4U2Self protocol extension

Subject	Author
Re: Query regarding S4U2Self protocol extension	Vipul Mehta