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

Reply via email to