Metze, We confirm that Oplock break notifications/acknowledgments/responses must be encrypted when encryption is active. For an Oplock, the FileID is used to derive the SessionId which is set in the notification/acknowledgement/response. See details in Sections 3.2.5.19.1 Receiving an Oplock Break Notification, 3.3.5.22.1 Processing an Oplock Acknowledgment.
Lease break notifications - sent by the server - do not have a SessionId, and as a result, are neither signed nor encrypted. Lease keys are not tied to a particular session from the client. However, Lease break acknowledgements sent by the client - and their responses sent by the server - must be encrypted when encryption is active. The client is responsible for selecting a session associated with one of the existing opens associated with that Lease Key, as per 3.2.5.19.2 Receiving a Lease Break Notification. The response is sent on the session that receives the acknowledgment, as documented in 3.3.5.22.2 Processing a Lease Acknowledgment. A future MS-SMB2 update will clarify that Lease break notifications are not encrypted. Regards, Edgar From: Edgar Olougouna Sent: Friday, August 24, 2012 12:06 AM To: 'Stefan (metze) Metzmacher' Cc: 'p...@tridgell.net'; 'cifs-protocol@cifs.org' Subject: [REG: 112082371227089] SMB3 encryption and Oplock/Lease break notifications Metze, Your observation is correct. For Oplock, we use the FileID - set in the Oplock break notification - and derive the SessionId which is set in the notification/acknowledgement. Per source code review, this should be encrypted as expected. Lease break notifications don’t have a SessionId, so they won’t be signed. From what I am observing they should not be encrypted as well. A document bug has been opened to clarify these behaviors in MS-SMB2. I will confirm you when updates are available. Regards, Edgar -----Original Message----- From: Edgar Olougouna Sent: Thursday, August 23, 2012 3:06 PM To: Stefan (metze) Metzmacher Cc: p...@tridgell.net; cifs-protocol@cifs.org Subject: RE: [REG:112080864018345] SMB3 encryption over multiple requests Metze, In order to track document bugs properly, I will be following up on these new questions in two separate cases. I will start a new thread for each case: 112082370902333 SMB3 encryption of SESSION_SETUP (for reauth/or channel binding) and TREE_CONNECT 112082371227089 SMB3 encryption and Oplock/Lease break notifications Thanks, Edgar -----Original Message----- From: Stefan (metze) Metzmacher [mailto:me...@samba.org] Sent: Wednesday, August 22, 2012 9:19 AM To: Edgar Olougouna Cc: p...@tridgell.net; cifs-protocol@cifs.org Subject: Re: [REG:112080864018345] SMB3 encryption over multiple requests Hi Edgar, thanks for the answers, I have some more questions inline. > 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. Windows doesn't complain if the client encrypt SESSION_SETUP (for reauth/or channel bind) and TREE_CONNECTS. > 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. For Oplocks the server known the session from the file_id, but what session is used for leases? To my understanding a lease key can be shared between sessions, is that correct? metze _______________________________________________ cifs-protocol mailing list cifs-protocol@cifs.org https://lists.samba.org/mailman/listinfo/cifs-protocol