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

[Hongwei Sun]

Hi, Andrew,

Thanks for your comments and the diagram attached. The security product group 
will review the content of the diagram to see whether we can incorporate it 
into the document.

Before we can use the diagram, we would like to confirm that Mr. Astrand is 
covered by the PFIF WSPP agreement that gives Microsoft a broad license to use 
and distribute any comments or suggestions to improve the WSPP documentation. 
This license is dependent on whether Mr. Astrand is a member of PFIF/Samba.  We 
also need to know if the he is expecting attribution for the work.

We appreciate your efforts to help us improve protocol documentation.

Thanks

--
Hongwei  Sun - Support Escalation Engineer
DSC Protocol  Team, Microsoft
[EMAIL PROTECTED]
Tel:  469-7757027 x 57027
---



-Original Message-
From: Andrew Bartlett [mailto:[EMAIL PROTECTED]
Sent: Monday, August 04, 2008 7:13 PM
To: Hongwei Sun
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: RE: [cifs-protocol] Clarify AEAD behaviour for GSSAPI with AES

On Thu, 2008-07-31 at 14:36 -0700, Hongwei Sun wrote:
 Andrew,



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.

Indeed - and that is why I am asking for this to be much more clearly specified.

I find digrams much more useful - see the attached work by Love Hörnquist 
Åstrand [EMAIL PROTECTED].

Can you please expand MS-KILE with this information?

Thanks,

--
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: [cifs-protocol] Session keys are not always 16 bytes long

[Hongwei Sun]

Hi, Andrew,



   In our last conference call, we talked about your question regarding which 
of the numerous keys Kerberos produce is considered the 'SMB session key'.  I 
had discussions with the product team to find what or how should be documented. 
  You mentioned that you would like to see the document to specify which GSSAPI 
call returns the session key.   They would like to have a little more 
background information, which you already talked about a little bit during our 
conversation.  I just want to confirm so I can pass it accurately to product 
team.



What do you mean by GSSAPI with CFX ? Do you mean the mechanism conforming 
to RFC 4121 ?

What implementation are you using  for GSSAPI with CFX in Vista  ?   Is it 
Heimdal's implementation ?

What is your expectation about how this detail should be included in the 
document ?  Do you expect it to associate with specific GSSAPI calls?



   I hope that with the information we can have a resolution soon.  Thanks for 
your patience.


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: Wednesday, July 23, 2008 12:58 AM
To: Interoperability Documentation Help
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [cifs-protocol] Session keys are not always 16 bytes long



I'm looking for correction assistance regarding SMB session keys.



Our tests show that the session keys, referred consistently in MS-SMB and 
MS-SAMR as 16 byte quantities are not a simple as they are made out to be.



For example, a Windows Vista SP1 client using GSSAPI with CFX will negotiate an 
AES session key with Samba4.  This is 32 bytes long, and all 32 bytes are 
required to satisfy the SMB signing between Vista SP1 and Samba4.  (despite 
MS-SMB 4.3 talking about a 16 bytes key).

Similarly, our tests have shown that for DES kerberos, an 8 byte key is used.



However, further in on the domain join, Samr password set operations are made.  
There similarly we have observed 8 bytes kerberos keys in the past, but testing 
shows that for the 32 byte key from the Vista join, the key must be truncated 
to 16 bytes.  (See MS-SAMR 3.1.2.2).



Please correct the documentation to clearly specify when the variable-length 
key is used (perhaps make it clear that it is usually, but not always 16 
bytes), and when a truncated key is used.



Furthermore, please clarify the linkage between MS-SAMR, MS-SMB and MS-KILE 
regarding session keys.  I can't find a clear reference as to which of the 
numerous keys kerberos produces is considered the 'SMB session key'.  Is it not 
possible to include section numbers in the document cross-references?



Thanks,



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