[cifs-protocol] [MS-SMB2] sign for 3.3.5.15.11 FSCTL_QUERY_NETWORK_INTERFACE_INFO - TrackingID#2404170040007704

[Kristian Smith]

Hi Jones,

Thanks for the reply. In [MS-SMB2] Section 3.2.4.1.1, we discuss the conditions in which we sign client messages. This message only exists in SMB 3.x, so we can ignore the first condition below.

The client MUST sign the message if one of the following conditions is TRUE:
§       If Connection.Dialect is equal to "2.0.2" or "2.1", the message being sent contains a nonzero value in the SessionId field and the session identified by the SessionId has Session.SigningRequired equal to TRUE.
§       If Connection.Dialect belongs to 3.x dialect family, the message being sent contains a nonzero value in the SessionId field and one of the following conditions is TRUE:
§       The session identified by SessionId has Session.EncryptData equal to FALSE.
§       The tree connection identified by the TreeId field has TreeConnect.EncryptData equal to FALSE.

The engineering team stated that this section should cover the signing of FSCTL_QUERY_NETWORK_INTERFACE_INFO requests. If you have any additional questions, please let me know.


Regards,
Kristian Smith
Support Escalation Engineer | Microsoft(r) Corporation
Office phone: +1 425-421-4442
Email: kristian.smith at microsoft.com

-----Original Message-----
From: Jones Syue 薛懷宗 <jonessyue at qnap.com>
Sent: Thursday, May 30, 2024 3:43 AM
To: Kristian Smith <Kristian.Smith at microsoft.com>; cifs-protocol at lists.samba.org
Cc: Microsoft Support <supportmail at microsoft.com>
Subject: [EXTERNAL] Re: [MS-SMB2] sign for 3.3.5.15.11 FSCTL_QUERY_NETWORK_INTERFACE_INFO - TrackingID#2404170040007704

> I’m following up on this case with regards to signing of Ioctl
> FSCTL_QUERY_NETWORK_INTERFACE_INFO requests as my last email was
> inaccurate. After the engineering team conducted further research,
> they determined that Windows (operating as a server) does not
> *require* that these incoming requests from the client are signed.

Thank you Kristian for kind feedback!

Ohh okay now i see that, Windows smb servers do not fail the Ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO requests if these requests are not signing. In other words, if a smb client sends these ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO requests to Windows (operating as a smb server), and these requests do not contains smb signing/signature, Windows servers do not fail these requests, still move on and send back responses with network information to smb client.

> Windows clients do, however, sign these requests.

This looks good to me, per my test with three kinds implementation of smb
clients:
1. Windows workstation/server edition
2. Linux kernel cifs.ko module (Ubuntu 22.04.4, linux 6.5.0-26-generic) 3. Apple macOS (Sonoma 14.3.1, MacBookPro M1)

Only the first one sign ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO
requests, the other two implementation so far do not.

smb client    | sign ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO request?
--------------+-----------
Windows       | yes
Linux cifs.ko | no
Apple macOS   | no


> As a result, there will not be any update to the [MS-SMB2] document.

Here is my question:
Although smb clients sign Ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO requests is not mandatory/required, considering Windows smb clients (including workstation/server editions) do sign these requests, is there a chance to mention this behavior of Windows smb clients in [MS-SMB2], perhaps in the Protocol Examples section like '4.8 Establish Alternate Channel'[1], or section 6. Appendix?

If this behavior of Windows smb client could be mentioned in [MS-SMB2], it would be great help to do further enhancements on current third-party smb client implemention to cope with Windows and increase interoperability.
Thank you for your great help :)

[1] https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-smb2/2e32e57a-166f-46ae-abe8-17fa3c897890
To establish an alternative channel, the client sends an FSCTL_QUERY_NETWORK_INTERFACE_INFO IOCTL request to query the available network interface on the server.

--

Regards,
Jones Syue | 薛懷宗
QNAP Systems, Inc.