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

Edgar Olougouna edgaro at microsoft.com
Mon Jan 30 13:26:20 MST 2012


This happens in a typical scenario similar to the following. 

The DC is running Windows Server 2008 at domain functional level Windows Server 2003.
The Kerberos client and server present following etypes to the DC:
EType: aes256-cts-hmac-sha1-96 (18)
EType: aes128-cts-hmac-sha1-96 (17)
EType: rc4-hmac (23)

The client is issued a ticket with an encryption type aes256-cts-hmac-sha1-96 (18). 
The PAC in the in the service ticket has a SignatureType of KERB_CHECKSUM_HMAC_MD5 (based of the logic described in my previous email, condition 1) is met but condition 2) is not met).

This has been seen with non-Windows servers as well.


-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org] 
Sent: Sunday, January 29, 2012 3:16 PM
To: Edgar Olougouna
Cc: cifs-protocol at samba.org
Subject: RE: Confirm kerberos key selection rules for PAC KDC signature

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 
> 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. 


Andrew Bartlett

Andrew Bartlett                                http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org

More information about the cifs-protocol mailing list