On Fri, 2012-01-27 at 18:46 +0000, Edgar Olougouna wrote: > 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.
How exactly would this happen? How would the domain create a ticket with X of AES256 or AES128 if that cryptosystem is not enabled and therefore available for creating a PAC signature of the same thing? At least we have now settled that the SignatureType is not the highest cryptography that the "domain" supports, because the key type of X is considered in the algorithm. 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
