One document matched: draft-reddy-behave-turn-auth-01.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-01"
     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>TURN server plays a vital and is a building block to support direct,
      interactive, real-time communication using audio, video, collaboration,
      games, etc., between two peers web-browsers in Web Real-Time
      communication (WebRTC) <xref target="I-D.ietf-rtcweb-overview"> </xref>
      framework. The use-case explained in Section 4.2.4.1 of <xref
      target="I-D.ietf-rtcweb-use-cases-and-requirements"> </xref> refers to
      deploying a TURN<xref target="RFC5766"> </xref> server to audit all
      media sessions from inside an Enterprise premises to any external peer.
      TURN server could also be deployed for recording, 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 choose to use TURN so
          as to not expose the host candidate addresses to the remote peer for
          privacy.</t>

          <t>Enterprise networks deploy firewalls typically configured to
          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>IPv6 support in TURN includes 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 because endpoint is behind NAT that performs Address-dependent
          mapping and relayed candidate allocated from the TURN server gets
          selected for media.</t>
        </list></t>

      <t><xref target="RFC5389">STUN</xref> specifies an authentication
      mechanism called the long-term credential mechanism. TURN servers and
      clients are required to implement this mechanism. The server requires
      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.</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 auth protection.
   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 a tool 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 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. The long-term credential mechanism 
          in <xref target="RFC5389"></xref> is also susceptible to offline dictionary
          attacks. This attack can be mitigated by using strong passwords with
          large entropy.</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. Thus
          requiring management overhead to maintain credential database 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 host and later snoops the
          traffic from the host 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
      destination address of the request.  With TURN the only
      information available is the Source IP. Note this is a problem with multi-tenant scenarios only.
      This is not a problem when deployed in Enterprise.</t>
        </list></t>
    </section>

    <section anchor="security" title="Security Considerations">
      <t>This document does not define an architecture nor a protocol; as such
      it does not raise any security concern.</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, 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'
?>

      <?rfc include='reference.I-D.ietf-pcp-base'?>

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