[cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES

Hongwei Sun hongweis at microsoft.com
Thu Jul 31 21:36:28 GMT 2008


   The  encryption function in Kerberos is described in details in 5.3 [RFC3961] (http://www.ietf.org/rfc/rfc3961.txt), which is referenced by [MS-KILE].

    I can summarize  as follows

*         "conf" is actually a random confounder prefix  of length c ,such as 16.

*         "pad" is for shortest padding to bring confounder and plaintext to a length that is the multiple of message block size m, which is octet(8) for AES encryption, as specified in  section 6 [RFC 3962] (http://www.ietf.org/rfc/rfc3962.txt)

*          Ke is an encryption key and Ki is a checksum key.

*         Plain text is the input confidential data before encryption.

*         The GSSWrapEX()  is exactly the same as the GSSWrap except that it supports ordered list of input buffers.  Input buffers for which conf_req_flag == TRUE are encrypted and returned. Buffers which sign == TRUE are included in the signature.

*         We use the Kerberos standard's encryption and signatures.    It is very important to  concatenate  the correct buffers to make it  work.

   Please let me know if further clarification is needed and I will be happy to assist you.


Hongwei  Sun - Support Escalation Engineer
DSC Protocol  Team, Microsoft
hongweis at microsoft.com
Tel:  469-7757027 x 57027

-----Original Message-----
From: cifs-protocol-bounces+hongweis=microsoft.com at cifs.org [mailto:cifs-protocol-bounces+hongweis=microsoft.com at cifs.org] On Behalf Of Andrew Bartlett
Sent: Monday, July 28, 2008 12:53 AM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at samba.org
Subject: [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES

I've been spending most of today staring at MS-KILE and Heimdal's implementation of GSSAPI CFX.

What has me stumped is exactly what this means:

> If the session key encryption type is AES128-CTS-HMAC-SHA1-96 or

> AES256-CTS-HMAC-SHA1-96, as specified in [RFC3961], the base line is

> [RFC4121] and the encrypted data per [RFC3961] (which [RFC4121] is based on) is:

>    C1 | H1[1..h]

>    Where

>    (C1, newIV) = E(Ke, conf | plaintext | pad, oldstate.ivec)

>    H1 = HMAC(Ki, conf | plaintext+encrypted-data | pad) where the

> "plaintext+encrypted-data" is all the input data buffers supplied to

> GSS_WrapEx() concatenated in the order provided in the ordered list, input_message.

I see that C1 is the output of the encryption function E, and presume that Ke is the encryption key, but what is 'conf', and is 'plaintext'

the confidential data in plaintext, or the data over which only a signature is computed (presumably the confidential data in plaintex, but then what is conf)?

I presume again that Ki is the signing key.

Likewise, a description of how the pad fits into the HMAC function here would be very helpful.

In short, because this is a deviation from the GSSAPI spec (as the spec does not allow data to be signed, but not sealed), I really need much more detail, and all the inputs and outputs clearly labelled, particularly as this seems to require a major rework of Heimdal to implement :-(


Andrew Bartlett


Andrew Bartlett


Authentication Developer, Samba Team           http://samba.org

Samba Developer, Red Hat Inc.
-------------- next part --------------
HTML attachment scrubbed and removed

More information about the cifs-protocol mailing list