[cifs-protocol] [REG:112080864018345] SMB3 encryption over multiple requests

Tue Aug 21 12:33:10 MDT 2012

Metze,

Please find our answers as follows. A future release of MS-SMB2 will further clarify SMB3 encryption, especially with specifics for compounded messages. Since one session key is used for the encrypted message, it is expected that all operations in this message belong to the SessionId in the TRANSFORM_HEADER.
The message is decrypted using the Session.DecryptionKey of the Session that corresponds to the SessionId in the TRANSFORM_HEADER. (ref. 3.2.5.1.1   Decrypting the Message, 3.3.5.2.1   Decrypting the Message). 

Questions/Answers
--------------------------

I just found out that windows2012 RC sends multiple compound requests within just one encrypted SMB2_TRANSFORM message.

[Answer] This is the expected protocol behavior as per Windows 8 RTM source code. All operations in the compounded chain are assembled before encryption is applied on the whole.  

From reading [MS-SMB2] version 37.0 I had the impression that each request would be encrypted on its own, similar to how signing works.

[Answer] This is by design, encryption is applied on the whole exchange before submission to the transport, and this exchange could consist of compounded chain operations. Encryption is done as an outer layer around the requests.

Can the other receiver side rely on the fact that all messages within a SMB2_TRANSFORM message belong to the same session as the session (referenced by the session id in the SMB2_TRANSFORM header) used for the encryption?

[Answer] 
In case of RELATED compounded requests, all the requests belong to the same SessionId (the client indicates to the server that it is using the SessionId, TreeId, and FileId of the previous request or resulted from the server processing that previous request, ref. 3.2.4.1.4   Sending Compounded Requests).

What will happen if a client send unrelated compound requests?

[Answer] 
For encrypted channels, we hope the following clarify the requirements, in addition to the statements in Section 3.3.5.2.7   Handling Compounded Requests. These outline the expected protocol behaviors from the client/server when it comes to sending an encrypted message, be it for compounded requests/responses or not.
The client SHOULD NOT send an encrypted request separately or as part of a compounded chain (related or unrelated) that contains a SessionId different from the session used for encryption.  (Note:  This statement might become a MUST NOT if we can fix the protocol to force a disconnection when a client attempts this).
The server SHOULD NOT send an encrypted response separately or as part of a compounded chain (related or unrelated) that contains a SessionId different from the session used for encryption.   (Windows Behavior:  Windows-based servers will respond in-kind to what the client sends.  If the client violates the above statement, our server will currently send the response as such.)

What about async responses with STATUS_PENDING, are they also encrypted?

[Answer] 
Yes. The exceptions that are not encrypted are SMB2 NEGOTIATE, SMB2 SESSION_SETUP or SMB2 TREE_CONNECT as documented in 3.2.4.1.8   Encrypting the Message, 3.3.4.1.4   Encrypting the Message.

How does it work, when the last request in a compound chain goes async?

[Answer]
There is no change of processing rules for the encryption due to the last request in a compounded chain going async. 

Are Oplock/Lease Break Notifications encrypted?

[Answer] Yes, see previous answer and references.

Can there be more than one SMB2_TRANSFORM message within a transport layer message?

[Answer] 
The encrypted message is sent as a single submission to the underlying transport, there is no provision for a next transform message in the 2.2.41   SMB2 TRANSFORM_HEADER. 

Thanks,
Edgar

-----Original Message-----
From: Bryan Burgin 
Sent: Thursday, August 09, 2012 10:22 AM
To: Stefan (metze) Metzmacher; Edgar Olougouna
Cc: pfif at tridgell.net; cifs-protocol at cifs.org; MSSolve Case Email
Subject: RE: [REG:112080864018345] SMB3 encryption over multiple requests

Metze,

Slight change in plan to load balance on this side: my colleague Edgar (copied) will help you on this issue.

Bryan

-----Original Message-----
From: Bryan Burgin 
Sent: Wednesday, August 08, 2012 1:17 PM
To: 'Stefan (metze) Metzmacher'
Cc: pfif at tridgell.net; cifs-protocol at cifs.org; MSSolve Case Email
Subject: [REG:112080864018345] SMB3 encryption over multiple requests

[dochelp to bcc]
[adding case number and casemail]

Hi Metze,

We created the case 112080864018345 to track this issue, which I will help you with.

Thanks.

Bryan

-----Original Message-----
From: Stefan (metze) Metzmacher [mailto:metze at samba.org] 
Sent: Wednesday, August 08, 2012 9:38 AM
To: Interoperability Documentation Help
Cc: pfif at tridgell.net; cifs-protocol at cifs.org
Subject: SMB3 encryption over multiple requests

Hi,