none
Message Integrity issue with 2016 Client RRS feed

  • Question

  • Hello,

    I am developing a custom Lync Clients, my clients can make call to each others using MS-ICE2 specification successfully. But When my client call to MS Lync client 2016, the ICE procedure always failed because the stun binding request I made can't be passed the verification of Ms Lync Client, the error like that ' hmac of message integrity failed on verification '.

    This message integrity works perfectly fine with 2015 client. However whenever i am trying to communicate to lync client 2016 message integrity is getting failed.  For 2015 client, i have followed the steps provided in this blog :

    https://blogs.msdn.microsoft.com/openspecification/2016/02/23/verifying-stun-message-integrity-for-lync-and-skype-for-business-ice-traffic/

    Can you please share the steps to create message-integrity for STUN bind request n response for 2016 clients. This seems to have changed for MS-IMPLEMNTATION-VERSION 3 or greater version onwards.

    Thank you very much!

    Thursday, May 17, 2018 1:14 PM

All replies

  • Hi DILIPBHAIM,

    Thank you for your inquiry about Microsoft Office Specifications. We have created an incident for investigating this issue and I'll be helping you out.

    Kindly send your network trace along with frame numbers and password so that we can calculate the hash at our end and verify the output to dochelp at Microsoft.com

    Thanks


    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Thursday, May 17, 2018 3:32 PM
  • Thanks. 

    I have sent Packet trace and keys to your mail id. Please do needful.

    Thursday, May 17, 2018 4:31 PM
  • Thank you. We got your traces, let's continue to work thro email and post our result here once we are able to resolve the issue.

    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Thursday, May 17, 2018 6:10 PM
  • Circling back to update the thread with research notes-

     

    We confirmed by replaying the traces that the information mentioned on this blogwill not work in this scenario as stated in MS-ICE2 specification, excerpt below. We are using RFC5389 to calculate the message-integrity because the supported version by both peers’ is == 0x03.

     

    3.1.5.2 Processing STUN Messages

    This protocol sends peer-to-peer Simple Traversal of UDP through NAT (STUN) messages between endpoints during the connectivity checks phase to select the candidate pairs for streaming media.

    This section specifies the processing of STUN binding request messages by the two endpoints.

    During the connectivity checks phase, whenever a connectivity check request is sent following the message format as specified in [IETFDRAFT-STUN-02], an additional connectivity check request or response SHOULD be sent following the message format as specified in [RFC5389]. The transmission of this additional connectivity check packet SHOULD be stopped on receiving a valid connectivity check request or response from the peer endpoint.

    The first time a valid STUN message is received from the peer endpoint, the value of the IMPLEMENTATION-VERSION attribute MUST be read. A value greater than or equal to 0x00000003 implies that the peer endpoint supports [RFC5389] message formats. A value less than 0x00000003, implies that the peer endpoint supports only [IETFDRAFT-STUN-02] message formats. If the attribute does not exist, it implies that the peer endpoint supports [RFC5389] message formats only. All subsequent connectivity check messages MUST follow the message format supported by the peer endpoint as detected based on the IMPLEMENTATION-VERSION attribute above.

     

    Test vector is as follows –

     

    Password: "RQFNRTnfTge4s4Uq5aOSKaM0"

    Input:

    00 01 00 54 21 12 a4 42-fa 00 ac dc 5e 96 e8 71

    0a 94 29 3f 00 06 00 09-6c 70 4b 4d 3a 4a 71 47

    67 00 00 00 00 24 00 04-6e ff fe ff 80 2a 00 08

    00 00 00 00 0f 3c 4d 3b-80 54 00 01 31 00 00 00

    80 70 00 04 00 00 00 03 

                          

    Adjusted length to '00 4c' ((USHORT)nTextLen (0x48) + size of message integrity (24) - size of Msg Header (20))

    Input:

    0001004c2112a442fa00acdc5e96e8710a94293f000600096c704b4d3a4a714767000000002400046efffeff802a0008000000000f3c4d3b80540001310000008070000400000003

    Hash:

    87fffd821405811f4a33403e0ca81c4c93bf956a 

     

    Our recommendation to Dilip was to implement the logic given in RFC5389 to calculate the correct hash.



    Tarun Chopra | Escalation Engineer | Open Specifications Support Team

    Friday, June 15, 2018 4:19 PM