One document matched: draft-rescorla-random-cname-00.xml
<?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-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 “AS IS” 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>
| PAFTECH AB 2003-2026 | 2026-04-23 19:35:21 |