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

[Andrew Bartlett]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/cifs-protocol/attachments/20080820/2707a792/attachment.bin