MS Edge ICE problem - MESSAGE-INTEGRITY

By design Issue #7728584

Details

Author
Erik L.
Created
May 29, 2016
Privacy
This issue is public.
Reports
Reported by 1 person

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

Key:
PSnUCb2FKNLTcgWuvfnfEh1ew

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

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

Attachments

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.

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

    Sign in