Andrew, After another look at the source code, I would try to describe how a Windows-based KDC decides on the signature type of the PAC server signature. Based on this, and the confirmation of the product team, it appears that the current MS-KILE is correct.
While there are several possible encryption types for the server key, there are only three possible values for the signatureType in the PAC server signature, as implemented in Windows Server 2008 R2 and documented in MS-KILE. Let’s assume the server key is of key type X. The key type is already known before the PAC is signed; it is the strongest common type that can be used by the application server and the KDC. When computing the PAC, Windows KDC passes the server key as an input to the following logic. By default, the SignatureType KERB_CHECKSUM_HMAC_MD5 is used to compute the PAC server signature, unless: 1. the server key type X is one the newer encryption types i.e. AES256 or AES128, 2. AND 2.1 the functional level of the domain NC is Windows Server 2008 or 2008 R2, 2.2 OR the registry setting disables the bit of HMAC-RC4 in the SupportedEncryptionTypes (registry entry on the DC at the following location (see KB977321): HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\parameters\) If the conditions 1) and 2) are met, the SignatureType will be HMAC_SHA1_96_AES256 or HMAC_SHA1_96_AES128, depending on whether X is AES256 or AES128. In a Windows-based domain, the strongest cryptography that the “domain” supports depends on Windows Server SKUs of the domain controllers (what cryptosystems are available) as well as the domain functional level and configuration (what cryptosystems are supported). On Windows Server 2000 and 2003 based KDCs, the signatureType is KERB_CHECKSUM_HMAC_MD5. When the server needs to validate the PAC signature, it uses the SignatureType to determine the corresponding cryptographic system used to calculate the checksum. The server however will use the long term key that it shares with the KDC; that is the key of type X. For example, in real world, you may have a server key of key type aes256-cts-hmac-sha1-96 (18), but a PAC server signature with SignatureType KERB_CHECKSUM_HMAC_MD5, based what I have described previously. Regards, Edgar -----Original Message----- From: Andrew Bartlett [mailto:[email protected]] Sent: Thursday, January 26, 2012 2:57 PM To: Edgar Olougouna Cc: [email protected] Subject: RE: Confirm kerberos key selection rules for PAC KDC signature On Thu, 2012-01-26 at 19:10 +0000, Edgar Olougouna wrote: > 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. Edgar, I'm sorry, but this all makes very little sense when applied to the real world. Firstly, what is this SHOULD business? Both of these statements are MUSTS: If the SignatureType is not the 'value of the cryptographic system used to calculate the checksum', how could it ever be validated? If the the has is not over 'entire PAC message with the Signature fields of both PAC_SIGNATURE_DATA structures set to zero' how could it ever work? Secondly, how does this statement match up with a server that does not understand AES? If this statement were true, then a pre-AES server (Win2000 for arguments sake) could never verify a PAC, as in an AES-capable domain (Win2008R2), it would be signed using a signature type simply never invented at the time the software was released. Finally, this still does not explain this behaviour: > 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. Please have another look over this. Thanks, 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
