<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC3552 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC2818 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2818.xml">
<!ENTITY RFC3261 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY RFC3711 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3711.xml">
<!ENTITY RFC5479 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5479.xml">
<!ENTITY RFC6347 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml">
<!ENTITY RFC4568 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4568.xml">
<!ENTITY RFC5763 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5763.xml">
<!ENTITY RFC4251 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY RFC3760 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3760.xml">
<!ENTITY RFC6189 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6189.xml">
<!ENTITY RFC8445 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8445.xml">
<!ENTITY RFC6454 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6454.xml">
<!ENTITY RFC6455 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6455.xml">
<!ENTITY RFC6222 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6222.xml">
<!ENTITY RFC7022 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7022.xml">
<!ENTITY RFC7675 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7675.xml">
<!ENTITY RFC8174 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY RFC6749 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6749.xml">
<!ENTITY RFC7033 SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7033.xml">

<!ENTITY I-D.ietf-rtcweb-security-arch SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security-arch.xml">
<!ENTITY I-D.ietf-rtcweb-overview SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-overview.xml">
<!ENTITY I-D.ietf-rtcweb-ip-handling SYSTEM "http://xml2rfc.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-ip-handling.xml">

]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<!-- Don't change this. It breaks stuff -->
<?rfc tocdepth="4"?> version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" consensus="true" docName="draft-ietf-rtcweb-security-12"
     ipr="pre5378Trust200902"> indexInclude="true" ipr="pre5378Trust200902" number="8826" prepTime="2021-01-14T11:01:13" scripts="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="4" tocInclude="true" xml:lang="en">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-rtcweb-security-12" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc8826" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="WebRTC Security">Security Considerations for WebRTC</title>
    <seriesInfo name="RFC" value="8826" stream="IETF"/>
    <author fullname="Eric Rescorla" initials="E.K." initials="E." surname="Rescorla">
      <organization>RTFM, Inc.</organization>
      <organization showOnFrontPage="true">Mozilla</organization>
      <address>
        <postal>
          <street>2064 Edgewood Drive</street>

          <city>Palo Alto</city>

          <region>CA</region>

          <code>94303</code>

          <country>USA</country>
        </postal>

        <phone>+1 650 678 2350</phone>
        <email>ekr@rtfm.com</email>
      </address>
    </author>
    <date year="2019" />

    <area>ART</area>

    <workgroup>RTC-Web</workgroup>

    <abstract>
      <t> month="01" year="2021"/>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">
        WebRTC is a protocol suite for use with
        real-time applications that can be deployed in browsers - "real time -- "real-time
        communication on the Web".  This document defines the WebRTC threat
        model and analyzes the security threats of WebRTC in that model.
      </t>
    </abstract>
  </front>

  <middle>
    <boilerplate>
      <section title="Introduction" anchor="sec.introduction">
      <t>
        The Real-Time Communications on anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Web (RTCWEB) working group Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has standardized
        protocols for real-time communications between Web browsers, generally
        called "WebRTC" <xref target="I-D.ietf-rtcweb-overview"/>. The
        major use cases for WebRTC technology are real-time audio and/or video calls,
        Web conferencing,
            received public review and direct data transfer. Unlike most conventional real-time systems,
        (e.g., SIP-based <xref target="RFC3261" /> soft phones) WebRTC communications are directly controlled has been approved for publication by some Web server. A simple case
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is shown below. available in Section 2 of
            RFC 7841.
        </t>

      <figure title="A simple WebRTC system" anchor="fig.simple">
        <artwork><![CDATA[
                            +----------------+
                            |                |
                            |   Web Server   |
                            |                |
                            +----------------+
                                ^        ^
                               /          \
                       HTTP   /            \   HTTP
                        or   /              \   or
                 WebSockets /                \ WebSockets
                           v                  v
                        JS API              JS API
                  +-----------+            +-----------+
                  |           |    Media   |           |
                  |  Browser  |<---------->|  Browser  |
                  |           |            |           |
                  +-----------+            +-----------+
                      Alice                     Bob

        ]]></artwork>
      </figure>
      <t>
        In
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the system shown in <xref target="fig.simple"/>, Alice current status of this document, any
            errata, and Bob both have
        WebRTC-enabled browsers how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc8826" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and they visit some Web server which operates a
        calling service. Each of their browsers exposes standardized JavaScript
        calling APIs (implemented the persons identified as browser built-ins)
        which are used by the Web server
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to set up a call between Alice BCP 78 and Bob.
        The Web server also serves as the signaling channel IETF Trust's Legal
            Provisions Relating to transport
        control messages between IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the browsers.
        While date of
            publication of this system is topologically similar to a conventional SIP-based
        system (with the Web server acting document. Please review these documents
            carefully, as the signaling service they describe your rights and browsers
        acting as softphones), control has moved to the central Web server;
        the browser simply provides API points that are used by the calling service.
        As restrictions with any Web application, the Web server can move logic between
            respect to this document. Code Components extracted from this
            document must include Simplified BSD License text as described in
            Section 4.e of the server Trust Legal Provisions and JavaScript are provided without
            warranty as described in the browser, but regardless of where Simplified BSD License.
        </t>
        <t indent="0" pn="section-boilerplate.2-3">
            This document may contain material from IETF Documents or IETF
            Contributions published or made publicly available before November
            10, 2008. The person(s) controlling the
        code is executing, it is ultimately under control copyright in some of the server.
      </t>
      <t>
        It should be immediately apparent that this type of system poses new
        security challenges beyond those of a conventional VoIP system. In particular,
        it needs to contend with malicious calling services.
        For example, if
            material may not have granted the calling service
        can cause IETF Trust the browser to make a call at any time right to any callee allow
            modifications of its
        choice, then this facility can be used to bug a user's computer without
        their knowledge, simply by placing a call to some recording service.
        More subtly, if such material outside the exposed APIs allow IETF Standards Process.
            Without obtaining an adequate license from the server to instruct person(s)
            controlling the
        browser to send arbitrary content, then they can copyright in such materials, this document may not
            be used to bypass
        firewalls or mount denial modified outside the IETF Standards Process, and derivative
            works of service attacks. Any successful system
        will need to it may not be resistant created outside the IETF Standards Process,
            except to this and format it for publication as an RFC or to translate it
            into languages other attacks. than English.
        </t>
      <t>
        A companion document <xref target="I-D.ietf-rtcweb-security-arch"/> describes a security
        architecture intended to address the issues raised in this document.
      </t>
    </section>
    <section anchor="sec-term" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
      "OPTIONAL" in this document are to be interpreted as described in
      BCP 14 <xref target="RFC2119"/>  <xref target="RFC8174"/> when, and only when, they appear in all
      capitals, as shown here.</t>
      </section>
    </boilerplate>
    <toc>
      <section title="The anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-terminology">Terminology</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-the-browser-threat-model">The Browser Threat Model" anchor="sec.web-security">
      <t>
        The security requirements Model</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-access-to-local-resources">Access to Local Resources</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-same-origin-policy">Same-Origin Policy</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-bypassing-sop-cors-websocke">Bypassing SOP: CORS, WebSockets, and Consent to Communicate</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-for-webrtc-applica">Security for WebRTC follow directly Applications</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-access-to-local-devices">Access to Local Devices</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2">
                  <li pn="section-toc.1-1.4.2.1.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.1.1"><xref derivedContent="4.1.1" format="counter" sectionFormat="of" target="section-4.1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-threats-from-screen-sharing">Threats from Screen Sharing</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.2.1"><xref derivedContent="4.1.2" format="counter" sectionFormat="of" target="section-4.1.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-calling-scenarios-and-user-">Calling Scenarios and User Expectations</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.1.2.2.2">
                      <li pn="section-toc.1-1.4.2.1.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.1.2.2.2.1.1"><xref derivedContent="4.1.2.1" format="counter" sectionFormat="of" target="section-4.1.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-dedicated-calling-services">Dedicated Calling Services</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.1.2.2.2.2">
                        <t indent="0" pn="section-toc.1-1.4.2.1.2.2.2.2.1"><xref derivedContent="4.1.2.2" format="counter" sectionFormat="of" target="section-4.1.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-calling-the-site-youre-on">Calling the
        requirement that Site You're On</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.3.1"><xref derivedContent="4.1.3" format="counter" sectionFormat="of" target="section-4.1.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-origin-based-security">Origin-Based Security</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.1.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.1.2.4.1"><xref derivedContent="4.1.4" format="counter" sectionFormat="of" target="section-4.1.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-properties-of-the-">Security Properties of the browser's job is Calling Page</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-communications-consent-veri">Communications Consent Verification</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.2.2">
                  <li pn="section-toc.1-1.4.2.2.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.1.1"><xref derivedContent="4.2.1" format="counter" sectionFormat="of" target="section-4.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ice">ICE</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.2.1"><xref derivedContent="4.2.2" format="counter" sectionFormat="of" target="section-4.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-masking">Masking</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.3.1"><xref derivedContent="4.2.3" format="counter" sectionFormat="of" target="section-4.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backward-compatibility">Backward Compatibility</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.2.2.4">
                    <t indent="0" pn="section-toc.1-1.4.2.2.2.4.1"><xref derivedContent="4.2.4" format="counter" sectionFormat="of" target="section-4.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ip-location-privacy">IP Location Privacy</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-communications-security">Communications Security</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2">
                  <li pn="section-toc.1-1.4.2.3.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.1.1"><xref derivedContent="4.3.1" format="counter" sectionFormat="of" target="section-4.3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protecting-against-retrospe">Protecting Against Retrospective Compromise</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.2.1"><xref derivedContent="4.3.2" format="counter" sectionFormat="of" target="section-4.3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protecting-against-during-c">Protecting Against During-Call Attack</xref></t>
                    <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.3.2.2.2">
                      <li pn="section-toc.1-1.4.2.3.2.2.2.1">
                        <t indent="0" pn="section-toc.1-1.4.2.3.2.2.2.1.1"><xref derivedContent="4.3.2.1" format="counter" sectionFormat="of" target="section-4.3.2.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-key-continuity">Key Continuity</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.3.2.2.2.2">
                        <t indent="0" pn="section-toc.1-1.4.2.3.2.2.2.2.1"><xref derivedContent="4.3.2.2" format="counter" sectionFormat="of" target="section-4.3.2.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-short-authentication-string">Short Authentication Strings</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.3.2.2.2.3">
                        <t indent="0" pn="section-toc.1-1.4.2.3.2.2.2.3.1"><xref derivedContent="4.3.2.3" format="counter" sectionFormat="of" target="section-4.3.2.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-third-party-identity">Third-Party Identity</xref></t>
                      </li>
                      <li pn="section-toc.1-1.4.2.3.2.2.2.4">
                        <t indent="0" pn="section-toc.1-1.4.2.3.2.2.2.4.1"><xref derivedContent="4.3.2.4" format="counter" sectionFormat="of" target="section-4.3.2.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-page-access-to-media">Page Access to protect Media</xref></t>
                      </li>
                    </ul>
                  </li>
                  <li pn="section-toc.1-1.4.2.3.2.3">
                    <t indent="0" pn="section-toc.1-1.4.2.3.2.3.1"><xref derivedContent="4.3.3" format="counter" sectionFormat="of" target="section-4.3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-malicious-peers">Malicious Peers</xref></t>
                  </li>
                </ul>
              </li>
              <li pn="section-toc.1-1.4.2.4">
                <t indent="0" pn="section-toc.1-1.4.2.4.1"><xref derivedContent="4.4" format="counter" sectionFormat="of" target="section-4.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-privacy-considerations">Privacy Considerations</xref></t>
                <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2.4.2">
                  <li pn="section-toc.1-1.4.2.4.2.1">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.1.1"><xref derivedContent="4.4.1" format="counter" sectionFormat="of" target="section-4.4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-correlation-of-anonymous-ca">Correlation of Anonymous Calls</xref></t>
                  </li>
                  <li pn="section-toc.1-1.4.2.4.2.2">
                    <t indent="0" pn="section-toc.1-1.4.2.4.2.2.1"><xref derivedContent="4.4.2" format="counter" sectionFormat="of" target="section-4.4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-browser-fingerprinting">Browser Fingerprinting</xref></t>
                  </li>
                </ul>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.7.2">
              <li pn="section-toc.1-1.7.2.1">
                <t indent="0" pn="section-toc.1-1.7.2.1.1"><xref derivedContent="7.1" format="counter" sectionFormat="of" target="section-7.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.7.2.2">
                <t indent="0" pn="section-toc.1-1.7.2.2.1"><xref derivedContent="7.2" format="counter" sectionFormat="of" target="section-7.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-address">Author's Address</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section anchor="sec.introduction" numbered="true" toc="include" removeInRFC="false" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">
        The Real-Time Communications on the user.
        Huang et al. Web (RTCWEB) Working Group has standardized
        protocols for real-time communications between Web browsers, generally
        called "WebRTC" <xref target="huang-w2sp"/> summarize the core browser security guarantee as:
      </t>
      <t>
        <list style="hanging">
          <t>
            Users can safely visit arbitrary web sites and execute scripts provided by those sites.
          </t>
        </list>
      </t>
      <t></t>
      <t>
        It is important to realize that this includes sites hosting arbitrary malicious
        scripts. target="RFC8825" format="default" sectionFormat="of" derivedContent="RFC8825"/>. The motivation for this requirement is simple: it is trivial
        major use cases for attackers
        to divert users to sites of their choice. For instance, an attacker can purchase
        display advertisements which WebRTC technology are real-time audio and/or video calls,
        Web conferencing, and direct the user (either automatically or via user
        clicking) to their site, at which point the browser will execute the attacker's
        scripts. Thus, it is important that it be safe to view arbitrarily malicious pages.
        Of course, browsers inevitably have bugs which cause them to fall short of this
        goal, but any new data transfer. Unlike most conventional real-time systems
        (e.g., SIP-based <xref target="RFC3261" format="default" sectionFormat="of" derivedContent="RFC3261"/> soft
        phones), WebRTC functionality must be designed with the intent to
        meet this standard. The remainder of this section provides more background
        on the existing communications are directly controlled by some Web security model.
        server. A simple case is shown below.
      </t>
      <t>
      <figure anchor="fig.simple" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-a-simple-webrtc-system">A Simple WebRTC System</name>
        <artwork name="" type="" align="left" alt="" pn="section-1-2.1">
                          +----------------+
                          |                |
                          |   Web Server   |
                          |                |
                          +----------------+
                              ^        ^
                             /          \
                    HTTPS   /            \   HTTPS
                      or   /              \   or
               WebSockets /                \ WebSockets
                         v                  v
                      JS API              JS API
                +-----------+            +-----------+
                |           |    Media   |           |
                |  Browser  |&lt;----------&gt;|  Browser  |
                |           |            |           |
                +-----------+            +-----------+
                    Alice                     Bob </artwork>
      </figure>
      <t indent="0" pn="section-1-3">
        In this model, then, the browser acts as a Trusted Coomputing Base (TCB) system shown in <xref target="fig.simple" format="default" sectionFormat="of" derivedContent="Figure 1"/>, Alice and Bob both
        from the user's perspective have
        WebRTC-enabled browsers and to they visit some extent from the server's. While HTML
        and Web server which operates a
        calling service. Each of their browsers exposes standardized JavaScript
        (JS) provided calling APIs (implemented as browser built-ins)
        which are used by the Web server can cause the browser to execute a variety of
        actions, those scripts operate in set up a sandbox that isolates them both from
        the user's computer call between Alice and from each other, Bob.
        The Web server also serves as detailed below.
      </t>
      <t>
        Conventionally, we refer to either web attackers, who are able to induce
        you to visit their sites but do not control the network, and network
        attackers, who are able signaling channel to transport
        control your network. Network attackers correspond
        to messages between the <xref target="RFC3552"/> "Internet Threat Model". Note that in some
        cases, a network attacker browsers.
        While this system is also topologically similar to a web attacker, since transport protocols
        that do not provide integrity protection allow conventional SIP-based
        system (with the network to inject traffic Web server acting as if they were any communications peer. TLS, the signaling service and HTTPS in particular, prevent
        against these attacks, but when analyzing HTTP connections, we must assume
        that traffic is going browsers
        acting as softphones), control has moved to the attacker.
      </t>
      <section title="Access to Local Resources" anchor="sec.resources">
        <t>
          While central Web server;
        the browser has access to local resources such as keying material,
          files, simply provides API points that are used by the camera, calling service.
        As with any Web application, the Web server can move logic between
        the server and JavaScript in the microphone, browser, but regardless of where the
        code is executing, it strictly limits or forbids web
          servers from accessing is ultimately under control of the server.
      </t>
      <t indent="0" pn="section-1-4">
        It should be immediately apparent that this type of system poses new
        security challenges beyond those same resources. For instance, while of a conventional Voice over IP (VoIP) system. In particular,
        it is possible needs to produce an HTML form which will allow file upload, a script cannot do
          so without user consent and in fact cannot even suggest a specific file
          (e.g., /etc/passwd); contend with malicious calling services.
        For example, if the user must explicitly select calling service
        can cause the file and consent browser to its upload. [Note: in many cases browsers are explicitly designed make a call at any time to
          avoid dialogs with the semantics any callee of "click here its
        choice, then this facility can be used to bypass security checks", as
          extensive research <xref target="cranor-wolf"/> shows that users are prone bug a user's computer without
        their knowledge, simply by placing a call to
          consent under such circumstances.]
        </t>
        <t>
          Similarly, while Flash programs (SWFs) <xref target="SWF"/> can access some recording service.
        More subtly, if the camera and microphone, they
          explicitly require that exposed APIs allow the user consent server to that access. In addition,
          some resources simply cannot be accessed from instruct the
        browser at all. For
          instance, there is no real way to run specific executables directly from a
          script (though the user send arbitrary content, then they can of course be induced used to download executable
          files bypass
        firewalls or mount denial-of-service (DoS) attacks. Any successful system
        will need to be resistant to this and run them).
        </t>
      </section>
      <section title="Same-Origin Policy" anchor="sec.same-origin">
        <t>
          Many other resources are accessible but isolated. For instance,
          while scripts are allowed attacks.
      </t>
      <t indent="0" pn="section-1-5">
        A companion document <xref target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827"/> describes a security
        architecture intended to make HTTP requests via address the XMLHttpRequest() API (see <xref target="XmlHttpRequest"/>)
          those requests issues raised in this document.
      </t>
    </section>
    <section anchor="sec-term" numbered="true" toc="include" removeInRFC="false" pn="section-2">
      <name slugifiedName="name-terminology">Terminology</name>
      <t indent="0" pn="section-2-1">The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
    "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>",
    "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are not allowed
    to be made to any server, but rather solely
          to the same ORIGIN from whence the script came <xref target="RFC6454"/>
          (although CORS interpreted as described in BCP 14 <xref target="CORS"/> target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/>
        <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and WebSockets
          <xref target="RFC6455"/> provide an escape hatch from this restriction, only when, they appear in all capitals,
    as described below.)
          This SAME ORIGIN POLICY (SOP) prevents server A shown here.</t>
    </section>
    <section anchor="sec.web-security" numbered="true" toc="include" removeInRFC="false" pn="section-3">
      <name slugifiedName="name-the-browser-threat-model">The Browser Threat Model</name>
      <t indent="0" pn="section-3-1">
        The security requirements for WebRTC follow directly from mounting attacks
          on server B via the user's browser, which protects both
        requirement that the user
          (e.g., from misuse of his credentials) and the server B (e.g., from
          DoS attack).
        </t>
        <t>
          More generally, SOP forces scripts from each site to run in their own, isolated,
          sandboxes. While there are techniques to allow them to interact, those interactions
          generally must be mutually consensual (by each site) and are limited browser's job is to certain
          channels. For instance, multiple pages/browser panes from the same origin
          can read each other's JS variables, but pages from protect the different origins--or
          even iframes from different origins on user.
        Huang et al. <xref target="huang-w2sp" format="default" sectionFormat="of" derivedContent="huang-w2sp"/> summarize
        the same page--cannot. core browser security guarantee as follows:
      </t>
        <!-- TODO: Picture -->

      </section>
      <section title="Bypassing SOP: CORS, WebSockets,
      <t indent="3" pn="section-3-2">Users can safely visit arbitrary web sites and consent to communicate" anchor="sec.cors-etc">
        <t>
          While SOP serves an execute scripts provided by those sites.</t>
      <t indent="0" pn="section-3-3">
        It is important security function, it also makes to realize that this includes sites hosting arbitrary malicious
        scripts. The motivation for this requirement is simple: it inconvenient is trivial for attackers
        to
          write certain classes divert users to sites of applications. In particular, mash-ups, in which a script
          from origin A uses resources from origin B, their choice. For instance, an attacker can only be achieved purchase
        display advertisements which direct the user (either automatically or via a certain amount of hackery.
          The W3C Cross-Origin Resource Sharing (CORS) spec <xref target="CORS"/> is a response user
        clicking) to this
          demand. In CORS, when a script from origin A executes what would otherwise be a forbidden
          cross-origin request, their site, at which point the browser instead contacts will execute the target server to determine
          whether attacker's
        scripts. Thus, it is willing to allow cross-origin requests from A. If important that it is so willing,
          the browser then allows the request. This consent verification process is designed be safe to safely allow cross-origin requests.
        </t>
        <t>
          While CORS is view arbitrarily malicious pages.
        Of course, browsers inevitably have bugs which cause them to fall short of this
        goal, but any new WebRTC functionality must be designed with the intent to allow cross-origin HTTP requests, WebSockets <xref target="RFC6455"/> allows
          cross-origin establishment
        meet this standard. The remainder of transparent channels. Once this section provides more background
        on the existing Web security model.
      </t>
      <t indent="0" pn="section-3-4">
        In this model, then, the browser acts as a WebSockets connection
          has been established Trusted Computing Base (TCB) both
        from a script the user's perspective and to a site, some extent from the script server's. While HTML
        and JavaScript provided by the server can exchange any traffic it
          likes without being required cause the browser to frame it as execute a series variety of HTTP request/response
          transactions. As with CORS, a WebSockets transaction starts with
        actions, those scripts operate in a consent verification
          stage sandbox that isolates them both from
        the user's computer and from each other, as detailed below.
      </t>
      <t indent="0" pn="section-3-5">
        Conventionally, we refer to avoid allowing scripts either Web attackers, who are able to simply send arbitrary data induce
        you to another origin.
        </t>
        <t>
          While consent verification is conceptually simple--just visit their sites but do a handshake before you
          start exchanging not control the real data--experience has shown network, or network
        attackers, who are able to control your network.
        Network attackers correspond
        to the <xref target="RFC3552" format="default" sectionFormat="of" derivedContent="RFC3552"/> "Internet Threat Model". Note that designing in some
        cases, a
          correct consent verification system network attacker is difficult. In particular, Huang et al. <xref target="huang-w2sp"/>
          have shown vulnerabilities in the existing Java and Flash consent verification
          techniques and in also a simplified version of Web attacker, since transport protocols
        that do not provide integrity protection allow the WebSockets handshake. In particular,
          it is important network to be wary of CROSS-PROTOCOL attacks inject traffic
        as if they were any communications peer. TLS, and HTTPS in which the attacking script
          generates particular, prevent
        against these attacks, but when analyzing HTTP connections, we must assume
        that traffic which is acceptable to some non-Web protocol state machine.
          In order to resist this form of attack, WebSockets incorporates a masking technique
          intended going to randomize the bits on the wire, thus making it more difficult to generate
          traffic which resembles a given protocol. attacker.
      </t>
      </section>
    </section>
      <section title="Security for WebRTC Applications" anchor="sec.rtc-web">
      <section title="Access anchor="sec.resources" numbered="true" toc="include" removeInRFC="false" pn="section-3.1">
        <name slugifiedName="name-access-to-local-resources">Access to Local Devices" anchor="sec.rtc-dev-access">
        <t>
          As discussed in <xref target="sec.introduction"/>, allowing arbitrary
          sites to initiate calls violates Resources</name>
        <t indent="0" pn="section-3.1-1">
          While the core Web security guarantee;
          without some browser has access restrictions on to local devices, any malicious site
          could simply bug a user. At minimum, then, resources such as keying material,
          files, the camera, and the microphone, it MUST NOT be strictly limits or forbids Web
          servers from accessing those same resources. For instance, while it is possible for
          arbitrary sites to initiate calls
          to arbitrary locations produce an HTML form which will allow file upload, a script cannot do
          so without user
          consent. This immediately raises the question, however, of what should
          be consent and in fact cannot even suggest a specific file
          (e.g., /etc/passwd); the scope of user consent.
        </t>
        <t>
          In order for must explicitly select the user to
          make an intelligent decision about whether to allow a call
          (and hence his camera file and microphone input consent
          to be routed somewhere),
          he must understand either who is requesting access, where the media
          is going, or both. As detailed below, there are two basic conceptual
          models:
        </t>
        <t>
          <list style="numbers">
            <t>You its upload. (Note: In many cases, browsers are sending your media to entity A because you want explicitly designed to
            talk
          avoid dialogs with the semantics of "click here to Entity A (e.g., your mother).</t>
            <t>Entity A (e.g., a calling service) asks bypass security checks", as
          extensive research <xref target="cranor-wolf" format="default" sectionFormat="of" derivedContent="cranor-wolf"/> shows that users are prone to
          consent under such circumstances.)
        </t>
        <t indent="0" pn="section-3.1-2">
          Similarly, while Flash programs (SWFs) <xref target="SWF" format="default" sectionFormat="of" derivedContent="SWF"/> can access the user's devices with the assurance camera and microphone, they
          explicitly require that it will transfer the media user consent to entity B (e.g., your mother)</t>
          </list>
        </t>
        <t> that access. In either case, identity is at the heart of any consent decision.
          Moreover, the identity of the party addition,
          some resources simply cannot be accessed from the browser at all. For
          instance, there is connecting no real way to is all that run specific executables directly from a
          script (though the browser user can meaningfully enforce;
          if you of course be induced to download executable
          files and run them).
        </t>
      </section>
      <section anchor="sec.same-origin" numbered="true" toc="include" removeInRFC="false" pn="section-3.2">
        <name slugifiedName="name-same-origin-policy">Same-Origin Policy</name>
        <t indent="0" pn="section-3.2-1">
          Many other resources are calling A, A can simply forward the media accessible but isolated.
          For instance,
          while scripts are allowed to C. Similarly,
          if you authorize A make HTTP requests via the fetch() API (see <xref target="fetch" format="default" sectionFormat="of" derivedContent="fetch"/>)
          when requests are made to place a call to B, A can call C instead.
          In either cases, all server other than from
          the browser is same <strong>origin</strong> from whence the script came <xref target="RFC6454" format="default" sectionFormat="of" derivedContent="RFC6454"/>
          they are not able to do is verify and check
          authorization for whoever is controlling where read the media goes.
          The target of the media can of course advertise a security/privacy
          policy, but responses. Cross-Origin Resource Sharing (CORS) <xref target="fetch" format="default" sectionFormat="of" derivedContent="fetch"/> and WebSockets
          <xref target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> provide an escape hatch from this is not something that restriction,
          as described below.
          This same-origin policy (SOP) prevents server A from mounting attacks
          on server B via the browser can
          enforce. Even so, there are a variety of different consent scenarios
          that motivate different technical consent mechanisms.
          We discuss these mechanisms in user's browser, which protects both the sections below. user
          (e.g., from misuse of their credentials) and server B (e.g., from
          DoS attacks).
        </t>
        <t>
          It's important
        <t indent="0" pn="section-3.2-2">
          More generally, SOP forces scripts from each site to understand that consent run in their own, isolated,
          sandboxes. While there are techniques to access local devices
          is largely orthogonal allow them to consent interact, those interactions
          generally must be mutually consensual (by each site) and are limited to transmit various kinds of
          data over the network (see <xref target="sec.rtc-comm-consent"/>).
          Consent for device access is largely a matter of protecting
          the user's privacy certain
          channels. For instance, multiple pages/browser panes from malicious sites. By contrast,
          consent to send network traffic is about preventing the
          user's browser same origin
          can read each other's JS variables, but pages from being used to attack its local network.
          Thus, we need to ensure communications consent different
          origins -- or
          even if the
          site is not able to access IFRAMEs from different origins on the camera and microphone at
          all (hence WebSockets's consent mechanism) same page -- cannot.
        </t>
      </section>
      <section anchor="sec.cors-etc" numbered="true" toc="include" removeInRFC="false" pn="section-3.3">
        <name slugifiedName="name-bypassing-sop-cors-websocke">Bypassing SOP: CORS, WebSockets, and similarly
          we need Consent to be concerned with the site accessing the
          user's camera and microphone even if the data is Communicate</name>
        <t indent="0" pn="section-3.3-1">
          While SOP serves an important security function, it also makes it inconvenient to
          write certain classes of applications. In particular, mash-ups, in which a script
          from origin A uses resources from origin B, can only be
          sent back to the site achieved via conventional HTTP-based network
          mechanisms such as HTTP POST.
        </t>
        <section title="Threats from Screen Sharing">
          <t>
            In addition to camera and microphone access, there has been
            demand for screen and/or application sharing functionality.
            Unfortunately, the security implications of this
            functionality are much harder for users to intuitively
            analyze than for camera and microphone access.
            (See http://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html
            for a full analysis.)
          </t>
          <t>
            The most obvious threats are simply those certain amount of "oversharing".
            I.e., the user may believe they are sharing a window when
            in fact they are sharing an application, or may forget they
            are sharing their whole screen, icons, notifications, and all.
            This is already an issue with existing screen sharing technologies
            and hackery.
          The W3C CORS spec <xref target="fetch" format="default" sectionFormat="of" derivedContent="fetch"/> is made somewhat worse if a partially trusted site is responsible for asking
            for the resource response to be shared rather than having the user propose it.
          </t>
          <t> this
          demand. In CORS, when a script from origin A less obvious threat involves the impact of screen sharing on executes a potentially unsafe
          cross-origin request, the
            Web security model. A key part of browser instead contacts the Same-Origin Policy target server to determine
          whether it is that
            HTML or JS from site A can reference content willing to allow cross-origin requests from site B and cause A. If it is so willing,
          the browser then allows the request. This consent verification process is designed
          to load it, but (unless explicitly permitted) cannot
            see the result. However, if safely allow cross-origin requests.
        </t>
        <t indent="0" pn="section-3.3-2">
          While CORS is designed to allow cross-origin HTTP requests, WebSockets <xref target="RFC6455" format="default" sectionFormat="of" derivedContent="RFC6455"/> allows
          cross-origin establishment of transparent channels. Once a web application WebSockets connection
          has been established from a site is
            screen sharing script to a site, the browser, then this violates that invariant, script can exchange any traffic it
          likes without being required to frame it as a series of HTTP request/response
          transactions. As with serious security consequences. For example, an attacker site
            might request screen sharing and then briefly open up CORS, a new
            Window WebSockets transaction starts with a consent verification
          stage to the user's bank or webmail account, using screen sharing avoid allowing scripts to read the resulting displayed content. A more sophisticated
            attack would be open up a source view window simply send arbitrary data to another origin.
        </t>
        <t indent="0" pn="section-3.3-3">
          While consent verification is conceptually simple -- just do a site and use handshake before you
          start exchanging the
            screen sharing result to view anti cross-site request forgery tokens.
          </t>
          <t>
            These threats suggest real data -- experience has shown that screen/application sharing might need designing a higher level of user
          correct consent than access to verification system is difficult. In particular, Huang et al. <xref target="huang-w2sp" format="default" sectionFormat="of" derivedContent="huang-w2sp"/>
          have shown vulnerabilities in the camera or
            microphone.
          </t>
        </section>
        <section title="Calling Scenarios existing Java and Flash consent verification
          techniques and User Expectations">
          <t>
            While a large number of possible calling scenarios are possible, the
            scenarios discussed in this section illustrate many a simplified version of the difficulties WebSockets handshake. It is important to be wary of identifying CROSS-PROTOCOL attacks in which the relevant scope of consent.
          </t>
          <section title="Dedicated Calling Services">
            <t>
              The first scenario we consider attacking script
          generates traffic which is a dedicated calling service. acceptable to some non-Web protocol state machine.
          In order to resist this
              case, the user has a relationship with form of attack, WebSockets incorporates a calling site
              and repeatedly makes calls on it. It is likely
              that rather than having masking technique
          intended to give permission for each call
              that randomize the user will want to give bits on the calling service long-term
              access wire, thus making it more difficult to the camera and microphone. This is generate
          traffic which resembles a natural fit given protocol.
        </t>
      </section>
    </section>
    <section anchor="sec.rtc-web" numbered="true" toc="include" removeInRFC="false" pn="section-4">
      <name slugifiedName="name-security-for-webrtc-applica">Security for a long-term consent mechanism (e.g., installing an
              app store "application" WebRTC Applications</name>
      <section anchor="sec.rtc-dev-access" numbered="true" toc="include" removeInRFC="false" pn="section-4.1">
        <name slugifiedName="name-access-to-local-devices">Access to indicate permission for the
              calling service.)
              A variant of Local Devices</name>
        <t indent="0" pn="section-4.1-1">
          As discussed in <xref target="sec.introduction" format="default" sectionFormat="of" derivedContent="Section 1"/>, allowing arbitrary
          sites to initiate calls violates the dedicated calling service is a gaming core Web security guarantee;
          without some access restrictions on local devices, any malicious site
              (e.g., a poker site) which hosts
          could simply bug a dedicated calling service user. At minimum, then, it <bcp14>MUST NOT</bcp14> be possible for
          arbitrary sites to allow players initiate calls to call each other.
            </t>
            <t>
              With any kind arbitrary locations without user
          consent. This immediately raises the question, however, of service where what should
          be the scope of user may use consent.
        </t>
        <t indent="0" pn="section-4.1-2">
          In order for the same
              service to talk user to many different people, there is a question
          make an intelligent decision about whether the user can know who they are talking to.
              If I grant permission to calling service A allow a call
          (and hence their camera and microphone input to make calls
              on my behalf, then I am implicitly granting it permission
              to bug my computer whenever it wants. This suggests another
              consent model in which a site be routed somewhere),
          they must understand either who is authorized to make calls
              but only to certain target entities (identified via
              media-plane cryptographic mechanisms as described in
              <xref target="sec.during-attack"/> and especially
              <xref target="sec.third-party-id"/>.) Note that requesting access, where the
              question of consent here media
          is related going, or both. As detailed below, there are two basic conceptual
          models:
        </t>
        <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1-3">
          <li pn="section-4.1-3.1" derivedCounter="1.">You are sending your media to but
              distinct from the question of peer identity: I
              might be willing entity A because you want to allow
            talk to entity A (e.g., your mother).</li>
          <li pn="section-4.1-3.2" derivedCounter="2.">Entity A (e.g., a calling site service) asks to in general
              initiate calls on my behalf but still have some calls
              via that site where I can be sure that the site is not
              listening in.
            </t>
          </section>
          <section title="Calling access the Site You're On">
            <t>
              Another simple scenario is calling user's devices with the site you're actually visiting.
              The paradigmatic case here is assurance
            that it will transfer the "click here to talk media to a
              representative" windows that appear on many shopping sites. entity B (e.g., your mother).</li>
        </ol>
        <t indent="0" pn="section-4.1-4">
          In this either case, identity is at the user's expectation heart of any consent decision.
          Moreover, the identity of the party the browser is connecting to is all that they the browser can meaningfully enforce;
          if you are calling A, A can simply forward the site they're actually visiting. However, it is
              unlikely that they want media to provide a general consent C. Similarly,
          if you authorize A to such
              a site; just because I want some information on place a car
              doesn't mean that I want the car manufacturer call to be B, A can call C instead.
          In either case, all the browser is able to activate my microphone whenever they please. Thus,
              this suggests the need do is verify and check
          authorization for a second consent mechanism whoever is controlling where I only grant consent for the duration media goes.
          The target of a given
              call. As described in <xref target="sec.resources"/>,
              great care must be taken in the design media can of course advertise a security/privacy
          policy, but this interface
              to avoid the users just clicking through. Note also
              that the user interface chrome, which is the representation
              through which the user interacts with the user agent itself,
              must clearly display elements
              showing not something that the call is continuing in order to avoid attacks
              where the calling site just leaves it up indefinitely but
              shows browser can
          enforce. Even so, there are a Web UI that implies otherwise.
            </t>
          </section>
        </section>
        <section title="Origin-Based Security">
        <t>
          Now variety of different consent scenarios
          that we have described the calling scenarios, we can start to reason about
          the security requirements.
        </t>
        <t>
          As discussed motivate different technical consent mechanisms.
          We discuss these mechanisms in <xref target="sec.same-origin"/>, the basic unit of
          Web sandboxing is the origin, and so it is natural sections below.
        </t>
        <t indent="0" pn="section-4.1-5">
          It's important to scope understand that consent to origin. Specifically, a script from origin A MUST only be allowed access local devices
          is largely orthogonal to initiate communications (and hence consent to access camera and microphone)
          if transmit various kinds of
          data over the user has specifically authorized access network (see <xref target="sec.rtc-comm-consent" format="default" sectionFormat="of" derivedContent="Section 4.2"/>).
          Consent for that origin.
          It device access is largely a matter of course technically possible to have coarser-scoped permissions,
          but because protecting
          the Web model is scoped user's privacy from malicious sites. By contrast,
          consent to origin, this creates a difficult
          mismatch.
        </t>
        <t>
          Arguably, origin send network traffic is not fine-grained enough. Consider about preventing the situation where
          Alice visits a site and authorizes it
          user's browser from being used to make a single call. If attack its local network.
          Thus, we need to ensure communications consent even if the
          site is
          expressed solely in terms of origin, then not able to access the camera and microphone at any future visit
          all (hence WebSockets's consent mechanism) and similarly,
          we need to that
          site (including one induced via mash-up or ad network), be concerned with the site can
          bug Alice's computer, use accessing the computer to place bogus calls, etc.
          While in principle Alice could grant
          user's camera and then
          revoke the privilege, in practice privileges accumulate; microphone even if we are concerned
          about this attack, something else the data is needed. There are a number of potential countermeasures to
          this sort of issue. be
          sent back to the site via conventional HTTP-based network
          mechanisms such as HTTP POST.
        </t>
        <t><list style="hanging">
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.1">
          <name slugifiedName="name-threats-from-screen-sharing">Threats from Screen Sharing</name>
          <t hangText="Individual Consent"></t><t>Ask the user indent="0" pn="section-4.1.1-1">
            In addition to camera and microphone access, there has been
            demand for permission screen and/or application sharing functionality.
            Unfortunately, the security implications of this
            functionality are much harder for each call.</t>
          <t></t>
          <t hangText="Callee-oriented Consent"></t><t>Only allow calls users to intuitively
            analyze than for camera and microphone access.
            (See <eref brackets="angle" target="https://lists.w3.org/Archives/Public/public-webrtc/2013Mar/0024.html"/>
            for a given user.</t>
          <t></t> full analysis.)
          </t>
          <t hangText="Cryptographic Consent"></t><t>Only allow calls to a given set indent="0" pn="section-4.1.1-2">
            The most obvious threats are simply those of peer keying material or
          to "oversharing".
            I.e., the user may believe they are sharing a cryptographically established identity.</t>
        </list>
        </t>
        <t>
          Unfortunately, none of these approaches window when
            in fact they are sharing an application, or may forget they
            are sharing their whole screen, icons, notifications, and all.
            This is satisfactory already an issue with existing screen sharing technologies
            and is made somewhat worse if a partially trusted site is responsible for all cases.
          As discussed above, individual consent puts the user's approval
          in the UI flow asking
            for every call. Not only does this quickly become annoying
          but it can train the user resource to simply click "OK", at which point the consent becomes
          useless. Thus, while it may be necessary to have individual consent in some
          case, this is not a suitable solution for (for instance) shared rather than having the calling
          service case. Where necessary, in-flow user interfaces must be carefully
          designed to avoid propose it.
          </t>
          <t indent="0" pn="section-4.1.1-3">
            A less obvious threat involves the risk impact of screen sharing on the user blindly clicking through.
        </t>
        <t>
          The other two options are designed to restrict calls to a given target.
          Callee-oriented consent provided by
            Web security model. A key part of the calling site
          would not work well because a malicious Same-Origin Policy is that
            HTML or JS from site A can claim that reference content from site B and cause
            the
          user is calling any user of his choice. One fix for this is to tie calls browser to load it, but (unless explicitly permitted) cannot
            see the result. However, if a
          cryptographically-established identity. While not suitable for all cases,
          this approach may be useful for some. If we consider Web application from a site is
            screen sharing the case
          of advertising, it's not particularly convenient
          to require the advertiser to instantiate browser, then this violates that invariant,
            with serious security consequences. For example, an iframe on the hosting attacker site just
          to get permission;
            might request screen sharing and then briefly open up a more convenient approach is new
            window to cryptographically tie the advertiser's certificate user's bank or webmail account, using screen sharing
            to read the communication directly. We're still
          tying permissions resulting displayed content. A more sophisticated
            attack would be to origin here, but open up a source view window to a site and use the media origin (and-or destination)
          rather
            screen sharing result to view anti-cross-site request forgery tokens.
          </t>
          <t indent="0" pn="section-4.1.1-4">
            These threats suggest that screen/application sharing might need
            a higher level of user consent than access to the Web origin. <xref target="I-D.ietf-rtcweb-security-arch"/>
          describes mechanisms
          which facilitate camera or
            microphone.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2">
          <name slugifiedName="name-calling-scenarios-and-user-">Calling Scenarios and User Expectations</name>
          <t indent="0" pn="section-4.1.2-1">
            While a large number of possible calling scenarios are possible, the
            scenarios discussed in this sort section illustrate many of
            the difficulties of identifying the relevant scope of consent.
          </t>
        <t>
          Another case where media-level cryptographic identity makes sense
          <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2.1">
            <name slugifiedName="name-dedicated-calling-services">Dedicated Calling Services</name>
            <t indent="0" pn="section-4.1.2.1-1">
              The first scenario we consider is when a user
          really does not trust dedicated calling service. In this
              case, the user has a relationship with a calling site. For instance, I might be worried site
              and repeatedly makes calls on it. It is likely
              that rather than having to give permission for each call,
              the calling service user will attempt to bug my computer, but I also want to be
          able to conveniently call my friends. If consent is tied give the calling service long-term
              access to particular
          communications endpoints, then my risk the camera and microphone. This is limited. Naturally, it
          is somewhat challenging a natural fit
              for a long-term consent mechanism (e.g., installing an
              app store "application" to design UI primitives which express this sort
          of policy. The problem becomes even more challenging in multi-user indicate permission for the
              calling cases.
        </t>
        </section>

        <section title="Security Properties service).
              A variant of the Calling Page">
        <t>
          Origin-based security dedicated calling service is intended a gaming site
              (e.g., a poker site) which hosts a dedicated calling service
              to secure against web attackers. However, we must
          also consider the case allow players to call each other.
            </t>
            <t indent="0" pn="section-4.1.2.1-2">
              With any kind of network attackers. Consider the case service where I have
          granted permission the user may use the same
              service to talk to many different people, there is a calling service by an origin that has question
              about whether the HTTP scheme,
          e.g., http://calling-service.example.com. user can know who they are talking to.
              If I ever use my computer grant permission to calling service A to make calls
              on
          an unsecured network (e.g., a hotspot or if my own home wireless network
          is insecure), and browse any HTTP site, behalf, then an attacker can I am implicitly granting it permission
              to bug my computer. The attack proceeds
          like this:
        </t>
        <t>
          <list style="numbers">
            <t>I connect computer whenever it wants. This suggests another
              consent model in which a site is authorized to http://anything.example.org/. make calls
              but only to certain target entities (identified via
              media-plane cryptographic mechanisms as described in
              <xref target="sec.during-attack" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/> and especially
              <xref target="sec.third-party-id" format="default" sectionFormat="of" derivedContent="Section 4.3.2.3"/>). Note that this site the
              question of consent here is unaffiliated
            with related to but
              distinct from the calling service.</t>
            <t>The attacker modifies my HTTP connection question of peer identity: I
              might be willing to inject an IFRAME (or allow a redirect) calling site to http://calling-service.example.com</t>
            <t>The attacker forges in general
              initiate calls on my behalf but still have some calls
              via that site where I can be sure that the response from  http://calling-service.example.com/ site is not
              listening in.
            </t>
          </section>
          <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.2.2">
            <name slugifiedName="name-calling-the-site-youre-on">Calling the Site You're On</name>
            <t indent="0" pn="section-4.1.2.2-1">
              Another simple scenario is calling the site you're actually visiting.
              The paradigmatic case here is the "click here to
            inject JS talk to initiate a call to himself.</t>
          </list>
        </t>
        <t>
          Note
              representative" windows that this attack does not depend appear on many shopping sites.
              In this case, the media being insecure. Because the
          call user's expectation is to that they are
              calling the attacker, site they're actually visiting. However, it is also encrypted
              unlikely that they want to him. Moreover, it need not
          be executed immediately; the attacker can "infect" the origin semi-permanently
          (e.g., with provide a web worker or general consent to such
              a popped-up window site; just because I want some information on a car
              doesn't mean that is hidden under I want the main window.)
          and thus car manufacturer to be able
              to bug me long
          after I have left activate my microphone whenever they please. Thus,
              this suggests the infected network. This risk is created by allowing
          calls at all from need for a page fetched over HTTP.
        </t>
        <t>
          Even if calls are second consent mechanism
              where I only possible from HTTPS [RFC2818] sites,
          if those sites include active content (e.g., JavaScript) from an untrusted
          site, that JavaScript is executed in the security context of grant consent for the page
          <xref target="finer-grained"/>. This could lead to compromise duration of a call
          even if given
              call. As described in <xref target="sec.resources" format="default" sectionFormat="of" derivedContent="Section 3.1"/>,
              great care must be taken in the parent page is safe. Note: design of this issue is not restricted interface
              to PAGES avoid the users just clicking through. Note also
              that the user interface chrome, which contain untrusted content. If any page from a
          given origin ever loads JavaScript from an attacker, then it is
          possible for the representation
              through which the user interacts with the user agent itself,
              must clearly display elements
              showing that attacker the call is continuing in order to infect avoid attacks
              where the browser's notion of calling site just leaves it up indefinitely but
              shows a Web UI that
          origin semi-permanently. implies otherwise.
            </t>
          </section>
        </section>
        <section title="Communications Consent Verification" anchor="sec.rtc-comm-consent">
        <t> numbered="true" toc="include" removeInRFC="false" pn="section-4.1.3">
          <name slugifiedName="name-origin-based-security">Origin-Based Security</name>
          <t indent="0" pn="section-4.1.3-1">
          Now that we have described the calling scenarios, we can start to reason about
          the security requirements.
          </t>
          <t indent="0" pn="section-4.1.3-2">
          As discussed in <xref target="sec.cors-etc"/>, allowing web applications unrestricted network access
          via the browser introduces target="sec.same-origin" format="default" sectionFormat="of" derivedContent="Section 3.2"/>, the risk basic unit of using the browser as an attack platform against
          machines which would not otherwise be accessible to
          Web sandboxing is the malicious site, for
          instance because they are topologically restricted (e.g., behind a firewall or NAT).
          In order to prevent this form of attack as well as cross-protocol attacks origin, and so it is
          important natural to require that the target of traffic explicitly scope consent
          to receiving the traffic in question. Until that consent has been verified for origin. Specifically, a given endpoint,
          traffic other than the consent handshake MUST NOT script from origin A <bcp14>MUST</bcp14> only be sent allowed
          to initiate communications (and hence to access the camera and microphone)
          if the user has specifically authorized access for that endpoint.
        </t>
        <t>
          Note that consent verification origin.
          It is not sufficient to prevent overuse of
          network resources. Because WebRTC allows for a course technically possible to have coarser-scoped permissions,
          but because the Web site model is scoped to create
          data flows between two browser instances without user consent, it the origin, this creates a difficult
          mismatch.
          </t>
          <t indent="0" pn="section-4.1.3-3">
          Arguably, the origin is
          possible for not fine-grained enough. Consider the situation where
          Alice visits a malicious site and authorizes it to chew up make a significant amount single call. If consent is
          expressed solely in terms of a user's
          bandwidth without incurring significant costs the origin, then on any future visit to himself by setting
          up such that
          site (including one induced via a channel mash-up or ad network), the site can
          bug Alice's computer, use the computer to another user. However, as a practical matter
          there place bogus calls, etc.
          While in principle Alice could grant and then
          revoke the privilege, in practice privileges accumulate; if we are concerned
          about this attack, something else is needed. There are a large number of Web sites which can act as data sources,
          so an attacker can at least use downlink bandwidth with existing
          Web APIs. However, this potential DoS vector reinforces the need
          for adequate congestion control for WebRTC protocols countermeasures to ensure that
          they play fair with other demands on the user's bandwidth.
        </t>
        <section title="ICE" anchor="sec.ice">
          <t>
          Verifying receiver consent requires some
          this sort of explicit handshake, but conveniently
          we already need one in order issue.
          </t>
          <dl newline="true" spacing="normal" indent="3" pn="section-4.1.3-4">
            <dt pn="section-4.1.3-4.1">Individual Consent</dt>
            <dd pn="section-4.1.3-4.2">Ask the user for permission for each call.</dd>
            <dt pn="section-4.1.3-4.3">Callee-oriented Consent</dt>
            <dd pn="section-4.1.3-4.4">Only allow calls to do NAT hole-punching. Interactive Connectivity Establishment (ICE)  <xref target="RFC8445"/> includes a handshake
          designed given user.</dd>
            <dt pn="section-4.1.3-4.5">Cryptographic Consent</dt>
            <dd pn="section-4.1.3-4.6">Only allow calls to verify that the receiving element wishes a given set of peer keying material or
          to receive traffic from the
          sender. It a cryptographically established identity.</dd>
          </dl>
          <t indent="0" pn="section-4.1.3-5">
          Unfortunately, none of these approaches is important to remember here that the site initiating ICE is
          presumed malicious; in order satisfactory for all cases.
          As discussed above, individual consent puts the handshake to be secure user's approval
          in the
          receiving element MUST demonstrate receipt/knowledge of some value
          not available to UI flow for every call. Not only does this quickly become annoying
          but it can train the site (thus preventing user to simply click "OK", at which point the site from forging
          responses).  In order consent becomes
          useless. Thus, while it may be necessary to achieve have individual consent in some
          cases, this objective with ICE, is not a suitable solution for (for instance) the STUN
          transaction IDs calling
          service case. Where necessary, in-flow user interfaces must be generated by the browser and MUST NOT be made
          available carefully
          designed to avoid the initiating script, even via a diagnostic interface.
          Verifying receiver consent also requires verifying risk of the receiver wants user blindly clicking through.
          </t>
          <t indent="0" pn="section-4.1.3-6">
          The other two options are designed to restrict calls to receive traffic from a particular sender, and at this time; for
          example given target.
          Callee-oriented consent provided by the calling site
          would not work well because a malicious site may simply attempt ICE to known servers can claim that are using ICE the
          user is calling any user of their choice. One fix for other sessions.  ICE provides this verification
          as well, by using the STUN credentials as is to tie calls to a form
          cryptographically established identity. While not suitable for all cases,
          this approach may be useful for some. If we consider the case
          of per-session shared
          secret.  Those credentials are known advertising, it's not particularly convenient
          to require the Web application, but would
          need advertiser to also be known and used by instantiate an IFRAME on the STUN-receiving element hosting site just
          to be useful.
          </t>
          <t>
            There also needs get permission; a more convenient approach is to be some mechanism for cryptographically tie
          the browser advertiser's certificate to verify that the target of communication directly. We're still
          tying permissions to the traffic continues origin here, but to wish the media origin (and/or destination)
          rather than to receive it. Because ICE keepalives are
            indications, they will not work here. the Web origin. <xref target="RFC7675"/> target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827"/>
          describes the mechanism
            for providing consent freshness. mechanisms which facilitate this sort of consent.
          </t>
        </section>
        <section title="Masking" anchor="sec.masking">
          <t>
            Once
          <t indent="0" pn="section-4.1.3-7">
          Another case where media-level cryptographic identity makes sense is when a user
          really does not trust the calling site. For instance, I might be worried that
          the calling service will attempt to bug my computer, but I also want to be
          able to conveniently call my friends. If consent is verified, there still tied to particular
          communications endpoints, then my risk is some concern about misinterpretation
            attacks as described by Huang et al.<xref target="huang-w2sp"/>.
            Where TCP limited. Naturally, it
          is used somewhat challenging to design UI primitives which express this sort
          of policy. The problem becomes even more challenging in multi-user
          calling cases.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.1.4">
          <name slugifiedName="name-security-properties-of-the-">Security Properties of the risk Calling Page</name>
          <t indent="0" pn="section-4.1.4-1">
          Origin-based security is substantial due intended to secure against Web attackers. However, we must
          also consider the potential
            presence case of transparent proxies and therefore if TCP is to be used,
            then WebSockets style masking MUST be employed.
          </t>
          <t>
            Since DTLS (with network attackers. Consider the anti-chosen plaintext mechanisms required case where I have
          granted permission to a calling service by
            TLS 1.1) does not allow an origin that has the attacker to generate predictable
            ciphertext, there is no need for masking of protocols running over
            DTLS (e.g. SCTP over DTLS, UDP over DTLS, etc.).
          </t>
          <t>
            Note that in principle HTTP scheme,
          e.g., &lt;http://calling-service.example.com&gt;. If I ever use my computer on
          an attacker could exert some control
            over SRTP packets by using unsecured network (e.g., a combination of the WebAudio API hotspot or if my own home wireless network
          is insecure), and extremely tight timing control. browse any HTTP site, then an attacker can bug my computer. The primary risk here seems attack proceeds
          like this:
          </t>
          <ol spacing="normal" type="1" indent="adaptive" start="1" pn="section-4.1.4-2">
            <li pn="section-4.1.4-2.1" derivedCounter="1.">I connect to be carriage of SRTP over TURN TCP.
            However, as SRTP packets have an extremely characteristic packet
            header it seems unlikely &lt;http://anything.example.org/&gt;. Note that any but this site is unaffiliated
            with the most aggressive
            intermediaries would be confused into thinking that another
            application layer protocol was in use.
          </t>
        </section>
        <section title="Backward Compatibility">
          <t>
            A requirement calling service.</li>
            <li pn="section-4.1.4-2.2" derivedCounter="2.">The attacker modifies my HTTP connection to use ICE limits compatibility with legacy non-ICE clients.
            It seems unsafe inject an IFRAME (or a redirect)
            to completely remove the requirement for some check.
            All proposed checks have &lt;http://calling-service.example.com&gt;.</li>
            <li pn="section-4.1.4-2.3" derivedCounter="3.">The attacker forges the common feature response from &lt;http://calling-service.example.com/&gt; to
            inject JS to initiate a call to themselves.</li>
          </ol>
          <t indent="0" pn="section-4.1.4-3">
          Note that this attack does not depend on the browser
            sends some message media being insecure. Because the
          call is to the candidate traffic recipient
            and refuses attacker, it is also encrypted to send other traffic until that message has been
            replied to. The message/reply pair must them. Moreover, it need not
          be generated in such
            a way that an attacker who controls executed immediately; the Web application
            cannot forge them, generally by having attacker can "infect" the message contain some
            secret value that must be incorporated origin semi-permanently
          (e.g., echoed, hashed into,
            etc.). Non-ICE candidates for this role (in cases where the
            legacy endpoint has with a public address) include:
          </t>
          <t>
            <list style="symbols">
              <t>STUN checks without using ICE (i.e., the non-RTC-web endpoint sets up Web worker or a STUN responder.)</t>
              <t>Use of RTCP as an implicit reachability check.</t>
            </list>
          </t>
          <t>
            In the RTCP approach, the WebRTC endpoint popped-up window that is allowed to send
            a limited number of RTP packets prior hidden under the main window)
          and thus be able to receiving consent. bug me long
          after I have left the infected network. This
            allows a short window of attack. In addition, some legacy endpoints
            do not support RTCP, so this risk is created by allowing
          calls at all from a much more expensive solution for
            such endpoints, for which it would likely be easier to implement ICE.
            For these two reasons, page fetched over HTTP.
          </t>
          <t indent="0" pn="section-4.1.4-4">
          Even if calls are only possible from HTTPS <xref target="RFC2818" format="default" sectionFormat="of" derivedContent="RFC2818"/> sites,
          if those sites include active content (e.g., JavaScript) from an RTCP-based approach does not seem to
            address untrusted
          site, that JavaScript is executed in the security issue satisfactorily.
          </t>
          <t>
            In the STUN approach, context of the WebRTC endpoint is able page
          <xref target="finer-grained" format="default" sectionFormat="of" derivedContent="finer-grained"/>. This could lead to verify that
            the recipient is running some kind compromise of STUN endpoint but unless a call
          even if the STUN responder parent page is integrated with the ICE username/password
            establishment system, the WebRTC endpoint cannot verify that
            the recipient consents to this particular call. safe. Note: This may be an issue if existing STUN servers are operated at addresses that
            are is not able restricted
          to handle bandwidth-based attacks. Thus, this
            approach does not seem satisfactory either.
          </t>
          <t> <strong>pages</strong> which contain untrusted content.
 If the systems are tightly integrated (i.e., the STUN endpoint responds with
            responses authenticated with ICE credentials) then this issue
            does not exist. However, such any page from a design is very close to
          given origin ever loads JavaScript from an ICE-Lite
            implementation (indeed, arguably attacker, then it is one).
            An intermediate approach would be to have a STUN extension that indicated
          possible for that one was responding attacker to WebRTC checks but not computing
            integrity checks based on the ICE credentials. This would allow infect the
            use browser's notion of standalone STUN servers without that
          origin semi-permanently.
          </t>
        </section>
      </section>
      <section anchor="sec.rtc-comm-consent" numbered="true" toc="include" removeInRFC="false" pn="section-4.2">
        <name slugifiedName="name-communications-consent-veri">Communications Consent Verification</name>
        <t indent="0" pn="section-4.2-1">
          As discussed in <xref target="sec.cors-etc" format="default" sectionFormat="of" derivedContent="Section 3.3"/>, allowing Web applications unrestricted network access
          via the browser introduces the risk of confusing them
            with legacy STUN servers. If using the browser as an attack platform against
          machines which would not otherwise be accessible to the malicious
          site, for
          instance, because they are topologically restricted (e.g., behind a non-ICE legacy solution is needed,
            then firewall or NAT).
          In order to prevent this form of attack as well as cross-protocol attacks, it is probably
          important to require that the best choice.
          </t>
          <t>
            Once initial target of traffic explicitly consent is verified, we also need to verify continuing
            consent, in order to avoid attacks where two people briefly share
            an IP (e.g., behind a NAT in an Internet cafe) and receiving
          the attacker
            arranges traffic in question. Until that consent has been verified for a large, unstoppable, given endpoint,
          traffic flow to other than the
            network and then leaves. The appropriate technologies here are
            fairly similar consent handshake <bcp14>MUST NOT</bcp14> be sent to those for initial consent, though are perhaps
            weaker since the threats are less severe. that endpoint.
        </t>
        </section>

        <section title="IP Location Privacy" anchor="sec.ip.location">
          <t>
        <t indent="0" pn="section-4.2-2">
          Note that consent verification is not sufficient to prevent overuse of
          network resources. Because WebRTC allows for a Web site to create
          data flows between two browser instances without user consent, it is
          possible for a malicious site to chew up a significant amount of a user's
          bandwidth without incurring significant costs to themselves by setting
          up such a channel to another user. However, as soon a practical matter
          there are a large number of Web sites which can act as data sources,
          so an attacker can at least use downlink bandwidth with existing
          Web APIs. However, this potential DoS vector reinforces the callee sends their ICE candidates, the
            caller learns need
          for adequate congestion control for WebRTC protocols to ensure that
          they play fair with other demands on the callee's IP addresses. The callee's server reflexive
            address reveals a lot user's bandwidth.
        </t>
        <section anchor="sec.ice" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.1">
          <name slugifiedName="name-ice">ICE</name>
          <t indent="0" pn="section-4.2.1-1">
          Verifying receiver consent requires some sort of information about the callee's location.
            In explicit handshake, but conveniently
          we already need one in order to avoid tracking, implementations may wish do NAT hole-punching. Interactive Connectivity Establishment (ICE)  <xref target="RFC8445" format="default" sectionFormat="of" derivedContent="RFC8445"/> includes a handshake
          designed to suppress
            the start of ICE negotiation until verify that the callee has answered. In
            addition, either side may wish receiving element wishes to hide their location receive traffic from the other
            side entirely by forcing all traffic through a TURN server.
          </t>
          <t>
            In ordinary operation,
          sender. It
          is important to remember here that the site learns initiating ICE is
          presumed malicious; in order for the browser's IP address,
            though it may handshake to be hidden via mechanisms like Tor  [http://www.torproject.org] or a VPN.
            However, because sites can cause secure, the browser
          receiving element <bcp14>MUST</bcp14> demonstrate receipt/knowledge of some value
          not available to provide
            IP addresses, the site (thus preventing the site from forging
          responses).  In order to achieve this provides a mechanism objective with ICE, the
          Session Traversal Utilities for sites NAT (STUN)
          transaction IDs must be generated by the browser and <bcp14>MUST NOT</bcp14> be made
          available to learn
            about the user's network environment initiating script, even if via a diagnostic interface.
          Verifying receiver consent also requires verifying the user is behind receiver wants
          to receive traffic from a VPN that masks their IP address. Implementations particular sender, and at this time; for
          example, a malicious site may wish simply attempt ICE to provide settings which suppress all non-VPN candidates if known servers
          that are using ICE for other sessions.  ICE provides this verification
          as well, by using the user is on certain kinds of VPN, especially privacy-oriented
            systems such STUN credentials as Tor.   See <xref target="I-D.ietf-rtcweb-ip-handling"/>
            for additional information.
          </t>
        </section>
      </section>

      <section title="Communications Security" anchor="sec.rtc-comsec">
        <t>
          Finally, we consider a problem familiar from the SIP world: communications security.
          For obvious reasons, it MUST be possible for form of per-session shared
          secret.  Those credentials are known to the communicating parties Web application, but would
          need to establish
          a channel which is secure against both message recovery and message modification.
          (See <xref target="RFC5479"/> for more details.)
          This service must also be provided for both data known and voice/video.
          Ideally used by the same security mechanisms would STUN-receiving element to be used useful.
          </t>
          <t indent="0" pn="section-4.2.1-2">
            There also needs to be some mechanism for both types the browser to verify that
            the target of content.
          Technology for providing this
          service (for instance, SRTP <xref target="RFC3711"/>, DTLS <xref target="RFC6347"/> and
          DTLS-SRTP <xref target="RFC5763"/>) is well understood. However, we must
          examine this technology in the WebRTC context, where traffic continues to wish to receive it. Because ICE keepalives are
            indications, they will not work here.
            <xref target="RFC7675" format="default" sectionFormat="of" derivedContent="RFC7675"/> describes the threat
          model is somewhat different. mechanism
            for providing consent freshness.
          </t>
        <t>
          In general, it
        </section>
        <section anchor="sec.masking" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.2">
          <name slugifiedName="name-masking">Masking</name>
          <t indent="0" pn="section-4.2.2-1">
            Once consent is important to understand that unlike a conventional SIP proxy,
          the calling service (i.e., the Web server) controls verified, there still is some concern about misinterpretation
            attacks as described by Huang et al. <xref target="huang-w2sp" format="default" sectionFormat="of" derivedContent="huang-w2sp"/>.
            This does not only the channel
          between the communicating endpoints but also the application running on
          the user's browser.
          While in principle seem like it is possible for the browser to cut the calling service
          out of serious concern with DTLS because
            the loop ICE handshake enforces receiver consent and directly present trusted information (and perhaps get
          consent), practice in modern browsers there is to avoid this whenever possible.
          "In-flow" modal dialogs which require little evidence
            of passive DTLS proxies of the user to consent to specific
          actions are particularly disfavored as human factors research indicates type studied by Huang. However, because
            RTCWEB can run over TCP there is some concern that unless they are made extremely invasive, users simply agree to
          them without actually consciously giving consent. <xref target="abarth-rtcweb"/>.
          Thus, nearly all attackers might
            control the UI will necessarily be rendered ciphertext by controlling the
          browser but under control of the calling service. plaintext input to SCTP.
            This likely includes the
          peer's identity information, which, after all, risk is only meaningful in partially mitigated by the context fact that the SCTP stack controls
            the framing of some calling service. the packets.
          </t>
        <t>
          This limitation does not mean that preventing attack by the calling service
          is completely hopeless. However, we need to distinguish between two
          classes of attack:
        </t>
        <t><list style="hanging">
          <t hangText="Retrospective compromise of calling service."></t><t>The calling service
          is non-malicious during a call but subsequently is compromised and wishes to
          attack indent="0" pn="section-4.2.2-2">
            Note that in principle an older call (often called a "passive attack")</t>
          <t></t>
          <t hangText="During-call attack attacker could exert some control
            over Secure Real-time Transport Protocol (SRTP) packets by calling service."></t><t>The calling service is compromised
          during using a combination of the call it wishes WebAudio API
            and extremely tight timing control.
            The primary risk here seems to attack (often called an "active attack").</t>
          </list>
          </t>
        <t>
          Providing security against the former type be carriage of attack is practical using the
          techniques discussed in <xref target="sec.retrospective-compromise"/>. SRTP over Traversal
            Using Relays around NAT (TURN) TCP.
            However, it is as SRTP packets have an extremely difficult to prevent a
          trusted but malicious calling service from actively attacking a user's calls,
          either by mounting a Man-in-the-Middle (MITM) attack or by diverting them entirely.
          (Note characteristic packet
            header it seems unlikely that this attack applies equally to a network attacker if communications
          to any but the calling service are not secured.) We discuss some potential approaches
          and why they are likely to most aggressive
            intermediaries would be impractical confused into thinking that another
            application-layer protocol was in <xref target="sec.during-attack"/>. use.
          </t>
        </section>
        <section title="Protecting Against Retrospective Compromise" anchor="sec.retrospective-compromise">
          <t>
            In a retrospective attack, the calling service was uncompromised during
            the call, but that an attacker subsequently wants numbered="true" toc="include" removeInRFC="false" pn="section-4.2.3">
          <name slugifiedName="name-backward-compatibility">Backward Compatibility</name>
          <aside pn="section-4.2.3-1">
            <t indent="0" pn="section-4.2.3-1.1">
            Note: The RTCWEB WG ultimately decided to recover the content of the
            call. We assume require ICE. This section
            provides context for that the attacker has access to the protected media stream
            as well as having full control of the calling service. decision.
            </t>
          <t>
            If the calling service has access
          </aside>
          <t indent="0" pn="section-4.2.3-2">
            A requirement to use ICE limits compatibility with legacy non-ICE clients.
            It seems unsafe to completely remove the traffic keying material
            (as in SDES <xref target="RFC4568"/>), then retrospective attack
            is trivial.
            This form of attack is particularly serious in requirement for some check.
            All proposed checks have the Web context because
            it is standard practice in Web services to run extensive logging and monitoring. Thus, it is highly
            likely common feature that if the browser
            sends some message to the candidate traffic key is part of any HTTP request it will be logged somewhere recipient
            and thus
            subject refuses to subsequent compromise. It is this consideration send other traffic until that makes an automatic, public key-based
            key exchange mechanism imperative for WebRTC (this is a good idea for any communications
            security system) and this mechanism SHOULD provide perfect forward secrecy (PFS). message has been
            replied to. The signaling channel/calling service can message/reply pair must be used to authenticate this mechanism.
          </t>
          <t>
            In addition, if end-to-end keying is generated in used,
            the system MUST NOT provide any APIs to extract either long-term
            keying material or to directly access any stored traffic keys.
            Otherwise, such
            a way that an attacker who subsequently compromised controls the calling service
            might be able to use those APIs to recover Web application
            cannot forge them, generally by having the traffic keys and thus
            compromise message contain some
            secret value that must be incorporated (e.g., echoed, hashed into,
            etc.). Non-ICE candidates for this role (in cases where the traffic.
          </t>
        </section>
        <section title="Protecting Against During-Call Attack" anchor="sec.during-attack">
          <t>
            Protecting against attacks during a call is
            legacy endpoint has a more difficult proposition. Even
            if the calling service cannot directly access keying material (as recommended
            in public address) include:
          </t>
          <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-4.2.3-3">
            <li pn="section-4.2.3-3.1">STUN checks without using ICE (i.e., the previous section), it can simply mount non-RTC-web endpoint sets up a man-in-the-middle attack
            on the connection, telling Alice that she is calling Bob and Bob that
            he is calling Alice, while in fact STUN responder).</li>
            <li pn="section-4.2.3-3.2">Use of the calling service is acting RTP Control Protocol (RTCP) as
            a calling bridge and capturing all an implicit reachability check.</li>
          </ul>
          <t indent="0" pn="section-4.2.3-4">
            In the traffic. Protecting against
            this form of attack requires positive authentication of RTCP approach, the remote WebRTC endpoint such as explicit out-of-band key verification (e.g., by a fingerprint)
            or a third-party identity service as described in
            <xref target="I-D.ietf-rtcweb-security-arch"/>.
          </t>
          <section title="Key Continuity" anchor="sec.key-continuity">
            <t>
              One natural approach is allowed to use "key continuity". While a malicious
              calling service can present any identity it chooses to the user,
              it cannot produce send
            a private key that maps limited number of RTP packets prior to receiving consent. This
            allows a given public key.
              Thus, it short window of attack. In addition, some legacy endpoints
            do not support RTCP, so this is possible a much more expensive solution for the browser
            such endpoints, for which it would likely be easier to note a given user's
              public key and generate implement ICE.
            For these two reasons, an alarm whenever that user's key
              changes. SSH <xref target="RFC4251"/> uses a similar technique.
              (Note that the need RTCP-based approach does not seem to avoid explicit user consent on every call
              precludes the browser requiring an immediate manual check of
            address the peer's key). security issue satisfactorily.
          </t>
            <t>
              Unfortunately, this sort of key continuity mechanism is far less
              useful in
          <t indent="0" pn="section-4.2.3-5">
            In the WebRTC context. First, much of STUN approach, the virtue of WebRTC (and any Web application) endpoint is able to verify that it
            the recipient is not bound running some kind of STUN endpoint but unless
            the STUN responder is integrated with the ICE username/password
            establishment system, the WebRTC endpoint cannot verify that
            the recipient consents to this particular piece of client software. Thus, it will call. This may be an
            issue if existing STUN servers are operated at addresses that
            are not only
              possible but routine for a user able to use multiple browsers
              on different computers which will of course have different
              keying material (SACRED <xref target="RFC3760"/> notwithstanding.) handle bandwidth-based attacks. Thus, users will frequently be alerted to key mismatches which
              are in fact completely legitimate, with this
            approach does not seem satisfactory either.
          </t>
          <t indent="0" pn="section-4.2.3-6">
            If the result that they systems are trained tightly integrated (i.e., the STUN endpoint responds with
            responses authenticated with ICE credentials), then this issue
            does not exist. However, such a design is very close to simply click through them. As it an ICE-Lite
            implementation (indeed, arguably is known one).
            An intermediate approach would be to have a STUN extension that
              users routinely will click through far more dire warnings
              <xref target="cranor-wolf"/>, it seems extremely unlikely indicated
            that
              any key continuity mechanism will be effective rather than
              simply annoying.
            </t>
            <t>
              Moreover, it is trivial one was responding to bypass even this kind WebRTC checks but not computing
            integrity checks based on the ICE credentials. This would allow the
            use of mechanism.
              Recall that unlike standalone STUN servers without the case risk of SSH, confusing them
            with legacy STUN servers. If a non-ICE legacy solution is needed,
            then this is probably the browser never directly
              gets the peer's identity from the user. Rather, it best choice.
          </t>
          <t indent="0" pn="section-4.2.3-7">
            Once initial consent is provided
              by the calling service. Even enabling a mechanism of this type
              would require an API verified, we also need to allow the calling service verify continuing
            consent, in order to tell avoid attacks where two people briefly share
            an IP (e.g., behind a NAT in an Internet cafe) and the
              browser "this is attacker
            arranges for a call large, unstoppable, traffic flow to user X". All the calling service
              needs to do to avoid triggering a key continuity warning
              is
            network and then leaves. The appropriate technologies here are
            fairly similar to tell those for initial consent, though are perhaps
            weaker since the browser threats are less severe.
          </t>
        </section>
        <section anchor="sec.ip.location" numbered="true" toc="include" removeInRFC="false" pn="section-4.2.4">
          <name slugifiedName="name-ip-location-privacy">IP Location Privacy</name>
          <t indent="0" pn="section-4.2.4-1">
            Note that "this is a call to user Y"
              where Y is confusable with X.
              Even if as soon as the user actually checks callee sends their ICE candidates, the other side's name
              (which all available evidence indicates is unlikely),
              this would require (a)
            caller learns the browser to use callee's IP addresses. The callee's server-reflexive
            address reveals a lot of information about the trusted UI callee's location.
            In order to provide avoid tracking, implementations may wish to suppress
            the name and (b) start of ICE negotiation until the user callee has answered. In
            addition, either side may wish to not be fooled by
              similar appearing names.
            </t>
          </section>
          <section title="Short Authentication Strings" anchor="sec.sas">
            <t>
              ZRTP <xref target="RFC6189"/> uses a "short authentication string" (SAS) which is derived hide their location from the key agreement protocol. This SAS is designed to be compared other
            side entirely by the users (e.g., read aloud over the voice channel or
              transmitted via an out of band channel) and if confirmed by both sides precludes MITM
              attack. The intention is that the SAS is used once and then key
              continuity (though forcing all traffic through a different mechanism from that discussed
              above) is used thereafter. TURN server.
          </t>
            <t>
              Unfortunately,
          <t indent="0" pn="section-4.2.4-2">
            In ordinary operation, the SAS does not offer a practical solution to site learns the
              problem of a compromised calling service.	"Voice conversion" systems, which modify
              voice from one speaker to make browser's IP address,
            though it sound may be hidden via mechanisms like another,
              are an active area of research.
              These systems are already good enough Tor <eref brackets="angle" target="https://www.torproject.org"/> or a VPN.
            However, because sites can cause the browser to fool both
              automatic recognition systems <xref target="farus-conversion"/> and
              humans <xref target="kain-conversion"/> in many cases, and are of course likely provide
            IP addresses, this provides a mechanism for sites to improve in future, especially in an learn
            about the user's network environment where even if the user just wants is behind
            a VPN that masks their IP address. Implementations may wish
            to get on with the phone call.
              Thus, even provide settings which suppress all non-VPN candidates if SAS is effective today, it
            the user is likely not to be so on certain kinds of VPN, especially privacy-oriented
            systems such as Tor.   See <xref target="RFC8828" format="default" sectionFormat="of" derivedContent="RFC8828"/>
            for much longer. additional information.
          </t>
            <t>
              Additionally, it is unclear that users will actually use an SAS.
              As discussed above, the browser UI constraints preclude requiring
              the SAS exchange prior to completing
        </section>
      </section>
      <section anchor="sec.rtc-comsec" numbered="true" toc="include" removeInRFC="false" pn="section-4.3">
        <name slugifiedName="name-communications-security">Communications Security</name>
        <t indent="0" pn="section-4.3-1">
          Finally, we consider a problem familiar from the call and so SIP world: communications security.
          For obvious reasons, it must <bcp14>MUST</bcp14> be
              voluntary; at most possible for the browser will provide some UI indicator that the
              SAS has not yet been checked. However, it communicating parties to establish
          a channel which is well-known that when
              faced with optional security mechanisms, many users simply
              ignore them secure against both message recovery and message modification.
          (See <xref target="whitten-johnny"/>.
            </t>
            <t>
              Once users have checked target="RFC5479" format="default" sectionFormat="of" derivedContent="RFC5479"/> for more details.)
          This service must be provided for both data and voice/video.
          Ideally the SAS once, key continuity same security mechanisms would be used for both types of content.
          Technology for providing this
          service (for instance, SRTP <xref target="RFC3711" format="default" sectionFormat="of" derivedContent="RFC3711"/>, DTLS <xref target="RFC6347" format="default" sectionFormat="of" derivedContent="RFC6347"/>, and
          DTLS-SRTP <xref target="RFC5763" format="default" sectionFormat="of" derivedContent="RFC5763"/>) is required to avoid them needing to check it on every call. well understood. However, we must
          examine this is problematic for reasons indicated technology in
              <xref target="sec.key-continuity"/>. the WebRTC context, where the threat
          model is somewhat different.
        </t>
        <t indent="0" pn="section-4.3-2">
          In principle general, it is of course possible to render a different
              UI element important to indicate that calls are using an unauthenticated
              set of keying material (recall understand that the attacker can just present unlike a slightly different name so that conventional SIP proxy,
          the attack shows calling service (i.e., the
              same UI as a call to a new device or to someone you haven't
              called before) Web server) controls not only the channel
          between the communicating endpoints but as a practical matter, users simply ignore
              such indicators even also the application running on
          the user's browser.
          While in principle it is possible for the rather more dire case of mixed
              content warnings.
            </t>
          </section>
          <section title="Third Party Identity" anchor="sec.third-party-id">
            <t>
              The conventional approach browser to providing communications identity
              has cut the calling service
          out of course been to have some third party identity system
              (e.g., PKI) to authenticate the endpoints. loop and directly present trusted information (and perhaps get
          consent), practice in modern browsers is to avoid this whenever possible.
          "In‑flow" modal dialogs which require the user to consent to specific
          actions are particularly disfavored as human factors research indicates
          that unless they are made extremely invasive, users simply agree to
          them without actually consciously giving consent <xref target="abarth-rtcweb" format="default" sectionFormat="of" derivedContent="abarth-rtcweb"/>.
          Thus, nearly all the UI will necessarily be rendered by the
          browser but under control of the calling service. This likely includes the
          peer's identity information, which, after all, is only meaningful in
          the context of some calling service.
        </t>
        <t indent="0" pn="section-4.3-3">
          This limitation does not mean that preventing attack by the calling service
          is completely hopeless. However, we need to distinguish between two
          classes of attack:
        </t>
        <dl newline="true" spacing="normal" indent="3" pn="section-4.3-4">
          <dt pn="section-4.3-4.1">Retrospective compromise of calling service:</dt>
          <dd pn="section-4.3-4.2">The calling service
          is non-malicious during a call but subsequently is compromised and wishes to
          attack an older call (often called a "passive attack").</dd>
          <dt pn="section-4.3-4.3">During-call attack by calling service:</dt>
          <dd pn="section-4.3-4.4">The calling service is compromised
          during the call it wishes to attack (often called an "active attack").</dd>
        </dl>
        <t indent="0" pn="section-4.3-5">
          Providing security against the former type of attack is practical using the
          techniques discussed in <xref target="sec.retrospective-compromise" format="default" sectionFormat="of" derivedContent="Section 4.3.1"/>.
          However, it is extremely difficult to prevent a
          trusted but malicious calling service from actively attacking a user's calls,
          either by mounting a Man-in-the-Middle (MITM) attack or by diverting them entirely.
          (Note that this attack applies equally to a network attacker if communications
          to the calling service are not secured.) We discuss some potential approaches
          in <xref target="sec.during-attack" format="default" sectionFormat="of" derivedContent="Section 4.3.2"/>.
        </t>
        <section anchor="sec.retrospective-compromise" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.1">
          <name slugifiedName="name-protecting-against-retrospe">Protecting Against Retrospective Compromise</name>
          <t indent="0" pn="section-4.3.1-1">
            In a retrospective attack, the calling service was uncompromised during
            the call, but an attacker subsequently wants to recover the content of the
            call. We assume that the attacker has access to the protected media stream
            as well as full control of the calling service.
          </t>
          <t indent="0" pn="section-4.3.1-2">
            If the calling service has access to the traffic keying material
            (as in Security Descriptions (SDES) <xref target="RFC4568" format="default" sectionFormat="of" derivedContent="RFC4568"/>), then retrospective attack
            is trivial.
            This form of attack is particularly serious in the Web context because
            it is standard practice in Web services to run extensive logging and monitoring. Thus, it is highly
            likely that if the traffic key is part of any HTTP request it will be logged somewhere and thus
            subject to subsequent compromise. It is this consideration that makes an automatic, public key-based
            key exchange mechanism imperative for WebRTC (this is a good idea for any communications
            security system), and this mechanism <bcp14>SHOULD</bcp14> provide Forward Secrecy (FS).
            The signaling channel/calling service can be used to authenticate this mechanism.
          </t>
          <t indent="0" pn="section-4.3.1-3">
            In addition, if end-to-end keying is used,
            the system <bcp14>MUST NOT</bcp14> provide any APIs to either extract long-term
            keying material or to directly access any stored traffic keys.
            Otherwise, an attacker who subsequently compromised the calling service
            might be able to use those APIs to recover the traffic keys and thus
            compromise the traffic.
          </t>
        </section>
        <section anchor="sec.during-attack" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2">
          <name slugifiedName="name-protecting-against-during-c">Protecting Against During-Call Attack</name>
          <t indent="0" pn="section-4.3.2-1">
            Protecting against attacks during a call is a more difficult proposition. Even
            if the calling service cannot directly access keying material (as recommended
            in the previous section), it can simply mount a man-in-the-middle attack
            on the connection, telling Alice that she is calling Bob and Bob that
            he is calling Alice, while in fact the calling service is acting as
            a calling bridge and capturing all the traffic. Protecting against
            this form of attack requires positive authentication of the remote
            endpoint such as explicit out-of-band key verification (e.g., by a fingerprint)
            or a third-party identity service as described in
            <xref target="RFC8827" format="default" sectionFormat="of" derivedContent="RFC8827"/>.
          </t>
          <section anchor="sec.key-continuity" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2.1">
            <name slugifiedName="name-key-continuity">Key Continuity</name>
            <t indent="0" pn="section-4.3.2.1-1">
              One natural approach is to use "key continuity". While a malicious
              calling service can present any identity it chooses to the user,
              it cannot produce a private key that maps to a given public key.
              Thus, it is possible for the browser to note a given user's
              public key and generate an alarm whenever that user's key
              changes. The Secure Shell (SSH) protocol <xref target="RFC4251" format="default" sectionFormat="of" derivedContent="RFC4251"/> uses a similar technique.
              (Note that the need to avoid explicit user consent on every call
              precludes the browser requiring an immediate manual check of the peer's key.)
            </t>
            <t indent="0" pn="section-4.3.2.1-2">
              Unfortunately, this sort of key continuity mechanism is far less
              useful in the WebRTC context. First, much of the virtue of
              WebRTC (and any Web application) is that it is not bound to a
              particular piece of client software. Thus, it will be not only
              possible but routine for a user to use multiple browsers
              on different computers that will of course have different
              keying material (Securely Available Credentials (SACRED) <xref target="RFC3760" format="default" sectionFormat="of" derivedContent="RFC3760"/> notwithstanding).
              Thus, users will frequently be alerted to key mismatches which
              are in fact completely legitimate, with the result that they
              are trained to simply click through them. As it is known that
              users routinely will click through far more dire warnings
              <xref target="cranor-wolf" format="default" sectionFormat="of" derivedContent="cranor-wolf"/>, it seems extremely unlikely that
              any key continuity mechanism will be effective rather than
              simply annoying.
            </t>
            <t indent="0" pn="section-4.3.2.1-3">
              Moreover, it is trivial to bypass even this kind of mechanism.
              Recall that unlike the case of SSH, the browser never directly
              gets the peer's identity from the user. Rather, it is provided
              by the calling service. Even enabling a mechanism of this type
              would require an API to allow the calling service to tell the
              browser "this is a call to user X." All the calling service
              needs to do to avoid triggering a key continuity warning
              is to tell the browser that "this is a call to user Y"
              where Y is confusable with X.
              Even if the user actually checks the other side's name
              (which all available evidence indicates is unlikely),
              this would require (a) the browser to use the trusted UI
              to provide the name and (b) the user to not be fooled by
              similar appearing names.
            </t>
          </section>
          <section anchor="sec.sas" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2.2">
            <name slugifiedName="name-short-authentication-string">Short Authentication Strings</name>
            <t indent="0" pn="section-4.3.2.2-1">
              ZRTP <xref target="RFC6189" format="default" sectionFormat="of" derivedContent="RFC6189"/> uses a "Short Authentication String" (SAS) which is derived
              from the key agreement protocol.
 This SAS is designed to be compared
              by the users (e.g., read aloud over the voice channel or
              transmitted via an out-of-band channel) and if confirmed by both sides precludes MITM
              attack. The intention is that the SAS is used once and then key
              continuity (though with a different mechanism from that discussed
              above) is used thereafter.
            </t>
            <t indent="0" pn="section-4.3.2.2-2">
              Unfortunately, the SAS does not offer a practical solution to the
              problem of a compromised calling service. "Voice cloning" systems,
              which mimic the voice of a given speaker
              are an active area of research  <xref target="deepfakes-ftc" format="default" sectionFormat="of" derivedContent="deepfakes-ftc"/> and are already being used in
              real-world attacks <xref target="deepfakes-fraud" format="default" sectionFormat="of" derivedContent="deepfakes-fraud"/>.
              These attacks are likely
              to improve in future, especially in an environment where the user just wants
              to get on with the phone call.
              Thus, even if the SAS is effective today, it is likely not to be so for much longer.
            </t>
            <t indent="0" pn="section-4.3.2.2-3">
              Additionally, it is unclear that users will actually use an SAS.
              As discussed above, the browser UI constraints preclude requiring
              the SAS exchange prior to completing the call and so it must be
              voluntary; at most the browser will provide some UI indicator that the
              SAS has not yet been checked. However, it is well known that when
              faced with optional security mechanisms, many users simply
              ignore them <xref target="whitten-johnny" format="default" sectionFormat="of" derivedContent="whitten-johnny"/>.
            </t>
            <t indent="0" pn="section-4.3.2.2-4">
              Once users have checked the SAS once, key continuity
              is required to avoid them needing to check it on every call.
              However, this is problematic for reasons indicated in
              <xref target="sec.key-continuity" format="default" sectionFormat="of" derivedContent="Section 4.3.2.1"/>.
              In principle it is of course possible to render a different
              UI element to indicate that calls are using an unauthenticated
              set of keying material (recall that the attacker can just present
              a slightly different name so that the attack shows the
              same UI as a call to a new device or to someone you haven't
              called before), but as a practical matter, users simply ignore
              such indicators even in the rather more dire case of mixed
              content warnings.
            </t>
          </section>
          <section anchor="sec.third-party-id" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2.3">
            <name slugifiedName="name-third-party-identity">Third-Party Identity</name>
            <t indent="0" pn="section-4.3.2.3-1">
              The conventional approach to providing communications identity
              has of course been to have some third-party identity system
              (e.g., PKI) to authenticate the endpoints. Such mechanisms
              have proven proven to be too cumbersome for use by typical users
              (and nearly too cumbersome for administrators).
              However,
              a new generation of Web-based identity providers (BrowserID, Federated Google Login,
              Facebook Connect, OAuth <xref target="RFC6749" format="default" sectionFormat="of" derivedContent="RFC6749"/>, OpenID <xref target="OpenID" format="default" sectionFormat="of" derivedContent="OpenID"/>, WebFinger <xref target="RFC7033" format="default" sectionFormat="of" derivedContent="RFC7033"/>) has been developed
              and use Web technologies to provide lightweight (from the user's
              perspective) third-party authenticated transactions.
              It is possible to use systems of this type to authenticate WebRTC calls,
              linking them to existing user notions of identity
              (e.g., Facebook adjacencies). Specifically, the third-party
              identity system is used to bind the user's identity to
              cryptographic keying material which is then used to
              authenticate the calling endpoints.
              Calls which are authenticated
              in this fashion are naturally resistant even to active MITM attack
              by the calling site.
            </t>
            <t indent="0" pn="section-4.3.2.3-2">
              Note that there is one special case in which PKI-style certificates
              do provide a practical solution: calls from end users to
              large sites. For instance, if you are making a call
              to Amazon.com, then Amazon can easily get a certificate
              to authenticate their media traffic, just as they get
              one to authenticate their Web traffic. This does not provide
              additional security value in cases in which the calling site
              and the media peer are one and the same, but might be useful
              in cases in which third parties (e.g., ad networks or
              retailers) arrange for calls but do not participate in them.
            </t>
          </section>
          <section anchor="sec.page-access" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.2.4">
            <name slugifiedName="name-page-access-to-media">Page Access to Media</name>
            <t indent="0" pn="section-4.3.2.4-1">
              Identifying the identity of the far media endpoint is a
              necessary but not sufficient condition for providing media
              security. In WebRTC, media flows are rendered into
              HTML5 MediaStreams which can be manipulated by the calling
              site. Obviously, if the site can modify or view the media,
              then the user is not getting the level of assurance they
              would expect from being able to authenticate their peer.
              In many cases, this is acceptable because the user values
              site-based special effects over complete security from the
              site. However, there are also cases where users wish to
              know that the site cannot interfere. In order to facilitate
              that, it will be necessary to provide features whereby
              the site can verifiably give up access to the media streams.
              This verification must be possible both from the local
              side and the remote side. I.e., users must be able to verify
              that the person called has engaged a secure media
              mode (see <xref target="sec.malicious" format="default" sectionFormat="of" derivedContent="Section 4.3.3"/>). In order to achieve this, it will be necessary to
              cryptographically bind an indication of the local media
              access policy into the cryptographic authentication
              procedures detailed in the previous sections.
            </t>
            <t indent="0" pn="section-4.3.2.4-2">
              It should be noted that the use of this secure media mode is
              left to the discretion of the site. When such a mode is
              engaged, the browser will need to provide indicia to the user
              that the associated media has been authenticated as coming from
              the identified user.  This allows WebRTC services that wish to
              claim end-to-end security to do so in a way that can be easily
              verified by the user. This model requires that the remote
              party's browser be included in the TCB, as described in
              <xref target="sec.web-security" format="default" sectionFormat="of" derivedContent="Section 3"/>.
            </t>
          </section>
        </section>
        <section anchor="sec.malicious" numbered="true" toc="include" removeInRFC="false" pn="section-4.3.3">
          <name slugifiedName="name-malicious-peers">Malicious Peers</name>
          <t indent="0" pn="section-4.3.3-1">
            One class of attack that we do not generally try to prevent
            is malicious peers. For instance, no matter what confidentiality
            measures you employ the person you are talking to might record
            the call and publish it on the Internet. Similarly, we do
            not attempt to prevent them from using voice or video processing
            technology for hiding or changing their appearance.
            While technologies (Digital Rights Management (DRM), etc.) do exist to attempt to address
            these issues, they are generally not compatible with open
            systems and WebRTC does not address them.
          </t>
          <t indent="0" pn="section-4.3.3-2">
            Similarly, we make no attempt to prevent prank calling or
            other unwanted calls. In general, this is in the scope of the
            calling site, though because WebRTC does offer some forms of
            strong authentication, that may be useful as part of a defense
            against such attacks.
          </t>
        </section>
      </section>
      <section anchor="sec.privacy" numbered="true" toc="include" removeInRFC="false" pn="section-4.4">
        <name slugifiedName="name-privacy-considerations">Privacy Considerations</name>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4.1">
          <name slugifiedName="name-correlation-of-anonymous-ca">Correlation of Anonymous Calls</name>
          <t indent="0" pn="section-4.4.1-1">
            While persistent endpoint identifiers can be a useful security
            feature (see <xref target="sec.key-continuity" format="default" sectionFormat="of" derivedContent="Section 4.3.2.1"/>), they can
            also represent a privacy threat in settings where the user
            wishes to be anonymous. WebRTC provides a number of possible
            persistent identifiers such as DTLS certificates
            (if they are reused between connections) and RTCP CNAMEs
            (if generated according to <xref target="RFC6222" format="default" sectionFormat="of" derivedContent="RFC6222"/> rather
            than the privacy-preserving mode of <xref target="RFC7022" format="default" sectionFormat="of" derivedContent="RFC7022"/>).
            In order to prevent this type of correlation, browsers need to
            provide mechanisms to reset these identifiers (e.g., with the
            same lifetime as cookies). Moreover, the API should provide
            mechanisms to allow sites intended for anonymous calling
            to force the minting of fresh identifiers. In addition,
            IP addresses can be a source of call linkage
            <xref target="RFC8828" format="default" sectionFormat="of" derivedContent="RFC8828"/>.
          </t>
        </section>
        <section numbered="true" toc="include" removeInRFC="false" pn="section-4.4.2">
          <name slugifiedName="name-browser-fingerprinting">Browser Fingerprinting</name>
          <t indent="0" pn="section-4.4.2-1">
            Any new set of API features adds a risk of browser fingerprinting,
            and WebRTC is no exception. Specifically, sites can use the
            presence or absence of specific devices as a browser fingerprint.
            In general, the API needs to be balanced between functionality
            and the incremental fingerprint risk.  See <xref target="Fingerprinting" format="default" sectionFormat="of" derivedContent="Fingerprinting"/>.
          </t>
        </section>
      </section>
    </section>
    <section anchor="sec.sec_cons" numbered="true" toc="include" removeInRFC="false" pn="section-5">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-5-1">This entire document is about security.</t>
    </section>
    <section numbered="true" toc="include" removeInRFC="false" pn="section-6">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-6-1">This document has no IANA actions.</t>
    </section>
  </middle>
  <back>
    <references pn="section-7">
      <name slugifiedName="name-references">References</name>
      <references pn="section-7.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author initials="S." surname="Bradner" fullname="S. Bradner">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="1997" month="March"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author initials="B." surname="Leiba" fullname="B. Leiba">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2017" month="May"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
      </references>
      <references pn="section-7.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="abarth-rtcweb" target="http://rtc-web.alvestrand.com/home/papers/barth-security-prompt.pdf?attredirects=0" quoteTitle="true" derivedAnchor="abarth-rtcweb">
          <front>
            <title>Prompting the user is security failure</title>
            <author initials="A." surname="Barth">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="September" year="2010"/>
          </front>
          <refcontent>RTC-Web Workshop</refcontent>
        </reference>
        <reference anchor="cranor-wolf" target="https://www.usenix.org/legacy/event/sec09/tech/full_papers/sunshine.pdf" quoteTitle="true" derivedAnchor="cranor-wolf">
          <front>
            <title>Crying Wolf: An Empirical Study of SSL Warning Effectiveness</title>
            <author initials="J." surname="Sunshine">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Egelman">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Almuhimedi">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Atri">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="Cranor">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="August" year="2009"/>
          </front>
          <refcontent>Proceedings of the 18th USENIX Security Symposium</refcontent>
        </reference>
        <reference anchor="deepfakes-fraud" target="https://www.theverge.com/2019/9/5/20851248/deepfakes-ai-fake-audio-phone-calls-thieves-trick-companies-stealing-money" quoteTitle="true" derivedAnchor="deepfakes-fraud">
          <front>
            <title>Thieves are now using AI deepfakes to trick companies into sending them money</title>
            <author initials="N." surname="Statt">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="September" year="2019"/>
          </front>
        </reference>
        <reference anchor="deepfakes-ftc" target="https://www.theverge.com/2020/1/29/21080553/ftc-deepfakes-audio-cloning-joe-rogan-phone-scams" quoteTitle="true" derivedAnchor="deepfakes-ftc">
          <front>
            <title>FTC says the tech behind audio deepfakes is getting better</title>
            <author initials="K." surname="Lyons">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="January" year="2020"/>
          </front>
        </reference>
        <reference anchor="fetch" target="https://fetch.spec.whatwg.org/" quoteTitle="true" derivedAnchor="fetch">
          <front>
            <title>Fetch</title>
            <author initials="A." surname="van Kesteren">
              <organization showOnFrontPage="true"/>
            </author>
          </front>
        </reference>
        <reference anchor="finer-grained" quoteTitle="true" derivedAnchor="finer-grained">
          <front>
            <title>Beware of Finer-Grained Origins</title>
            <author initials="C." surname="Jackson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Barth">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="July" year="2008"/>
          </front>
          <refcontent>Web 2.0 Security and Privacy (W2SP 2008)</refcontent>
        </reference>
        <reference anchor="Fingerprinting" target="https://www.w3.org/TR/fingerprinting-guidance/" quoteTitle="true" derivedAnchor="Fingerprinting">
          <front>
            <title>Mitigating Browser Fingerprinting in Web Specifications</title>
            <author initials="N." surname="Doty" role="editor"/>
            <date month="March" year="2019"/>
          </front>
        </reference>
        <reference anchor="huang-w2sp" quoteTitle="true" derivedAnchor="huang-w2sp">
          <front>
            <title>Talking to be too cumbersome Yourself for Fun and Profit</title>
            <author initials="L-S." surname="Huang">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E.Y." surname="Chen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Barth">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jackson">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="May" year="2011"/>
          </front>
          <refcontent>Web 2.0 Security and Privacy (W2SP 2011)</refcontent>
        </reference>
        <reference anchor="OpenID" target="https://openid.net/specs/openid-connect-core-1_0.html" quoteTitle="true" derivedAnchor="OpenID">
          <front>
            <title>OpenID Connect Core 1.0</title>
            <author initials="N." surname="Sakimura">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Bradley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="de Medeiros">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Mortimore">
              <organization showOnFrontPage="true"/>
            </author>
            <date month="November" year="2014"/>
          </front>
        </reference>
        <reference anchor="RFC2818" target="https://www.rfc-editor.org/info/rfc2818" quoteTitle="true" derivedAnchor="RFC2818">
          <front>
            <title>HTTP Over TLS</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2000" month="May"/>
            <abstract>
              <t indent="0">This memo describes how to use by typical users
              (and nearly too cumbersome Transport Layer Security (TLS) to secure Hypertext Transfer Protocol (HTTP) connections over the Internet.  This memo provides information for the Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="2818"/>
          <seriesInfo name="DOI" value="10.17487/RFC2818"/>
        </reference>
        <reference anchor="RFC3261" target="https://www.rfc-editor.org/info/rfc3261" quoteTitle="true" derivedAnchor="RFC3261">
          <front>
            <title>SIP: Session Initiation Protocol</title>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Schulzrinne" fullname="H. Schulzrinne">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G." surname="Camarillo" fullname="G. Camarillo">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Johnston" fullname="A. Johnston">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Peterson" fullname="J. Peterson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="R." surname="Sparks" fullname="R. Sparks">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Handley" fullname="M. Handley">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Schooler" fullname="E. Schooler">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2002" month="June"/>
            <abstract>
              <t indent="0">This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants.  These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3261"/>
          <seriesInfo name="DOI" value="10.17487/RFC3261"/>
        </reference>
        <reference anchor="RFC3552" target="https://www.rfc-editor.org/info/rfc3552" quoteTitle="true" derivedAnchor="RFC3552">
          <front>
            <title>Guidelines for Writing RFC Text on Security Considerations</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="B." surname="Korver" fullname="B. Korver">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2003" month="July"/>
            <abstract>
              <t indent="0">All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak.  This document provides guidelines to RFC authors on how to write a good Security Considerations section.   This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for administrators).
              However,
              a new generation improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="72"/>
          <seriesInfo name="RFC" value="3552"/>
          <seriesInfo name="DOI" value="10.17487/RFC3552"/>
        </reference>
        <reference anchor="RFC3711" target="https://www.rfc-editor.org/info/rfc3711" quoteTitle="true" derivedAnchor="RFC3711">
          <front>
            <title>The Secure Real-time Transport Protocol (SRTP)</title>
            <author initials="M." surname="Baugher" fullname="M. Baugher">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="McGrew" fullname="D. McGrew">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Naslund" fullname="M. Naslund">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Carrara" fullname="E. Carrara">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="K." surname="Norrman" fullname="K. Norrman">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="March"/>
            <abstract>
              <t indent="0">This document describes the Secure Real-time Transport Protocol (SRTP), a profile of Web-based identity providers (BrowserID, Federated Google Login,
              Facebook Connect, OAuth <xref target="RFC6749"/>, OpenID <xref target="OpenID"/>, WebFinger <xref target="RFC7033"/>), has recently been developed the Real-time Transport Protocol (RTP), which can provide confidentiality, message authentication, and use Web technologies replay protection to provide lightweight (from the user's
              perspective) third-party authenticated transactions.
              It is possible RTP traffic and to use systems the control traffic for RTP, the Real-time Transport Control Protocol (RTCP).   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3711"/>
          <seriesInfo name="DOI" value="10.17487/RFC3711"/>
        </reference>
        <reference anchor="RFC3760" target="https://www.rfc-editor.org/info/rfc3760" quoteTitle="true" derivedAnchor="RFC3760">
          <front>
            <title>Securely Available Credentials (SACRED) - Credential Server Framework</title>
            <author initials="D." surname="Gustafson" fullname="D. Gustafson">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Just" fullname="M. Just">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Nystrom" fullname="M. Nystrom">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2004" month="April"/>
            <abstract>
              <t indent="0">As the number, and more particularly the number of this type to authenticate WebRTC calls,
              linking them to existing user notions different types, of identity
              (e.g., Facebook adjacencies). Specifically, the third-party
              identity system is used devices connecting to bind the user's identity to
              cryptographic keying material which is then used Internet increases, credential mobility becomes an issue for IETF standardization.  This document responds to
              authenticate the calling endpoints.
              Calls which are authenticated requirements on protocols for secure exchange of credentials listed in this fashion are naturally resistant even to active MITM attack RFC 3157, by presenting an abstract protocol framework.  This memo provides information for the calling site.
            </t>
            <t>
              Note that there is one special case in which PKI-style certificates
              do provide a practical solution: calls from end-users to
              large sites. For instance, if you are making a call
              to Amazon.com, then Amazon can easily get a certificate
              to authenticate their media traffic, just as they get
              one to authenticate their Web traffic. Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3760"/>
          <seriesInfo name="DOI" value="10.17487/RFC3760"/>
        </reference>
        <reference anchor="RFC4251" target="https://www.rfc-editor.org/info/rfc4251" quoteTitle="true" derivedAnchor="RFC4251">
          <front>
            <title>The Secure Shell (SSH) Protocol Architecture</title>
            <author initials="T." surname="Ylonen" fullname="T. Ylonen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Lonvick" fullname="C. Lonvick" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="January"/>
            <abstract>
              <t indent="0">The Secure Shell (SSH) Protocol is a protocol for secure remote login and other secure network services over an insecure network.  This does not provide
              additional security value in cases in which document describes the calling site
              and architecture of the media peer are one in SSH protocol, as well as the same, but might be useful
              in cases in which third parties (e.g., ad networks or
              retailers) arrange for calls but do not participate notation and terminology used in them.
            </t>
          </section>

          <section title="Page Access to Media" anchor="sec.page-access">
            <t>
              Identifying SSH protocol documents.  It also discusses the identity SSH algorithm naming system that allows local extensions.  The SSH protocol consists of three major components: The Transport Layer Protocol provides server authentication, confidentiality, and integrity with perfect forward secrecy.  The User Authentication Protocol authenticates the far media endpoint is client to the server.  The Connection Protocol multiplexes the encrypted tunnel into several logical channels.  Details of these protocols are described in separate documents.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4251"/>
          <seriesInfo name="DOI" value="10.17487/RFC4251"/>
        </reference>
        <reference anchor="RFC4568" target="https://www.rfc-editor.org/info/rfc4568" quoteTitle="true" derivedAnchor="RFC4568">
          <front>
            <title>Session Description Protocol (SDP) Security Descriptions for Media Streams</title>
            <author initials="F." surname="Andreasen" fullname="F. Andreasen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Baugher" fullname="M. Baugher">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2006" month="July"/>
            <abstract>
              <t indent="0">This document defines a
              necessary but not sufficient condition Session Description Protocol (SDP) cryptographic attribute for providing unicast media
              security. In WebRTC, streams.  The attribute describes a cryptographic key and other parameters that serve to configure security for a unicast media flows are rendered into
              HTML5 MediaStreams which stream in either a single message or a roundtrip exchange.  The attribute can be manipulated by used with a variety of SDP media transports, and this document defines how to use it for the calling
              site. Obviously, if Secure Real-time Transport Protocol (SRTP) unicast media streams.  The SDP crypto attribute requires the site can modify or view services of a data security protocol to secure the media,
              then SDP message.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="4568"/>
          <seriesInfo name="DOI" value="10.17487/RFC4568"/>
        </reference>
        <reference anchor="RFC5479" target="https://www.rfc-editor.org/info/rfc5479" quoteTitle="true" derivedAnchor="RFC5479">
          <front>
            <title>Requirements and Analysis of Media Security Management Protocols</title>
            <author initials="D." surname="Wing" fullname="D. Wing" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="S." surname="Fries" fullname="S. Fries">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="F." surname="Audet" fullname="F. Audet">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2009" month="April"/>
            <abstract>
              <t indent="0">This document describes requirements for a protocol to negotiate a security context for SIP-signaled Secure RTP (SRTP) media.  In addition to the user natural security requirements, this negotiation protocol must interoperate well with SIP in certain ways.  A number of proposals have been published and a summary of these proposals is not getting in the level appendix of assurance they
              would expect from being able to authenticate their peer.
              In many cases, this is acceptable because document.  This memo provides information  for the user values
              site-based special effects over complete security from Internet community.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5479"/>
          <seriesInfo name="DOI" value="10.17487/RFC5479"/>
        </reference>
        <reference anchor="RFC5763" target="https://www.rfc-editor.org/info/rfc5763" quoteTitle="true" derivedAnchor="RFC5763">
          <front>
            <title>Framework for Establishing a Secure Real-time Transport Protocol (SRTP) Security Context Using Datagram Transport Layer Security (DTLS)</title>
            <author initials="J." surname="Fischl" fullname="J. Fischl">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Tschofenig" fullname="H. Tschofenig">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2010" month="May"/>
            <abstract>
              <t indent="0">This document specifies how to use the
              site. However, there are also cases where users wish Session Initiation Protocol (SIP) to
              know establish a Secure Real-time Transport Protocol (SRTP) security context using the Datagram Transport Layer Security (DTLS) protocol.  It describes a mechanism of transporting a fingerprint attribute in the Session Description Protocol (SDP) that identifies the site cannot interfere. In order to facilitate
              that, it key that will be necessary to provide features whereby presented during the site can verifiably give up access to DTLS handshake.  The key exchange travels along the media streams.
              This verification must be possible both from the local
              side and path as opposed to the remote side. I.e., users must signaling path.  The SIP Identity mechanism can be able used to verify
              that protect the person called has engaged integrity of the fingerprint attribute from modification by intermediate proxies.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5763"/>
          <seriesInfo name="DOI" value="10.17487/RFC5763"/>
        </reference>
        <reference anchor="RFC6189" target="https://www.rfc-editor.org/info/rfc6189" quoteTitle="true" derivedAnchor="RFC6189">
          <front>
            <title>ZRTP: Media Path Key Agreement for Unicast Secure RTP</title>
            <author initials="P." surname="Zimmermann" fullname="P. Zimmermann">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Johnston" fullname="A. Johnston" role="editor">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Callas" fullname="J. Callas">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="April"/>
            <abstract>
              <t indent="0">This document defines ZRTP, a secure protocol for media
              mode (see <xref target="sec.malicious"/>). In order to achieve this it will be necessary path Diffie-Hellman exchange to
              cryptographically bind an indication of the local agree on a session key and parameters for establishing unicast Secure Real-time Transport Protocol (SRTP) sessions for Voice over IP (VoIP) applications.  The ZRTP protocol is media
              access policy into the cryptographic authentication
              procedures detailed path keying because it is multiplexed on the same port as RTP and does not require support in the previous sections.
            </t>
            <t>
              It should be noted that signaling protocol.  ZRTP does not assume a Public Key Infrastructure (PKI) or require the use complexity of this secure media mode is
              left to certificates in end devices.  For the discretion of media session, ZRTP provides confidentiality, protection against man-in-the-middle (MiTM) attacks, and, in cases where the site. When such signaling protocol provides end-to-end integrity protection, authentication.  ZRTP can utilize a mode is
              engaged, the browser will need Session Description Protocol (SDP) attribute to provide indicia to the user
              that discovery and authentication through the associated signaling channel.  To provide best effort SRTP, ZRTP utilizes normal RTP/AVP (Audio-Visual Profile) profiles. ZRTP secures media has been authenticated as coming from
              the identified user.  This allows WebRTC services sessions that wish to
              claim end-to-end security to do so in include a way that voice media stream and can be easily
              verified by the user. This model requires that the remote
              party's browser be included in the TCB, as described in
              <xref target="sec.web-security"/>.
            </t>
          </section>
        </section>
        <section title="Malicious Peers" anchor="sec.malicious">
          <t>
            One class of attack also secure media sessions that we do not generally try to prevent
            is malicious peers. For instance, no matter what confidentiality
            measures you employ the person you are talking to might record
            the call and publish it on the Internet. Similarly, we do not attempt to prevent them from using include voice or video processing
            technology from hiding or changing their appearance.
            While technologies (DRM, etc.) do exist to attempt to address
            these issues, they are generally not compatible with open
            systems and WebRTC does by using an optional digital signature.  This document is not address them.
          </t>
          <t>
            Similarly, we make no attempt to prevent prank calling or
            other unwanted calls. In general, this an Internet  Standards Track specification; it is published for informational purposes.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6189"/>
          <seriesInfo name="DOI" value="10.17487/RFC6189"/>
        </reference>
        <reference anchor="RFC6222" target="https://www.rfc-editor.org/info/rfc6222" quoteTitle="true" derivedAnchor="RFC6222">
          <front>
            <title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</title>
            <author initials="A." surname="Begen" fullname="A. Begen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="April"/>
            <abstract>
              <t indent="0">The RTP Control Protocol (RTCP) Canonical Name (CNAME) is in the scope of the
            calling site, though because WebRTC does offer some forms of
            strong authentication, that may be useful as part of a defense
            against such attacks.
          </t>
        </section>
      </section>
      <section title="Privacy Considerations" anchor="sec.privacy">
        <section title="Correlation of Anonymous Calls">
          <t>
            While persistent transport-level identifier for an RTP endpoint.  While the Synchronization Source (SSRC) identifier of an RTP endpoint identifiers can be a useful security
            feature (see <xref target="sec.key-continuity"/>) they can
            also represent may change if a privacy threat in settings where collision is detected or when the user
            wishes RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be anonymous. WebRTC provides a number of possible
            persistent identifiers such as DTLS certificates
            (if they are reused between connections) uniquely identified and associated with their RTP media streams.  For proper functionality, RTCP CNAMES
            (if generated according to <xref target="RFC6222"/> rather
            than CNAMEs should be unique within the privacy preserving mode participants of <xref target="RFC7022"/>).
            In order an RTP session.  However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to prevent achieve this type uniqueness.  This memo updates those guidelines to allow endpoints to choose unique RTCP CNAMEs.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6222"/>
          <seriesInfo name="DOI" value="10.17487/RFC6222"/>
        </reference>
        <reference anchor="RFC6347" target="https://www.rfc-editor.org/info/rfc6347" quoteTitle="true" derivedAnchor="RFC6347">
          <front>
            <title>Datagram Transport Layer Security Version 1.2</title>
            <author initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Modadugu" fullname="N. Modadugu">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2012" month="January"/>
            <abstract>
              <t indent="0">This document specifies version 1.2 of correlation, browsers need the Datagram Transport Layer Security (DTLS) protocol.  The DTLS protocol provides communications privacy for datagram protocols.  The protocol allows client/server applications to
            provide mechanisms communicate in a way that is designed to reset these identifiers (e.g., with prevent eavesdropping, tampering, or message forgery.  The DTLS protocol is based on the
            same lifetime as cookies). Moreover, Transport Layer Security (TLS) protocol and provides equivalent security guarantees.  Datagram semantics of the API should provide
            mechanisms to allow sites intended for anonymous calling underlying transport are preserved by the DTLS protocol.  This document updates DTLS 1.0 to force work with TLS version 1.2.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6347"/>
          <seriesInfo name="DOI" value="10.17487/RFC6347"/>
        </reference>
        <reference anchor="RFC6454" target="https://www.rfc-editor.org/info/rfc6454" quoteTitle="true" derivedAnchor="RFC6454">
          <front>
            <title>The Web Origin Concept</title>
            <author initials="A." surname="Barth" fullname="A. Barth">
              <organization showOnFrontPage="true"/>
            </author>
            <date year="2011" month="December"/>
            <abstract>
              <t indent="0">This document defines the minting of fresh identifiers. In addition,
            IP addresses can be a source of call linkage
            <xref target="I-D.ietf-rtcweb-ip-handling"/>.
          </t>
        </section>

        <section title="Browser Fingerprinting">
          <t>
            Any new set of API features adds a risk concept of browser fingerprinting,
            and WebRTC an "origin", which is no exception. Specifically, sites can use often used as the
            presence scope of authority or absence privilege by user agents.  Typically, user agents isolate content retrieved from different origins to prevent malicious web site operators from interfering with the operation of specific devices as a browser fingerprint. benign web sites.  In general, the API needs addition to be balanced between functionality
            and outlining the incremental fingerprint risk.  See <xref target="Fingerprinting"/>.
          </t>
        </section>
      </section>
    </section>

    <section title="Security Considerations" anchor="sec.sec_cons">
      <t>This entire principles that underlie the concept of origin, this document is about security.</t>
    </section>

        <section title="Acknowledgements">
          <t>
            Bernard Aboba, Harald Alvestrand, Dan Druta,
            Cullen Jennings, Alan Johnston, Hadriel Kaplan (S 4.2.1), Matthew Kaufman,
            Martin Thomson, Magnus Westerlund.
          </t>
      <t></t>
    </section>

    <section title="IANA Considerations">
       <t>There are no IANA considerations.</t>
     </section>

    <section title="Changes Since -04">
      <t>
        <list style="symbols">
          <t>Replaced RTCWEB and RTC-Web with WebRTC, except when referring details how to determine the IETF WG</t>
          <t>Removed discussion origin of the IFRAMEd advertisement case, since we decided not to
          treat it specially.</t>
          <t>Added a privacy section considerations section.</t>
          <t>Significant edits to the SAS section to reflect Alan Johnston's comments.</t>
          <t>Added some discussion if IP location privacy URI and Tor.</t>
          <t>Updated the "communications consent" section how to reflrect draft-ietf.</t>
          <t>Added a section about "malicious peers".</t>
          <t>Added serialize an origin into a section describing screen sharing threats.</t>
          <t>Assorted editorial changes.</t>
        </list>
      </t>
    </section>
  </middle>

  <back>

    <references title="Normative References">
      &RFC2119;
      &RFC8174;
    </references>
    <references title="Informative References">
      &RFC3261;
      &RFC3552;
      &RFC3711;
      &RFC2818;
      &RFC5479;
      &RFC5763;
      &RFC6347;
      &RFC4568;
      &RFC4251;
      &RFC3760;
      &RFC6189;
      &RFC8445;
      &RFC6222;
      &RFC6454;
      &RFC6455;
      &RFC6749;
      &RFC7022;
      &RFC7033;
      &RFC7675;
      &I-D.ietf-rtcweb-security-arch;
      &I-D.ietf-rtcweb-ip-handling;
      &I-D.ietf-rtcweb-overview; string.  It also defines an HTTP header field, named "Origin", that indicates which origins are associated with an HTTP request.   [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6454"/>
          <seriesInfo name="DOI" value="10.17487/RFC6454"/>
        </reference>
        <reference anchor="abarth-rtcweb"> anchor="RFC6455" target="https://www.rfc-editor.org/info/rfc6455" quoteTitle="true" derivedAnchor="RFC6455">
          <front>
          <title>Prompting the user is security failure</title>
            <title>The WebSocket Protocol</title>
            <author initials="I." surname="Fette" fullname="I. Fette">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Barth">
            <organization></organization> surname="Melnikov" fullname="A. Melnikov">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date from PDF properties -->
            <date day="19" month="September" year="2010" /> year="2011" month="December"/>
            <abstract>
              <t indent="0">The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code.  The security model used for this is the origin-based security model commonly used by web browsers.  The protocol consists of an opening handshake followed by basic message framing, layered over TCP.  The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or &lt;iframe&gt;s and long polling).  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="" value="RTC-Web Workshop"/>
        <format target="http://rtc-web.alvestrand.com/home/papers/barth-security-prompt.pdf?attredirects=0" type="PDF"/> name="RFC" value="6455"/>
          <seriesInfo name="DOI" value="10.17487/RFC6455"/>
        </reference>
        <reference anchor="whitten-johnny"> anchor="RFC6749" target="https://www.rfc-editor.org/info/rfc6749" quoteTitle="true" derivedAnchor="RFC6749">
          <front>
          <title>Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0</title>

          <author initials="A." surname="Whitten">
            <organization></organization>
          </author>
            <title>The OAuth 2.0 Authorization Framework</title>
            <author initials="J.D." surname="Tygar">
            <organization></organization> initials="D." surname="Hardt" fullname="D. Hardt" role="editor">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date of USENIX Security Symposium -->
            <date month="August" year="1999" />
        </front>
        <seriesInfo name="" value="Proceedings year="2012" month="October"/>
            <abstract>
              <t indent="0">The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the 8th USENIX Security Symposium, 1999"/> resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf.  This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849.  [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="6749"/>
          <seriesInfo name="DOI" value="10.17487/RFC6749"/>
        </reference>
        <reference anchor="cranor-wolf"> anchor="RFC7022" target="https://www.rfc-editor.org/info/rfc7022" quoteTitle="true" derivedAnchor="RFC7022">
          <front>
          <title>Crying Wolf: An Empirical Study of SSL Warning Effectiveness</title>

          <author initials="J." surname="Sunshine">
            <organization></organization>
          </author>
            <title>Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)</title>
            <author initials="S." surname="Egelman">
            <organization></organization> initials="A." surname="Begen" fullname="A. Begen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="H." surname="Almuhimedi">
            <organization></organization> initials="C." surname="Perkins" fullname="C. Perkins">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="N." surname="Atri">
            <organization></organization> initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="L." surname="cranor">
            <organization></organization> initials="E." surname="Rescorla" fullname="E. Rescorla">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date of USENIX Security Symposium -->
            <date month="August" year="2009" />
        </front>

        <seriesInfo name="" value="Proceedings of year="2013" month="September"/>
            <abstract>
              <t indent="0">The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint.  While the 18th USENIX Security Symposium, 2009"/>

      </reference>

      <reference anchor="kain-conversion">
        <front>
          <title>Design and Evaluation Synchronization Source (SSRC) identifier of an RTP endpoint may change if a Voice Conversion Algorithm based on Spectral Envelope Mapping collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and Residual Prediction</title>

          <author initials="A." surname="Kain">
            <organization></organization>
          </author>

          <author initials="M." surname="Macon">
            <organization></organization>
          </author>

          <!-- Date associated with their RTP media streams.</t>
              <t indent="0">For proper functionality, RTCP CNAMEs should be unique within the participants of ICASSP 2001 -->
          <date month="May" year="2001" /> an RTP session.  However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard (RFC 3550) are insufficient to achieve this uniqueness.  RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs.  Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective.  This document addresses these concerns and replaces RFC 6222.</t>
            </abstract>
          </front>
          <seriesInfo name="" value="Proceedings of ICASSP, May 2001"/> name="RFC" value="7022"/>
          <seriesInfo name="DOI" value="10.17487/RFC7022"/>
        </reference>
        <reference anchor="farus-conversion"> anchor="RFC7033" target="https://www.rfc-editor.org/info/rfc7033" quoteTitle="true" derivedAnchor="RFC7033">
          <front>
          <title>Speaker Recognition Robustness to Voice Conversion</title>
            <title>WebFinger</title>
            <author initials="P." surname="Jones" fullname="P. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="M." surname="Farrus">
            <organization></organization> initials="G." surname="Salgueiro" fullname="G. Salgueiro">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="D." surname="Erro">
            <organization></organization> initials="M." surname="Jones" fullname="M. Jones">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Hernando">
            <organization></organization> surname="Smarr" fullname="J. Smarr">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date from http://www.researchgate.net/publication/228819912 -->
            <date month="January" year="2008" /> year="2013" month="September"/>
            <abstract>
              <t indent="0">This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods.  WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7033"/>
          <seriesInfo name="DOI" value="10.17487/RFC7033"/>
        </reference>
        <reference anchor="huang-w2sp"> anchor="RFC7675" target="https://www.rfc-editor.org/info/rfc7675" quoteTitle="true" derivedAnchor="RFC7675">
          <front>
          <title>Talking to Yourself
            <title>Session Traversal Utilities for Fun and Profit</title> NAT (STUN) Usage for Consent Freshness</title>
            <author initials="L-S." surname="Huang">
            <organization></organization> initials="M." surname="Perumal" fullname="M. Perumal">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E.Y." surname="Chen">
            <organization></organization> initials="D." surname="Wing" fullname="D. Wing">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="A." surname="Barth">
            <organization></organization> initials="R." surname="Ravindranath" fullname="R. Ravindranath">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="E." surname="Rescorla">
            <organization></organization> initials="T." surname="Reddy" fullname="T. Reddy">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jackson">
            <organization></organization> initials="M." surname="Thomson" fullname="M. Thomson">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date from PDF properties -->
            <date month="May" year="2011" /> year="2015" month="October"/>
            <abstract>
              <t indent="0">To prevent WebRTC applications, such as browsers, from launching attacks by sending traffic to unwilling victims, periodic consent to send needs to be obtained from remote endpoints.</t>
              <t indent="0">This document describes a consent mechanism using a new Session Traversal Utilities for NAT (STUN) usage.</t>
            </abstract>
          </front>
          <seriesInfo name="" value="W2SP, 2011"/> name="RFC" value="7675"/>
          <seriesInfo name="DOI" value="10.17487/RFC7675"/>
        </reference>
        <reference anchor="finer-grained"> anchor="RFC8445" target="https://www.rfc-editor.org/info/rfc8445" quoteTitle="true" derivedAnchor="RFC8445">
          <front>
          <title>Beware of Finer-Grained Origins</title>
            <title>Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal</title>
            <author initials="A." surname="Barth">
            <organization></organization> surname="Keranen" fullname="A. Keranen">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Jackson">
            <organization></organization> surname="Holmberg" fullname="C. Holmberg">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="J." surname="Rosenberg" fullname="J. Rosenberg">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date from PDF properties -->
            <date month="July" year="2008" /> year="2018" month="July"/>
            <abstract>
              <t indent="0">This document describes a protocol for Network Address Translator (NAT) traversal for UDP-based communication.  This protocol is called Interactive Connectivity Establishment (ICE).  ICE makes use of the Session Traversal Utilities for NAT (STUN) protocol and its extension, Traversal Using Relay NAT (TURN).</t>
              <t indent="0">This document obsoletes RFC 5245.</t>
            </abstract>
          </front>
          <seriesInfo name="" value="W2SP, 2008"/> name="RFC" value="8445"/>
          <seriesInfo name="DOI" value="10.17487/RFC8445"/>
        </reference>
        <reference anchor="CORS"> anchor="RFC8825" target="https://www.rfc-editor.org/info/rfc8825" quoteTitle="true" derivedAnchor="RFC8825">
          <front>
          <title>Cross-Origin Resource Sharing</title>
            <title>Overview: Real-Time Protocols for Browser-Based Applications</title>
            <author initials="A." surname="van Kesteren">
            <organization></organization> initials="H." surname="Alvestrand" fullname="Harald T. Alvestrand">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date from http://www.w3.org/TR/2014/REC-cors-20140116/ -->
            <date day="16" month="January" year="2014" /> year="2021"/>
          </front>
        <format target="http://www.w3.org/TR/cors/" type="TXT"/>
          <seriesInfo name="RFC" value="8825"/>
          <seriesInfo name="DOI" value="10.17487/RFC8825"/>
        </reference>
        <reference anchor="SWF"> anchor="RFC8827" target="https://www.rfc-editor.org/info/rfc8827" quoteTitle="true" derivedAnchor="RFC8827">
          <front>
          <title>SWF File Format Specification Version 19</title>
            <title>WebRTC Security Architecture</title>
            <author surname="Adobe">
          <organization></organization> initials="E." surname="Rescorla" fullname="Eric Rescorla">
              <organization showOnFrontPage="true"/>
            </author>

          <!-- Date from PDF properties -->
            <date day="23" month="April" year="2013" /> month="January" year="2021"/>
          </front>
        <format target="http://www.adobe.com/content/dam/Adobe/en/devnet/swf/pdf/swf_file_format_spec_v10.pdf" type="PDF"/>
          <seriesInfo name="RFC" value="8827"/>
          <seriesInfo name="DOI" value="10.17487/RFC8827"/>
        </reference>
        <reference anchor="XmlHttpRequest"> anchor="RFC8828" target="https://www.rfc-editor.org/info/rfc8828" quoteTitle="true" derivedAnchor="RFC8828">
          <front>
           <title>XMLHttpRequesti Level 2</title>
            <title>WebRTC IP Address Handling Requirements</title>
            <author initials="A." surname="van Kesteren">
                <organization></organization> initials="J" surname="Uberti" fullname="Justin Uberti">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="G" surname="Shieh" fullname="Guo-wei Shieh">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="17" month="January" year="2012"/> year="2021"/>
          </front>
          <format target="http://www.w3.org/TR/XMLHttpRequest/" type="TXT"/>
          <seriesInfo name="RFC" value="8828"/>
          <seriesInfo name="DOI" value="10.17487/RFC8828"/>
        </reference>
        <reference anchor="Fingerprinting"> anchor="SWF" target="https://www.adobe.com/content/dam/acom/en/devnet/pdf/swf-file-format-spec.pdf" quoteTitle="true" derivedAnchor="SWF">
          <front>
           <title>Fingerprinting Guidance for Web
            <title>SWF File Format Specification Authors (Draft)</title>

           <author surname="W3C">
               <organization></organization>
           </author> Version 19</title>
            <author/>
            <date day="24" month="November" year="2013" /> month="April" year="2013"/>
          </front>
         <format target="https://www.w3.org/TR/fingerprinting-guidance/#acknowledgement/" type="TXT"/>
        </reference>
        <reference anchor="OpenID"> anchor="whitten-johnny" target="https://www.usenix.org/legacy/publications/library/proceedings/sec99/whitten.html" quoteTitle="true" derivedAnchor="whitten-johnny">
          <front>
         <title>OpenID Connect Core 1.0</title>

            <author initials="N." surname="Sakimura">
                <organization></organization>
            </author>
            <author initials="J." surname="Bradley">
                <organization></organization>
            </author>
            <author initials="M." surname="Jones">
                <organization></organization>
            </author>
            <title>Why Johnny Can't Encrypt: A Usability Evaluation of PGP 5.0</title>
            <author initials="B." surname="de Medeiros">
                <organization></organization> initials="A." surname="Whitten">
              <organization showOnFrontPage="true"/>
            </author>
            <author initials="C." surname="Mortimore">
                <organization></organization> initials="J.D." surname="Tygar">
              <organization showOnFrontPage="true"/>
            </author>
            <date day="8" month="November" year="2014" /> month="August" year="1999"/>
          </front>
          <format target="https://openid.net/specs/openid-connect-core-1_0.html/" type="HTML"/>
          <refcontent>Proceedings of the 8th USENIX Security Symposium</refcontent>
        </reference>
      </references>
    </references>
    <section numbered="false" toc="include" removeInRFC="false" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">
            <contact fullname="Bernard Aboba"/>, <contact fullname="Harald             Alvestrand"/>, <contact fullname="Dan Druta"/>,
            <contact fullname="Cullen Jennings"/>, <contact fullname="Alan             Johnston"/>, <contact fullname="Hadriel Kaplan"/> (<xref target="sec.ice" format="default" sectionFormat="of" derivedContent="Section 4.2.1"/>), <contact fullname="Matthew Kaufman"/>,
            <contact fullname="Martin Thomson"/>, <contact fullname="Magnus Westerlund"/>.
      </t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-address">Author's Address</name>
      <author fullname="Eric Rescorla" initials="E." surname="Rescorla">
        <organization showOnFrontPage="true">Mozilla</organization>
        <address>
          <email>ekr@rtfm.com</email>
        </address>
      </author>
    </section>
  </back>
</rfc>