none
[MS-SIPAE] [MS-NLMP] Getting SEC_E_MESSAGE_ALTERED errors when verifying NTLM message signature

    Question

  • I'm implementing a SIP server with NTLM auth according to the MS-SIPAE and MS-NLMP specs.  When a client using SSPI connects to my server, the NTLM session appears to be established correctly (i.e. the CHALLENGE_MESSAGE and AUTHENTICATE_MESSAGE are exchanged properly and the first signed REGISTER response from the server is accepted by the client).  However, every message following the first fails signature verification (i.e. the SSPI VerifySignature function is returning 0x8009030f SEC_E_MESSAGE_ALTERED).

    My server implementation works with the Pidgin client using SIPE if configured with its own NTLM implementation, but fails when it's configured to use SSPI.

    Is it possible that SSPI implements NTLM signature verification differently than how it's described in the MS-SIPAE or MS-NLMP docs?

    I can provide trace logs on request.
    • Edited by Eden Li Tuesday, December 18, 2012 9:00 PM
    Tuesday, December 18, 2012 8:51 PM

Answers

  • We were not properly reinitializing the RC4 cipher while NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY was set. Once we began doing this, the issue with message verification was resolved.
    • Marked as answer by Eden Li Tuesday, January 22, 2013 5:09 PM
    Tuesday, January 22, 2013 5:09 PM

All replies

  • Hi Eden

     Thank you for contacting Microsoft Support. One of the Open specifications team member will contact you to assist further.

    Thanks


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Tuesday, December 18, 2012 9:40 PM
  • Hi Eden

    I have taken ownership of this inquiry and will be assisting you. Can you please send network trace to my attention, Tarun Chopra, to dochelp at microsoft dot com for further analysis ? Furthermore, please confirm if you are using extended sesstion security.

    Regards.


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Wednesday, December 19, 2012 2:01 PM
  • Thank you.  I have sent a follow up email to that address.  

    In the SSPI case, the client AUTHENTICATE_CHALLENGE message does not set NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY.  In the non-SSPI case, it is set.

    Wednesday, December 19, 2012 5:59 PM
  • We were not properly reinitializing the RC4 cipher while NTLMSSP_NEGOTIATE_EXTENDED_SESSIONSECURITY was set. Once we began doing this, the issue with message verification was resolved.
    • Marked as answer by Eden Li Tuesday, January 22, 2013 5:09 PM
    Tuesday, January 22, 2013 5:09 PM