none
OCS SIP NTLM Signature verification & Generation: RRS feed

  • Question

  • Hi,

    I am trying to write a OCS SIP Client using Java. Registration works fine here. But after I get 200 OK from server, I get a srand, snum and response (NTLM signature) within Authentication-Info header as shown below.

    SIP/2.0 200 OK
    Authentication-Info: NTLM rspauth="01000000000000004388D7B36E884A8A", srand="4BFB0851", snum="1", opaque="EAB39E9A", qop="auth", targetname="306181sip2.global.avaya.com", realm="SIP Communications Service"
    ms-keep-alive: UAS; tcp=no; hop-hop=yes; end-end=no; timeout=300
    Via: SIP/2.0/TCP 198.152.113.78:11367;ms-received-port=1532;ms-received-cid=5143e00
    From: <sip:rjangam@avaya.com>;tag=6dfc10f44b;epid=38a4235837
    To: <sip:rjangam@avaya.com>;tag=504425B9B8E76FDED17D97C33A0B31E6
    Call-ID: bc286de70ed7493983823b2c9a0032f9
    CSeq: 3 REGISTER
    Contact: <sip:198.152.113.78:1532;transport=tcp;ms-received-cid=5143E00>;methods="INVITE, MESSAGE, INFO, SUBSCRIBE, OPTIONS, BYE, CANCEL, NOTIFY, ACK, REFER, BENOTIFY";expires=7200
    Expires: 7200
    presence-state: required="yes",resync="yes"
    Allow-Events: vnd-microsoft-provisioning,vnd-microsoft-roaming-contacts,vnd-microsoft-roaming-ACL,presence,presence.wpending
    Supported: adhoclist
    Server: RTC/2.1
    Content-Length: 0

    Now I don't know how to validate the signature from Authentication-Info. MS-SIPAE says that i need to create a Sevurity Buffer and process it using GSS_VerifyMic() method from MS-NLMP. But it does not clearly says how to verify the signature and there is no process explained to calculate or verify signature.

    Here is the buffer that i calculated from what MS-SIPAE says:

    <NTLM><4BFB0851><1><SIP Communications Service><306181sip2.global.avaya.com><bc286de70ed7493983823b2c9a0032f9><3><REGISTER><rjangam@avaya.com><6dfc10f44b><rjangam@avaya.com><504425B9B8E76FDED17D97C33A0B31E6><><><7200><200>

    Is this correct buffer??

    And also don't know how do i calculate it when i want to send a SUBSCRIBE to the OCS Server.

    Can anybody help me on this?? Also can anybody show me exactly how do I calculate signature "01000000000000004388D7B36E884A8A" from Auth-Info header information and above buffer??

     

    Thanks in advance,

    Rahul (rahul.jangam@gmail.com)

     

    Tuesday, August 10, 2010 10:10 AM

Answers

  • Just to update this forum:

    Our investigation has revealed no problem in the documentation. Windows calculates the signature as described in the document and no correction is planned in the documentation for this issue.


    Regards, Obaid Farooqi
    Friday, October 15, 2010 10:43 PM
    Owner

All replies

  • Rahul,

    Someone from our team will be following-up with you shortly.

    Dominic Salemno
    Escalation Engineer
    US-CSS DSC Protocols Team

    Tuesday, August 10, 2010 3:07 PM
  • Rahul,

    I am the engineer who has taken ownership of your issue. I am currently researching this and will follow-up with you as things progress.

    Dominic Salemno
    Escalation Engineer
    US-CSS DSC Protocols Team

     

    Tuesday, August 10, 2010 6:08 PM
  • HI Dominic,

    Did you find anything on this?? We need this ASAP.

     

    Thanks,

    Rahul

    Wednesday, August 18, 2010 4:20 AM
  • Rahul,

    Could you send me a network trace of the exhibited behavior to dochelp (at) microsoft.com so that I may further diagnose this issue?

    Dominic Salemno
    Escalation Engineer
    US-CSS DSC Protocols Team

    Thursday, August 19, 2010 8:00 PM
  • HI Dominic,

    Could you please tell me your email/contact id so that i can send you network trace. I will send you trace from office communication when i logon to my OCS server using it. And there you can find how it sends NTLM signature for every communication to server.

     

    Thanks,

    Rahul

    Monday, August 23, 2010 4:25 AM
  • Rahul,

    The spam filter will catch an e-mail address written exactly as-is. The e-mail address is as follows:

    dochelp (at) microsoft.com

    substitute (at) with @.

    Dominic Salemno
    Escalation Engineer
    US-CSS DSC Protocols Team

     

    Monday, August 23, 2010 4:59 PM
  • Rahul,

     

    Review Section 3.3.4.1 (Sending Messages to the SIP Client) of the documentation.

     

    Step 8 states the following:

     

    rspauth with the value generated in step 4

     

    4. The server uses an authentication protocol GSS_GetMIC() call as described in [MS-NLMP] section

    3.1.4, for NTLM, or in [RFC2743] section 2.3.1, for Kerberos, to generate a signature token for

    the buffer constructed in step 3, using the authentication protocol context stored in the SA.

     

    Note that for the NT LAN Manager (NTLM) Authentication Protocol Security Support Provider

    Interface (SSPI), the server provides a fixed message sequence number of 100, in addition to the

    buffer and protocol context.

     

    For TLS-DSK, the server computes the signature token using the HMAC algorithm specified in

    [RFC2104], with the hash function and server authentication key obtained when TLS negotiation

    completed (the "finished" handshake message was received from the client, as described in

    section 3.3.5.1), and the buffer constructed in step 3.

    The binary token returned by the authentication protocol implementation is then encoded using

    the base 64 encoding procedure specified in [RFC3548] section 3.

     

    5. The server generates an Authentication-Info header field (if it acted as a UAS when the SA

    was established) or a Proxy-Authentication-Info header field (if it acted as a proxy when the

    SA was established), according to the syntax described in section 2.2.2, with the data generated

    in the preceding steps and data generated during initialization or SA creation.

     

    Specifically, it MUST add the following fields:

     

    1. Authentication protocol ("NTLM", "Kerberos", or "TLS-DSK")

    2.  realm with the value selected by the server during initialization

    3.  targetname with the value selected by the server during initialization

    4. opaque with the value that the server generated during SA creation

    5. qop with the value "auth"

    6.  snum with the value generated in step 2

    7.  srand with the value generated in step 2

     

    Dominic Salemno

    Escalation Engineer

    Open Specifications

    Thursday, August 26, 2010 7:54 PM
  • Rahul,

    Has your question been answered?

    Dominic Salemno
    Escalation Engineer
    Open Specifications

     

    Friday, August 27, 2010 5:33 PM
  • HI Dominic,

    The procedure above is to calculate the security buffer that Server and client both will use and then  there GSS_getMIC() is called to calculate NTLM Signature.

     

    So in my very first post on this forum, you can see that i have created buffer as per the steps mentioned in doc segment that you pasted above.

     

    So I am wondering my security buffer is correct? and if yes then what is procedure inside GSS_MIC() that calculates NTLM singature from this buffer?

    I was on vacation so i could not send you the SIP trace. But i am sending you trace right away.

     

    THanks,

    Rahul

    Tuesday, August 31, 2010 12:03 PM
  • Dominic,

     

    Just posted my SIP trace with little bit explanation again to dochelp @ microsoft . com.

     

    THanks,

    Rahul

    Tuesday, August 31, 2010 12:20 PM
  • Hi Rahul:

    I have sent a reply to your question through email.

     


    Regards, Obaid Farooqi
    Wednesday, September 1, 2010 9:27 PM
    Owner
  • Hi Obaid,

     

    Just replied to your email.

     

    Thanks,

    Rahul

    Thursday, September 2, 2010 3:32 AM
  • This issue is being dealt with off-line via email. One the issue is resolved, a summary will be posted here.
    Regards, Obaid Farooqi
    Monday, September 13, 2010 3:16 PM
    Owner
  • Just to update this forum:

    Our investigation has revealed no problem in the documentation. Windows calculates the signature as described in the document and no correction is planned in the documentation for this issue.


    Regards, Obaid Farooqi
    Friday, October 15, 2010 10:43 PM
    Owner