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

[Hongwei Sun]

Andrew,

In this case, you provided a diagram for us to add to the  document and metze added some comments.  Thanks for your contribution to our documentation and continued feedback.

The product team reviewed the diagram and comments provided.  We believe that the diagrams imply interaction between elements and without detailed notes they are subject to multiple interpretation and hence confusion.    We believe that as a matter of providing deterministic documentation, we would prefer to provide specific examples.

We'll be happy to get your  feedback on creating examples and  send them for your review  once they are ready.

Thanks !


Hongwei

-----Original Message-----
From: Andrew Bartlett [mailto:abartlet at samba.org]
Sent: Tuesday, August 19, 2008 8:17 PM
To: Hongwei Sun
Cc: pfif at tridgell.net; cifs-protocol at samba.org; Stefan (metze) Metzmacher
Subject: Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES

On Fri, 2008-08-08 at 09:17 +0200, Stefan (metze) Metzmacher wrote:
> Hongwei,
>
> >    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.
> >
>
> It would be extremly useful if the MS-RPCE document would explain what
> the exact input buffers to GssWrapEX() are and what flags are used in
> each of the cases (with and without header signing).
>
> Then it would be useful to know to what exactly SSPI EncryptMessage
> call this is mapped.
>
> And finally how each of the of the encryption types (des-*,
> arcfour-hmac-md5, and aes-*) are supposed to process the
> EncryptMessage input.
>
> It would be nice if you could use a realistic example, with explicit
> values. A bit like the "A.5 Test suite" section of RFC1321 - The MD5
> Message-Digest Algorithm.

While we have Microsoft's bugs and features in this area worked around, this is the level of documentation this area needs.

Has there been any more progress on this?  (We didn't seem to get to this on the call today).

Andrew Bartlett

--
Andrew Bartlett
http://samba.org/~abartlet/
Authentication Developer, Samba Team           http://samba.org
Samba Developer, Red Hat Inc.