One document matched: draft-ietf-tram-auth-problems-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="info" docName="draft-ietf-tram-auth-problems-04"
     ipr="trust200902">
  <front>
    <title abbrev=" Problems with STUN Authentication for TURN">Problems with
    STUN long-term 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="R."
            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="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="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>TRAM</workgroup>

    <abstract>
      <t> This document discusses some of the security and practical problems
      with the current STUN authentication for TURN messages. </t>
    </abstract>
  </front>

  <middle>
    <section anchor="introduction" title="Introduction">
      <t>Traversal Using Relay NAT (TURN) <xref target="RFC5766"></xref> is a
      protocol that is often used to improve the connectivity of Peer-to-Peer
      (P2P) applications (as defined in section 2.7 of <xref
      target="RFC5128"></xref>). TURN allows a connection to be established
      when one or both sides is incapable of a direct P2P connection. The TURN
      server is also 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.</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
          DeMilitarized Zone (DMZ) might be used to traverse firewalls.</t>

          <t>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 server in the DMZ to audit all media sessions
          from inside an Enterprise premises to any external peer.</t>

          <t>TURN server could also be deployed for RTP Mobility <xref
          target="I-D.wing-tram-turn-mobility"></xref> etc.</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 <xref target="RFC5245"></xref> connectivity checks using
          server reflexive candidates could fail when the endpoint is behind
          NAT <xref target="RFC3235"></xref> that performs Address-dependent
          mapping as described in section 4.1 of <xref
          target="RFC4787"></xref>. 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 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, client
      authentication is essential 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 security and practical problems with
      current STUN authentication for TURN so that it can serve as the basis
      for stronger authentication mechanisms.</t>

      <t>An Allocate request is more likely than a Binding request 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>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 STUN long-term Authentication for TURN">
      <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 the 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. Long-term
          credentials (username, realm, and password) need to be stored on the
          server-side using MD5 hash over the credentials, which is not
          considered best current practice. <xref target="RFC6151"></xref>
          discusses security vulnerabilities of MD5 and encourages not to use
          it. It is not possible to use STUN long-term credentials in US FIPS
          140-2 <xref target="FIPS-140-2"></xref> compliant implementations,
          since MD5 isn't an approved algorithm.</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. If TURN
          usernames are linked to real usernames then it will result in
          privacy leakage, but 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>STUN authentication relies on HMAC-SHA1 <xref
          target="RFC2104"></xref>. There is no mechanism for hash agility in
          the protocol itself, although Section 16.3 of <xref
          target="RFC5389"></xref> does discuss a plan for migrating to a more
          secure algorithm in case HMAC-SHA1 is found to be compromised.</t>

          <t>A man-in-the middle 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 in the response, 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 code needs to 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. The malicious java script could misuse or leak
          the credentials. If the credentials happen to be used for accessing
          services other than TURN then the security implications are much
          larger.</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, Marc Petit-Huguenin, Gonzalo Camarillo,
      Brian E Carpenter, Spencer Dawkins and Simon Perreault for their
      comments and review.</t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      <?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.5128"?>

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

      <?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-tram-turn-mobility'?>

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

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

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

      <reference anchor="FIPS-140-2"
                 target="http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf">
        <front>
          <title>NIST, "Security Requirements for Cryptographic
          Modules"</title>

          <author fullname="NIST" surname="NIST">
            <organization></organization>
          </author>

          <date month="June" year="2005" />
        </front>
      </reference>

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