Andrew, I received responses to your follow-up questions. Please let me know if this resolves your original line of questioning. If it does, I would like to close that issue.
(Q1) KerbSupportedEncryptionTypes is msDS-SupportedEncryptionTypes? (A1) For Windows, yes. Other KDC implementations have different settings. (Q2) 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). (A2) Same as for other tickets [RFC3962], [RFC4757], [RFC3961]. There is a local ADM variable for what encryption types are supported by Kerberos ([MS-KILE] Section 3.1.1.5) as specified in MS-KILE this is 0000001F for Windows Server 2008 R2 DCs. The krbtgt account has a KerbSupportedEncryptionTypes. As with other tickets the strongest encryption type supported by the KDC and the target account, krbtgt is used. (Q3) 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? (A3) If the KDC support AES ([MS-KILE] Section 3.1.1.5) and krbtgt account. (Q4) Why do you allow krbtgt tickets to be encrypted between KDCs with only des-cbc-md5 encryption? (A4) Yes, when either the KDC is configured to only support DES or the krbtgt account is set for UseDESOnly/msDS-SupportedEncryptionTypes set to DES only (Q5) Does this not allow a trivial brute-force attack on the all-important krbtgt password? (A5) Yes, but this is not a default setting. (Q6) 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) (A6) Correct. This is per [RFC4120] Section 3.1.3 for AS requests and Section 3.3.3 for TGS requests Bryan -----Original Message----- From: Bryan Burgin Sent: Tuesday, July 13, 2010 9:29 AM To: 'Andrew Bartlett' Cc: [email protected]; [email protected]; [email protected]; MSSolve Case Email Subject: RE: [REG:110062157456375] -[MS-ADTS] 7.1.6.7.3 msDs-supportedEncryptionTypes usage 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:[email protected]] Sent: Friday, July 09, 2010 7:58 PM To: Bryan Burgin Cc: [email protected]; [email protected]; [email protected]; 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. _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
