[Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
hongweis at microsoft.com
Tue Aug 26 15:50:04 GMT 2008
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.
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:
> > 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).
Authentication Developer, Samba Team http://samba.org
Samba Developer, Red Hat Inc.
More information about the cifs-protocol