idnits 2.17.1 draft-rescorla-avtcore-random-cname-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. -- The draft header indicates that this document updates RFC6222, but the abstract doesn't seem to directly say this. It does mention RFC6222 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 09, 2012) is 4306 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC4648' is mentioned on line 119, but not defined ** Downref: Normative reference to an Informational RFC: RFC 4096 ** Obsolete normative reference: RFC 6222 (Obsoleted by RFC 7022) == Outdated reference: A later version (-20) exists of draft-ietf-rtcweb-security-arch-02 -- Obsolete informational reference (is this intentional?): RFC 5245 (Obsoleted by RFC 8445, RFC 8839) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft RTFM, Inc. 4 Updates: 6222 (if approved) July 09, 2012 5 Intended status: Standards Track 6 Expires: January 10, 2013 8 Random algorithm for RTP CNAME generation 9 draft-rescorla-avtcore-random-cname-00 11 Abstract 13 RFC 6222 describes a number of mechanisms for generating a unique 14 CNAME Unfortunately, these algorithms are rather complicated and also 15 produce CNAMEs which in some cases are potentially linkable over 16 multiple RTCP sessions even if a new CNAME is generated for each 17 session. This document specifies a replacement algorithm for the 18 algorithm in Section 5 which does not have this limitation and is 19 also simpler to implement. 21 Legal 23 THIS DOCUMENT AND THE INFORMATION CONTAINED THEREIN ARE PROVIDED ON 24 AN "AS IS" BASIS AND THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 25 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 26 IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE, DISCLAIM ALL 27 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 28 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 29 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 30 FOR A PARTICULAR PURPOSE. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on January 10, 2013. 49 Copyright Notice 51 Copyright (c) 2012 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 80 2.1. Linkability of the RFC 6222 algorithm . . . . . . . . . . . 5 81 3. Alternative Algorithm . . . . . . . . . . . . . . . . . . . . . 6 82 3.1. Comparison to RFC 6222 Algorithm . . . . . . . . . . . . . 6 83 3.1.1. Ease of implementation . . . . . . . . . . . . . . . . 6 84 3.1.2. Format . . . . . . . . . . . . . . . . . . . . . . . . 6 85 3.1.3. Uniqueness . . . . . . . . . . . . . . . . . . . . . . 7 86 3.1.4. Linkability . . . . . . . . . . . . . . . . . . . . . . 7 87 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 88 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 89 5.1. Normative References . . . . . . . . . . . . . . . . . . . 7 90 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 91 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 1. Terminology 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Introduction 101 [RFC6222] defines a set of algorithms for generating unique RTP 102 CNAMES [RFC3550]. Although these algorithms attempt to provide some 103 privacy, the CNAMEs they generate are still potentially linkable, as 104 acknowledged in the security considerations section of RFC 6222. 105 This document describes a simpler algorithm which produces an 106 identifier which is compatible with RFC 6222 identifiers and is in 107 fact indistinguishable from them without significant computational 108 effort, 110 RFC 6222 Section 4.2 requires: 112 " An RTP endpoint that wishes to generate a per-session RTCP CNAME MUST 113 use the following method: 115 o For every new RTP session, a new CNAME is generated following the 116 procedure described in Section 5. After performing that 117 procedure, the least significant 96 bits are used to generate an 118 identifier (to compromise between packet size and security), which 119 is converted to ASCII using Base64 encoding [RFC4648]. This 120 results in a 16-octet string representation. The RTCP CNAME 121 cannot change over the life of an RTP session [RFC3550]; hence, 122 only the initial SSRC value chosen by the endpoint is used. The 123 "user@" part of the RTCP CNAME is omitted when generating 124 per-session RTCP CNAMEs." 126 The algorithm in Section 5 of RFC 6222 is a cryptographic hash of the 127 following input values: 129 o The current time in 64-bit NTP format 130 o An EUI-64 or 48-bit MAC address [RFC4291]. 131 o The initial SSRC and source and destination address/port quartets 133 The result of this process is a random-appearing binary value which 134 can then be converted to a CNAME by the process described above. 135 Unfortunately, in many settings the input values do not provide 136 sufficient entropy, thus making it possible to determine if multiple 137 CNAME values were generated on the same machine. 139 2.1. Linkability of the RFC 6222 algorithm 141 While the output of the RFC6222 algorithm is with high probability 142 unique, it is not clearly unlinkable. Consider the case where we 143 have two CNAMEs C1 and C2 and we wish to determine whether they were 144 generated by the same endpoint. This situation might occur if 145 multiple calls were made from some anonymous location like a domestic 146 violence shelter. For instance, the attacker receives a call from an 147 unknown location and then calls a number of candidate locations in an 148 attempt to determine if they are the same. Starting with C1, the 149 attacker exhaustively searches all the potential input values to find 150 a set which hashes to C1. He then can simply search the nearby input 151 space and if the result is C2, he knows that the calls involve the 152 same endpoint. 154 The complexity of this attack is directly related to the entropy of 155 the input variables. At minimum the attacker knows: 157 o The destination IP address and port exactly. 158 o The timestamp (from the RTP header) to within a few seconds. With 159 a typical 100 ticks/second clock, this represents about 10 bits of 160 entropy at most (and potentially more like 2-3 bits) 161 o The SSRC (from the RTP header). 163 This leaves the primary sources of entropy as the source IP address/ 164 port and the MAC/EUI-64 address. RFC 6222 is unclear on which IP 165 address/port is to be used, but there are three main possibilities: 167 o A relayed address/port (known to the attacker) by looking at the 168 RTP. [Note we are assuming that a media relay is used otherwise 169 linkability is trivial.] 170 o The local IP address (most likely chosen from a very small number 171 of local addresses in the the 10.0.x.x. or 192.168.x.x range.). 172 As residential NATs generally assign addresses in sequence and 173 phones are often the first item to reboot addresses 10.0.0.1, 174 192.168.0.1, and 192.168.1.1 are very common with the first 5 175 addresses in each range representing a large fraction of all 176 devices. 177 o The public IP address of the peer--hard to guess but easy to 178 determine with a scan and not really a natural choice. 180 Similarly, the port in use is often not chosen randomly but often 181 from a small set of initial ports chosen by the implementation (by 182 default Cisco devices often use 16000-16004. Thus, while in 183 principle there are 48 bits of randomness in the IP and port, in 184 practice they may offer no entropy (in the case where the relayed 185 address is used as the RFC 6222 input) or only 7 bits (where the 186 local address is used but the client is behind a residential NAT and 187 uses a limited port range.) 189 Similarly, while in principle the MAC address has 48 bits of entropy, 190 in practice devices are easily fingerprinted and once the 191 manufacturer is known, the MAC address is restricted to the much 192 narrower range assigned to the manufacturer, which are again often 193 assigned in sequence (on the order of 20-32 bits). 195 Thus, in order to mount the initial attack, the attacker need search 196 somewhere between 20-30 bits (if the relayed address is known) and 70 197 bits. On the upper end, there is no real linkability problem, but on 198 the lower end linkability is practical. The lower-end case is 199 relevant to many residential and small business settings (exactly the 200 kind operated by DV shelters) with "natural" implementations of RFC 201 6222. 203 3. Alternative Algorithm 205 In this document, we propose an alternative approach based on simply 206 generating a cryptographically pseudorandom value. Implementations 207 conformant with this specification MAY replace the algorithm in 208 Section 5 with a random value generated using a cryptographic random 209 number generator [RFC4096]. This value MUST be at least 96 bits but 210 MAY be longer (see Section 4 for analysis of the length). 212 3.1. Comparison to RFC 6222 Algorithm 214 3.1.1. Ease of implementation 216 The biggest bottleneck to implementation of this algorithm is the 217 availability of an appropriate cryptographically secure PRNG 218 (CSPRNG). In any setting whcih already has a secure PRNG, this 219 algorithm described is far simpler, and many implementations already 220 have this capability. SIP stacks [RFC3261] are required to use 221 cryptographically random numbers to generate To and From tags 222 (Section 19.3). RTCWEB implementations 223 [I-D.ietf-rtcweb-security-arch] will need to have secure PRNGs to 224 implement ICE [RFC5245] and DTLS-SRTP [RFC5764]. And of course 225 essentially every Web browser already supports TLS, which requires a 226 secure PRNG. 228 3.1.2. Format 230 The output produced by this algorithm is a string of random bits. If 231 it is of length 96 bits, it is indistinguishable from the output of 232 the RFC6222 algorithm without significant computation (see 233 Section 2.1). 235 3.1.3. Uniqueness 237 One concern that is often raised whenever random numbers are proposed 238 is that of uniqueness. However, for the purposes of statistical 239 uniqueness, the RFC6222 algorithm has equivalent properties to a 240 PRNG, since the chance of the hashes of any two arbitrarily chosen 241 strings colliding are the same as those of any two random strings 242 colliding (or else this constitutes a weakness in the hash.) 244 3.1.4. Linkability 246 A basic design criterion of a good CSPRNG is that it not be possible 247 to distinguish its output from random values. Clearly, identifying 248 two outputs as being from the same CSPRNG would violate this 249 requirement In order to mount the attack described in Section 2.1 250 would require exhaustively searching the seed space of the PRNG. Any 251 conditions under which this was practical would represent a severe 252 threat to the security of the CSPRNG if used in any communications 253 security setting. 255 4. Security Considerations 257 The privacy properties of the algorithm described here are as strong 258 or stronger than those of the RFC6222 algorithm. Because of the 259 properties of the PRNG, there is no significant privacy/linkability 260 difference between long and short CNAMEs. However, the requirement 261 to generate unique CNAMEs implies a certain minimum length. A length 262 of 96-bits allows on the order of 2^{40} CNAMEs globally before there 263 is a large chance of collision (there is about a 50% chance of one 264 collision after 2^{48} CNAMEs). 266 5. References 268 5.1. Normative References 270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 271 Requirement Levels", BCP 14, RFC 2119, March 1997. 273 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 274 Jacobson, "RTP: A Transport Protocol for Real-Time 275 Applications", STD 64, RFC 3550, July 2003. 277 [RFC4096] Malamud, C., "Policy-Mandated Labels Such as "Adv:" in 278 Email Subject Headers Considered Ineffective At Best", 279 RFC 4096, May 2005. 281 [RFC6222] Begen, A., Perkins, C., and D. Wing, "Guidelines for 282 Choosing RTP Control Protocol (RTCP) Canonical Names 283 (CNAMEs)", RFC 6222, April 2011. 285 5.2. Informative References 287 [I-D.ietf-rtcweb-security-arch] 288 Rescorla, E., "RTCWEB Security Architecture", 289 draft-ietf-rtcweb-security-arch-02 (work in progress), 290 June 2012. 292 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 293 A., Peterson, J., Sparks, R., Handley, M., and E. 294 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 295 June 2002. 297 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 298 Architecture", RFC 4291, February 2006. 300 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 301 (ICE): A Protocol for Network Address Translator (NAT) 302 Traversal for Offer/Answer Protocols", RFC 5245, 303 April 2010. 305 [RFC5764] McGrew, D. and E. Rescorla, "Datagram Transport Layer 306 Security (DTLS) Extension to Establish Keys for the Secure 307 Real-time Transport Protocol (SRTP)", RFC 5764, May 2010. 309 Author's Address 311 Eric Rescorla 312 RTFM, Inc. 313 2064 Edgewood Drive 314 Palo Alto, CA 94303 315 USA 317 Phone: +1 650 678 2350 318 Email: ekr@rtfm.com