One document matched: draft-johnston-rtcweb-zrtp-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" >
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-johnston-rtcweb-zrtp-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN"
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>

    <title abbrev="ZRTP and WebRTC">Using ZRTP to Secure WebRTC</title>

    <author fullname="Alan Johnston" initials="A.J."
            surname="Johnston">
      <organization>Avaya</organization>

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

          <city>St. Louis</city>

          <region>MO</region>

          <code></code>

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

        <phone></phone>

        <email>alan.b.johnston@gmail.com</email>

      </address>
    </author>


    <author fullname="Phil Zimmermann" initials="P."
            surname="Zimmermann">
      <organization>Silent Circle</organization>

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

          <city>Santa Cruz</city>

          <region>CA</region>

          <code></code>

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

        <phone></phone>

        <email>prz@mit.edu</email>

      </address>
    </author>

    <author fullname="Jon Callas" initials="J."
            surname="Callas">
      <organization>Silent Circle</organization>

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

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>jon@callas.org</email>

      </address>
    </author>


     <author fullname="Travis Cross" initials="T."
            surname="Cross">
      <organization>OfficeTone</organization>

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

          <city></city>

          <region></region>

          <code></code>

          <country></country>
        </postal>

        <phone></phone>

        <email>tc@traviscross.com</email>

      </address>
    </author>


    <author fullname="John Yoakum" initials="J."
            surname="Yoakum">
      <organization>Avaya</organization>

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

          <city>Cary</city>

          <region>NC</region>

          <code></code>

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

        <phone></phone>

        <email>yoakum@avaya.com</email>

      </address>
    </author>



    <date month="August" year="2013" />

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill
         in the current day for you. If only the current year is specified, xml2rfc will fill
         in the current day and month for you. If the year is not the current one, it is
         necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
         purpose of calculating the expiry date).  With drafts it is normally sufficient to
         specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>RAI</area>

    <workgroup>Internet Engineering Task Force</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.
         If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>zrtp</keyword>
    <keyword>webrtc</keyword>
    <keyword>rtcweb</keyword>
    <keyword>security</keyword>
    <keyword>srtp</keyword>
    <keyword>mitm</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>WebRTC, Web Real-Time Communications, is a set of protocols and APIs used to enable web developers to add real-time communications into their web pages and applications with a few lines of JavaScript.  WebRTC media flows are encrypted and authenticated by SRTP, the Secure Real-time Transport Protocol while the key agreement is provided by DTLS-SRTP, Datagram Transport Layer Security for Secure Real-time Transport Protocol.  However, without some third party identity service or certificate authority, WebRTC media flows have no protection against a man-in-the-middle (MitM) attack.  ZRTP, Media Path Key Agreement for Unicast Secure RTP, RFC 6189, does provide protection against MitM attackers using key continuity augmented with a Short Authentication String (SAS).  This specification describes how ZRTP can be used over the WebRTC data channel to provide MitM protection for WebRTC media flows keyed using DTLS-SRTP.  This provides users protection against MitM attackers without requiring browsers to support ZRTP or users to download a plugin or extension to implement ZRTP. </t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
<t>
WebRTC, Web Real-Time Communications, adds real-time, interactive voice and video media capabilities to browsers <xref target="I-D.ietf-rtcweb-overview" /> without a plugin or download, and allows web developers to access this functionality using JavaScript API calls <xref target="WebRTC-API" />.  For a complete description of WebRTC protocols and APIs see <xref target="WebRTC-Book" />.  In addition, WebRTC supports the establishment of a peer-to-peer data channel between browsers <xref target="I-D.ietf-rtcweb-data-channel" />.  This document describes how ZRTP, Media Path Key Agreement for Unicast Secure RTP, <xref target="RFC6189" />,  can be used over the WebRTC data channel to secure voice and video sessions established using WebRTC.
 </t>
 <t>
The security of voice and video media sessions established using WebRTC is described in <xref target="I-D.ietf-rtcweb-security" />.  All media sessions utilize SRTP encryption and authentication, which relies on DTLS-SRTP for key management.  DTLS-SRTP can utilize TLS modes offering perfect forward secrecy (PFS), but relies on the exchange of fingerprints for protection against Man-in-the-Middle (MitM) attacks <xref target="RFC5763" />.  A mechanism for utilizing trusted third parties, known as Identity Providers, to authenticate the fingerprint is also described.  ZRTP always offers perfect forward secrecy, and protects against MitM attacks with key continuity, Short Authentication Strings (SAS), and optionally and additionally, with long-term signing keys or shared secrets.  For subsequent calls between the same ZRTP endpoints, a hash of previous keying material is mixed in when generating the current keying material.  In addition, the SAS can be used to confirm the absence of a MitM attack over the entire lifetime of the key continuity (going both backwards and forwards in time). Both parties in the communication must have ZRTP software, which performs a DH key agreement and are capable of storing a cache of previous shared secrets and rendering the SAS to the users.  The human users then have the option to compare the SAS's to see if they match to confirm the absence of a MitM attacker.  This could be done by verbally reading aloud the string (which can be two words or four hex characters), or otherwise exchanging them.  If the SAS values match, then there is no MitM attacker.  ZRTP is signaling channel and protocol independent, and does not rely on ANY third party services for authentication (though it can optionally and additionally leverage a public key infrastructure (PKI)).  As such, ZRTP has been used with SIP, Jingle, and proprietary signaled VoIP systems.  There are a number of open source ZRTP stacks and commercial implementations and products.  For the reasons why ZRTP is a good fit for WebRTC, see <xref target="I-D.johnston-rtcweb-media-privacy" />. </t>
 <t>
ZRTP is not currently built into the browser like DTLS-SRTP.  However, this doesn't mean that ZRTP cannot be used with WebRTC.  ZRTP can be implemented in JavaScript and run over the WebRTC data channel between the browsers.  The format and message flow can be identical to RFC 6189, with the exception that instead of ZRTP running on UDP, it runs on top of SCTP/DTLS/UDP.  A small change in the policy usage of the ZRTP auxsecret provides MitM protection for media sessions established by WebRTC between the browsers.
</t>
<t>
This allows the ZRTP SAS to be used to authenticate WebRTC media sessions for WebRTC applications that include ZRTP JavaScript.  Also, since the ZRTP data channel can be used to authenticate all WebRTC Peer Connections between a pair of browsers, a ZRTP WebRTC application could be used to authenticate and protect other WebRTC sessions that do not even use ZRTP.  For example, users of a particular WebRTC service which claims to offer end-to-end media privacy could use a ZRTP-enabled WebRTC application in another tab or window to verify that assertion or audit the service and protect against MitM attacks.
</t>
      <section title="Requirements Language">
        <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">RFC 2119</xref>.</t>
      </section>
    </section>

<section title="ZRTP over a WebRTC Data Channel">
<t>
In the base ZRTP protocol <xref target="RFC6189" />, ZRTP uses UDP transport, multiplexed over the same port as the media session that it is keying.  ZRTP over a WebRTC data channel means that ZRTP messages are sent over the SCTP/DTLS/UDP protocol stack.  It is RECOMMENDED that SCTP reliability be used so that the ZRTP timer and retransmissions in Section 6 of <xref target="RFC6189" /> are not needed.  The state machine is identical, with the exchange beginning with the Hello and ending with the ConfACK.  The ZRTP Hello Hash MAY be exchanged over the WebRTC signaling channel.  The ZID MAY be statelessly generated by hashing the DTLS-SRTP fingerprint of the browser.  Also, the ZRTP cache of previous shared secrets can be stored in a number of ways, including indexed database, HTML5 file system, or even as a cookie.
</t>
<t>
In order to provide protection against a MitM attack of WebRTC media sessions, ZRTP needs to:
</t>
<t>
<list style="symbols">
<t> Verify that both browsers see the same local and remote fingerprint used by DTLS-SRTP.  This is accomplished by always including the DTLS-SRTP fingerprints in the ZRTP auxsecret.</t>
<t> Verify that there is no MitM attack against ZRTP.  This is accomplished by the various mechanisms ZRTP provides, including key continuity and human users comparing the SAS.</t>
</list>
</t>
<t>
The ZRTP auxsecret is defined in Section 4.3 of <xref target="RFC6189" />. This specification defines the following new policies relating to the usage of auxsecret when ZRTP is used to secure DTLS-SRTP media sessions.
</t>
<t>
The auxsecret MUST be used.  The auxsecret is truncated to the negotiated hash length (defined in Section 4.5.1 of <xref target="RFC6189" />) of:
</t>
<t>
<figure><artwork><![CDATA[
     auxsecret = hash(initiator's DTLS-SRTP fingerprint ||
                      responder's DTLS-SRTP fingerprint ||
                      original_auxsecret)
]]></artwork></figure>
</t>
<t>
The original_auxsecret is any auxsecret value that would otherwise have been used with ZRTP, or the null string if no such value exists as will ordinarily be the case.
</t>
<t>
Note that this auxsecret is actually not a secret, since the fingerprints are hashes of known public keys used by the browsers.  This does not affect the security of ZRTP.
</t>
<t>If the auxsecrets of the initiator and responder do not match, this MUST be treated as a MitM attack.  This is to protect against the case where the DTLS-SRTP session has an MitM attacker but the ZRTP session does not.  Note that this can be done as soon as the DHPart1 and DHPart2 messages have been exchanged and can be done automatically without calculating or comparing the SAS.</t>
<t>
Any failure in the ZRTP exchange MUST be treated as a MitM attack.
</t>
<t>
Detection of a MitM attack MUST result in the closure of the DTLS-SRTP sessions and alerting the browser users.
</t>
<t>
If the users successfully compare the SAS strings, it means that neither the DTLS nor the ZRTP sessions have MitM attackers.  Any media sessions which were established using this same pair of local and remote fingerprints also do not have MitM attackers, regardless of which browser tab or window they are present in.</t>
<t>
This specification requires DTLS to use a Forward Secrecy (FS) mode.  If a FS mode is not available, the DTLS connection MUST fail.
</t>
</section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

    </section>

