[cifs-protocol] Confirm kerberos key selection rules for PAC KDC signature

[Edgar Olougouna]

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: cifs-protocol at samba.org
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:abartlet at samba.org]
Sent: Monday, December 19, 2011 3:37 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
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