[prev in list] [next in list] [prev in thread] [next in thread] 

List:       cifs-protocol
Subject:    Re: [cifs-protocol] [REG: 112082371227089] SMB3 encryption and Oplock/Lease break notifications
From:       Edgar Olougouna <edgaro () microsoft ! com>
Date:       2012-08-30 16:39:26
Message-ID: E827A438BE2C9B4982EDA46E6B7171881EA4F892 () TK5EX14MBXC225 ! redmond ! corp ! microsoft ! com
[Download RAW message or body]

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: 'pfif@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: pfif@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:metze@samba.org] 
Sent: Wednesday, August 22, 2012 9:19 AM
To: Edgar Olougouna
Cc: pfif@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


[prev in list] [next in list] [prev in thread] [next in thread]