draft-ietf-rtcweb-stun-consent-freshness.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc='yes'?>
<?rfc tocdepth="3"?>
<?rfc compact="yes"?>
<?rfc tocdepth="yes"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline ="yes"?>
<?rfc subcompact="no"?>
<?rfc tocompact="yes"?>
<?rfc colonspace="yes"?>
<rfc category="std" docName="draft-ietf-rtcweb-stun-consent-freshness-16"
 ipr="trust200902">
 <front>
 <title abbrev="STUN Usage for Consent Freshness">STUN Usage for Consent
 Freshness</title>

 <author fullname="Muthu Arul Mozhi Perumal" initials="M."
            surname="Perumal">
      <organization>Ericsson</organization>

      <address>
        <postal>
          <street>Ferns Icon</street>

          <street>Doddanekundi, Mahadevapura</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560037</code>

          <country>India</country>
        </postal>

        <email>muthu.arul@gmail.com</email>
      </address>
    </author>

    <author fullname="Dan Wing" initials="D" surname="Wing">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>821 Alder Drive</street>

          <city>Milpitas</city>

          <region>California</region>

          <code>95035</code>

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

        <email>dwing@cisco.com</email>
      </address>
    </author>

    <author fullname="Ram Mohan Ravindranath" initials="R"
            surname="Ravindranath">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Cessna Business Park</street>

          <street>Sarjapur-Marathahalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>rmohanr@cisco.com</email>
      </address>
    </author>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization>Cisco Systems</organization>

      <address>
        <postal>
          <street>Cessna Business Park, Varthur Hobli</street>

          <street>Sarjapur Marathalli Outer Ring Road</street>

          <city>Bangalore</city>

          <region>Karnataka</region>

          <code>560103</code>

          <country>India</country>
        </postal>

        <email>tireddy@cisco.com</email>
      </address>
    </author>

    <author fullname="Martin Thomson" initials="M." surname="Thomson">
      <organization>Mozilla</organization>

      <address>
        <postal>
          <street>Suite 300</street>

          <street>650 Castro Street</street>

          <city>Mountain View</city>

          <region>California</region>

          <code>94041</code>

          <country>US</country>
        </postal>

        <email>martin.thomson@gmail.com</email>
      </address>
    </author>

    <date />

    <area>RAI</area>

    <workgroup>RTCWEB</workgroup>

    <abstract>
      <t>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>This document describes a consent mechanism using a new Session
      Traversal Utilities for NAT (STUN) usage.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>To prevent attacks on peers, endpoints have to ensure the remote peer
      is willing to receive traffic. Verification of peer consent before sending
      traffic is necessary in deployments like WebRTC to ensure that a
      malicious JavaScript cannot use the browser as a platform for launching
      attacks. This is performed both when the session
      is first established to the remote peer using <xref
      target="RFC5245">Interactive Connectivity Establishment ICE</xref>
      connectivity checks, and periodically for the duration of the session
      using the procedures defined in this document.</t>

      <t>When a session is first established, ICE implementations obtain an
      initial consent to send by performing STUN connectivity checks. This
      document describes a new STUN usage with exchange of request and
      response messages that verifies the remote peer's ongoing consent to
      receive traffic. This consent expires after a period of time and needs
      to be continually renewed, which ensures that consent can be
      terminated.</t>

      <t>This document defines what it takes to obtain, maintain, and lose
      consent to send. Consent to send applies to a single 5-tuple. How
      applications react to changes in consent is not described in this
      document. The consent mechanism does not update the ICE procedures
      defined in <xref target="RFC5245"></xref>.</t>

      <t>Consent is obtained only by full ICE implementations. An ICE-lite
      agent (as defined in Section 2.7 of <xref target="RFC5245"></xref>) does
      not generate connectivity checks or run the ICE state machine. Hence, an
      ICE-lite agent does not generate consent checks and will only respond to
      any checks that it receives. No changes are required to ICE-lite
      implementations in order to respond to consent checks, as they are
      processed as normal ICE connectivity checks.</t>
    </section>

    <section anchor="sec-applic" title="Applicability">
      <t>This document defines what it takes to obtain, maintain, and lose
      consent to send using ICE. Section 4.4 and Section 5.3 of <xref
      target="I-D.ietf-rtcweb-security-arch"></xref> further explains the
      value of obtaining and maintaining consent.</t>

      <t>Other Applications that have similar security requirements to verify
      peer consent before sending non-ICE packets can use the consent
      mechanism described in this document. The mechanism of how applications
      are made aware of consent expiration is outside the scope of the
      document.</t>
    </section>

    <section anchor="sec-term" title="Terminology">
      <t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
      "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
      document are to be interpreted as described in <xref
      target="RFC2119"></xref>.</t>

      <t><list style="hanging">
          <t hangText="Consent:">The mechanism of obtaining permission from
          the remote endpoint to send non-ICE traffic to a remote transport
          address. Consent is obtained using ICE. Note that this is an 
          application-level consent; no human intervention is involved.</t>

          <t hangText="Consent Freshness:">Maintaining and renewing consent
          over time.</t>

          <t hangText="Transport Address:">The remote peer's IP address and
          UDP or TCP port number.</t>
        </list></t>
    </section>

    <section title="Design Considerations">
      <t>Although ICE requires periodic keepalive traffic to keep NAT bindings
      alive (Section 10 of <xref target="RFC5245"></xref>, <xref
      target="RFC6263"></xref>), those keepalives are sent as STUN Indications
      which are send-and-forget, and do not evoke a response. A response is
      necessary for consent to continue sending traffic. Thus, we need a
      request/response mechanism for consent freshness. ICE can be used for
      that mechanism because ICE implementations are already required to
      continue listening for ICE messages, as described in Section 10 of <xref
      target="RFC5245"></xref>. STUN binding requests sent for consent
      freshness also serve the keepalive purpose (i.e to keep NAT bindings
      alive). Because of that, dedicated keepalives (e.g. STUN Binding
      Indications) are not sent on candidate pairs where consent requests are
      sent, in accordance with Section 20.2.3 of <xref
      target="RFC5245"></xref>.</t>

      <t>When Secure Real-time Transport Protocol (SRTP) is used, the
      following considerations are applicable. SRTP is encrypted and
      authenticated with symmetric keys; that is, both sender and receiver
      know the keys. With two party sessions, receipt of an authenticated
      packet from the single remote party is a strong assurance the packet
      came from that party. However, when a session involves more than two
      parties, all of whom know each other's keys, any of those parties could
      have sent (or spoofed) the packet. Such shared key distributions are
      possible with some <xref target="RFC3830">MIKEY</xref> modes, <xref
      target="RFC4568">Security Descriptions</xref>, and <xref
      target="I-D.ietf-avtcore-srtp-ekt">EKT</xref>. Thus, in such shared
      keying distributions, receipt of an authenticated SRTP packet is not
      sufficient to verify consent.</t>

      <t>The mechanism proposed in the document is an optional extension to
      the ICE protocol, it can be deployed at one end of the two-party
      communication session without impact on the other party.</t>
    </section>

    <section title="Solution">
      <t>Initial consent to send traffic is obtained using <xref
      target="RFC5245">ICE</xref>. An endpoint gains consent to send on a
      candidate pair when the pair enters the Succeeded ICE state. This
      document establishes a 30 second expiry time on consent. 30 seconds was
      chosen to balance the need to minimize the time taken to respond to a
      loss of consent with the desire to reduce the occurrence of spurious
      failures.</t>

      <t>ICE does not identify when consent to send traffic ends. This
      document describes two ways in which consent to send ends: expiration of
      consent and immediate revocation of consent, which are discussed in the
      following sections.</t>

      <section title="Expiration of Consent">
        <t>A full ICE implementation obtains consent to send using ICE. After
        ICE concludes on a particular candidate pair and whenever the endpoint
        sends application data on that pair consent is maintained
        following the procedure described in this document.</t>

        <t>An endpoint MUST NOT send data other than the messages used to
        establish consent unless the receiving endpoint has consented to
        receive data. Connectivity checks that are paced as described in
        Section 16 of <xref target="RFC5245"></xref> and responses to
        connectivity checks are permitted. That is, no application data (e.g.,
        RTP or Datagram Transport Layer Security (DTLS)) can be sent until
        consent is obtained.</t>

        <t>Explicit consent to send is obtained and maintained by sending a
        STUN binding request to the remote peer's transport address and
        receiving a matching, authenticated, non-error STUN binding response
        from the remote peer's transport address. These STUN binding requests
        and responses are authenticated using the same short-term credentials
        as the initial ICE exchange. <list style="hanging">
            <t hangText="Note:">Although TCP has its own consent mechanism
            (TCP acknowledgements), consent is necessary over a TCP connection
            because it could be translated to a UDP connection (e.g., <xref
            target="RFC6062"></xref>).</t>
          </list></t>

        <t>Consent expires after 30 seconds. That is, if a valid STUN binding
        response has not been received from the remote peer's transport
        address in 30 seconds, the endpoint MUST cease transmission on that
        5-tuple. STUN consent responses received after consent expiry do not
        re-establish consent, and may be discarded or cause an ICMP error.</t>

        <t>To prevent expiry of consent, a STUN binding request can be sent
        periodically. To prevent synchronization of consent checks, each
        interval MUST be randomized from between 0.8 and 1.2 times the basic
        period. Implementations SHOULD set a default interval of 5 seconds,
        resulting in a period between checks of 4 to 6 seconds.
        Implementations MUST NOT set the period between checks to less than 4
        seconds. This timer is independent of the consent expiry timeout.</t>

        <t>Each STUN binding request for consent MUST use a new STUN
        transaction identifier, as described
        in Section 6 of <xref target="RFC5389"></xref>. Each STUN binding
        request for consent is transmitted once only. A sender therefore
        cannot assume that it will receive a response for every consent
        request, and a response might be for a previous request (rather than
        for the most recently sent request).</t>

        <t>An endpoint SHOULD await a binding response for each request it
        sends for a time based on the estimated round-trip time (RTT) (see
        Section 7.2.1 of <xref target="RFC5389"></xref>) with an allowance for
        variation in network delay. The RTT value can be updated as described
        in <xref target="RFC5389"></xref>. All outstanding STUN consent
        transactions for a candidate pair MUST be discarded when consent
        expires.</t>

        <t>To meet the security needs of consent, an untrusted application
        (e.g., JavaScript or signaling servers) MUST NOT be able to obtain or
        control the STUN transaction identifier, because that enables spoofing
        of STUN responses, falsifying consent.</t>

        <t>To prevent attacks on the peer during ICE restart, an endpoint that
        continues to send traffic on the previously validated candidate pair
        during ICE restart MUST continue to perform consent freshness on that
        candidate pair as described earlier.</t>

        <t>While TCP affords some protection from off-path attackers (<xref
        target="RFC5961"></xref>, <xref target="RFC4953"></xref>), there is
        still a risk an attacker could cause a TCP sender to send forever by
        spoofing ACKs. To prevent such an attack, consent checks MUST be
        performed over all transport connections, including TCP. In this way,
        an off-path attacker spoofing TCP segments cannot cause a TCP sender
        to send once the consent timer expires (30 seconds).</t>

        <t>An endpoint does not need to maintain consent if it does not send
        application data. However, an endpoint MUST regain consent before it
        resumes sending application data. In the absence of any packets, any
        bindings in middleboxes for the flow might expire. Furthermore, having
        one peer unable to send is detrimental to many protocols. Absent
        better information about the network, if an endpoint needs to ensure
        its NAT or firewall mappings do not expire, it can be done using
        keepalive or other techniques (see Section 10 of <xref
        target="RFC5245"></xref> and see <xref target="RFC6263"></xref>).</t>

        <t>After consent is lost, the same ICE credentials MUST NOT be used on
        the affected 5-tuple again. That means that a new session, or an ICE
        restart, is needed to obtain consent to send on the affected candidate
        pair.</t>
      </section>

      <section title="Immediate Revocation of Consent">
        <t>In some cases it is useful to signal that consent is terminated
        rather than relying on a timeout.</t>

        <t>Consent for sending application data is immediately revoked by
        receipt of an authenticated message that closes the connection (e.g.,
        a TLS fatal alert) or receipt of a valid and authenticated STUN
        response with error code Forbidden (403). Note however that consent
        revocation messages can be lost on the network, so an endpoint could
        resend these messages, or wait for consent to expire.</t>

        <t>Receipt of an unauthenticated message that closes a connection
        (e.g., TCP FIN) does not indicate revocation of consent. Thus, an
        endpoint receiving an unauthenticated end-of-session message SHOULD
        continue sending media (over connectionless transport) or attempt to
        re-establish the connection (over connection-oriented transport) until
        consent expires or it receives an authenticated message revoking
        consent.</t>

        <t>Note that an authenticated SRTCP BYE does not terminate consent; it
        only indicates the associated SRTP source has quit.</t>
      </section>
    </section>

    <section anchor="DSCP-consent" title="DiffServ Treatment for Consent">
      <t>It is RECOMMENDED that STUN consent checks use the same Diffserv
      Codepoint markings as the ICE connectivity checks described in Section
      7.1.2.4 of <xref target="RFC5245"></xref> for a given 5-tuple. <list
          style="hanging">
          <t hangText="Note:">It is possible that different Diffserv
          Codepoints are used by different media over the same transport
          address <xref target="I-D.ietf-tsvwg-rtcweb-qos"></xref>. Such a
          case is outside the scope of this document.</t>
        </list></t>
    </section>

    <section title="DTLS applicability">
      <t>The DTLS applicability is identical to what is described in Section
      4.2 of <xref target="RFC7350"></xref>.</t>
    </section>

    <section title="Security Considerations">
      <t>This document describes a security mechanism, details of which are
      mentioned in Section 4.1 and Section 4.2. Consent requires 96 bits
      transaction ID defined in section 6 of <xref target="RFC5389"/> to be
      uniformly and randomly chosen from the interval 0
      .. 2**96-1, and be cryptographically strong. This is good enough
      security against an off-path attacker replaying old STUN consent
      responses. Consent Verification to avoid attacks using a browser as an
      attack platform against machines is discussed in Sections 3.3 and 4.2 of
      <xref target="I-D.ietf-rtcweb-security"></xref>.</t>

      <t>The security considerations discussed in <xref
      target="RFC5245"></xref> should also be taken into account.</t>
    </section>

    <section anchor="sec.iana-considerations" title="IANA Considerations">
      <t>This document does not require any action from IANA.</t>
    </section>

    <section title="Acknowledgement">
      <t>Thanks to Eric Rescorla, Harald Alvestrand, Bernard Aboba, Magnus
      Westerlund, Cullen Jennings, Christer Holmberg, Simon Perreault, Paul
      Kyzivat, Emil Ivov, Jonathan Lennox, Inaki Baz Castillo, Rajmohan
      Banavi, Christian Groves, Meral Shirazipour and David Black for their
      valuable inputs and comments. Thanks to Christer Holmberg for doing a
      thorough review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?rfc include="reference.RFC.2119"?>

      <?rfc include="reference.RFC.5245"?>

      <?rfc include="reference.RFC.5389"?>
    </references>

    <references title="Informative References">
      <?rfc include="reference.RFC.3830"?>

      <?rfc include="reference.RFC.4568"?>

      <?rfc include="reference.RFC.6062"?>

      <?rfc include="reference.I-D.ietf-tsvwg-rtcweb-qos"?>

      <?rfc include="reference.I-D.ietf-avtcore-srtp-ekt"?>
      <?rfc include="reference.I-D.ietf-rtcweb-security-arch"?>
      <?rfc include="reference.RFC.6263"?>

      <?rfc include="reference.I-D.ietf-rtcweb-security"?>

      <?rfc include="reference.RFC.5961"?>

      <?rfc include="reference.RFC.4953"?>

      <?rfc include="reference.RFC.7350"?>
    </references>
  </back>
</rfc>