RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
On Tue, 2008-08-26 at 08:50 -0700, Hongwei Sun wrote: 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. A visual description of how the RRC interacts with the AEAD behaviour and the subsequent placement of the trailer in the header will be critical. Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. signature.asc Description: This is a digitally signed message part ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
RE: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
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:[EMAIL PROTECTED] Sent: Tuesday, August 19, 2008 8:17 PM To: Hongwei Sun Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; 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. ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
Re: [Pfif] [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES
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. metze * 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. Thanks -- Hongwei Sun - Support Escalation Engineer DSC Protocol Team, Microsoft [EMAIL PROTECTED] Tel: 469-7757027 x 57027 --- -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrew Bartlett Sent: Monday, July 28, 2008 12:53 AM To: Interoperability Documentation Help Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES I've been spending most of today staring at MS-KILE 3.4.5.4.1 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. It would be extremly useful if the MS-RPCE document would explain what the exact input buffers are and 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 :-( Thanks, Andrew Bartlett -- Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. ___ Pfif mailing list [EMAIL PROTECTED] http://lists.tridgell.net/cgi-bin/mailman/listinfo/pfif signature.asc Description: OpenPGP digital signature ___ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol
