<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY RFC6222 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6222.xml">
<!ENTITY RFC3550 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3550.xml">
<!ENTITY RFC4291 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4291.xml">
<!ENTITY RFC4096 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4096.xml">
<!ENTITY RFC5245 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5245.xml">
<!ENTITY RFC5764 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5764.xml">
<!ENTITY RFC3261 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml">
<!ENTITY I-D.ietf-rtcweb-security-arch SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-rtcweb-security-arch">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc colonspace="yes" ?>
<?rfc rfcedstyle="no" ?>
<!-- Don't change this. It breaks stuff -->
<?rfc tocdepth="4"?>
<rfc category="std" docName="draft-rescorla-avtcore-random-cname-00"
     ipr="pre5378Trust200902" updates="6222">
  <front>
    <title abbrev="Random CNAMEs">Random algorithm for RTP CNAME generation</title>

    <author fullname="Eric Rescorla" initials="E.K." surname="Rescorla">
      <organization>RTFM, Inc.</organization>

      <address>
        <postal>
          <street>2064 Edgewood Drive</street>

          <city>Palo Alto</city>

          <region>CA</region>

          <code>94303</code>

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

        <phone>+1 650 678 2350</phone>

        <email>ekr@rtfm.com</email>
      </address>
    </author>

    <date day="09" month="July" year="2012" />

    <area>RAI</area>

<!--    <workgroup>RTCWEB</workgroup> -->

    <abstract>
      <t>
	RFC 6222 describes a number of mechanisms
	for generating a unique CNAME 
	Unfortunately, these algorithms are rather complicated
	and also produce CNAMEs
	which in some cases are potentially linkable over multiple RTCP sessions
	even if a new CNAME is generated for each session.
	This document specifies a replacement algorithm for
	the algorithm in Section 5 which does not have this
	limitation and is also simpler to implement.
      </t>
    </abstract>
    <note title="Legal">
      <t>THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON
      AN &ldquo;AS IS&rdquo; BASIS AND THE CONTRIBUTOR, THE ORGANIZATION
      HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
      IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL
      WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
      WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY
      RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
      PARTICULAR PURPOSE.</t>
    </note>
  </front>

  <middle>
    <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">RFC 2119</xref>.</t>
    </section>

    <section title="Introduction" anchor="sec.introduction">
      <t>
	<xref target="RFC6222"/> defines a set of algorithms for generating
	unique RTP CNAMES <xref target="RFC3550"/>. Although these algorithms
	attempt to provide some privacy, the CNAMEs they generate are still
	potentially linkable, as acknowledged in the security considerations section
	of RFC 6222.
	This document describes a simpler algorithm which produces
	an identifier which is compatible with RFC 6222 identifiers and
	is in fact indistinguishable from them without significant
	computational effort,
      </t>
      <t>
      RFC 6222 Section 4.2 requires:
      </t>
      <figure>
	<artwork><![CDATA[
" An RTP endpoint that wishes to generate a per-session RTCP CNAME MUST
 use the following method:

   o  For every new RTP session, a new CNAME is generated following the
   procedure described in Section 5.  After performing that
   procedure, the least significant 96 bits are used to generate an
   identifier (to compromise between packet size and security), which
   is converted to ASCII using Base64 encoding [RFC4648].  This
   results in a 16-octet string representation.  The RTCP CNAME
   cannot change over the life of an RTP session [RFC3550]; hence,
   only the initial SSRC value chosen by the endpoint is used.  The
   "user@" part of the RTCP CNAME is omitted when generating
   per-session RTCP CNAMEs."
 	]]></artwork>
      </figure>
      <t>
	The algorithm in Section 5 of RFC 6222 is a cryptographic hash of the following
	input values:
      </t>
      <t>
      <list style="symbols">
	<t>The current time in 64-bit NTP format</t>
	<t>An EUI-64 or 48-bit MAC address <xref target="RFC4291"/>.</t>
	<t>The initial SSRC and source and destination address/port quartets</t>
      </list>
      </t>
      <t>
	The result of this process is a random-appearing binary value
	which can then be converted to a CNAME by the process
	described above. Unfortunately, in many settings the input values
	do not provide sufficient entropy, thus making it possible to
	determine if multiple CNAME values were generated on the same
	machine.
      </t>
      <section title="Linkability of the RFC 6222 algorithm" anchor="linkability">
	<t>
	  While the output of the RFC6222 algorithm is with high probability unique,
	  it is not clearly unlinkable. 
	  Consider the case where we have 
	  two CNAMEs C1 and C2 and we wish to determine whether they 
	  were generated by the same endpoint. This situation might
	  occur if multiple calls were made from some anonymous location 
	  like a domestic violence shelter. For instance, the attacker
	  receives a call from an unknown location and then 
	  calls a number of candidate locations in an attempt to
	  determine if they are the same.
	  Starting with C1, the
	  attacker exhaustively searches all the potential input
	  values to find a set which hashes to C1. He then 
	  can simply search the nearby input space and if the
	  result is C2, he knows that the calls involve
	  the same endpoint.
	</t>
	<t>
	  The complexity of this attack is directly related to the
	  entropy of the input variables. At minimum the attacker
	  knows:
	</t>
	<t>
	  <list style="symbols">
	    <t>The destination IP address and port exactly.</t>
	    <t>The timestamp (from the RTP header) to within a few seconds. With
	    a typical 100 ticks/second clock, this represents about 10 bits
	    of entropy at most (and potentially more like 2-3 bits)</t>
	    <t>The SSRC (from the RTP header).</t>
	  </list>
	</t>
	<t>
	  This leaves the primary sources of entropy as the source IP address/port
	  and the MAC/EUI-64 address. RFC 6222 is unclear on which IP address/port is
	  to be used, but there are three main possibilities: 
	</t>
	<t>
	  <list style="symbols">
	    <t>A relayed address/port (known to the attacker) by looking at the RTP.
	    [Note we are assuming that a media relay is used otherwise linkability
	    is trivial.]</t>
	    <t>The local IP address (most likely chosen from a very small number of
	    local addresses in the the 10.0.x.x. or 192.168.x.x range.). As residential
	    NATs generally assign addresses in sequence and phones are often the first
	    item to reboot addresses 10.0.0.1, 192.168.0.1, and 192.168.1.1 are very
	    common with the first 5 addresses in each range representing a large
	    fraction of all devices.</t>
	    <t>The public IP address of the peer--hard to guess but easy to
	    determine with a scan and not really a natural choice.</t>
	  </list>
	</t>
	<t>
	  Similarly, the port in use is often not chosen randomly but often from a small
	  set of initial ports chosen by the implementation (by default Cisco devices
	  often use 16000-16004. Thus, while in principle
	  there are 48 bits of randomness in the IP and port, in practice they
	  may offer no entropy (in the case where the relayed address is used 
	  as the RFC 6222 input) or only 7 bits (where the local address is
	  used but the client is behind a residential NAT and uses a limited
	  port range.)
	</t>
	<t>
	  Similarly, while in principle the MAC address has 48 bits of entropy,
	  in practice devices are easily fingerprinted and once the manufacturer
	  is known, the MAC address is restricted to the much narrower range
	  assigned to the manufacturer, which are again often assigned in
	  sequence (on the order of 20-32 bits).
	</t>
	<t>
	  Thus, in order to mount the initial attack, the attacker need search
	  somewhere between 20-30 bits (if the relayed address is known) and 70 bits.
	  On the upper end, there is no real linkability problem, but on the
	  lower end linkability is practical. The lower-end case is relevant
	  to many residential and small business settings (exactly the kind
	  operated by DV shelters) with "natural" implementations of RFC 6222.
	</t>
      </section>
    </section>
    <section title="Alternative Algorithm">
      <t>
	In this document, we propose an alternative
	approach based on simply generating a cryptographically
	pseudorandom value.
	Implementations conformant with this specification MAY replace the
	algorithm in Section 5 with a random value generated using
	a cryptographic random number generator <xref target="RFC4096"/>.
	This value MUST be at least 96 bits but MAY be longer 
	(see <xref target="sec.sec-cons"/> for analysis of the length).
      </t>
      <section title="Comparison to RFC 6222 Algorithm">
	<section title="Ease of implementation">
	  <t>
	    The biggest bottleneck to implementation of this algorithm
	    is the availability of an appropriate cryptographically
	    secure PRNG (CSPRNG). 
	    In any setting whcih already has a secure PRNG, 
	    this algorithm described is far simpler, and
	    many implementations already have this capability. 
	    SIP stacks <xref target="RFC3261"/> are required to
	    use cryptographically random numbers to generate
	    To and From tags (Section 19.3). RTCWEB implementations 
	    <xref target="I-D.ietf-rtcweb-security-arch"/> 
	    will need to have secure PRNGs to implement ICE
	    <xref target="RFC5245"/> and DTLS-SRTP <xref target="RFC5764"/>.
	    And of course essentially every Web browser already supports
	    TLS, which requires a secure PRNG.
	  </t>
	</section>
	<section title="Format">
	  <t>
	    The output produced by this algorithm is a string of
	    random bits. If it is of length 96 bits,
	    it is indistinguishable from the
	    output of the RFC6222 algorithm without significant
	    computation (see <xref target="linkability"/>).
	  </t>
	</section>
	<section title="Uniqueness">
	  <t>
	    One concern that is often raised whenever random numbers
	    are proposed is that of uniqueness. However, for the
	    purposes of statistical uniqueness, the RFC6222 algorithm
	    has equivalent properties to a PRNG, since the chance
	    of the hashes of any two arbitrarily chosen strings
	    colliding are the same as those of any two random
	    strings colliding (or else this constitutes a weakness
	    in the hash.)
	  </t>
	</section>
	<section title="Linkability" anchor="linkability-comparison">
	  <t>
	    A basic design criterion of a good CSPRNG is that it
	    not be possible to distinguish its output from random
	    values. Clearly, identifying two outputs as being
	    from the same CSPRNG would violate this requirement
	    In order to mount the attack described in <xref target="linkability"/>
	    would require exhaustively searching the seed space of the
	    PRNG. Any conditions under which this was practical would
	    represent a severe threat to the security of the CSPRNG
	    if used in any communications security setting.
	  </t>
	</section>
      </section>
    </section>
    <section title="Security Considerations" anchor="sec.sec-cons">
	<t>
	  The privacy properties of the algorithm described here are
	  as strong or stronger than those of the RFC6222 algorithm.
	  Because of the properties of the PRNG, there is no significant
	  privacy/linkability difference between long and short
	  CNAMEs. However, the requirement to generate unique CNAMEs
	  implies a certain minimum length. A length of 96-bits allows
	  on the order of 2^{40} CNAMEs globally before there is a 
	  large chance of collision (there is about a 50% chance of 
	  one collision after 2^{48} CNAMEs).
	</t>
    </section>
    </middle>
    <back>
      <references title="Normative References">
	&RFC2119;
	&RFC6222;
	&RFC3550;
	&RFC4096;
      </references>
      <references title="Informative References">
	&RFC4291;
	&RFC5245;
	&RFC5764;
	&RFC3261;
	&I-D.ietf-rtcweb-security-arch;
      </references>
    </back>
  </rfc>

