Andrew, Regarding your observation on “MS-KILE 3.3.5.3.2.3 Server Signature”:
We confirm that the document is correct. The statement: “the strongest cryptography that the domain supports” is related to the SignatureType of the checksum instead of the server account key. Based on this investigation, I have suggested to the product team to revise the text as follows. MS-KILE 3.3.5.3.2.3 Server Signature: The KDC creates a keyed hash ([RFC4757]) of the entire PAC message with the Signature fields of both PAC_SIGNATURE_DATA structures set to zero using: • the server account key, • the strongest cryptography that the domain supports<30>, (see SignatureType). The KDC populates the returned PAC_SIGNATURE_DATA structure ([MS-PAC] section 2.8) fields as follows: • The SignatureType SHOULD be the value ([MS-PAC] section 2.8) corresponding to the cryptographic system used to calculate the checksum. • The Signature field SHOULD be the keyed hash ([RFC4757]) of the entire PAC message with the Signature fields of both PAC_SIGNATURE_DATA structures set to zero. Regarding your question on “3.3.5.3.2.4 KDC Signatures”: We confirm that MS-KILE has the correct description. For the KDC signature, the strongest encryption type for "krbtgt" account key needs to be also supported by the KDC. For example, the KDC signature would be generated with following: SignatureType --- Encryption type for "krbtgt" account key HMAC_SHA1_96_AES256 --- aes256-cts-hmac-sha1-96 HMAC_SHA1_96_AES128 --- aes128-cts-hmac-sha1-96 KERB_CHECKSUM_HMAC_MD5 --- rc4-hmac or rc4-hmac-old 3.3.5.3.2.4 KDC Signatures The KDC creates a keyed hash ([RFC4757]) of the Server Signature field using the strongest "krbtgt" account key and populates the returned PAC_SIGNATURE_DATA structure field ([MS-PAC] section 2.8) as follows: • The SignatureType SHOULD be the value ([MS-PAC] section 2.8) corresponding to the cryptographic system used to calculate the checksum. • The Signature field SHOULD be the keyed hash ([RFC4757]) of the Server Signature field in the PAC message. Regards, Edgar -----Original Message----- From: Josh Curry Sent: Monday, December 19, 2011 6:02 PM To: Andrew Bartlett; Interoperability Documentation Help Cc: [email protected] Subject: RE: Confirm kerberos key selection rules for PAC KDC signature Hi Andrew, thank you for your question. A member of the protocol documentation team will be in touch with you soon. Josh Curry | Escalation Engineer | Open Specifications Support Team P +1 469 775 7215 One Microsoft Way, 98052, Redmond, WA, USA http://support.microsoft.com -----Original Message----- From: Andrew Bartlett [mailto:[email protected]] Sent: Monday, December 19, 2011 3:37 PM To: Interoperability Documentation Help Cc: [email protected] Subject: Confirm kerberos key selection rules for PAC KDC signature MS-KILE 3.3.5.3.2.3 Server Signature suggests: The KDC creates a keyed hash ([RFC4757]) of the entire PAC message with the Signature fields of both PAC_SIGNATURE_DATA structures set to zero using the server account key with the strongest cryptography that the domain supports<30> and populates the returned PAC_SIGNATURE_DATA structure ([MS-PAC] section 2.8) fields as follows: Would it not be more correct to say that the KDC creates a keyed hash with the key with which the ticket is encrypted to the target server? Samba has always used that key to verify the PAC. The semantics where the hmac-md5 keyed checksum is used to verify DES keys (rather than the DES checksum) should also be noted here. Our source code comment is: /* If the checksum is HMAC-MD5, the checksum type is not tied to * the key type, instead the HMAC-MD5 checksum is applied blindly * on whatever key is used for this connection, avoiding issues * with unkeyed checksums on des-cbc-md5 and des-cbc-crc. See * http://comments.gmane.org/gmane.comp.encryption.kerberos.devel/8743 * for the same issue in MIT, and * http://blogs.msdn.com/b/openspecification/archive/2010/01/01/verifying-the-server-signature-in-kerberos-privilege-account-certificate.aspx * for Microsoft's explaination */ While neither of the links directly addresses the DES issue, it has come up for us in the real world. Given that a server may or may not support AES based on it's supported encryption types, the statement that it is the 'strongest cryptography that the domain supports' seems unlikey. Anyway, the reason I ask is to verify the behaviour for the KDC checksum: 3.3.5.3.2.4 KDC Signatures The KDC creates a keyed hash ([RFC4757]) of the Server Signature field using the strongest "krbtgt" account key and populates the returned PAC_SIGNATURE_DATA structure field ([MS-PAC] section 2.8) as follows: § The SignatureType SHOULD be the value ([MS-PAC] section 2.8) corresponding to the cryptographic system used to calculate the checksum. § The Signature field SHOULD be the keyed hash ([RFC4757]) of the Server Signature field in the PAC message. Can you confirm this is correct? I am working on a customer issue regarding the selection of the correct encryption type here, in an all-Samba situation, but in fixing that, I do not wish to break interoperability with Microsoft, so clarity here would be most welcome. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org _______________________________________________ cifs-protocol mailing list [email protected] https://lists.samba.org/mailman/listinfo/cifs-protocol
