1.7 Versioning and Capability Negotiation

  • Article

This document covers versioning in the following areas:

  • Supported Transports: This protocol can be implemented on top of NetBIOS, TCP, RDMA, or QUIC as defined in section 2.1.

  • Protocol Versions: This protocol supports several capability bits. These are defined in section 2.2.5.

  • Security and Authentication Methods: The SMB 2 Protocol supports authentication through the use of the Generic Security Service Application Programming Interface (GSS-API), as specified in [MS-SPNG].

    When a suitable authentication is performed, the authenticity and integrity of SMB2 operations are optionally protected by Message Authentication Code (MAC) signatures using cryptographically secure keys. HMAC-SHA256, AES-128-CMAC, or AES-GMAC is used, depending on the negotiated dialect and hash algorithm.

    When the SMB 3.x dialect family is negotiated, and when suitable authentication is performed, authenticated encryption and integrity protection are optionally supported through the use of AES-128-CCM or AES-128-GCM, depending on the negotiated dialect and cipher algorithm.

    When the SMB 3.1.1 dialect is negotiated, and when suitable authentication is performed, authenticated encryption and integrity protection are optionally supported through the use of AES-256-CCM or AES-256-GCM, depending on the cipher algorithm.

  • Capability Negotiation: Though the semantics and the command set for the SMB 2 Protocol closely match the SMB Protocol, as specified in [MS-SMB], the wire format for SMB 2 Protocol packets is different from that of the SMB Protocol. For maintaining interoperability between clients and servers in a mixed SMB 2/SMB Protocol environment, the SMB 2 Protocol can be negotiated in one of two ways:

If a client uses an SMB negotiate message to indicate to an SMB 2 Protocol–capable server that it requests to use SMB 2, the server responds with an SMB2 NEGOTIATE Response as specified in section 2.2.4.

A client that maintains a runtime cache for each server with which it communicates, including whether the server is SMB 2 Protocol–capable, would then use an SMB2 NEGOTIATE Request (as specified in section 2.2.3) in future attempts to connect to any server whose cached entry indicates support for the SMB 2 Protocol.

Servers capable of only the SMB 2 Protocol would reject communication with traditional SMB Protocol clients that do not offer "SMB 2.002" or "SMB 2.???" as a negotiate dialect, and accept communication only from SMB 2 Protocol clients.

There are currently three dialect families of the SMB 2 Protocol:

Dialect Family

Dialect Revisions

Revision Code

SMB 2.0.2

SMB 2.0.2 dialect revision

0x0202

SMB 2.1

SMB 2.1 dialect revision

0x0210

SMB 3.x

SMB 3.0 dialect revision

SMB 3.0.2 dialect revision

SMB 3.1.1 dialect revision

0x0300

0x0302

0x0311

  • Negotiating the SMB 2.0.2 dialect implies support for the requests and responses as specified in this document, except those explicitly marked for the SMB 2.1 or 3.x dialect family.

  • Negotiating the SMB 2.1 dialect implies support for the requests and responses as specified in this document and support for the SMB 2.0.2 dialect, except those explicitly marked for the SMB 3.x dialect family.

  • Negotiating the SMB 3.0 dialect implies support for the requests and responses as specified in this document and support for the SMB 2.0.2 and SMB 2.1 dialects, except those explicitly marked for the SMB 3.0.2 or SMB 3.1.1 dialect.

  • Negotiating the SMB 3.0.2 dialect implies support for the requests and responses as specified in this document and support for the SMB 2.0.2, SMB 2.1, and SMB 3.0 dialects, except those explicitly marked for the SMB 3.1.1 dialect.

  • Negotiating the SMB 3.1.1 dialect implies support for the requests and responses as specified in this document and support for the SMB 2.0.2, SMB 2.1, SMB 3.0, and SMB 3.0.2 dialects.

For the rest of the document, unless otherwise specified, the term 'SMB 3.x dialect family' implies the SMB 3.0, SMB 3.0.2, and SMB 3.1.1 dialect revisions. The following state diagram illustrates dialect negotiation on the server implementing the SMB 2 Protocol dialects. In this diagram, state transitions occur as the SMB_COM_NEGOTIATE, SMB2 NEGOTIATE, and other requests are received from the client. The server uses a per-connection variable, Connection.NegotiateDialect, to represent the current state of dialect negotiation between client and server on each transport connection.

Connection.NegotiateDialect state transitions in an SMB 2 Protocol server

Figure 3: Connection.NegotiateDialect state transitions in an SMB 2 Protocol server