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