none
NTLMSSP_NEGOTIATE_ALWAYS_SIGN vs NTLMSSP_NEGOTIATE_SIGN RRS feed

  • Question

  • Hi,

        I am trying to understand more about NTLMSSP_NEGOTIATE_SIGN & NTLMSSP_NEGOTIATE_ALWAYS_SIGN and their impact on MIC presence. I am little confused with NTLMSSP_NEGOTIATE_SIGN after going through NLMP documentation

    Following is a snip for NTLMSSP_NEGOTIATE_SIGN

        <snip>

              D (1 bit): If set, requests session key negotiation for message signatures. If the client sends NTLMSSP_NEGOTIATE_SIGN to the server in the NEGOTIATE_MESSAGE, the server MUST return NTLMSSP_NEGOTIATE_SIGN to the client in the CHALLENGE_MESSAGE. An alternate name for this field is NTLMSSP_NEGOTIATE_SIGN.

        </snip>

    Here this sentence describing more about session key negotiation, but not signing requirement itself. Does this mean presence of this bit doesn't mandate client/server for signing messages?

    Where as NTLMSSP_NEGOTIATE_ALWAYS_SIGN indicates that NTLMSSP_NEGOTIATE_SIGN is overridden by NTLMSSP_NEGOTIATE_SIGN.

    Following is a snip for NTLMSSP_NEGOTIATE_ALWAYS_SIGN

        <snip>

              M (1 bit): If set, requests the presence of a signature block on all messages. NTLMSSP_NEGOTIATE_ALWAYS_SIGN MUST be set in the NEGOTIATE_MESSAGE to the server and the CHALLENGE_MESSAGE to the client. NTLMSSP_NEGOTIATE_ALWAYS_SIGN is overridden by NTLMSSP_NEGOTIATE_SIGN and NTLMSSP_NEGOTIATE_SEAL, if they are supported. An alternate name for this field is NTLMSSP_NEGOTIATE_ALWAYS_SIGN.

         </snip>

        My understanding is that NTLMSSP_NEGOTIATE_SIGN indicates presence of signature block on all messages as well as requesting session key negotiation. Is my understanding correct?

        One more question I have is; does the presence of NTLMSSP_NEGOTIATE_SIGN/NTLMSSP_NEGOTIATE_ALWAYS_SIGN has influence MIC presence?

        my understanding is that either NTLMSSP_NEGOTIATE_SIGN or NTLMSSP_NEGOTIATE_ALWAYS_SIGN requires MIC to be present for NTLMv2 (though presence can be indicated through MsvAvFlags. Is my understanding correct?

    Friday, September 2, 2016 8:53 AM

Answers

  • Hi Prasad:

    The flag NTLMSSP_NEGOTIATE_ALWAYS_SIGN shows capability, not requirement. As an authentication protocol, MS-NLMP does not dictate requirements for encapsulating protocol e.g. RPC. MS-NLMP does the authentication and establishes the session, signing and sealing keys. It is the job of the encapsulating protocol to use them or not use them.

    As per MS-NLMP, the Windows client always sets the following flags in the NEGOTIATE_MESSAGE

    • NTLMSSP_REQUEST_TARGET
    • NTLMSSP_NEGOTIATE_NTLM
    • NTLMSSP_NEGOTIATE_ALWAYS_SIGN
    • NTLMSSP_NEGOTIATE_UNICODE

    All Windows server always set the following flags in CHALLENGE_MESSAGE

    • The supported flags requested in the NEGOTIATE_MESSAGE.NegotiateFlags field
    • NTLMSSP_REQUEST_TARGET
    • NTLMSSP_NEGOTIATE_NTLM
    • NTLMSSP_NEGOTIATE_ALWAYS_SIGN

    Based on the above, your implementation (whether client or server) will at least have these flags set.

    Given that these flags are always set, the only other thing needed to process MIC is proper setting of MsvAvFlags AV_PAIR.

    You must have at least one of the flags set to verify MIC:

    NTLMSSP_NEGOTIATE_ALWAYS_SIGN

    NTLMSSP_NEGOTIATE_SIGN

    NTLMSSP_NEGOTIATE_SEAL

    Since Windows always sets NTLMSSP_NEGOTIATE_ALWAYS_SIGN in authenticate message (due to the negotiation and challenge above), the MIC is verified if proper AV_PAIR is set.

    If you fail to set any of the above mentioned three flags, MIC will not be verified even if the AV_PAIR is set properly.

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    Friday, September 2, 2016 7:20 PM
    Owner
  • Hi Prasad:

    If any of the AV_Pair is modified by a MITM, the authentication will fail since the NtProofStr calculation includes AV_Pairs. Please consult MS-NLMP section "3.3.2 NTLM v2 Authentication"

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    Tuesday, September 27, 2016 3:04 AM
    Owner

All replies

  • Hi Prasad,
    Thank you for this inquiry. One of our engineers will review this and follow-up.

    Thanks,
    Edgar

    Friday, September 2, 2016 3:15 PM
    Moderator
  • Hi Prasad:

    The flag NTLMSSP_NEGOTIATE_ALWAYS_SIGN shows capability, not requirement. As an authentication protocol, MS-NLMP does not dictate requirements for encapsulating protocol e.g. RPC. MS-NLMP does the authentication and establishes the session, signing and sealing keys. It is the job of the encapsulating protocol to use them or not use them.

    As per MS-NLMP, the Windows client always sets the following flags in the NEGOTIATE_MESSAGE

    • NTLMSSP_REQUEST_TARGET
    • NTLMSSP_NEGOTIATE_NTLM
    • NTLMSSP_NEGOTIATE_ALWAYS_SIGN
    • NTLMSSP_NEGOTIATE_UNICODE

    All Windows server always set the following flags in CHALLENGE_MESSAGE

    • The supported flags requested in the NEGOTIATE_MESSAGE.NegotiateFlags field
    • NTLMSSP_REQUEST_TARGET
    • NTLMSSP_NEGOTIATE_NTLM
    • NTLMSSP_NEGOTIATE_ALWAYS_SIGN

    Based on the above, your implementation (whether client or server) will at least have these flags set.

    Given that these flags are always set, the only other thing needed to process MIC is proper setting of MsvAvFlags AV_PAIR.

    You must have at least one of the flags set to verify MIC:

    NTLMSSP_NEGOTIATE_ALWAYS_SIGN

    NTLMSSP_NEGOTIATE_SIGN

    NTLMSSP_NEGOTIATE_SEAL

    Since Windows always sets NTLMSSP_NEGOTIATE_ALWAYS_SIGN in authenticate message (due to the negotiation and challenge above), the MIC is verified if proper AV_PAIR is set.

    If you fail to set any of the above mentioned three flags, MIC will not be verified even if the AV_PAIR is set properly.

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    Friday, September 2, 2016 7:20 PM
    Owner
  • Hi Obaid,

        Thank you for your reply and apologies for coming late on this matter. I still have one question based your previous reply.

        <snip from previous reply>

              MS-NLMP does the authentication and establishes the session, signing and sealing keys. It is the job of the encapsulating protocol to use them or not use them.

        </snip from previous reply>

        Assuming NTLMSSP (and NTLMv2) being used as authentication protocol as part of SMB2 session setup, can SMB2 be called encapsulating protocol in that context? If so, if signing is mandatory by SMB2 server (ie signing strictly enforced by SMB2 server implementation), does that mandate MIC validation by server and MIC value inclusion by client (through AV_PAIR)? If not in which scenario does SMB2 implementation (server) makes it mandatory to validate MIC for NTLMSSP implementation?


    Prasad


    • Edited by Prasad JVV Monday, September 26, 2016 9:34 AM
    Monday, September 26, 2016 9:34 AM
  • Hi Prasad:

    I am looking into it and will post response here as soon as I have an answer.


    Regards, Obaid Farooqi

    Monday, September 26, 2016 3:59 PM
    Owner
  • Hi Prasad:

    Please find the answers to your questions in a Q&A fashion below.

    Q. Assuming NTLMSSP (and NTLMv2) being used as authentication protocol as part of SMB2 session setup, can SMB2 be called encapsulating protocol in that context?

    A. Yes

    Q. If so, if signing is mandatory by SMB2 server (ie signing strictly enforced by SMB2 server implementation), does that mandate MIC validation by server and MIC value inclusion by client (through AV_PAIR)?

    A. MIC is not part of MS-SMB/MS-SMB2 protocol. So SMB server does not have anything to do with MIC. The SMB server and client will use the session key negotiated by NTLM to sign and verify the messages, as explained in MS-SMB2 section "3.3.5.5.3 Handling GSS-API Authentication", item 6.

    https://msdn.microsoft.com/en-us/library/cc246772.aspx

    Q. If not in which scenario does SMB2 implementation (server) makes it mandatory to validate MIC for NTLMSSP implementation?

    A. Please see my answer above.

    If you do not want to deal with MIC, just do not include the AV_PAIR that shows the inclusion of MIC. MIC is not mandatory in any case. The MS-NLMP protocol only recommends that it be included, as mentioned in section "5 Security" of MS-NLMP document ( https://msdn.microsoft.com/en-us/library/cc236715.aspx ) , reproducing here for convenience:

    "

    .....

    The NTLM server does not require the NTLM client to send the MIC, but sending the MIC when the timestamp is present greatly increases security. Although implementations of NLMP will work without support for MIC, they will be vulnerable to message tampering.......

    "

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    Monday, September 26, 2016 4:35 PM
    Owner
  • Hi Obaid,

        Thanks for your reply providing additional details. So AFAIU, though MIC inclusion can increase security by help avoiding message tampering, it can't completely prevent message tampering for the fact that authentication message itself can be tampered to modify (re-set flag that indicates MIC presence) such that server assumes that MIC is not present in the packet and does not do MIC validation. Please correct me if my understanding is not correct.

    Thank you for your replies so far, have a good day.


    Prasad

    Monday, September 26, 2016 10:55 PM
  • Hi Prasad:

    If any of the AV_Pair is modified by a MITM, the authentication will fail since the NtProofStr calculation includes AV_Pairs. Please consult MS-NLMP section "3.3.2 NTLM v2 Authentication"

    Please let me know if it does not answer your question.


    Regards, Obaid Farooqi

    Tuesday, September 27, 2016 3:04 AM
    Owner
  • Hi Obaid,

        Thank you for additional details; my bad I missed this detail. This clarifies all my queries.

        So though server or client can negotiate NTLMSSP signing capability (through NTLMSSP_NEGOTIATE_SIGN or other flags), server can't enforce NTLMSSP signing but it is left to client's discretion whether to add MIC or not (presence indicated through AV_PAIRs - MsvAvFlags). Server has to validate MIC value if and only it is present.

    Thank you for all your help, have a good day.


    Prasad

    Tuesday, September 27, 2016 9:24 AM