[cifs-protocol] [EXTERNAL] [MS-SFU] Clarify the new NonForwardableDelegation flag - TrackingID#2107090040004014

[Jeff McCashland]

Hi Isaac,

Thank you for the additional observations and information. I will continue working with our CVE team to get verification and clarification. 

Best regards,
Jeff McCashland | Senior Escalation Engineer | Microsoft Protocol Open Specifications Team 
Phone: +1 (425) 703-8300 x38300 | Hours: 9am-5pm | Time zone: (UTC-08:00) Pacific Time (US and Canada)
Local country phone number found here: http://support.microsoft.com/globalenglish | Extension 1138300
We value your feedback.  My manager is Natesha Morrison (namorri), +1 (704) 430-4292

-----Original Message-----
From: Isaac Boukris <iboukris at gmail.com> 
Sent: Tuesday, July 27, 2021 7:16 AM
To: Jeff McCashland <jeffm at microsoft.com>
Cc: cifs-protocol at lists.samba.org; Greg Hudson <ghudson at mit.edu>; Jeff McCashland <jeffm at microsoftsupport.com>
Subject: Re: [EXTERNAL] [MS-SFU] Clarify the new NonForwardableDelegation flag - TrackingID#2107090040004014

On Tue, Jul 27, 2021 at 3:43 PM Isaac Boukris <iboukris at gmail.com> wrote:
>
> I've run a couple of tests, it looks like the behavior did change 
> significantly, as now any service with an empty 
> msDS-AllowedToDelegateTo list is treated as TrustedToAuthForDelegation 
> and gets forwardable tickets with S4U2Self, on the other hand when the 
> new NonForwardableDelegation is enabled (set to 0..), then the 
> evidence ticket is required to be forwardable even in RBCD.
>
> Please confirm and update the documentation accordingly, especially 
> for the cross-realm RBCD case which I suppose would also require 
> forwardable tickets and the other realm is trusted for that.

Looking at the updated doc again, I can see that the S4U2Self change is already documented in MS-SFU 3.2.5.1.2, but not the S4U2Proxy part in 3.2.5.2.3, assuming we only need to document the NonForwardableDelegation enabled behavior (which I understand will be the default), then I guess we can remove the 'UserAccountControl'
check and simply say that: if the service ticket in the additional-tickets field is not set to forwardable then the KDC MUST return KRB-ERR-BADOPTION ..

Thanks