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

[Andrew Bartlett]

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