idnits 2.17.1 draft-ietf-stir-threats-03.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 (June 11, 2014) is 3605 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-19) exists of draft-ietf-rtcweb-overview-09 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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 June 11, 2014 5 Expires: December 13, 2014 7 Secure Telephone Identity Threat Model 8 draft-ietf-stir-threats-03.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 capabilities available to and used by attackers, and 19 describing scenarios in which attacks are launched. 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 December 13, 2014. 38 Copyright Notice 40 Copyright (c) 2014 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 7 63 3.3. Telephony Denial-of-Service Attacks . . . . . . . . . . . 8 64 4. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . 9 65 4.1. Solution-Specific Attacks . . . . . . . . . . . . . . . . 10 66 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 69 8. Informative References . . . . . . . . . . . . . . . . . . . 11 70 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 72 1. Introduction and Scope 74 As is discussed in the STIR problem statement 75 [I-D.ietf-stir-problem-statement], the primary enabler of 76 robocalling, vishing, swatting and related attacks is the capability 77 to impersonate a calling party number. The starkest examples of 78 these attacks are cases where automated callees on the PSTN rely on 79 the calling number as a security measure, for example to access a 80 voicemail system. Robocallers use impersonation as a means of 81 obscuring identity; while robocallers can, in the ordinary PSTN, 82 block (that is, withhold) their calling number from presentation, 83 callees are less likely to pick up calls from blocked identities, and 84 therefore appearing to calling from some number, any number, is 85 preferable. Robocallers however prefer not to call from a number 86 that can trace back to the robocaller, and therefore they impersonate 87 numbers that are not assigned to them. 89 The scope of impersonation in this threat model pertains solely to 90 the rendering of a calling telephone number to a callee (human user 91 or automaton) at the time of call set-up. The primary attack vector 92 is therefore one where the attacker contrives for the calling 93 telephone number in signaling to be a chosen number. In this attack, 94 the number is one that the attacker is not authorized to use (as a 95 caller), but gives in order for that number to be consumed or 96 rendered on the terminating side. The threat model assumes that this 97 attack simply cannot be prevented: there is no way to stop the 98 attacker from creating call setup messages that contain attacker- 99 chosen calling telephone numbers. The solution space therefore 100 focuses on ways that terminating or intermediary elements might 101 differentiate authorized from unauthorized calling party numbers, in 102 order that policies, human or automatic, might act on that 103 information. 105 Securing an authenticated calling party number at call set-up time 106 does not entail any assertions about the entity or entities that will 107 send and receive media during the call itself. In call paths with 108 intermediaries and gateways (as described below), there may be no way 109 to provide any assurance in the signaling about participants in the 110 media of a call. In those end-to-end IP environments where such 111 assurance is possible, it is highly desirable. However, in the 112 threat model described in this document, "impersonation" does not 113 consider impersonating an authorized listener after a call has been 114 established (e.g., as a third party attempting to eavesdrop on a 115 conversation). Attackers that could impersonate an authorized 116 listener require capabilities that robocallers and voicemail hackers 117 are unlikely to possess, and historically such attacks have not 118 played a role in enabling robocalling or related problems. 120 In SIP and even many traditional telephone protocols, call signaling 121 can be renegotiated after the call has been established. Using 122 various transfer mechanisms common in telephone systems, a callee can 123 easily be connected to, or conferenced in with, telephone numbers 124 other than the original calling number once a call has been 125 established. These post-setup changes to the call are outside the 126 scope of impersonation considered in this model. Furthermore, this 127 threat model does not include in its scope the verification of the 128 reached party's telephone number back to the originator of the call. 129 There is no assurance to the originator that they are reaching the 130 correct number, nor any indication when call forwarding has taken 131 place. This threat model is focused only on verifying the calling 132 party number to the callee. 134 In much of the PSTN, there exists a supplemental service that 135 translates calling party numbers into names, including the proper 136 names of people and businesses, for rendering to the called user. 137 These services (frequently marketed as part of 'Caller ID') provide a 138 further attack surface for impersonation. The threat model described 139 in this document addresses only the calling party number, even though 140 presenting a forged calling party number may cause a chosen calling 141 party name to be rendered to the user as well. Providing a 142 verifiable calling party number therefore improves the security of 143 calling party name systems, but this threat model does not consider 144 attacks specific to names. Such attacks may be carried out against 145 the databases consulted by the terminating side of a call to provide 146 calling party names, or by impersonators forging a particular calling 147 party number in order to present a misleading name to the user. 149 2. Actors 151 2.1. Endpoints 153 There are two main categories of end-user terminals relevant to this 154 discussion, a dumb device (such as a 'black phone') or a smart 155 device. 157 Dumb devices comprise a simple dial pad, handset and ringer, 158 optionally accompanied by a display that can render a limited 159 number of characters. Typically the display renders enough 160 characters for a telephone number and an accompanying name, but 161 sometimes fewer are rendered. Although users interface with these 162 devices, the intelligence that drives them lives in the service 163 provider network. 165 Smart devices are general purpose computers with some degree of 166 programmability, and with the capacity to access the Internet and 167 to render text, audio and/or images. This category includes smart 168 phones, telephone applications on desktop and laptop computers, IP 169 private branch exchanges, etc. 171 There is a further category of automated terminals without an end 172 user. These include systems like voicemail services, which may 173 provide a different set of services to a caller based solely on the 174 calling party's number, for example granting the (purported) mailbox 175 owner access to a menu while giving other callers only the ability to 176 leave a message. Though the capability of voicemail services varies 177 widely, many today have Internet access and advanced application 178 interfaces (to render 'visual voicemail,' [refs.OMTP-VV] to 179 automatically transcribe voicemail to email, etc.). 181 2.2. Intermediaries 183 The endpoints of a traditional telephone call connect through 184 numerous intermediary devices in the network. The set of 185 intermediary devices traversed during call setup between two 186 endpoints is referred to as a call path. The length of the call path 187 can vary considerably: it is possible in VoIP deployments for two 188 endpoint entities to send traffic to one another directly, but, more 189 commonly, several intermediaries exist in a VoIP call path. One or 190 more gateways also may appear on a call path. 192 Intermediaries forward call signaling to the next device in the 193 path. These intermediaries may also modify the signaling in order 194 to improve interoperability, to enable proper network-layer media 195 connections, or to enforce operator policy. This threat model 196 assumes there are no restrictions on the modifications to 197 signaling that an intermediary can introduce (which is consistent 198 with the observed behavior of such devices). 200 A gateway is a subtype of intermediary that translates call 201 signaling from one protocol into another. In the process, they 202 tend to consume any signaling specific of the original protocol 203 (elements like transaction-matching identifiers) and may need to 204 transcode or otherwise alter identifiers as they are rendered in 205 the destination protocol. 207 This threat model assumes that intermediaries and gateways can 208 forward and retarget calls as necessary, which can result in a call 209 terminating at a place the originator did not expect; this is a 210 common condition in call routing. This observation is significant to 211 the solution space, because it limits the ability of the originator 212 to anticipate what the telephone number of the respondent will be 213 (for more on the "unanticipated respondent" problem, see 214 [I-D.peterson-sipping-retarget]). 216 Furthermore, we assume that some intermediaries or gateways may, due 217 to their capabilities or policies, discard calling party number 218 information, in whole or in part. Today, many IP-PSTN gateways 219 simply ignore any information available about the caller in the IP 220 leg of the call, and allow the telephone number of the PRI line used 221 by the gateway to be sent as the calling party number for the PSTN 222 leg of the call. For example, a call might also gateway to a multi- 223 frequency network where only a limited number of digits of automatic 224 numbering identification (ANI) data are signaled. Some protocols may 225 render telephone numbers in a way that makes it impossible for a 226 terminating side to parse or canonicalize a number. In these cases, 227 providing authenticated calling number data may be impossible, but 228 this is not indicative of an attack or other security failure. 230 2.3. Attackers 232 We assume that an attacker has the following capabilities: 234 An attacker can create telephone calls at will, originating them 235 either on the PSTN or over IP, and can supply an arbitrary calling 236 party number. 238 An attacker can capture and replay signaling previously observed 239 by it. 241 An attacker has access to the Internet, and thus the ability to 242 inject arbitrary traffic over the Internet, to access public 243 directories, etc. 245 There are attack scenarios in which an attacker compromises 246 intermediaries in the call path, or captures credentials that allow 247 the attacker to impersonate a caller. Those system-level attacks are 248 not considered in this threat model, though secure design and 249 operation of systems to prevent these sorts of attacks are necessary 250 for envisioned countermeasures to work. 252 This threat model also does not consider scenarios in which the 253 operators of intermediaries or gateways are themselves adversaries 254 who intentionally discard valid identity information (without a user 255 requesting anonymity) or who send falsified identity; see 256 Section 4.1. 258 3. Attacks 260 The uses of impersonation described in this section are broadly 261 divided into two categories: those where an attacker impersonates an 262 arbitrary identity in order to disguise its own, and those where an 263 attack will not succeed unless the attacker impersonates a specific 264 identity. At a high level, impersonation encourages targets to 265 answer attackers' calls and makes identifying attackers more 266 difficult. This section shows how concrete attacks based on those 267 different techniques might be launched. 269 3.1. Voicemail Hacking via Impersonation 271 A voicemail service may allow users calling from their phones access 272 to their voicemail boxes on the basis of the calling party number. 273 If an attacker wants to access the voicemail of a particular target, 274 the attacker may try to impersonate the calling party number using 275 one of the scenarios described in Section 4. 277 This attack is closely related to attacks on similar automated 278 systems, potentially including banks, airlines, calling-card 279 services, conferencing providers, ISPs, and other businesses that 280 fully or partly grant access to resources on the basis of the calling 281 party number. It is analogous to an attack in which a human is 282 encouraged to answer a phone, or to divulge information once a call 283 is in progress, by seeing a familiar calling party number. 285 The envisioned countermeasures for this attack involve the voicemail 286 system treating calls that supply an authenticated calling number 287 data differently from other calls. In the absence of that identity 288 information, for example, a voicemail service might enforce some 289 other caller authentication policy (perhaps requiring a PIN for 290 caller authentication). Asserted caller identity alone provides an 291 authenticated basis for granting access to a voice mailbox only when 292 an identity is claimed legitimately; the absence of calling identity 293 here may not be evidence of malice, just of uncertainty or a 294 limitation imposed by the set of intermediaries traversed for a 295 specific call path. 297 If the voicemail service could learn ahead of time that it should 298 expect authenticated calling number data from a particular number, 299 that would enable the voicemail service to adopt stricter policies 300 for handling a request without authentication data. Since users 301 typically contact a voicemail service repeatedly, the service could 302 for example remember which requests contain authenticated calling 303 number data and require further authentication mechanisms when 304 identity is absent. Alternatively, issuers of credentials or other 305 authorities could provide a service that informs verifiers that they 306 should expect identity in calls from particular numbers. 308 3.2. Unsolicited Commercial Calling from Impersonated Numbers 310 The unsolicited commercial calling, or for short robocalling, attack 311 is similar to the voicemail attack, except that the robocaller does 312 not need to impersonate the particular number controlled by the 313 target, merely some "plausible" number. A robocaller may impersonate 314 a number that is not an assignable number (for example, in the United 315 States, a number beginning with 0), or an unassigned number. A 316 robocaller may change numbers every time a new call is placed, e.g., 317 selecting numbers randomly. 319 A closely related attack is sending unsolicited bulk commercial 320 messages via text messaging services. These messages usually 321 originate on the Internet, though they may ultimately reach endpoints 322 over traditional telephone network protocols or the Internet. While 323 most text messaging endpoints are mobile phones, increasingly, 324 broadband residential services support text messaging as well. The 325 originators of these messages typically impersonate a calling party 326 number, in some cases a "short code" specific to text messaging 327 services. 329 The envisioned countermeasures to robocalling are similar to those in 330 the voicemail example, but there are significant differences. One 331 important potential countermeasure is simply to verify that the 332 calling party number is in fact assignable and assigned. Unlike 333 voicemail services, end users typically have never been contacted by 334 the number used by a robocaller before. Thus they can't rely on past 335 association to anticipate whether or not the calling party number 336 should supply authenticated calling number data. If there were a 337 service that could inform the terminating side that it should expect 338 this data for calls or texts from that number, however, that would 339 also help in the robocalling case. 341 When a human callee is to be alerted at call setup time, the time 342 frame for executing any countermeasures is necessarily limited. 343 Ideally, a user would not be alerted that a call has been received 344 until any necessary identity checks have been performed. This could 345 however result in inordinate post-dial delay from the perspective of 346 legitimate callers. Cryptographic and network operations must be 347 minimized for these countermeasures to be practical. For text 348 messages, a delay for executing anti-impersonation countermeasures is 349 much less likely to degrade perceptible service. 351 The eventual effect of these countermeasures would be to force 352 robocallers to either block their caller identity, in which case end 353 users could opt not to receive such calls or messages, or to force 354 robocallers to use authenticated calling numbers traceable to them, 355 which would then allow for other forms of redress. 357 3.3. Telephony Denial-of-Service Attacks 359 In the case of telephony denial-of-service (or TDoS) attacks, the 360 attack relies on impersonation in order to obscure the origin of an 361 attack that is intended to tie up telephone resources. By placing 362 incessant telephone calls, an attacker renders a target number 363 unreachable by legitimate callers. These attacks might target a 364 business, an individual or a public resource like emergency 365 responders; the attacker may intend to extort the target. Attack 366 calls may be placed from a single endpoint, or from multiple 367 endpoints under the control of the attacker, and the attacker may 368 control endpoints in different administrative domains. Impersonation 369 in this case allows the attack to evade policies that would block 370 based on the originating number, and furthermore prevents the victim 371 from learning the perpetrator of the attack, or even the originating 372 service provider of the attacker. 374 As is the case with robocalling, the attacker typically does not have 375 to impersonate a specific number in order to launch a denial-of- 376 service attack. The number simply has to vary enough to prevent 377 simple policies from blocking the attack calls. An attacker may 378 however have a further intention to create the appearance that a 379 particular party is to blame for an attack, and in that case, the 380 attacker might want to impersonate a secondary target in the attack. 382 The envisioned countermeasures are twofold. First, as with 383 robocalling, ensuring that calling party numbers are assignable or 384 assigned will help mitigate unsophisticated attacks. Second, if 385 authenticated calling number data is supplied for legitimate calls, 386 then Internet endpoints or intermediaries can make effective policy 387 decisions in the middle of an attack by deprioritizing unsigned calls 388 when congestion conditions exist; signed calls, if accepted, have the 389 necessary accountability should it turn out they are malicious. This 390 could extend to include, for example, an originating network 391 observing a congestion condition for a destination number and perhaps 392 dropping unsigned calls that are clearly part of a TDoS attack. As 393 with robocalling, all of these countermeasures must execute in a 394 timely manner to be effective. 396 There are certain flavors of TDoS attacks, including those against 397 emergency responders, against which authenticated calling number data 398 is unlikely to be a successful countermeasure. These entities are 399 effectively obligated to attempt to respond to every call they 400 receive, and the absence of authenticated calling number data in many 401 cases will not remove that obligation. 403 4. Attack Scenarios 405 The examples that follow rely on Internet protocols including SIP 406 [RFC3261] and WebRTC [I-D.ietf-rtcweb-overview]. 408 Impersonation, IP-IP 410 An attacker with an IP phone sends a SIP request to an IP-enabled 411 voicemail service. The attacker puts a chosen calling party number 412 into the From header field value of the INVITE. When the INVITE 413 reaches the endpoint terminal, the terminal renders the attacker's 414 chosen calling party number as the calling identity. 416 Impersonation, PSTN-PSTN 418 An attacker with a traditional PBX (connected to the PSTN through 419 ISDN) sends a Q.931 SETUP request with a chosen calling party number 420 which a service provider inserts into the corresponding SS7 421 [refs.Q764] calling party number (CgPN) field of a call setup message 422 (IAM). When the call setup message reaches the endpoint switch, the 423 terminal renders the attacker's chosen calling party number as the 424 calling identity. 426 Impersonation, IP-PSTN 428 An attacker on the Internet uses a commercial WebRTC service to send 429 a call to the PSTN with a chosen calling party number. The service 430 contacts an Internet-to-PSTN gateway, which inserts the attacker's 431 chosen calling party number into the SS7 [refs.Q764] call setup 432 message (the CgPN field of an IAM). When the call setup message 433 reaches the terminating telephone switch, the terminal renders the 434 attacker's chosen calling party number as the calling identity. 436 Impersonation, IP-PSTN-IP 438 An attacker with an IP phone sends a SIP request to the telephone 439 number of a voicemail service, perhaps without even knowing that the 440 voicemail service is IP-based. The attacker puts a chosen calling 441 party number into the From header field value of the INVITE. The 442 attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts 443 the attacker's chosen calling party number into the CgPN of an IAM. 444 That IAM then traverses the PSTN until (perhaps after a call 445 forwarding) it reaches another gateway, this time back to the IP 446 realm, to an H.323 network. The PSTN-IP gateway takes the calling 447 party number in the IAM CgPN field and puts it into the SETUP 448 request. When the SETUP reaches the endpoint terminal, the terminal 449 renders the attacker's chosen calling party number as the calling 450 identity. 452 4.1. Solution-Specific Attacks 454 Solution-specific attacks are outside the scope of this document. 455 There are a few points which future work on solution-specific threats 456 must acknowledge. The design of the credential system envisioned as 457 a solution to this threats must for example limit the scope of the 458 credentials issued to carriers or national authorities to those 459 numbers that fall under their purview. This will impose limits on 460 what (verifiable) assertions can be made by intermediaries. 462 Some of the attacks that should be considered in the future include 463 the following: 465 Attacks Against In-band 467 Token replay 469 Baiting a call to a chosen number with a REFER 471 Removal of in-band signaling features 473 Attacks Against Out-of-Band 475 Provisioning Garbage CPRs 477 Data Mining 479 Attacks Against Either Approach 480 Attack on directories/services that say whether you should expect 481 authenticated calling number data or not 483 Canonicalization attacks 485 5. Acknowledgments 487 Sanjay Mishra, David Frankel, Penn Pfautz, Stephen Kent, Brian Rosen, 488 Alex Bobotek, Henning Schulzrinne, Hannes Tschofenig, Cullen Jennings 489 and Eric Rescorla provided key input to the discussions leading to 490 this document. 492 6. IANA Considerations 494 This memo includes no request to IANA. 496 7. Security Considerations 498 This document provides a threat model and is thus entirely about 499 security. 501 8. Informative References 503 [I-D.ietf-rtcweb-overview] 504 Alvestrand, H., "Overview: Real Time Protocols for Brower- 505 based Applications", draft-ietf-rtcweb-overview-09 (work 506 in progress), February 2014. 508 [I-D.ietf-stir-problem-statement] 509 Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 510 Telephone Identity Problem Statement and Requirements", 511 draft-ietf-stir-problem-statement-05 (work in progress), 512 May 2014. 514 [I-D.peterson-sipping-retarget] 515 Peterson, J., "Retargeting and Security in SIP: A 516 Framework and Requirements", draft-peterson-sipping- 517 retarget-00 (work in progress), February 2005. 519 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 520 A., Peterson, J., Sparks, R., Handley, M., and E. 521 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 522 June 2002. 524 [refs.OMTP-VV] 525 OMTP, , "Visual Voice Mail Interface Specification", URL: 526 http://www.gsma.com/newsroom/wp-content/uploads/2012/07/ 527 OMTP_VVM_Specification_1_3.pdf, May 1998. 529 [refs.Q764] 530 ITU-T, , "Signaling System No. 7; ISDN User Part Signaling 531 procedure", ITU-T URL: 532 http://www.itu.int/rec/T-REC-Q.764/_page.print, September 533 1997. 535 [refs.Q931] 536 ITU-T, , "ISDN user-network interface layer 3 537 specification for basic call control", ITU-T URL: 538 http://www.itu.int/rec/T-REC-Q.931-199805-I/en, May 1998. 540 Author's Address 542 Jon Peterson 543 NeuStar, Inc. 544 1800 Sutter St Suite 570 545 Concord, CA 94520 546 US 548 Email: jon.peterson@neustar.biz