[cifs-protocol] [REG:110062157456375] -[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

[Bryan Burgin]

Quick status.

I sent your comments to the dev group when I received them Saturday.  I'm still working with them to get you a response.

Notes like <28> and <31> appear in a separate Product Behavior section for several reasons, including where the behavior may be different between versions of Windows or a feature is supported in just a subset of Windows.

Bryan


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Friday, July 09, 2010 7:58 PM
To: Bryan Burgin
Cc: pfif at tridgell.net; cifs-protocol at samba.org; mat+Informatique.Samba at matws.net; MSSolve Case Email
Subject: RE: [REG:110062157456375] -[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage

On Fri, 2010-07-09 at 20:53 +0000, Bryan Burgin wrote:
> Andrew,
> 
>  
> 
> I received the following response from the product group, which I am 
> forwarding for your feedback.  Please let me know if this resolves 
> your question.

Not really, because I can't really map the response back to my question, and because of the silly practice of documenting Microsoft-specific exceptions (<28> and <31>) to a Microsoft specific protocol.

What are those exceptions, and why can't they be described inline?

> [MS-KILE] Section 3.3.1.1 “Account Database Extensions” specifies the 
> account database extension which impacts KDC behavior:
> 
>  
> 
> KerbSupportedEncryptionTypes: A 32-bit unsigned integer that contains 
> a combination of flags that specify what encryption types (section
> 2.2.5) are supportedby the application server.<24> KILE 
> implementations that use an Active Directory for the accountdatabase 
> SHOULD use the msDS-SupportedEncryptionTypes attribute ([MS-ADA2] 
> section 2.324).
> 
>  
> 
> [MS-KILE] Section 3.3.5.3 “AS Exchange” specifies the behavior during 
> AS_REQ processing:
> 
>  
> 
> If the krbtgt account has a KerbSupportedEncryptionTypes populated 
> with supported encryption types, then the KDC SHOULD<28> return in the 
> encrypted part ([Referrals-11], Appendix A) of AS-REP message PA-DATA 
> with padata-type set to PA-SUPPORTED-ENCTYPES(165), to indicate what 
> encryption types are supported by the domain KDCs.

KerbSupportedEncryptionTypes is msDS-SupportedEncryptionTypes?

Also, how exactly is the key available for encryption of the krbtgt ticket calculated (rather than the PA-SUPPORTED-ENCTYPES(165) value, which is multi-value). 

> If not, the KDC SHOULD check if the krbtgt account has the UseDESOnly 
> flag and if set to:
> 
> §             TRUE: the KDC SHOULD, in the encrypted pre-auth data
> part ([Referrals-11], Appendix A) of the AS-REP message, include 
> PA-DATA with the padata-type set to PA-SUPPORTED-ENCTYPES (165), and 
> the padata-value set to 0x3 (Section 2.2.5).
> 
> §             FALSE: the KDC SHOULD, in the encrypted pre-auth data
> part ([Referrals-11], Appendix A) of the AS-REP message, include 
> PA-DATA with the padata-type set to PA-SUPPORTED-ENCTYPES (165), and 
> the padata-value set to 0x7 (Section 2.2.5).

So, to get this a little more concrete we only encrypt krbtgt with AES msDS-SupportedEncryptionTypes only if that is specified for krbtgt and that enc type is included in msDS-SupportedEncryptionTypes?

Why do you allow krbtgt tickets to be encrypted between KDCs with only
des-cbc-md5 encryption?  Does this not allow a trivial brute-force attack on the all-important krbtgt password?

> [MS-KILE] Section 3.3.5.4 “TGS Exchange” specifies the behavior during 
> the TGS_REQ processing:
> 
>  
> 
> If the server or service has a KerbSupportedEncryptionTypes populated 
> with supported encryption types, then the KDC SHOULD<31> return in the 
> encrypted part ([Referrals-11] Appendix A) of TGS-REP message PA-DATA 
> with padata-type set to PA-SUPPORTED-ENCTYPES (165), to indicate what 
> encryption types are supported by the server or service. If not, the 
> KDC SHOULD<32> check the server or service account's UseDESOnly and if 
> set to:
> 
> §             TRUE: the KDC SHOULD, in the encrypted pre-auth data
> part ([Referrals-11], Appendix A) of the TGS-REP message, include 
> PA-DATA with the padata-type set to PA-SUPPORTED-ENCTYPES (165), and 
> the padata-value set to 0x3 (Section 2.2.5).
> 
> §             FALSE: the KDC SHOULD, in the encrypted pre-auth data
> part ([Referrals-11], Appendix A) of the TGS-REP message, include 
> PA-DATA with padata-type set to PA-SUPPORTED-ENCTYPES (165), and the 
> padata-value set to 0x7 (Section 2.2.5).

I'm still a little lost as to how this applies to what keys are available for AS-REQ and TGS-REQ on and to a given account.

Is the actual behaviour much more like:
 - the supported encryption types displayed over the Kerberos protocol is calculated from the intersection of the keys available and the msDS-SupportedEncryptionTypes value (or fallback value based on
UseDESOnly)

 (The keys available are of course limited by the domain functional level that controls what encryption types are written on password
change)

Andrew Bartlett

-- 
Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Cisco Inc.