idnits 2.17.1 draft-peterson-stir-threats-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 04, 2013) is 3886 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 406, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 410, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 415, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 420, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 425, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 432, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 435, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 444, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 448, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 452, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 457, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 462, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '1') (Obsoleted by RFC 8224) -- Duplicate reference: RFC3261, mentioned in '3', was also mentioned in '2'. == Outdated reference: A later version (-02) exists of draft-peterson-secure-origin-ps-01 == Outdated reference: A later version (-04) exists of draft-ietf-straw-b2bua-loop-detection-01 == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-04 Summary: 0 errors (**), 0 flaws (~~), 17 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational September 04, 2013 5 Expires: March 08, 2014 7 Secure Telephone Identity Threat Model 8 draft-peterson-stir-threats-00.txt 10 Abstract 12 As the Internet and the telephone network have become increasingly 13 interconnected and interdependent, attackers can impersonate or 14 obscure calling party numbers when orchestrating bulk commercial 15 calling schemes, hacking voicemail boxes or even circumventing multi- 16 factor authentication systems trusted by banks. This document 17 analyzes threats in the resulting system, enumerating actors, 18 reviewing the powers available to and used by attackers, and 19 describing scenarios in which those powers are exercised. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 08, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . 2 56 2. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 2.1. Endpoints . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.2. Intermediaries . . . . . . . . . . . . . . . . . . . . . 4 59 2.3. Attackers . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Attacks . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1. Voicemail Hacking via Impersonation . . . . . . . . . . . 6 62 3.2. Unsolicited Commercial Calling from Impersonated Numbers 6 63 3.3. Attack Scenarios . . . . . . . . . . . . . . . . . . . . 7 64 3.4. Solution-Specific Attacks . . . . . . . . . . . . . . . . 8 65 4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 7. Informative References . . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 71 1. Introduction and Scope 73 As is discussed in the STIR problem statemnt [9], the primary enabler 74 of robocalling, vishing and related attacks is the capability to 75 impersonate a calling party number. The most stark example of these 76 attacks are cases where automated callees on the PSTN rely on the 77 calling number as a security measure, for example to access a 78 voicemail system. Robocallers use impersonation as a means of 79 obscuring identity; while robocallers can, in the ordinary PSTN, 80 block (that is, withhold) their caller identity, callees are less 81 likely to pick up calls from blocked identities, and therefore 82 calling from some number, any number, is prefereable. Robocallers 83 however prefer not to call from a number that can trace back to the 84 robocaller, and therefore they impersonate numbers that are not 85 assigned to them. 87 The scope of impersonation in this threat model pertains solely to 88 the rendering of a calling telephone number to an end user or 89 automaton at the time of call set-up. The primary attack vector is 90 therefore one where the attacker contrives for the calling telephone 91 number in signaling to be a particular chosen number, one that the 92 attacker does not have the authority to call from, in order for that 93 number to be rendered on the terminating side. The threat model 94 assumes that this attack simply cannot be prevented: there is no way 95 to stop the attacker from creating calls that contain attacker-chosen 96 calling telephone numbers in their signaling. The solution space 97 therefore focuses on ways that terminating or intermediary elements 98 might differentiate authorized from unauthorized calling party 99 numbers, in order that policies, human or automatic, might act on 100 that information. 102 Rendering an authenticated calling party number during call set-up 103 time does not entail anything about the entity or entities that will 104 send and receive media during the call itself. In call paths with 105 intermediaries and gateways as described below, there may be no way 106 to provide any assurance in the signaling about participants in the 107 media. In those end-to-end IP environments where such an assurance 108 is possible, it is highly desirable, but in the threat model 109 considered in this document, the threat of impersonation does not 110 extend to impersonating an authorized listener after a call has been 111 completed. Attackers that could impersonate an authorized listener 112 require powers that robocallers and voicemail hackers are unlikely to 113 possess, and historically such attacks have not played a role in 114 enabling robocalling or related problems. 116 In protocols like SIP, call signaling can be renegotiated after the 117 call has been completed, and through various transfer mechanisms 118 common in telephone systems, callees can easily be connected to, or 119 conferenced in with, telephone numbers other than the original 120 calling number once a call has been set up. These post-setup changes 121 to the call are outside the scope of impersonation considered in this 122 model. Furthermore, impersonating a reached number to the originator 123 of a call is outside the scope of this threat model. 125 In much of the PSTN, there exists a supplemental service that 126 translates calling party numbers into regular names, including the 127 proper names of people and businesses, for rendering to the called 128 user. These services (frequently termed 'Caller ID') provide a 129 further attack surface for impersonation. The threat model explored 130 in this document focuses only on the calling party number, though 131 presenting a forged calling party number can let the attacker cause a 132 forged 'Caller ID' name to be rendered to the user as well. 133 Providing a verifiable calling party number therefore does improve 134 the security of Caller ID systems, but this threat model does not 135 consider attacks specific to Caller ID, such as attacks on the 136 databases consulted by the terminating side of a call to provide 137 Caller ID, or impersonators choosing to forge a particular calling 138 party number in order to present a misleading Caller ID to the user. 140 Finally, the scope of impersonation in this threat model does not 141 consider simple anonymity as a threat. The ability to place 142 anonymous calls has always been a feature of the PSTN, and users of 143 the PSTN today have the capability to reject anonymous calls should 144 they wish to. 146 2. Actors 148 2.1. Endpoints 150 There are two main categories of end-user terminals, a dumb device 151 (such as a 'black phone') or a smart device: 153 Dumb devices comprise a simple dial pad, handset and ringer, 154 optionally accompanied by a display that can show only a limited 155 number of characters (typically, enough for a telephone number and 156 an accompanying name, sometimes less). These devices are 157 controlled by service providers in the network. 159 Smart devices are general purpose computers with some degree of 160 programmability and the capacity to access the Internet, along 161 with a rich display. This includes smart phones, telephone 162 applications on desktop and laptop computers, IP private branch 163 exchanges, and so on. 165 There are also various hybrid devices, such as terminal adapters 166 which attach dumb devices to a VoIP service, but which may in turn 167 use auxiliary screens as displays for rich information (for example, 168 some cable deployments use the television screen to render caller 169 ID). These devices expose little programmability to end users. 171 There is a further category of automated terminals without an end 172 user. These include systems like voicemail services that consume the 173 calling party number without rendering it to a human. Though the 174 capability of voicemail services varies widely, many today have 175 Internet access and advanced application interfaces (to render 176 'visual voicemail,' to automatically transcribe voicemail to email, 177 and so on). 179 2.2. Intermediaries 181 We assume that a call between two endpoints traverses a call path. 182 The length of the call path can vary considerably: it is possible in 183 VoIP deployments for two endpoint entities to send traffic to one 184 another directly, but more commonly several intermediaries exist in a 185 VoIP call path. One or more gateways may also appear on a call path. 187 Intermediaries forward call signaling to the next entity in the 188 path. These intermediaries may also modify the signaling in order 189 to improve interoperability, to enable proper network-layer media 190 connections, or to enforce operator policy. This threat model 191 assumes there are no restrictions on the modifications to 192 signaling that an intermediary can introduce. 194 Gateways translate call signaling from one protocol into another. 195 In the process, they tend to consume any signaling specific to the 196 original protocol (elements like transaction-matching identifiers) 197 and may need to transcode or otherwise alter identifiers as they 198 are rendered in the destination protocol. 200 This threat model assumes that intermediaries and gateways can 201 forward and retarget calls as necessary, which can result in a call 202 terminating at a place the originator did not expect, and that this 203 is an ordinary condition in call routing. This is significant to the 204 solution space, however, because it limits the ability of the 205 originator to anticipate what the telephone number of the respondent 206 will be. 208 Furthermore, we assume that some intermediaries or gateways may, due 209 to their capabilities or policies, discard calling party number 210 information, as a whole or in part. Today, many IP-PSTN gateways 211 simply ignore any information available about the caller in the IP 212 leg of the call, and allow the telephone number of the PRI line that 213 the gateway happens to use to be sent as the calling party number for 214 the PSTN leg of the call. A call might also gateway to a 215 multifrequency network where only a limit number of digits of 216 automatic numbering identification (ANI) data are signaled, for 217 example. Some protocols may render telephone numbers in a way that 218 makes it impossible for a terminating side to parse or canonicalize a 219 number. In these cases, providing authenticated identity may be 220 impossible. This is not however indicative of an attack or other 221 security failure. 223 2.3. Attackers 225 We assume that an attacker has the following powers: 227 The attacker can create telephone calls at will, originating them 228 on either the PSTN or over IP, and can supply an arbitrary calling 229 party number. 231 The attacker can capture and replay signaling previously received. 232 [TBD: should this include a passive attacker that can capture 233 signaling that isn't directly sent to it? Not a factor for 234 robocalling, but perhaps for voicemail hacking, say.] 236 The attacker has access to the Internet, and thus the ability to 237 inject arbitrary traffic over the Internet, to access public 238 directories, and so on. 240 There are many potential threats in which an attacker compromises 241 intermediaries in the call path, or captures credentials that allow 242 the attacker to impersonate a target. Those system-level threats are 243 not considered in this threat model, though secure design of systems 244 to prevent these sorts of attacks is necessary for any of these 245 countermeasures to work. 247 This threat model also does not consider a case in which the 248 operators of intermediaries or gateways are themselves adversaries 249 who intentionally suppress identity or send falsified identity with 250 their own credentials. 252 3. Attacks 254 3.1. Voicemail Hacking via Impersonation 256 A voicemail service allows users calling from their mobile phones 257 access to their voicemail boxes on the basis of the calling party 258 number. An attacker wants to access the voicemail of a particular 259 target. The attacker therefore impersonates the calling party number 260 using one of the scenarios described below. 262 In all cases, the countermeasure to this threat is for the voicemail 263 service to have an expectation that calls to its service will supply 264 an authenticated identity, and in the absence of that identity, for 265 it to adopt a different policy (perhaps requiring a shared secret to 266 be dialed as a PIN). Authenticated identity alone provides a 267 positive confirmation only when an identity is claimed legitimately; 268 the absence of authenticated identity here is not evidence of malice, 269 just of uncertainty. 271 If the voicemail service could know ahead of time that it should 272 always expect authenticated identity from a particular number, that 273 would enable the voicemail service to adopt different policies for 274 handling a request without authenticated identity. Since users 275 contact a voicemail service repeatedly, this is something that a 276 voicemail server could learn, for example, the first time that a user 277 contacts it. Alternatively, it could access a directory of some kind 278 that informs verifiers that they should expect identity from 279 particular numbers. 281 3.2. Unsolicited Commercial Calling from Impersonated Numbers 283 The unsolicited commercial calling, or for short robocalling, threat 284 is similar to the voicemail threat, except in so far as the 285 robocaller does not need to impersonate any specific number, merely a 286 plausible number. A robocaller may impersonate a number that is not 287 a valid number (for example, in the United States, a number beginning 288 with 0), or an unassigned number. The robocaller may change numbers 289 every time a new call is placed, even selecting numbers randomly. 291 The countermeasures to robocalling are similar to the voicemail 292 example, but there are significant differences. One important 293 potential countermeasure is simply to verify that the calling party 294 number is in fact valid and assigned. Unlike voicemail services, end 295 users typically have never been contacted by the number used by a 296 robocaller before, so they can't rely on past association to know 297 whether or not the calling party number should always supply 298 authenticated identity. If there were a directory that could inform 299 the terminating side of that fact, however, that would help in the 300 robocalling case. 302 When alerting a human is involved, the time frame for executing these 303 countermeasures is necessarily limited. Ideally, a user would not be 304 alerted that a call has been received until any necessary identity 305 checks have been performed. This could however result in inordinate 306 post-dial delay from the perspective of legitimate callers. 307 Cryptographic operations and network operations must be minimized for 308 these countermeasures to be practical. 310 The eventual effect of these countermeasures would be to force 311 robocallers to either block their caller identity, in which case end 312 users could opt not to receive their calls, or to use authenticated 313 identity for numbers traceable to them, which would then allow for 314 other forms of redress. 316 3.3. Attack Scenarios 318 Impersonation, IP-PSTN 320 An attacker on the Internet uses a commercial WebRTC service to send 321 a call to the PSTN with a chosen calling party number. The service 322 contacts an Internet-to-PSTN gateway, which inserts the attacker's 323 chosen calling party number into the CPN field of an IAM. When the 324 IAM reaches the endpoint terminal, the terminal renders the 325 attacker's chosen calling party number as the calling identity. 327 Countermeasure: out-of-band authenticated identity 329 Impersonation, PSTN-PSTN 331 An attacker with a traditional PBX (connected to the PSTN through an 332 ISDN PRI) sends a Q.931 SETUP request with a chosen calling party 333 number which a service provider inserts into the corresponding SS7 334 CPN field of an IAM. When the IAM reaches the endpoint terminal, the 335 terminal renders the attacker's chosen calling party number as the 336 calling identity. 338 Countermeasure: out-of-band authenticated identity 339 Impersonation, IP-IP 341 An attacker with an IP phone sends a SIP request to an IP-enabled 342 voicemail service. The attacker puts a chosen calling party number 343 into the From header field value of the INVITE. When the INVITE 344 reaches the endpoint terminal, the terminal renders the attacker's 345 chosen calling party number as the calling identity. 347 Countermeasure: in-band authenticated identity 349 Impersonation, IP-PSTN-IP 351 An attacker with an IP phone sends a SIP request to the telephone 352 number of a voicemail service, perhaps without even knowing that the 353 voicemail service is IP-based. The attacker puts a chosen calling 354 party number into the From header field value of the INVITE. The 355 attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts 356 the attacker's chosen calling party number into the CPN field of an 357 IAM. That IAM then traverses the PSTN until (perhaps after a call 358 forwarding) it reaches another gateway, this time back to the IP 359 realm, to an H.323 network. The PSTN-IP gateway puts takes the 360 calling party number in the IAM CPN field and puts it into the SETUP 361 request. When the SETUP reaches the endpoint terminal, the terminal 362 renders the attacker's chosen calling party number as the calling 363 identity. 365 Countermeasure: out-of-band authenticated identity 367 3.4. Solution-Specific Attacks 369 [TBD: This is just forward-looking notes] 371 Threats Against In-band 373 Token replay 375 Removal of in-band signaling features 377 Threats Against Out-of-Band 379 Provisioning Gargbage CPRs 381 Data Mining 383 Threats Against Either Approach 385 Attack on directories/services that say whether you should expect 386 authenticated identity or not 387 Canonicalization attack 389 4. Acknowledgments 391 Henning Schulzrinne, Hannes Tschofenig, Cullen Jennings and Eric 392 Rescorla provided key input to the discussions leading to this 393 document. 395 5. IANA Considerations 397 This memo includes no request to IANA. 399 6. Security Considerations 401 This document provides a threat model and is thus entirely about 402 security. 404 7. Informative References 406 [1] Peterson, J. and C. Jennings, "Enhancements for 407 Authenticated Identity Management in the Session 408 Initiation Protocol (SIP)", RFC 4474, August 2006. 410 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 411 A., Peterson, J., Sparks, R., Handley, M., and E. 412 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 413 June 2002. 415 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 416 A., Peterson, J., Sparks, R., Handley, M., and E. 417 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 418 June 2002. 420 [4] Jennings, C., Peterson, J., and M. Watson, "Private 421 Extensions to the Session Initiation Protocol (SIP) for 422 Asserted Identity within Trusted Networks", RFC 3325, 423 November 2002. 425 [5] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 426 of Named Entities (DANE) Transport Layer Security (TLS) 427 Protocol: TLSA", RFC 6698, August 2012. 429 [6] Elwell, J., "Connected Identity in the Session Initiation 430 Protocol (SIP)", RFC 4916, June 2007. 432 [7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 433 3966, December 2004. 435 [8] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, 436 "Secure Call Origin Identification", draft-cooper-iab- 437 secure-origin-00 (work in progress), November 2012. 439 [9] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 440 Origin Identification: Problem Statement, Threat Model, 441 Requirements, and Roadmap", draft-peterson-secure-origin- 442 ps-01 (work in progress), July 2013. 444 [10] Peterson, J., "Retargeting and Security in SIP: A 445 Framework and Requirements", draft-peterson-sipping- 446 retarget-00 (work in progress), February 2005. 448 [11] Rosenberg, J., "Concerns around the Applicability of RFC 449 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 450 progress), February 2008. 452 [12] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for 453 Session Initiation Protocol (SIP) Back-to- Back User 454 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-01 455 (work in progress), August 2013. 457 [13] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 458 Huguenin, "Verification Involving PSTN Reachability: 459 Requirements and Architecture Overview", draft-jennings- 460 vipr-overview-04 (work in progress), February 2013. 462 [14] Rosenberg, J. and H. Schulzrinne, "Session Initiation 463 Protocol (SIP): Locating SIP Servers", RFC 3263, June 464 2002. 466 Author's Address 468 Jon Peterson 469 NeuStar, Inc. 470 1800 Sutter St Suite 570 471 Concord, CA 94520 472 US 474 Email: jon.peterson@neustar.biz