One document matched: draft-muthu-behave-consent-freshness-04.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 category="std" docName="draft-muthu-behave-consent-freshness-04"
     ipr="trust200902">
  <front>
    <title abbrev="STUN Usage for Consent Freshness">STUN Usage for Consent
    Freshness</title>

    <author fullname="Muthu Arul Mozhi Perumal" initials="Muthu A M"
            surname="Perumal">
      <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>mperumal@cisco.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>

    <date year="2013" />

    <area>Transport</area>

    <workgroup>Behave</workgroup>

    <abstract>
      <t>Verification of peer consent before sending traffic is necessary in
      WebRTC deployments to ensure that a malicious JavaScript cannot use the
      browser as a platform for launching attacks. A related problem is
      session liveness. WebRTC application may want to detect connection
      failure and take appropriate action.</t>

      <t>This document describes how a WebRTC browser can verify peer consent
      to continue sending traffic and detect connection failure.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>To prevent attacks on WebRTC peers, WebRTC browsers have to ensure
      the remote peer wants to receive traffic. This is performed both when
      the session is first established to the remote peer (using ICE
      connectivity checks), and periodically when for the duration of the
      session (using the procedure defined in this document).</t>

      <t>When a session is first established, WebRTC implementations are
      required to perform STUN connectivity checks as part of <xref
      target="RFC5245">ICE</xref>. That initial consent is not described
      further in this document. </t>

      <t>Related to consent is loss of connectivity ("liveness"). WebRTC
      applications want notification of connection failure to take appropriate
      actions (e.g., alert the user, try switching to a different interface).
      </t>

      <t>This document describes a new STUN usage with a request and response
      which verifies the remote peer consents to receive traffic, and detects
      loss of liveness. To meet the security needs of consent, the JavaScript
      application has no control over the consent requests or the requirement
      to receive a consent response. However, the JavaScript does get
      notification of consent failure and loss of connectivity.</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:">It is the mechanism of obtaining permission
          from the peer to send traffic on a candidate pair.</t>

          <t hangText="Consent Freshness:">It is the mechanism of obtaining
          permission from the peer to continue sending traffic on a nominated
          candidate pair after ICE has concluded.</t>

          <t hangText="Session Liveness:">It is the mechanism of detecting
          connectivity on a nominated candidate pair after ICE has
          concluded.</t>

          <t hangText="Transport Address:">The combination of an IP address
          and port number (such as a UDP or TCP port number).</t>
        </list></t>
    </section>

    <section title="Design Considerations">
      <t>Although ICE requires periodic keepalive traffic to be sent in order
      to keep NAT bindings alive (Section 10 of <xref
      target="RFC5245"></xref>, <xref target="RFC6263"></xref>), those
      keepalives are send-and-forget, and do not evoke a response. A response
      is necessary both for consent to continue sending traffic, as well as to
      ensure connectivity. Thus, we need a request/response mechanism.</t>

      <t>Though ICE specifies STUN Binding indications to be used for
      keepalives, it requires that an agent be prepared to receive
      connectivity check as well. If a connectivity check is received, a
      response is generated, but there is no impact on ICE processing, as
      described in section 10 of <xref target="RFC5245"></xref>.</t>

      <t>While a WebRTC browser could verify whether the peer continues to
      send SRTCP reports before sending traffic to the peer, the usage of
      SRTCP together with <xref target="RFC4568">Security Descriptions</xref>
      requires exposing the media keys to the JavaScript and renders SRTCP
      unsuitable for consent freshness.</t>

      <t>For consent, calculating the SHA1 HMAC is necessary for
      MESSAGE-INTEGRITY which is computationally expensive. Security analysis
      concluded that the STUN 96 bits transaction ID is sufficient for
      consent, without needing MESSAGE-INTEGRITY. However, omitting the
      MESSAGE-INTEGRITY attribute from STUN Binding request/response to avoid
      the cost of computing SHA1 would make browsers incapable of verifying
      consent freshness with legacy ICE/ICE-lite implementations, resulting in
      backward compatibility issues.</t>

      <t>The above considerations suggest that STUN Binding request/response
      is most suitable for performing consent freshness.</t>
    </section>

    <section title="Solution Overview">
      <t>Consent freshness serves as a circuit breaker (so that if the path or
      remote peer fails the WebRTC browser stops sending all traffic on that
      remote peer), determining session liveness serves the purpose of
      notifying the application of connectivity failure so that the
      application can take appropriate action.</t>

      <t>The solution uses three values:</t>

      <t><list style="numbers">
          <t>A consent timer, Tc, whose value is determined by the browser.
          This value MUST be 15 seconds.</t>

          <t>A packet receipt timer, Tr, whose value is determined by the
          application, but MUST NOT be shorter than 1 second or longer than 15
          seconds, and SHOULD have a default value of 5 seconds.</t>

          <t>A consent timeout, Tf, which is how many seconds elapse without a
          consent response before the browser ceases transmission of media.
          Its value MUST be 15 seconds or less, and the value 15 seconds is
          RECOMMENDED.</t>
        </list></t>

      <t>A WebRTC browser performs a combined consent freshness and session
      liveness test using STUN request/response as described below:</t>

      <t>Every Tc seconds, the WebRTC browser sends a STUN Binding Request to
      the peer. This request MUST use a new, cryptographically random
      Transaction ID <xref target="RFC4086"></xref>, and is formatted as for
      an <xref target="RFC5245">ICE connectivity check</xref>. A valid STUN
      Binding Response is also formatted as for an <xref target="RFC5245">ICE
      connectivity check</xref>. The STUN Binding Request and STUN Binding
      Response are validated as for an <xref target="RFC5245">ICE connectivity
      check</xref>.</t>

      <t>If a valid STUN Binding Response is received, the consent timer is
      reset and fires again Tc seconds later.</t>

      <t>If a valid STUN Binding Response is not received after 500ms, the
      STUN Binding Request is retransmitted (with the same Transaction ID and
      all other fields). As long as a valid STUN Binding Response is not
      received, this retransmission is repeated every 500ms until Tf seconds
      have elapsed or a valid response is received. If no valid response is
      received after Tf seconds, the WebRTC browser MUST quit transmitting
      traffic to this remote peer. Considering the default value of Tf=15
      seconds, this means transmission will stop after 30 consent check
      packets have resulted in no response.</t>

      <t>Liveness timer: If no packets have been received on the local port in
      Tr seconds, the WebRTC browser MUST inform the JavaScript that
      connectivity has been lost. The JavaScript application will use this
      notification however it desires (e.g., cease transmitting to the remote
      peer, provide a notification to the user, etc.). Note the definition of
      a received packet is liberal, and includes an SRTP packet that fails
      authentication, a STUN Binding Request with an invalid USERNAME or
      PASSWORD, or any other packet.</t>
    </section>

    <section title="W3C API Implications">
      <t>For the consent freshness and liveness test the W3C specification
      should provide APIs as described below: <list style="numbers">
          <t>Ability for the browser to notify the JavaScript that a consent
          freshness transaction has failed for a media stream and the browser
          has stopped transmitting for that stream.</t>

          <t>Ability for the JavaScript to start and stop liveness test and
          set the liveness test interval.</t>

          <t>Ability for the browser to notify the JavaScript that a liveness
          test has failed for a media stream.</t>
        </list></t>
    </section>

    <section title="Interaction with Keepalives used for Refreshing NAT Bindings">
      <t>When not actively sending traffic on a nominated candidate pair,
      performing consent freshness does not serve any purpose from a security
      perspective. If consent freshness is not performed during this period,
      the browser continues to performs the ICE keepalives <xref
      target="RFC5245"> </xref> or RTP keepalive <xref
      target="RFC6263"></xref> to refresh NAT bindings.</t>
    </section>

    <section title="Security Considerations">
      <t>Security considerations discussed in <xref target="RFC5245"></xref>
      are to be taken into account.</t>

      <t>In <xref target="RFC5245">ICE</xref> the STUN request/response are
      protected with MESSAGE-INTEGRITY, using an ephemeral username and
      password exchanged in the SDP ice-ufrag and ice-pwd attributes. This
      prevents ICE from accidentally connecting to an in-intended peer, in
      that ICE will only connect to a peer that also knows the same username
      and password (exchanged in call signaling). Once that connection to the
      remote peer has been established with ICE, the consent to continue
      sending traffic does not benefit from re-asserting that same username
      and password, so long as the senders and receiver's IP addresses remain
      the same (as they usually do).</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, Martin Thomson, Bernard
      Aboba, Cullen Jennings and Simon Perreault for their valuable inputs and
      comments.</t>
    </section>
  </middle>

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

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

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

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

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