Re: Query regarding S4U2Self protocol extension

[Vipul Mehta]

Did some more digging and found out following:
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.

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/dd1b47f9-580c-4c4e-8f34-4485b9728331
This is proved here:
https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html#serendipity




On Sat, Jul 24, 2021 at 2:08 AM Vipul Mehta <vipulme...@gmail.com>
wrote:

> Hi,
>
> To perform constrained delegation from Service A to Service B,
> forwardable flag must be set in the S4U2Self service ticket returned by KDC
> to Service A.
>
> 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 ?
> In my test, I have configured resource based constrained delegation in
> Service B (principalsAllowedToDelegateTo).
>
> --
> Regards,
> Vipul
>


--
Regards,
Vipul

[Vipul Mehta]

[Greg Hudson]

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.

[Isaac Boukris]

On Mon, Jul 26, 2021 at 10:17 PM Greg Hudson <ghu...@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.

...
> https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3

Now that I read this again, and read again the "Additional
considerations" section in that link, I think what might happened with
this change is that now RBCD requires the forwardable flag but any
service with an empty msDS-AllowedToDelegateTo to list, as Vipul
remarked, gets treated as TrustedToAuthForDelegation and gets the flag
(presumably, unless the client is in the protected-users group or has
the not-delegated flag).

I'll run some tests and check it with dochelp.

[Isaac Boukris]

Yes, now any service is treated as TrustedToAuthForDelegation unless
it has a none-empty msDS-AllowedToDelegateTo list, on the other hand
with
NonForwardableDelegation set to enabled RBCD is no longer allowed with
non-forwardable tickets (this would be the default soon, or it is
already).

I guess that cross-realm would also be required to be forwardable,
which means the other realm is trusted for that, I'll try to test it.

[Isaac Boukris]

Note, for MIT I think we don't need the NonForwardableDelegation flag,
just need to behave as enabled and let the plugin's get_principal()
add 'TrustedToAuthForDelegation' if the list is empty. This could
simplify the KDC code as we don't need to check the PAC's
not-delegated flag, although some tests would need updating.

[Vipul Mehta]

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

[Isaac Boukris]

On Tue, Jul 27, 2021 at 6:54 PM Vipul Mehta <vipulme...@gmail.com> wrote:
>
> 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

In case of 2) we'll also check that
'ServicesAllowedToSendForwardedTicketsTo' is empty like in the doc, I
was just suggesting implementation wise that we do it in the plugin
instead of the kdc itself, that is when the principal is retrieved the
plugin will add 'ok_to_auth_as_delegate' if the
'ServicesAllowedToSendForwardedTicketsTo' is empty.

[Isaac Boukris]

On Wed, Jul 28, 2021 at 11:10 AM Vipul Mehta <vipulme...@gmail.com> wrote:
>
> I have windows server 2012 R2 with all the security updates installed and did some tests:
>
> Resource Based Constrained Delegation configured for Service A in Service B account.
>
> Case 1) Service A : trustedToAuthForDelegation = false and non-empty msds-AllowedToDelegateTo -> S42U2Self ticket didn't have a forwardable flag and subsequent S4U2Proxy failed.

That's expected because the default of 'NonForwardableDelegation' is
enabled I think, so RBCD requires forwardable flag now, if you set
NonForwardableDelegation to disabled (that is to 1 ..), then RBCD
S4U2Proxy will continue to work as before the update.

[Isaac Boukris]

On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta <vipulme...@gmail.com> wrote:
>
> Now we know that behavior is unified and S4U2Self ticket should be forwardable to avoid vulnerability, i think we can add a check in MIT Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if ticket is not forwardable it will fail in client itself.
>
> I can see that JDK has this check:
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java -> line 105

MIT used to have that as well before RBCD was added, although I don't
think this was ever necessary, as that check should be done in the
KDC. Also disabling NonForwardableDelegation can be a valid usage when
relying on SIDs and not using protected-group, as in the original RBCD
design:

https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/kerberos/kerberos-constrained-delegation-overview.md

[Vipul Mehta]

Now we know that behavior is unified and S4U2Self ticket should be
forwardable to avoid vulnerability, i think we can add a check in MIT
Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if
ticket is not forwardable it will fail in client itself.

I can see that JDK has this check:
https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java
-> line 105

--
Regards,
Vipul

[Vipul Mehta]

I have windows server 2012 R2 with all the security updates installed and
did some tests:

Resource Based Constrained Delegation configured for Service A in Service B
account.

Case 1) Service A : trustedToAuthForDelegation = false and non-empty
msds-AllowedToDelegateTo -> S42U2Self ticket didn't have a forwardable flag
and subsequent S4U2Proxy failed.

