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

[Andrew Bartlett]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part
URL: <http://lists.samba.org/pipermail/cifs-protocol/attachments/20100710/e377055d/attachment.pgp>