4.3 Message Signing Example

The following is the sequence of events that is related to SMB message authentication. In the following scenario, as specified in [RFC4178], authentication is used between the client and the server. The client and server are both configured not to require SMB signing; however, both are capable of using SMB signing. This also applies to the figure in section 4.1; however, the parameters significant to signing a negotiation are called out.

  1. The client sends an SMB_COM_NEGOTIATE request to the server.

     Client -> Server: SMB: C negotiate, Dialect = NTLM 0.12
     SMB Flags2 contains 0xC843 
       1...  ....  ....  ....  = Unicode Strings: Strings are Unicode
       .1..  ....  ....  ....  = Error Code Type: Error codes are NT error codes
       ..0.  ....  ....  ....  = Execute-Only Reads: Do not permit reads if execute-only
       ...0 ....  ....  ....  = Dfs: Do not resolve pathnames with Dfs
       ....  1...  ....  ....  = Extended security negotiation is supported
       ....  ....  .1..  ....  = Long Names Used
       ....  ....  ....  .0..  = Security signatures are not supported
       ....  ....  ....  ..1.  = Extended Attributes: Extended attributes are supported
       ....  ....  ....  ...1 = Long Names Allowed
     Security Signature is not set (the value is 00 00 00 00 00 00 00 
     00).
     SECURITY_SIGNATURE: Bit2  (not set)
      
    

    No SecuritySignature is generated at this stage.

  2. The client receives an SMB_COM_NEGOTIATE response SMB from the server.

      
      
     Server -> Client: SMB: R negotiate, Dialect # = 5
     SMB Flags2 contains 0xC853
     Binary: 00000000 00000000 11001000 01010011
                                   ^      ^  ^
      
     SECURITY_SIGNATURE: Bit2: (not set)
     Security Signature is not set (the value is  00 00 00 00 00 00 00 00).
      
    

    No SecuritySignature is generated at this stage.

  3. The client builds an SMB_COM_SESSION_SETUP_ANDX request SMB and sends it to the server.

    In the SessionSetupAndX SMB, an authentication request, such as an NTLM or NTLMv2 Challenge/Response or a Kerberos ticket, is sent from the client to the server.

    At this stage, the SessionKey is not yet available.

     Client -> Server: SMB: C session setup & X
     SMB Flags2 contains 0xC807
     Binary: 00000000 00000000 11001000 00000111
                                   ^      ^  ^
      
     SECURITY_SIGNATURE: Bit2 (set)
      
    

    After the packet is sent by the client, the sequence number is incremented to 1, which is the expected sequence number for the response packet from the server.

  4. The server processes the request and sends an SMB_COM_SESSION_SETUP_ANDX response to the client.

    It is possible that multiple roundtrips of SessionSetupAndX can be required to complete a given authentication. If STATUS_MORE_PROCESSING_REQUIRED is returned, then the implementer would return to the previous step and repeat. The following example demonstrates what happens when STATUS_SUCCESS is returned. Similarly, if this authentication was for Anonymous or Guest, then signing would not be activated at this time.

     Server -> Client: SMB: R session setup & X
     SMB Flags2 contains 0xC807
     Binary: 00000000 00000000 11001000 00000111
                                          ^  ^
      
     SECURITY_SIGNATURE: Bit2 (set)
      
    

    The server sets the sequence number to 1 for the response packet and generates the SecuritySignature as follows.

    The server places the sequence number (1) in the SecuritySignature field of the SMB header, and an MD5 hash is performed on the SessionKey + SMB packet. This results in a 16-byte value. The first 8 bytes of the computed hash (AB 44 C4 76 45 84 1A 6A) are placed in the SecuritySignature field and sent to the client.

      
      
     00000:  00 11 43 02 26 E6 00 C0 4F 60 2E 45 08 00 45 00   ..C.&f.@O'.E..E.
     00010:  01 78 85 60 40 00 80 32 F6 4B AC 1B 92 B9 AC 1B   .x&'@.,2vK,.9,.
     00020:  92 B7 88 F2 96 BD 00 00 00 14 01 BD 05 48 8B A1   "Fr=.....=.H9!
     00030:  8F 6C C1 3F C0 39 50 18 FF F0 84 70 00 00 00 00   lA?@9P.pp....
     00040:  01 2F FF 53 4D 42 73 00 00 00 00 98 07 C8 00 00   ./SMBs....\.H..
     00050: >AB 44 C4 76 45 84 1A 6A<00 00 00 00 FF FE 00 08   +DDvE.j....~..
     00060:  40 00 04 FF 00 2F 01 00 00 A2 00 04 01 A1 81 9F   @.../..."...!x
     00070:  30 81 9C A0 03 0A 01 00 A1 0B 06 09 2A 86 48 82   0S 
     ....!...* H
      
    

    After the server sends the packet, the sequence number is incremented to 2, which is the expected sequence number for the next SMB packet from the client.

  5. The client processes the response and obtains the SessionKey.

     SMB Flags2 contains 0xC807
     Binary: 00000000 00000000 11001000 00000111
                                          ^  ^
      
     SECURITY_SIGNATURE: Bit2 (set)
      
    

    The expected sequence number is 1 for the response packet from the server.

    The client saves the SecuritySignature in the response packet. The expected sequence number (1) is placed in the SecuritySignature field of the SMB header, and an MD5 hash is performed on the SessionKey SMB packet. This results in a 16-byte value. The first 8 bytes of the computed hash are compared with the one sent by the server (AB 44 C4 76 45 84 1A 6A) to validate the SMB packet. For the SessionKey that is used for signing when Kerberos is used, see [MS-KILE] section 3.1.1.2, Cryptographic Material.

  6. The client proceeds further and sends an SMB_COM_TREE_CONNECT_ANDX request SMB.

     Client -> Server: SMB: C tree connect & X, Share
      
    

    The client sequence number is now incremented. The new value is 2.

    The sequence number (2) is placed in the SecuritySignature field of the SMB header, and an MD5 hash is performed on the 16-byte SessionKey + SMB packet. This results in a 16-byte value. The first 8 bytes (in this case, A5 B0 43 DC 07 51 0F 8B) are placed in the SecuritySignature field in the SMB header and then sent to the server.

      
     00000:  00 C0 4F 60 2E 45 00 11 43 02 26 E6 08 00 45 00   .@O'.E..C.&f..E.
     00010:  00 98 21 48 40 00 80 32 5B 44 AC 1B 92 B7 AC 1B   .\!H@.,2[D,.",.
     00020:  92 B9 C4 70 3D 34 00 00 00 1C 05 48 01 BD C1 3F   9Dp=4.....H.=A?
     00030:  C0 39 8B A1 90 9F 50 18 42 EF D0 D6 00 00 00 00   @99!xP.BoPV....
     00040:  00 54 FF 53 4D 42 75 00 00 00 00 18 07 C8 00 00   .TSMBu......H..
     00050: >A5 B0 43 DC 07 51 0F 8B<00 00 00 00 FF FE 00 08   %0C\.Q.9....~..
     00060:  80 00 04 FF 00 54 00 0C 00 01 00 29 00 00 5C 00   ,...T.....)..\.
     00070:  5C 00 4D 00 4F 00 48 00 41 00 4B 00 34 00 31 00   \.M.O.H.A.K.4.1.
      
    

    The sequence continues until the session is terminated.

    In the case where extended security is not used, the same process is followed. However, the MD5 hash is performed on the 16-byte session key + NTLM challenge response + SMB packet with the appropriate sequence number. The NTLM challenge response is the authentication that is received in the SMB_COM_SESSION_SETUP_ANDX request in the UnicodePassword field if NTLM was used for authentication, or in the OEMPassword field if LM authentication was used.