Verifying the server signature in Kerberos Privilege Account Certificate
This blog post focuses on understanding how a server signature is verified in a Kerberos Privilege Account Certificate (PAC). A PAC contains two signatures: a server signature and a KDC signature. In a previous blog, I introduced PAC validation, whereby the server requests the KDC to verify the PAC. In this blog, I will talk about the verification of PAC server signature, more specifically how the verification is done even when the encryption/hashing types are different for the service ticket and the PAC server signature.
Background
The Privilege Account Certificate (PAC) is an extension element of the authorization-data field contained in the clients' Kerberos ticket. The PAC structure is defined in [MS-PAC] and conveys authorization data provided by domain controllers (DCs) in an Active Directory-enabled domain. It contains information such as security identifiers, group membership, user profile information, and password credentials.
More details can be found in [MS-PAC] Section 2, which describes the Encapsulation layers.
One key reason why a PAC should be verified as unaltered is to ensure that no privileges have been maliciously added to - or removed from - the ticket; that is to prevent a man-in-the-middle from spoofing and tampering the PAC.
The signatures allow the KDC or the principal verifying the PAC to determine if the contents have been modified. The first signature is the server signature, or server checksum. The second is the KDC signature.
In the remainder of this post, I will focus on the server signature or server checksum in a PAC_INFO_BUFFER with the ultype of 0x00000006, as defined in [MS-PAC] 2.4.
Understanding the cryptographic system used by the KDC to generate the PAC server signature
The following logic reflects the testing of [MS-KILE] and MS-PAC implementations in Windows-based servers 2008 and 2008 R2.
By default, HMAC-RC4 is used to compute the PAC server signature, unless:
- - the server key type is one the newer encryption types i.e. AES256 or AES128, and
- - the functional level of the domain NC is Windows Server 2008 or 2008 R2, 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\)
This logic can be explained as follows. First, as highlighted by Windows behavior note <26> in [MS-KILE], AES is supported in Windows 2008 and onward.
Second, there are several DCs on the field that have 2003 functional level. Even though some of these DCs are running Windows Server 2008 or 2008 R2, domain administrators tend sometimes to be conservative and keep the functional level to 2003.
Third, unless otherwise configured, a DC that is operating at Windows Server 2003 functional level will use the strongest encryption type that the client can support to issue a Kerberos service ticket (e.g. AES 256 for Windows 7). However, the PAC signature could be fairly computed with HMAC-RC4. This would be important to support of cross-domain or cross-forest scenarios.
Excerpt from MS-KILE
This is an excerpt from 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 with the strongest cryptography that the domain supports<26> and 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.
Windows Behavior Note
<26> Section 3.3.5.3.2.3: Active Directories with the msDS-Behavior-Version attribute on a domain NC root object equal to DS_BEHAVIOR_WIN2000, DS_BEHAVIOR_WIN20003_WITH_MIXED_DOMAINS, or DS_BEHAVIOR_WIN2003, cannot support AES.
Examples
These examples assume the default settings are used on all servers and clients.
Example 1: Same cryptosystem
DC: Windows Server 2008 SP2, functional level Windows Server 2008
Kerberos Server: Windows Server 2008 SP1
Kerberos client: Windows 7 RTM
The Kerberos client is issued a Ticket with an encryption type Etype: aes256-cts-hmac-sha1-96 (18). For the CIFS service, the PAC in the in the service ticket has a SignatureType of 0x00000010 (HMAC_SHA1_96_AES256), or 16. This signature type corresponds to the aes256-cts-hmac-sha1-96 cryptosystem. The resulting checksum size is 12 bytes as defined in MS-PAC Section 2.8.1.
Example 2: Different cryptosystems
DC: Windows Server 2008 SP2, functional level Windows Server 2003
Kerberos Server: Windows Server 2008 SP1
Kerberos client: Windows 7 RTM
The Kerberos client is issued a Ticket with an encryption type Etype: aes256-cts-hmac-sha1-96 (18). For the CIFS service, the PAC in the in the service ticket has a SignatureType of 0xFFFFFF76 (KERB_CHECKSUM_HMAC_MD5), or a checksum type of -138. This signature type corresponds to the rc4-hmac-md5 cryptosystem. The resulting checksum size is 16 bytes as defined in MS-PAC Section 2.8.1.
Algorithm used to verify the PAC server signature
When the server verifies the PAC signature, it must use the same cryptosystem that the KDC used to generate the server checksum. The list of signature types and corresponding cryptographic systems are documented in MS-PAC 2.8.
The cryptosystem that is used to compute the server checksum does not depend on the key type of the long term key that the KDC shares with the server. For instance in the Example 2 above, the server signature type is KERB_CHECKSUM_HMAC_MD5, the same algorithm RC4-HMAC-MD5 will be used to generate and verify the signature in case of AES 128/256 long-term keys, or RC4-HMAC-MD5 long-term key. Any attempt to use a cryptosystem that does not correspond to the signature type will produce a different keyed hashed server checksum.
Per HMAC RFC 2104 (referenced by RFC 4757), B=64 bytes is used for the padding for both MD5 and SHA1. The key can be of any length up to B, the block length of the hash function. Since the AES256 key length is 256 bits (32 bytes), the key material will not be truncated but appended with 32 bytes of zeroes; for AES128 the padding would have been 48 bytes of zeros.
Conclusion
When generating the PAC server signature, the KDC uses the long-term key that it shares with the server ([MS-PAC] 2.8. 1). The server must always use the long term key (that is used to decrypt the service ticket) as an input to the keyed hash. This allows the server to verify the signature on receiving the PAC, based on the signature type and the corresponding cryptographic system.
References
[MS-KILE] Kerberos Protocol Extensions
[MS-PAC] Privilege Attribute Certificate Data Structure
[RFC4120] The Kerberos Network Authentication Service (V5)
[RFC4757] The RC4-HMAC Kerberos Encryption Types Used by Microsoft Windows
[RFC2104] HMAC: Keyed-Hashing for Message Authentication
Comments
Anonymous
November 10, 2010
I have a 2008R2 client, connecting to a 2008R2 Domain controller in 2003 functional level. The client performs AS-REQ with encryptions 3, 1, 23, 16 (des, rc4, des3) and 17 (aes128). It is rejected due to lack of pre-auth, with enctype 17 (!) ,23 (rc4) and 3 (des). The client now tries again with pre-auth - and 17 - and this is rejected by the DC because of ERR_ETYPE_NOTSUPP - sounds like a bug to me. mykaul <> gmail.comAnonymous
November 11, 2010
Hi Yaniv, Your question seems to be a valid protocol documentation support issue. Currently, there are two options available to engage our team and get support on the open specifications:
- either you send the question to dochelp <at> winse.microsoft.com;
- or you post the question on one of the open specifications forums under social.msdn.microsoft.com/.../openspecifications Once you send us the request, we will happy to work with you and investigate this. Thanks!