Case 2) Service A : trustedToAuthForDelegation = false and empty
msds-AllowedToDelegateTo -> S42U2Self ticket was forwardable and subsequent
S4U2Proxy passed.

Because ticket signature check has been enabled in KDC in the security
update, now I cannot change the forwardable flag from false to true in
S42U2Self ticket in case 1).

On Tue, Jul 27, 2021 at 9:58 PM Isaac Boukris <ibou...@gmail.com> wrote:

> On Tue, Jul 27, 2021 at 6:54 PM Vipul Mehta <vipulme...@gmail.com>
> wrote:
> >
> > 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
>
> In case of 2) we'll also check that
> 'ServicesAllowedToSendForwardedTicketsTo' is empty like in the doc, I
> was just suggesting implementation wise that we do it in the plugin
> instead of the kdc itself, that is when the principal is retrieved the
> plugin will add 'ok_to_auth_as_delegate' if the
> 'ServicesAllowedToSendForwardedTicketsTo' is empty.
>

--
Regards,
Vipul

[Vipul Mehta]

Thank you.
This was a useful discussion for me.

On Wed, Jul 28, 2021 at 4:36 PM Isaac Boukris <ibou...@gmail.com> wrote:

> On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta <vipulme...@gmail.com>
> wrote:
> >
> > Now we know that behavior is unified and S4U2Self ticket should be
> forwardable to avoid vulnerability, i think we can add a check in MIT
> Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if
> ticket is not forwardable it will fail in client itself.
> >
> > I can see that JDK has this check:
> >
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java
> -> line 105
>

> MIT used to have that as well before RBCD was added, although I don't
> think this was ever necessary, as that check should be done in the
> KDC. Also disabling NonForwardableDelegation can be a valid usage when
> relying on SIDs and not using protected-group, as in the original RBCD
> design:
>
>
> https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/kerberos/kerberos-constrained-delegation-overview.md
>

--
Regards,
Vipul

[Vipul Mehta]

Hi,

I have one more query on this based on following statement in microsoft
document:

"If a non forwardable S4U2self-generated user's service ticket for a
nonsensitive user is used, then the SFU client SHOULD<11> locate a
DS_BEHAVIOR_WIN2012 DC ([MS-KILE] section 3.2.5.3) to send the request."

https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960
<https://urldefense.com/v3/__https:/docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960__;!!KpaPruflFCEp!xs7LC6xF-p5noCT18UnibXxKXcrNUf6GDk_BArh2V7T3TRWFgGLo5IL9RlB1cVwEOw$>

Is this implemented in the MIT Kerberos client ?


On Thu, Jul 29, 2021 at 2:20 PM Vipul Mehta <vipulme...@gmail.com>

wrote:

> Thank you.
> This was a useful discussion for me.
>
> On Wed, Jul 28, 2021 at 4:36 PM Isaac Boukris <ibou...@gmail.com> wrote:
>
>> On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta <vipulme...@gmail.com>
>> wrote:
>> >
>> > Now we know that behavior is unified and S4U2Self ticket should be
>> forwardable to avoid vulnerability, i think we can add a check in MIT
>> Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if
>> ticket is not forwardable it will fail in client itself.
>> >
>> > I can see that JDK has this check:
>> >
>> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java
>> -> line 105
>>
>> MIT used to have that as well before RBCD was added, although I don't
>> think this was ever necessary, as that check should be done in the
>> KDC. Also disabling NonForwardableDelegation can be a valid usage when
>> relying on SIDs and not using protected-group, as in the original RBCD
>> design:
>>
>>
>> https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/kerberos/kerberos-constrained-delegation-overview.md
>>
>
>
> --
> Regards,
> Vipul
>

--
Regards,
Vipul

[Isaac Boukris]

Hi Vipul,

On Wed, Aug 25, 2021 at 6:12 AM Vipul Mehta <vipulme...@gmail.com> wrote:
>
> I have one more query on this based on following statement in microsoft document:
>
> "If a non forwardable S4U2self-generated user's service ticket for a nonsensitive user is used, then the SFU client SHOULD<11> locate a DS_BEHAVIOR_WIN2012 DC ([MS-KILE] section 3.2.5.3) to send the request."
>
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960
>

> Is this implemented in the MIT Kerberos client ?

No it isn't, we just assume all the KDCs support RBCD.

I think this has become less relevant now that RBCD requires the
forwardable flag as well [1]. I guess this doc should be updated too.

[1] https://lists.samba.org/archive/cifs-protocol/2021-July/003608.html

[Vipul Mehta]

Thanks.
This information will be provided to openjdk dev as they were asking about
MIT krb5 behavior -> https://bugs.openjdk.java.net/browse/JDK-8272162

--
Regards,
Vipul