By design Issue #7728584


Erik L.
May 29, 2016
This issue is public.
Reported by 5 people

Sign in to watch or report this issue.

Steps to reproduce

During Edge interoperability testing with ORTC Lib, we have run into the issue with MESSAGE-INTEGRITY calculation on the Edge side.

Problem is that for some packets, Edge is calculating MESSAGE-INTEGRITY value by using full message size value stated in the message (fingerprint included), and it should modify length before calculation so it includes only attributes that are in message before MESSAGE-INTEGRITY, plus MESSAGE-INTEGRITY size. Additionally, input string used for calculation has been padded to 64-bit chunks, which is not proper.

Please find test packet received from MS Edge bellow, along with key value that should be used for calculation.

Test packet:
00 01 00 60 21 12 a4 42 6c 80 0f f0 d0 17 3c d1 38 fc 74 b0 00 06 00 18 74 33 70 4f 30 77 4b 4e 6e 48 74 59 30 6a 78 65 3a 50 46 78 68 00 00 00 00 24 00 04 6e ff fe ff 80 29 00 08 00 00 00 00 14 f1 a9 53 80 54 00 04 31 00 00 00 80 70 00 04 00 00 00 03 00 08 00 14 b6 f4 8c ee 06 4f 75 44 73 76 08 b5 03 54 73 17 9e 00 9e 3b 80 28 00 04 d6 f9 5a ab


Proper input value for MESSAGE-INTEGRITY calculation (as per spec):

Input value used by MS Edge to calculate MESSAGE-INTEGRITY:


0 attachments

    Comments and activity

    • Microsoft Edge Team

      Changed Assigned To to “Christian F.”

      Changed Assigned To to “Venkat K.”

      Changed Assigned To from “Venkat K.” to “Shijun S.”

      Changed Status to “Confirmed”

    • Hi,

      Thanks for providing the feedback to us!

      ORTC engine will send both RFC 3489 style and RFC 5389 style packets till we get a response from the peer endpoint and settle on the supported version.  The bug report is valid against the RFC 3489 style packet we send.  For the time being, we hope you can work out cross-platform interop based on the RFC 5389 option.  Please let us know if we can be any further help.

      All the Best, MS Edge Team

    • Microsoft Edge Team

      Changed Status from “Confirmed” to “By design”

    • I would suggest that if you need to interoperate with RFC 3489 that you instead put this behind a constructor flag to the RTCIceGatherer (or RTCIceTransport), or even better, only respond with RFC 3489 packets if those style packets were received rather than always sending these legacy style packets. As it stands, packets coming from the same candidate pairing are both passing and causing authorization errors with no distinction. This looks like an attack by the remote party (or an attempted interception of media flow). This is also non-standard behaviour overall.

    • Please give this “by design” feature a bit more consideration as support for both RFC’s with the same transaction info is causing the request/response process to fail. This is particularly prevalent in the ice4j library and keeps our product which uses ice4j from offering support for Edge. Microsoft can choose to join the pack or get left in the dust IMHO.

    You need to sign in to your Microsoft account to add a comment.

    Sign in