none
SMB2 signing key without key exchange RRS feed

  • Question

  • I have been investigating a problem I have been having with Windows clients connecting to my SMB2 server when certain signing modes are negotiated.  In particular, I am seeing signing failures on the SMB2 session setup response signature verification in cases where either the client or server require signing.

    I've carefully read the MS-NLMP specification, and the signatures work when signing is not required, but is instead optional.  Here are the circumstances of the failure:

    -- Signing is forced by either side

    -- NTLMv2 authentication is used

    -- The NTLMSSP_NEGOTIATE_KEY_EXCH flag is not set, and key exchange is not used

    It is my understanding from the MS-NLMP specification that the signing key should be the same as the KeyExchangeKey, which should also be the same as the 128-bit SessionBaseKey for NTLMv2.  That same key works for the optional signing case, and nothing in the MS-NLMP spec indicates that the state of the forced signing bit influences the key.

    Can someone point me to the piece of information I am missing?  I am fairly certain that my current key choice worked sometime in the past during testing, but I don't have any historical packet captures to prove it.

    Tuesday, November 22, 2016 10:30 PM

Answers

  • After confirming the key computation on the server, I discovered that some of my shared server architecture was pulling the key value from an incorrect location associated with the connection instead of the session.  The key value it was using was NIL instead of the correct key data.

    Confirming key computation with the client side was critical for locating the problem.  Thanks for your time.

    • Marked as answer by Charles Emig Thursday, December 8, 2016 9:42 PM
    Thursday, December 8, 2016 9:42 PM

All replies

  • Hi Charles,

    Thank you writing to the Microsoft Open Specifications forum.  Someone from the protocols support team will be in touch to review further and respond here to assist.

    Thanks,

    Nathan Manis

    Wednesday, November 23, 2016 1:08 AM
    Moderator
  • Hi Charles:

    I'll help you with this issue.

    Can you please send an email to dochelp at Microsoft dot com to my attention? I need some traces from you.


    Regards, Obaid Farooqi

    Monday, November 28, 2016 8:30 PM
    Owner
  • After confirming the key computation on the server, I discovered that some of my shared server architecture was pulling the key value from an incorrect location associated with the connection instead of the session.  The key value it was using was NIL instead of the correct key data.

    Confirming key computation with the client side was critical for locating the problem.  Thanks for your time.

    • Marked as answer by Charles Emig Thursday, December 8, 2016 9:42 PM
    Thursday, December 8, 2016 9:42 PM