[cifs-protocol] 113100910848314 session logoff request / response clarification

[Sreekanth Nadendla]

Hello Shirish,
                        Is there a particular reason why you are talking about the errors in a log off scenario ? It seems like you feel like the client and/or server side processing during log off scenario requires special handling that is not explained/inferred in these documents.  Please review the following and let me know if you feel like I have misunderstood anything.


1) Types of error a server can return in response to a session logoff request from a client (section 2.2.8).
   
   SMB2 ERROR Response packet is sent by the server to respond to a request that has failed or encountered an error. See section 2.2.2 from MS-SMB2. This document does not describe all possible error conditions and how to handle them. Also review section "3.2.5.1   Receiving Any Message"
        
   section 3.2.5.1.3 states  ..".If signature verification fails, the client MUST discard the received message and do no further processing for it. The client MAY also choose to disconnect the connection. ...."
   

2) The state of the session and expected client behaviour when a server returns an error to a session logoff request.
   Specifically, does the client behaviour stated in section 3.2.5.4  (Receiving an SMB2 LOGOFF Response) apply in case of an error as well?

   No. The client processing goes through 3.2.5.1 before going through 3.2.5.4. In the case of an error the client will not process 3.2.5.4. 
   

3) There is no verbiage about server behaviour if the signature verification fails the way it is described for client behaviour if the signature
   verification fails in section 3.2.5.1.3. In the context of session logoff request, if the signature does not match, what is the correct/expected server behaviour?   Right now, in SMB3 dialect, Windows 8 server returns a response with an  error (access denied) for a missing/mismatched signature.  Is that correct or should a server discard the request and do no further processing for it?
   
   
  In this case, the server behavior is documented in section "3.3.5.2.4   Verifying the Signature". As mentioned, Access Denied is the  expected error and the server MAY disconnect the connection. Note that Windows servers do not disconnect due to mismatched signature. This is true for any request that fails signature verification. 
   


Regards,
Sreekanth Nadendla
Microsoft Windows Open Specifications


-----Original Message-----
From: Shirish Pargaonkar [mailto:shirishpargaonkar at gmail.com] 
Sent: Tuesday, October 8, 2013 8:53 PM
To: Interoperability Documentation Help
Cc: cifs-protocol at samba.org
Subject: session logoff request / response clarification

---
Would like to have a clarification in MS-SMB2 document about the

1) Types of error a server can return in response to a session logoff
   request from a client (section 2.2.8).

2) The state of the session and expected client behaviour when a server
   returns an error to a session logoff request.
   Specifically, does the client behaviour stated in section 3.2.5.4
   (Receiving an SMB2 LOGOFF Response) apply in case of an error as well?

3) There is no verbiage about server behaviour if the signature verification
   fails the way it is described for client behaviour if the signature
   verification fails in section 3.2.5.1.3.
   In the context of session logoff request, if the signature does not match,
   what is the correct/expected server behaviour?
   Right now, in SMB3 dialect, Windows 8 server returns a response with an
   error (access denied) for a missing/mismatched signature.  Is that correct
   or should a server discard the request and do no further processing for it?

---
MS-CIFS document lists the types of error a server may return in response to a session logoff request (section 2.2.4.54.2) but it does not state the state of the smb session and expected client behaviour in case of an error received in logoff response in section 3.2.5.1.
In case of signature mismatch in the context of session logoff request, Windows 8 server for smb1 dialect, behaves in a similar way as above (smb3).