<section anchor="Security" title="Security Considerations">
<t>
For the security analysis of this approach, consider a pair of browsers, used by Alice and Bob which have established at a minimum a voice media session and a ZRTP data channel.  There are two possibilities:</t>
<t>
        <list style="symbols">
                <t>Both the media and data run over the same DTLS connection, or</t>
                <t>The media and data run over separate DTLS connections.</t>
    </list>
</t>
<t>
As such, an attacker could choose to attack any combination of these connections and the DTLS and/or ZRTP protocols.  However, note that since ZRTP runs on top of DTLS, it is not possible to MitM ZRTP without first launching a MitM attack on the DTLS connection over which it runs.  In the following analysis, "attacking the media channel" means a MitM attack launched against the DTLS session used to establish the voice media session, and "attacking the data channel" means a MitM attack against ZRTP and the DTLS session over which ZRTP runs.</t>
<t>
Given these two possibilities, the attacker could choose to attack:</t>
<t>
        <list style="symbols">
                <t>Both the media and data channel,</t>
                <t>Just the media channel,</t>
                <t>Just the data channel, or</t>
        <t>Neither media or data channel.</t>
    </list>
These will be considered in turn.  Note that a MitM attack launched against DTLS-SRTP will result in the remote fingerprint as seen by each browser to be that of the attacker instead of the other browser.
</t>
<t>
If the MitM attacks both the media and the data channel, the SAS as computed by each browser will be different, and the users can detect this by verbally comparing the SAS.  Additionally, if the users have communicated before without a MitM attacker, the presence of the MitM will create a break in key continuity and the users will be alerted that they should verify the SAS.
</t>
<t>
If the MitM attacks just the media channel, after the exchange of DHPart1 and DHPart2 messages, the different fingerprints will be detected by checking the hashed auxsecret values and discovering that they do not match.  The MitM attack is immediately and automatically detected.
</t>
<t>
If the MitM attacks just the data channel, the SAS as computed by each browser will be different as two independent DH exchanges occurred.  If the users have spoken before, the MitM will cause a break in key continuity.  In any case, the MitM will be definitively detected by comparing ZRTP's SAS.  Note that it doesn't make much sense for the MitM to attack just the data channel, but this could happen.
</t>
<t>
If the MitM attacks neither the media nor the data channel, the auxsecrets will match, the SAS as computed by each browser will be the same, and key continuity will be maintained.  As a result, both the ZRTP and media session are free of MitM attackers.
</t>
<t>
Note that only in one scenario does this approach rely on the users comparing the SAS -- and even there, the users would likely be protected by key continuity even if the SAS were not manually checked.  Also, note that all these attacks rely on the attacker being able to insert herself in the path as a MitM.  For the scenario in which the media channel and data channel use different DTLS connections, it could be potentially difficult for the attacker to insert herself as a MitM in the data channel as it could take a complete different route over the Internet from the media channel.  For example, the data channel used by ZRTP could be deliberately routed over a different IP connection or via a TURN server forcing a different path that may not accessible to the attacker.
</t>
<t>
In summary, this approach can be thought of as having three distinct layers.  The first layer is the DTLS session, which protects against passive attacks but has no protection against a MitM attack without a third party service.  The next layer is the ZRTP session, which allows the fingerprints to be exchanged and compared.  A fingerprint mismatch allows a MitM attack on DTLS to be detected.  The third layer is ZRTP and its protections against a MitM: short authentication strings, key continuity, and optional SAS signing with a PKI.  These protections are cumulative -- even over time.  Because of key continuity, a single comparison of the SAS guarantees that no MitM has attacked past sessions and cannot attack future sessions.  And even if the SAS is not compared, key continuity ensures that for a MitM attacker to remain undetected, she must attack each session between the users without exception.  </t>
</section>



  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>

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

      <?rfc include="reference.I-D.johnston-rtcweb-media-privacy.xml"?>

      <reference anchor="WebRTC-Book" target="http://webrtcbook.com">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>WebRTC: APIs and RTCWEB Protocols of the HTML5 Real-Time Web</title>

          <author initials="A." surname="Johnston">
            <organization></organization>
          </author>

          <author initials="D." surname="Burnett">
            <organization></organization>
          </author>
          <date year="2013" />
        </front>
        <seriesInfo name='' value='Digital Codex LLC' />
      </reference>

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

      <reference anchor='WebRTC-API'
           target='http://www.w3.org/TR/2012/WD-webrtc-20120821/'>
  <front>
    <title>WebRTC 1.0: Real-time Communication Between Browsers</title>
    <author fullname='Adam Bergkvist' surname='Bergkvist' initials='A. '/>
    <author fullname='Daniel C. Burnett' surname='Burnett' initials='D. '/>
    <author fullname='Cullen Jennings' surname='Jennings' initials='C. '/>
    <author fullname='Anant Narayanan' surname='Narayanan' initials='A. '/>
    <date year="2013" />
  </front>
  <seriesInfo name='W3C Working Draft' value='http://www.w3.org/TR/webrtc/'/>
</reference>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6189.xml"?>

      <?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5763.xml"?>

    </references>

   </back>
</rfc>