One document matched: draft-reddy-behave-turn-auth-04.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-reddy-behave-turn-auth-04"
     ipr="trust200902">
  <front>
    <title abbrev=" Problems with STUN Authentication for TURN">Problems with
    STUN Authentication for TURN</title>

    <author fullname="Tirumaleswar Reddy" initials="T." surname="Reddy">
      <organization abbrev="Cisco">Cisco Systems, Inc.</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="Ram Mohan Ravindranath" initials="Ram Mohan"
            surname="Ravindranath">
      <organization abbrev="Cisco">Cisco Systems, Inc.</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>rmohanr@cisco.com</email>
      </address>
    </author>

    <author fullname="Muthu Arul Mozhi Perumal" initials="Muthu A M"
            surname="Perumal">
      <organization abbrev="Cisco">Cisco Systems, Inc.</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="Alper Yegin" initials="A." surname="Yegin">
      <organization>Samsung</organization>

      <address>
        <postal>
          <street></street>

          <city>Istanbul</city>

          <region></region>

          <code></code>

          <country>Turkey</country>
        </postal>

        <email>alper.yegin@yegin.org</email>
      </address>
    </author>

    <date />

    <workgroup>BEHAVE</workgroup>

    <abstract>
      <t>This document discusses some of the issues with STUN authentication
      for TURN messages.</t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>The TURN server is a building block to support interactive, real-time
      communication using audio, video, collaboration, games, etc., between
      two peer web browsers using the Web Real-Time communication (WebRTC)
      <xref target="I-D.ietf-rtcweb-overview"> </xref> framework. The use-case
      explained in "Simple Video Communication Service, enterprise aspects"
      (Section 3.2.5 of <xref
      target="I-D.ietf-rtcweb-use-cases-and-requirements"> </xref>) refers to
      deploying a TURN<xref target="RFC5766"> </xref> server in the DMZ to
      audit all media sessions from inside an Enterprise premises to any
      external peer. TURN server could also be deployed for RTP Mobility <xref
      target="I-D.wing-mmusic-ice-mobility"> </xref> etc.</t>

      <t>TURN server is also used in the following scenarios:</t>

      <t><list style="symbols">
          <t>Users of RTCWEB based web application may use TURN server to hide
          host candidate addresses from the remote peer for privacy.</t>

          <t>Enterprise networks deploy firewalls which typically block UDP
          traffic. When SIP user agents or WebRTC endpoints are deployed
          behind such firewalls, media cannot be sent over UDP across the
          firewall, but must be sent using TCP (which causes a different user
          experience). In such cases a TURN server deployed in the DMZ MAY be
          used to traverse Firewalls.</t>

          <t>TURN Server may be used for IPv4-to-IPv6, IPv6-to-IPv6, and IPv6
          -to-IPv4 relaying <xref target="RFC6156"></xref>.</t>

          <t>ICE connectivity checks using server-reflexive candidates could
          fail when the endpoint is behind NAT that performs Address-dependent
          mapping. In such cases relayed candidate allocated from the TURN
          server is used for media.</t>
        </list></t>

      <t><xref target="RFC5389">STUN</xref> specifies an authentication
      mechanism called the long-term credential mechanism. <xref
      target="RFC5766">TURN </xref> in section 4 specifies that TURN servers
      and clients MUST implement this mechanism and the TURN server MUST
      demand that all requests from the client be authenticated using this
      mechanism, or that a equally strong or stronger mechanism for client
      authentication be used.</t>

      <t>In the above scenarios RTCWEB based web applications would use
      Interactive Connectivity Establishment (ICE) protocol <xref
      target="RFC5245"> </xref> for gathering candidates. ICE agent can use
      TURN to learn server-reflexive and relayed candidates. If the TURN
      server requires the TURN request to be authenticated then ICE agent will
      use the long-term credential mechanism explained in section 10 of <xref
      target="RFC5389"> </xref> for authentication and message integrity. TURN
      specification <xref target="RFC5766"> </xref> in section 10 explains the
      importance of long-term credential mechanism to mitigate various
      attacks. With proposals like<xref
      target="I-D.thomson-mmusic-rtcweb-bw-consent"> </xref> that defines a
      STUN BANDWIDTH attribute for requesting bandwidth allocation at a TURN
      server, STUN authentication becomes further important to prevent
      un-authorized users from accessing the TURN server and misuse of
      credentials could impose significant cost on the victim TURN server.</t>

      <t>This note focuses on listing the problems with current STUN
      authentication for TURN so that it can serve as the basis for stronger
      authentication mechanisms.</t>

      <t>Compared to a Binding request the Allocate request is more likely to
      be identified by a server administrator as needing client authentication
      and integrity protection of messages exchanged. Hence, the issues
      discussed here in STUN authentication are applicable mainly in the
      context of TURN messages.</t>
    </section>

    <section anchor="notation" title="Notational Conventions">
      <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>This note uses terminology defined in <xref target="RFC5389"></xref>,
      <xref target="RFC5766"> </xref>.</t>
    </section>

    <section title="Scope">
      <t>This document can be used as an input to design solution(s) to
      address the problems with the current STUN authentication for TURN
      messages.</t>
    </section>

    <section anchor="TURN_Auth"
             title="Problems with usage of STUN Authentication">
      <t><list style="numbers">
          <t>The long-term credential mechanism in <xref
          target="RFC5389"></xref> could use traditional "log-in" username and
          password given to users which does not change for extended periods
          of time and uses the key derived from user credentials to generate
          message integrity for every TURN request/response. An attacker that
          is capable of eavesdropping on a message exchange between a client
          and server can determine the password by trying a number of
          candidate passwords and checking if one of them is correct by
          calculating the message-integrity of the message using these
          candidate passwords and comparing with the message integrity value
          in the MESSAGE-INTEGRITY attribute.</t>

          <t>When TURN server is deployed in DMZ and requires requests to be
          authenticated using the long-term credential mechanism in <xref
          target="RFC5389"> </xref>, TURN server needs to be aware of the
          username and password to validate the message integrity of the
          requests and to provide message integrity for responses. This
          results in management overhead on the TURN server. </t>

          <t>The long-term credential mechanism in <xref
          target="RFC5389"></xref> requires that the TURN client must include
          username value in the USERNAME STUN attribute. An adversary snooping
          the TURN messages between the TURN client and server can identify
          the users involved in the call resulting in privacy leakage. In
          certain scenarios TURN usernames need not be linked to any real
          usernames given to users as they are just provisioned on a per
          company basis.</t>

          <t>An Attacker posing as a TURN server challenges the client to
          authenticate, learns the USERNAME of the client and later snoops the
          traffic from the client identifying the user activity resulting in
          privacy leakage.</t>

          <t>Hosting multiple realms on a single IP address is challenging
          with TURN. When a TURN server needs to send the REALM attribute in
          response to an unauthenticated request, it has no useful information
          for determining which realm it should send, except the source
          transport address of the TURN request. Note this is a problem with
          multi-tenant scenarios only. This may not be a problem when TURN
          server is located in enterprise premises.</t>

          <t>In WebRTC the Javascript needs be know the username and password
          to use in W3C RTCPeerConnection API to access the TURN server. This
          exposes the user credentials to the Javascript which could be
          malicious.</t>
        </list></t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document lists problems with current STUN authentication for
      TURN so that it can serve as the basis for stronger authentication
      mechanisms.</t>
    </section>

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

    <section title="Acknowledgments">
      <t>Authors would like to thank Dan Wing, Harald Alvestrand, Sandeep Rao,
      Prashanth Patil, Pal Martinsen and Simon Perreault for their comments
      and review.</t>
    </section>
  </middle>

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

      <?rfc include='reference.RFC.5766'?>

      <?rfc include='reference.RFC.5389'?>

      <?rfc include='reference.RFC.6156'?>
    </references>

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

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

      <?rfc include='reference.I-D.ietf-rtcweb-use-cases-and-requirements'?>

      <?rfc include='reference.I-D.ietf-rtcweb-overview'?>

      <?rfc include='reference.I-D.wing-mmusic-ice-mobility'
?>

      <?rfc include='reference.I-D.thomson-mmusic-rtcweb-bw-consent'
?>

      <!---->
    </references>
  </back>
</rfc>