[cifs-protocol] [REG:115100613235242] Send oplock breaks unencrypted, as lease breaks are sent plain?

Edgar Olougouna edgaro at microsoft.com
Tue Oct 6 16:32:25 UTC 2015


Volker,

Please find the following details in this blog. If the specific test case is not covered in the blog, please send me a network trace and the Windows version.

Encryption in SMB 3.0: A protocol perspective
http://blogs.msdn.com/b/openspecification/archive/2012/10/05/encryption-in-smb-3-0-a-protocol-perspective.aspx

Oplock and Lease Breaks
 
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 more details in MS-SMB2. 
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. The response is sent on the session that receives the acknowledgment. 

Encryption clauses
 
The sender encrypts the message if any of the following conditions is satisfied:
.	If the sender is sending a response to an encrypted request.
.	If Session.EncryptData is TRUE and the request or response being sent is not NEGOTIATE.
.	If Session.EncryptData is FALSE, the request or response being sent is not NEGOTIATE or SESSION_SETUP or TREE_CONNECT, and <TreeConnect|Share>.EncryptData is TRUE.
 
Note: TreeConnect.EncryptData is on the client side. Share.EncryptData is on the server side.
 
Review of encryption clauses
 
.	All clauses exclude any operation which does use a SessionId. A SessionId is needed to find the Session object and derive the encryption and decryption keys from its session key. For example, if the client sends a non-encrypted ECHO, Windows 8 server will respond with a non-encrypted response. 
.	Clause "response to an encrypted request": if the sender encrypts the request, the receiver will respond in the same way by encrypting the response. There is however a prerequisite that encryption is active, i.e. encryption keys have been generated. For example, if the client encrypts an ECHO, Windows 8 server responds in-kind by encrypting the response.  
.	Clause "Session.EncryptData is TRUE": SMB 3 session setup encryption goes as follows:
--         Initial session setup messages are un-encrypted as there is no session object (key etc).
--         Session binding requests must be signed, but not encrypted. Note:  Windows-based server does not encrypt session setup responses for session binding, regardless whether the client encrypts the session binding request. On the other side, Windows client does not encrypt session binding requests when Session.EncryptData is TRUE.
--         Spontaneous re-authentication of a valid session must be encrypted, otherwise the server returns STATUS_ACCESS_DENIED.
--         Re-authentication of an expired session is encrypted as well.
--         For re-authentication at reconnection after a broken connection, if the client lost all of its connections to the server, then the client would reconnect and create a new session (initial session setup). If the client lost some of its connections but not all, then the client would reconnect and bind to the existing session (session setup binding).
.	Clause "Session.EncryptData is FALSE  and <TreeConnect|Share>.EncryptData is TRUE": 
If the client performs TREE_DISCONNECT before a LOGOFF, the logoff will not be encrypted.

Thanks,
Edgar

-----Original Message-----
From: Edgar Olougouna 
Sent: Tuesday, October 6, 2015 11:17 AM
To: Volker.Lendecke at SerNet.DE
Cc: MSSolve Case Email <casemail at microsoft.com>; cifs-protocol at lists.samba.org
Subject: RE: [REG:115100613235242] [cifs-protocol] Send oplock breaks unencrypted, as lease breaks are sent plain?

Volker can you please share the network trace? Is this Windows 8.1 or Windows 8?
Thanks,
Edgar

-----Original Message-----
From: Edgar Olougouna
Sent: Tuesday, October 6, 2015 11:07 AM
To: Volker.Lendecke at SerNet.DE
Cc: MSSolve Case Email <casemail at microsoft.com>; cifs-protocol at lists.samba.org
Subject: [REG:115100613235242] [cifs-protocol] Send oplock breaks unencrypted, as lease breaks are sent plain?

[Case number in subject]
[bcc dochelp, cc casemail]

Volker,
Glad to hear from you. We've created the case number 115100613235242 for this inquiry.
I will look into this and follow-up soon.

Thanks,
Edgar

-----Original Message-----
From: Volker Lendecke [mailto:Volker.Lendecke at SerNet.DE]
Sent: Tuesday, October 6, 2015 10:51 AM
To: Interoperability Documentation Help <dochelp at microsoft.com>
Cc: cifs-protocol at lists.samba.org
Subject: Re: [cifs-protocol] Send oplock breaks unencrypted, as lease breaks are sent plain?

On Tue, Oct 06, 2015 at 04:35:36PM +0200, Volker Lendecke wrote:
> Hi!
> 
> Testing leases and oplocks against Windows 8 over encrypted smb3 I see 
> that I get lease breaks in plain text, unencrypted, but oplock breaks 
> are sent encrypted by Windows 8. Samba does the same, however a 
> Windows 8 client seems very unhappy with our unencrypted oplock 
> breaks,
                                               ^^^^^^^^^^^ obvious typo: We send oplock breaks encrypted, is what Win8 does but which seems wrong.

Volker


> it just seems not to respect them. If we modify Samba to send oplock 
> breaks unencrypted, Windows 8 client is happily downgrading the 
> oplock, everything is fine.
> 
> Where in the documentation can I find what is correct? And, where is 
> the bug? Client or server?
> 
> If required, I can provide network traces.
> 
> With best regards,
> 
> Volker Lendecke
> 
> --
> SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
> phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816,
> GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de
> 
> _______________________________________________
> cifs-protocol mailing list
> cifs-protocol at lists.samba.org
> https://lists.samba.org/mailman/listinfo/cifs-protocol

--
SerNet GmbH, Bahnhofsallee 1b, 37081 Göttingen
phone: +49-551-370000-0, fax: +49-551-370000-9 AG Göttingen, HRB 2816, GF: Dr. Johannes Loxen http://www.sernet.de, mailto:kontakt at sernet.de




More information about the cifs-protocol mailing list