idnits 2.17.1 draft-ietf-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 (October 12, 2013) is 3849 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '1' is defined on line 420, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 424, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 429, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 434, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 439, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 443, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 446, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 449, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 461, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 465, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 470, but no explicit reference was found in the text == Unused Reference: '14' is defined on line 475, 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 (-05) exists of draft-ietf-stir-problem-statement-00 == Outdated reference: A later version (-04) exists of draft-ietf-straw-b2bua-loop-detection-02 == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-04 Summary: 0 errors (**), 0 flaws (~~), 16 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 October 12, 2013 5 Expires: April 15, 2014 7 Secure Telephone Identity Threat Model 8 draft-ietf-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 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 April 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 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 4. Attack Scenarios . . . . . . . . . . . . . . . . . . . . . . 8 64 4.1. TBD: Solution-Specific Attacks . . . . . . . . . . . . . 8 65 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 68 8. Informative References . . . . . . . . . . . . . . . . . . . 9 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction and Scope 73 As is discussed in the STIR problem statement [9], the primary 74 enabler of robocalling, vishing, swatting and related attacks is the 75 capability to impersonate a calling party number. The starkest 76 example of these attacks are cases where automated callees on the 77 PSTN rely on the calling number as a security measure, for example to 78 access a voicemail system. Robocallers use impersonation as a means 79 of 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 preferable. 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 a callee (human user 89 or automaton) at the time of call set-up. The primary attack vector 90 is therefore one where the attacker contrives for the calling 91 telephone number in signaling to be a specific number. In this 92 attack, the number is one that the attacker is not authorized to use 93 (as a caller), but gives in order for that number to be consumed or 94 rendered on the terminating side. The threat model assumes that this 95 attack simply cannot be prevented: there is no way to stop the 96 attacker from creating calls that contain attacker-chosen calling 97 telephone numbers. The solution space therefore focuses on ways that 98 terminating or intermediary elements might differentiate authorized 99 from unauthorized calling party numbers, in order that policies, 100 human or automatic, might act on that information. 102 Securing an authenticated calling party number at call set-up time 103 does not entail anything about the entity or entities that will send 104 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 of a call. In those end-to-end IP environments where such an 108 assurance is possible, it is highly desirable. However, in the 109 threat model described in this document, "impersonation" does not 110 consider impersonating an authorized listener after a call has been 111 established, such as a third party attempting to eavesdrop on a 112 conversation. Attackers that could impersonate an authorized 113 listener require capabilities that robocallers and voicemail hackers 114 are unlikely to possess, and historically such attacks have not 115 played a role in enabling robocalling or related problems. 117 In SIP and even many traditional telephone protocols, call signaling 118 can be renegotiated after the call has been established. Using 119 various transfer mechanisms common in telephone systems, a callee can 120 easily be connected to, or conferenced in with, telephone numbers 121 other than the original calling number once a call has been 122 established. These post-setup changes to the call are outside the 123 scope of impersonation considered in this model. Furthermore, 124 impersonating a reached number to the originator of a call is outside 125 the scope of this threat model. 127 In much of the PSTN, there exists a supplemental service that 128 translates calling party numbers into regular names, including the 129 proper names of people and businesses, for rendering to the called 130 user. These services (frequently termed 'Caller ID') provide a 131 further attack surface for impersonation. The threat model described 132 in this document addresses only the calling party number, even though 133 presenting a forged calling party number may cause a forged 'Caller 134 ID' name to be rendered to the user as well. Providing a verifiable 135 calling party number therefore improve the security of Caller ID 136 systems, but this threat model does not consider attacks specific to 137 Caller ID. Such attacks may be carried out against the databases 138 consulted by the terminating side of a call to provide Caller ID, or 139 by impersonators forging a particular calling party number in order 140 to present a misleading Caller ID to the user. 142 2. Actors 143 2.1. Endpoints 145 There are two main categories of end-user terminals relevant to this 146 discussion, a dumb device (such as a 'black phone') or a smart 147 device: 149 Dumb devices comprise a simple dial pad, handset and ringer, 150 optionally accompanied by a display that can render a limited 151 number of characters (typically, enough for a telephone number and 152 an accompanying name, sometimes less). Although users interface 153 with these devices, the intelligence that drives them lives in the 154 service provider network. 156 Smart devices are general purpose computers with some degree of 157 programmability, and with the capacity to access the Internet and 158 to render text, audio and/or images. This category includes smart 159 phones, telephone applications on desktop and laptop computers, IP 160 private branch exchanges, and so on. 162 There is a further category of automated terminals without an end 163 user. These include systems like voicemail services, which may 164 provide a different set of services to a caller based solely on the 165 calling party's number, granting the mailbox owner access to a menu 166 while giving other callers only the ability to leave a message. 167 Though the capability of voicemail services varies widely, many today 168 have Internet access and advanced application interfaces (to render 169 'visual voicemail,' to automatically transcribe voicemail to email, 170 and so on). 172 There is a further category of automated terminals without an end 173 user. These include systems like voicemail services that consume the 174 calling party number without rendering it to a human. Though the 175 capability of voicemail services varies widely, many today have 176 Internet access and advanced application interfaces (to render 177 'visual voicemail,' to automatically transcribe voicemail to email, 178 and so on). 180 2.2. Intermediaries 182 The endpoints of a traditional telephone call connect through 183 numerous intermediary switches in the network. The set of 184 intermediary devices traversed during call setup between two 185 endpoints is referred to as a call path. The length of the call path 186 can vary considerably: it is possible in VoIP deployments for two 187 endpoint entities to send traffic to one another directly, but, more 188 commonly, several intermediaries exist in a VoIP call path. One or 189 more gateways may also appear on a call path. 191 Intermediaries forward call signaling to the next entity in the 192 path. These intermediaries may also modify the signaling in order 193 to improve interoperability, to enable proper network-layer media 194 connections, or to enforce operator policy. This threat model 195 assumes there are no restrictions on the modifications to 196 signaling that an intermediary can introduce (which is consistent 197 with the observed behavior of such devices). 199 Gateways translate call signaling from one protocol into another. 200 In the process, they tend to consume any signaling specific of the 201 original protocol (elements like transaction-matching identifiers) 202 and may need to transcode or otherwise alter identifiers as they 203 are rendered in the destination protocol. 205 This threat model assumes that intermediaries and gateways can 206 forward and retarget calls as necessary, which can result in a call 207 terminating at a place the originator did not expect; this is an 208 common condition in call routing. This is significant to the 209 solution space, because it limits the ability of the originator to 210 anticipate what the telephone number of the respondent will be (for 211 more on the "unanticipated respondent" problem, see [10]). 213 Furthermore, we assume that some intermediaries or gateways may, due 214 to their capabilities or policies, discard calling party number 215 information, in whole or part. Today, many IP-PSTN gateways simply 216 ignore any information available about the caller in the IP leg of 217 the call, and allow the telephone number of the PRI line used by the 218 gateway to be sent as the calling party number for the PSTN leg of 219 the call. A call might also gateway to a multifrequency network 220 where only a limited number of digits of automatic numbering 221 identification (ANI) data are signaled, for example. Some protocols 222 may render telephone numbers in a way that makes it impossible for a 223 terminating side to parse or canonicalize a number. In these cases, 224 providing authenticated identity may be impossible. This is not 225 however indicative of an attack or other security failure. 227 2.3. Attackers 229 We assume that an attacker has the following capabilities: 231 An attacker can create telephone calls at will, originating them 232 either on the PSTN or over IP, and can supply an arbitrary calling 233 party number. 235 An attacker can capture and replay signaling previously observed 236 by it. [TBD: should this include an attacker that can capture 237 signaling that isn't directly sent to it? Not a factor for 238 robocalling, but perhaps for voicemail hacking, say.] 239 An attacker has access to the Internet, and thus the ability to 240 inject arbitrary traffic over the Internet, to access public 241 directories, and so on. 243 There are attack scenarios in which an attacker compromises 244 intermediaries in the call path, or captures credentials that allow 245 the attacker to impersonate a target. Those system-level attacks are 246 not considered in this threat model, though secure design and 247 operation of systems to prevent these sorts of attacks is necessary 248 for envisioned countermeasures to work. 250 This threat model also does not consider scenarios in which the 251 operators of intermediaries or gateways are themselves adversaries 252 who intentionally discard valid identity information (without a user 253 requesting anonymity) or who send falsified identity using their own 254 credentials. The design of the credential system will however limit 255 the scope of the credentials issued to carriers or national 256 authorities to those numbers that fall under their purview. 258 3. Attacks 260 3.1. Voicemail Hacking via Impersonation 262 A voicemail service allows users calling from their mobile phones 263 access to their voicemail boxes on the basis of the calling party 264 number. If an attacker wants to access the voicemail of a particular 265 target, the attacker may try to impersonate the calling party number 266 using one of the scenarios described below. 268 The envisioned countermeasures for this attack involve the voicemail 269 treating calls that supply an authenticated identity differently from 270 other calls. In the absence of identity, for example, a voicemail 271 service might enforce some other caller authentication policy 272 (perhaps requiring a PIN for caller authentication). Authenticated 273 identity alone provides a positive confirmation only when an identity 274 is claimed legitimately; the absence of authenticated identity here 275 may not be evidence of malice, just of uncertainty. 277 If the voicemail service could learn ahead of time that it should 278 expect authenticated identity from a particular number, that would 279 enable the voicemail service to adopt stricter policies for handling 280 a request without authenticated identity. Since users contact a 281 voicemail service repeatedly, the service could for example remember 282 which users usually sign their requests and require further 283 authentication mechanisms when signatures are absent. Alternatively, 284 issuers of credentials or other authorities could provide a service 285 that informs verifiers that they should expect identity signatures in 286 calls from particular numbers. 288 3.2. Unsolicited Commercial Calling from Impersonated Numbers 290 The unsolicited commercial calling, or for short robocalling, attack 291 is similar to the voicemail attack, except that the robocaller does 292 not need to impersonate the particular number controlled by the 293 target, merely some "plausible" number. A robocaller may impersonate 294 a number that is not an assignable number (for example, in the United 295 States, a number beginning with 0), or an unassigned number. A 296 robocaller may change numbers every time a new call is placed, even 297 selecting numbers randomly. 299 A closely related attack is sending unsolicited bulk commercial 300 messages via text messaging services. Almost always, these messages 301 originate on the Internet, though they may ultimately reach endpoints 302 over traditional telephone network protocols or the Internet. While 303 most text messaging endpoints are mobile phones, increasingly 304 broadband residential services support text messaging as well. The 305 originators of these messages typically impersonate a calling party 306 number, in some cases a "short code" specific to text messaging 307 services. 309 The envisioned countermeasures to robocalling are similar to those in 310 the voicemail example, but there are significant differences. One 311 important potential countermeasure is simply to verify that the 312 calling party number is in fact assignable and assigned. Unlike 313 voicemail services, end users typically have never been contacted by 314 the number used by a robocaller before. Thus they can't rely on past 315 association to anticipate whether or not the calling party number 316 should supply authenticated identity. If there were a service that 317 could inform the terminating side of that it should expect an 318 identity signature in calls or texts from that number, however, that 319 would also help in the robocalling case. 321 When a human callee is to be alerted at call setup time, the time 322 frame for executing any countermeasures is necessarily limited. 323 Ideally, a user would not be alerted that a call has been received 324 until any necessary identity checks have been performed. This could 325 however result in inordinate post-dial delay from the perspective of 326 legitimate callers. Cryptographic operations and network operations 327 must be minimized for these countermeasures to be practical. For 328 text messages, a delay for executing anti-impersonation 329 countermeasures is much less likely to degrade perceptible service. 331 The eventual effect of these countermeasures would be to force 332 robocallers to either block their caller identity, in which case end 333 users could opt not to receive their calls or messages, or to force 334 robocallers to use authenticated identity for numbers traceable to 335 them, which would then allow for other forms of redress. 337 4. Attack Scenarios 339 Impersonation, IP-PSTN 341 An attacker on the Internet uses a commercial WebRTC service to send 342 a call to the PSTN with a chosen calling party number. The service 343 contacts an Internet-to-PSTN gateway, which inserts the attacker's 344 chosen calling party number into the CPN field of an IAM. When the 345 IAM reaches the terminating telephone switch, the terminal renders 346 the attacker's chosen calling party number as the calling identity. 348 Impersonation, PSTN-PSTN 350 An attacker with a traditional PBX (connected to the PSTN through 351 ISDN) sends a Q.931 SETUP request with a chosen calling party number 352 which a service provider inserts into the corresponding SS7 calling 353 party number (CPN) field of a call setup message (IAM). When the IAM 354 reaches the endpoint switch, the terminal renders the attacker's 355 chosen calling party number as the calling identity. 357 Impersonation, IP-IP 359 An attacker with an IP phone sends a SIP request to an IP-enabled 360 voicemail service. The attacker puts a chosen calling party number 361 into the From header field value of the INVITE. When the INVITE 362 reaches the endpoint terminal, the terminal renders the attacker's 363 chosen calling party number as the calling identity. 365 Impersonation, IP-PSTN-IP 367 An attacker with an IP phone sends a SIP request to the telephone 368 number of a voicemail service, perhaps without even knowing that the 369 voicemail service is IP-based. The attacker puts a chosen calling 370 party number into the From header field value of the INVITE. The 371 attacker's INVITE reaches an Internet-to-PSTN gateway, which inserts 372 the attacker's chosen calling party number into the CPN of an IAM. 373 That IAM then traverses the PSTN until (perhaps after a call 374 forwarding) it reaches another gateway, this time back to the IP 375 realm, to an H.323 network. The PSTN-IP gateway puts takes the 376 calling party number in the IAM CPN field and puts it into the SETUP 377 request. When the SETUP reaches the endpoint terminal, the terminal 378 renders the attacker's chosen calling party number as the calling 379 identity. 381 4.1. TBD: Solution-Specific Attacks 383 [TBD: This is just forward-looking notes] 384 Attacks Against In-band 386 Token replay 388 Removal of in-band signaling features 390 Attacks Against Out-of-Band 392 Provisioning Gargbage CPRs 394 Data Mining 396 Attacks Against Either Approach 398 Attack on directories/services that say whether you should expect 399 authenticated identity or not 401 Canonicalization attack 403 5. Acknowledgments 405 Stephen Kent, Brian Rosen, Alex Bobotek, Henning Schulzrinne, Hannes 406 Tschofenig, Cullen Jennings and Eric Rescorla provided key input to 407 the discussions leading to this document. 409 6. IANA Considerations 411 This memo includes no request to IANA. 413 7. Security Considerations 415 This document provides a threat model and is thus entirely about 416 security. 418 8. Informative References 420 [1] Peterson, J. and C. Jennings, "Enhancements for 421 Authenticated Identity Management in the Session 422 Initiation Protocol (SIP)", RFC 4474, August 2006. 424 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 425 A., Peterson, J., Sparks, R., Handley, M., and E. 426 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 427 June 2002. 429 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 430 A., Peterson, J., Sparks, R., Handley, M., and E. 431 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 432 June 2002. 434 [4] Jennings, C., Peterson, J., and M. Watson, "Private 435 Extensions to the Session Initiation Protocol (SIP) for 436 Asserted Identity within Trusted Networks", RFC 3325, 437 November 2002. 439 [5] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 440 of Named Entities (DANE) Transport Layer Security (TLS) 441 Protocol: TLSA", RFC 6698, August 2012. 443 [6] Elwell, J., "Connected Identity in the Session Initiation 444 Protocol (SIP)", RFC 4916, June 2007. 446 [7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 447 3966, December 2004. 449 [8] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, 450 "Secure Call Origin Identification", draft-cooper-iab- 451 secure-origin-00 (work in progress), November 2012. 453 [9] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 454 Telephone Identity Problem Statement", draft-ietf-stir- 455 problem-statement-00 (work in progress), October 2013. 457 [10] Peterson, J., "Retargeting and Security in SIP: A 458 Framework and Requirements", draft-peterson-sipping- 459 retarget-00 (work in progress), February 2005. 461 [11] Rosenberg, J., "Concerns around the Applicability of RFC 462 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 463 progress), February 2008. 465 [12] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for 466 Session Initiation Protocol (SIP) Back-to- Back User 467 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-02 468 (work in progress), September 2013. 470 [13] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 471 Huguenin, "Verification Involving PSTN Reachability: 472 Requirements and Architecture Overview", draft-jennings- 473 vipr-overview-04 (work in progress), February 2013. 475 [14] Rosenberg, J. and H. Schulzrinne, "Session Initiation 476 Protocol (SIP): Locating SIP Servers", RFC 3263, June 477 2002. 479 Author's Address 481 Jon Peterson 482 NeuStar, Inc. 483 1800 Sutter St Suite 570 484 Concord, CA 94520 485 US 487 Email: jon.peterson@neustar.biz