idnits 2.17.00 (12 Aug 2021) /tmp/idnits15773/draft-ietf-stir-problem-statement-04.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 (May 9, 2014) is 2934 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4916' is defined on line 1063, but no explicit reference was found in the text == Outdated reference: draft-farrell-perpass-attack has been published as RFC 7258 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 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 H. Schulzrinne 5 Expires: November 10, 2014 Columbia University 6 H. Tschofenig 7 Nokia Siemens Networks 8 May 9, 2014 10 Secure Telephone Identity Problem Statement and Requirements 11 draft-ietf-stir-problem-statement-04.txt 13 Abstract 15 Over the past decade, Voice over IP (VoIP) systems based on SIP have 16 replaced many traditional telephony deployments. Interworking VoIP 17 systems with the traditional telephone network has reduced the 18 overall security of calling party number and Caller ID assurances by 19 granting attackers new and inexpensive tools to impersonate or 20 obscure calling party numbers when orchestrating bulk commercial 21 calling schemes, hacking voicemail boxes or even circumventing multi- 22 factor authentication systems trusted by banks. Despite previous 23 attempts to provide a secure assurance of the origin of SIP 24 communications, we still lack of effective standards for identifying 25 the calling party in a VoIP session. This document examines the 26 reasons why providing identity for telephone numbers on the Internet 27 has proven so difficult, and shows how changes in the last decade may 28 provide us with new strategies for attaching a secure identity to SIP 29 sessions. It also gives high-level requirements for a solution in 30 this space. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on November 10, 2014. 49 Copyright Notice 51 Copyright (c) 2014 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 68 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 69 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. VoIP-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 6 71 4.2. IP-PSTN-IP Call . . . . . . . . . . . . . . . . . . . . . 7 72 4.3. PSTN-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 8 73 4.4. VoIP-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 9 74 4.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 10 75 4.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 11 76 5. Limitations of Current Solutions . . . . . . . . . . . . . . 11 77 5.1. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 12 78 5.2. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 14 79 5.3. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 17 80 6. Environmental Changes . . . . . . . . . . . . . . . . . . . . 19 81 6.1. Shift to Mobile Communication . . . . . . . . . . . . . . 19 82 6.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 19 83 6.3. Public Key Infrastructure Developments . . . . . . . . . 20 84 6.4. Prevalence of B2BUA Deployments . . . . . . . . . . . . . 20 85 6.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 20 86 6.6. Concerns about Pervasive Monitoring . . . . . . . . . . . 21 87 6.7. Relationship with Number Assignment and Management . . . 21 88 7. Basic Requirements . . . . . . . . . . . . . . . . . . . . . 21 89 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22 90 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 91 10. Security Considerations . . . . . . . . . . . . . . . . . . . 23 92 11. Informative References . . . . . . . . . . . . . . . . . . . 23 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 95 1. Introduction 97 In many communication architectures that allow users to communicate 98 with other users, the need arises for identifying the originating 99 party that initiates a call or a messaging interaction. The desire 100 for identifying communication parties in end-to-end communication 101 attempt derives from the need to implement authorization policies (to 102 grant or reject call attempts) but has also been utilized for 103 charging. While there are a number of ways to enable identification 104 this functionality has been provided by the Session Initiation 105 Protocol (SIP) [RFC3261] by using two main types of approaches, 106 namely using P-Asserted-Identity (PAI) [RFC3325] and SIP Identity 107 [RFC4474], which are described in more detail in Section 5. The goal 108 of these mechanisms is to validate that originator of a call is 109 authorized to claim an originating identifier. Protocols, like XMPP, 110 use mechanisms that are conceptually similar to those offered by SIP. 112 Although solutions have been standardized, it turns out that the 113 current deployment situation is unsatisfactory and, even worse, there 114 is little indication that it will be improved in the future. In 115 [I-D.cooper-iab-secure-origin] we illustrate what challenges arise. 116 In particular, interworking with different communication 117 architectures (e.g., SIP, PSTN, XMPP, RTCWeb) or other forms of 118 mediation breaks the end-to-end semantic of the communication 119 interaction and destroys any identification capabilities. 120 Furthermore, the use of different identifiers (e.g., E.164 numbers 121 vs. SIP URIs) creates challenges for determining who is able to claim 122 "ownership" for a specific identifier; although domain-based 123 identifiers (sip:user@example.com) might use certificate or DNS- 124 related approaches to determine who is able to claim "ownership" of 125 the URI, telephone numbers do not yet have any similar mechanism 126 defined. 128 After the publication of the PAI and SIP Identity specifications 129 various further attempts have been made to tackle the topic but 130 unfortunately with little success. The complexity resides in the 131 deployment situation and the long list of (often conflicting) 132 requirements. A number of years have passed since the last attempts 133 were made to improve the situation and we therefore believe it is 134 time to give it another try. With this document we would like to 135 start to develop a common understanding of the problem statement as 136 well as basic requirements to develop a vision on how to advance the 137 state of the art and to initiate technical work to enable secure call 138 origin identification. 140 2. Problem Statement 142 In the classical public-switched telephone network, there were a 143 limited number of carriers, all of whom trusted each other to provide 144 accurate caller origination information, in an evnironment without 145 any cryptographic validation. In some cases, national 146 telecommunication regulation codified these obligations. This model 147 worked as long as the number of entities was relatively small, easily 148 identified (e.g., in the manner carriers are certified int he US) and 149 subject to effective legal sanctions in case of misbehavior. 150 However, for some time, these assumptions have no longer held true. 151 For example, entities that are not traditional telecommunication 152 carriers, possibly located outside the country whose country code 153 they are using, can act as voice service providers. While in the 154 past, there was a clear distinction between customers and service 155 providers, VoIP service providers can now easily act as customers, 156 originating and transit providers. The problem is moreover not 157 limited to voice communications, as growth in text messaging has made 158 it another vector for bulk unsolicited commercial messaging relying 159 on impersonation of a source telephone number (sometimes a short 160 code). For telephony, Caller ID spoofing has become common, with a 161 small subset of entities either ignoring abuse of their services or 162 willingly serving to enable fraud and other illegal behavior. 164 For example, recently, enterprises and public safety organizations 165 [TDOS] have been subjected to telephony denial-of-service attacks. 166 In this case, an individual claiming to represent a collections 167 company for payday loans starts the extortion scheme with a phone 168 call to an organization. Failing to get payment from an individual 169 or organization, the criminal organization launches a barrage of 170 phone calls, with spoofed numbers, preventing the targeted 171 organization from receiving legitimate phone calls. Other boiler- 172 room organizations use number spoofing to place illegal "robocalls" 173 (automated telemarketing, see, for example, the US Federal 174 Communications Commission webpage [robocall-fcc] on this topic). 175 Robocalls are a problem that has been recognized already by various 176 regulators; for example, the US Federal Trade Commission (FTC) 177 recently organized a robocall competition to solicit ideas for 178 creating solutions that will block illegal robocalls 179 [robocall-competition]. Criminals may also use number spoofing to 180 impersonate banks or bank customers to gain access to information or 181 financial accounts. 183 In general, number spoofing is used in two ways, impersonation and 184 anonymization. For impersonation, the attacker pretends to be a 185 specific individual. Impersonation can be used for pretexting, where 186 the attacker obtains information about the individual impersonated, 187 activates credit cards or for harassment, e.g., by causing utility 188 services to be disconnected, take-out food to be delivered, or by 189 causing police to respond to a non-existing hostage situation 190 ("swatting", see [swatting]). Some voicemail systems can be set up 191 so that they grant access to stored messages without a password, 192 relying solely on the caller identity. As an example, the News 193 International phone-hacking scandal [news-hack] has also gained a lot 194 of press attention where employees of the newspaper were accused of 195 engaging in phone hacking by utilizing Caller ID spoofing to get 196 access to a voicemail. For numbers where the caller has suppressed 197 textual caller identification, number spoofing can be used to 198 retrieve this information, stored in the so-called Calling Name 199 (CNAM) database. For anonymization, the caller does not necessarily 200 care whether the number is in service, or who it is assigned to, and 201 may switch rapidly and possibly randomly between numbers. 202 Anonymization facilitates automated illegal telemarketing or 203 telephony denial-of-service attacks, as described above, as it makes 204 it difficult to identify perpetators and craft policies to block 205 them. It also makes tracing such calls much more labor-intensive, as 206 each call has to be identified in each transit carrier hop-by-hop, 207 based on destination number and time of call. 209 It is insufficient to simply outlaw all spoofing of originating 210 telephone numbers, because the entities spoofing numbers are already 211 committing other crimes and thus unlikely to be deterred by legal 212 sanctions. Secure origin identification should prevent impersonation 213 and, to a lesser extent, anonymization. However, if numbers are easy 214 and cheap to obtain, and if the organizations assigning identifiers 215 cannot or will not establish the true corporate or individual 216 identity of the entity requesting such identifiers, robocallers will 217 still be able to switch between many different identities. 219 The problem space is further complicated by a number of use cases 220 where entities in the telephone network legitimately send calls on 221 behalf of others, including "Find-Me/Follow-Me" services. 222 Ultimately, any SIP entity can receive an INVITE and forward it to 223 any other entity, and the recipient of a forwarded message has little 224 means to ascertain which recipient a call should legitimately target 225 (see [I-D.peterson-sipping-retarget]. Also, in some cases, third 226 parties may need to temporarily use the identity of another 227 individual or organization, with full consent of the "owner" of the 228 identifier. For example: 230 The doctor's office: Physicians calling their patients using their 231 cell phones would like to replace their mobile phone number with 232 the number of their office to avoid being called back by patients 233 on their personal phone. 235 Call centers: Call centers operate on behalf of companies and the 236 called party expects to see the Caller ID of the company, not the 237 call center. 239 3. Terminology 241 The following terms are defined in this document: 243 In-band Identity Conveyance: In-band conveyance is the presence of 244 call origin identification information conveyed within the control 245 plane protocol(s) setting up a call. Any in-band solution must 246 accommodate prevalence of in-band intermdiaries such as B2BUAs. 248 Out-of-Band Identity Verification: Out-of-band verification 249 determines whether the telephone number used by the calling party 250 actually exists, whether the calling entity is entitled to use the 251 number and whether a call has recently been made from this phone 252 number. This approach is needed because the in-band technique 253 does not work in all cases, as when certain intermediaries are 254 involved or due to interworking with PSTN networks. 256 Authority Delegation Infrastructure: This functionality defines how 257 existing authority over telephone numbers are used in number 258 portability and delegation cases. It also describes how the 259 existing numbering infrastructure is re-used to maintain the 260 lifecycle of number assignments. 262 Canonical Telephone Number: In order for either in-band conveyance 263 or out-of-band verification to work, entities in this architecture 264 must be able to canonicalize telephone numbers to arrive at a 265 common syntactical form. 267 4. Use Cases 269 In order to explain the requirements and other design assumptions we 270 will explain some of the scenarios that need to be supported by any 271 solution. To reduce clutter, the figures do not show call routing 272 elements, such as SIP proxies, of voice or text service providers. 273 We generally assume that the PSTN component of any call path cannot 274 be altered. 276 4.1. VoIP-to-VoIP Call 278 For the IP-to-IP communication case, a group of service providers 279 that offer interconnected VoIP service exchange calls using SIP end- 280 to-end, but may also deliver some calls via circuit-switched 281 facilities, as described in separate use cases below. These service 282 providers use telephone numbers as source and destination 283 identifiers, either as the user component of a SIP URI (e.g., 284 sip:12125551234@example.com) or as a tel URI [RFC3966]. 286 As illustrated in Figure 1, if Alice calls Bob, the call will use SIP 287 end-to-end. (The call may or may not traverse the Internet.) 289 +------------+ 290 | IP-based | 291 | SIP Phone |<--+ 292 | of Bob | | 293 |+19175551234| | 294 +------------+ | 295 | 296 +------------+ | 297 | IP-based | | 298 | SIP Phone | ------------ 299 | of Alice | / | \ 300 |+12121234567| // | \\ 301 +------------+ // ,' \\\ 302 | /// / ----- 303 | //// ,' \\\\ 304 | / ,' \ 305 | | ,' | 306 +---->|......: IP-based | 307 | Network | 308 \ / 309 \\\\ //// 310 ------------------------- 312 Figure 1: VoIP-to-VoIP Call. 314 4.2. IP-PSTN-IP Call 316 Frequently, two VoIP-based service providers are not directly 317 connected by VoIP and use TDM circuits to exchange calls, leading to 318 the IP-PSTN-IP use case. In this use case, Dan's VSP is not a member 319 of the interconnect federation Alice's and Bob's VSP belongs to. As 320 far as Alice is concerned Dan is not accessible via IP and the PSTN 321 is used as an interconnection network. Figure 2 shows the resulting 322 exchange. 324 -------- 325 //// \\\\ 326 +--- >| PSTN | 327 | | | 328 | \\\\ //// 329 | -------- 330 | | 331 | | 332 | | 333 +------------+ +--+----+ | 334 | IP-based | | PSTN | | 335 | SIP Phone | --+ VoIP +- v 336 | of Alice | / | GW | \ +---+---+ 337 |+12121234567| // `''''''' \\| PSTN | 338 +------------+ // | \+ VoIP + 339 | /// | | GW |\ 340 | //// | `'''''''\\ +------------+ 341 | / | | \ | IP-based | 342 | | | | | | Phone | 343 +---->|---------------+ +------|---->| of Dan | 344 | | |+12039994321| 345 \ IP-based / +------------+ 346 \\\\ Network //// 347 ------------------------- 349 Figure 2: IP-PSTN-IP Call. 351 Note: A B2BUA/Session Border Controller (SBC) exhibits behavior that 352 looks similar to this scenario since the original call content would, 353 in the worst case, be re-created on the call origination side. 355 4.3. PSTN-to-VoIP Call 357 Consider Figure 3 where Carl is using a PSTN phone and initiates a 358 call to Alice. Alice is using a VoIP-based phone. The call from 359 Carl traverses the PSTN and enters the Internet via a PSTN/VoIP 360 gateway. This gateway attaches some identity information to the 361 call, for example, based on the caller identification information it 362 had received through the PSTN, if available. 364 -------- 365 //// \\\\ 366 +->| PSTN |--+ 367 | | | | 368 | \\\\ //// | 369 | -------- | 370 | | 371 | v 372 | +----+-------+ 373 +---+------+ |PSTN / VoIP | +-----+ 374 |PSTN Phone| |Gateway | |SIP | 375 |of Carl | +----+-------+ |UA | 376 +----------+ | |Alice| 377 Invite +-----+ 378 | ^ 379 V | 380 +---------------+ Invite 381 |VoIP | | 382 |Interconnection| Invite +-------+ 383 |Provider(s) |----------->+ | 384 +---------------+ |Alice's| 385 |VSP | 386 | | 387 +-------+ 389 Figure 3: PSTN-to-VoIP Call. 391 4.4. VoIP-to-PSTN Call 393 Consider Figure 4 where Alice calls Carl. Carl uses a PSTN phone and 394 Alice an IP-based phone. When Alice initiates the call, the E.164 395 number is get translated to a SIP URI and subsequently to an IP 396 address. The call of Alice traverses her VoIP provider where the 397 call origin identification information is added. It then hits the 398 PSTN/VoIP gateway. It is desirable that the gateway verify that 399 Alice can claim the E.164 number she is using before it populates the 400 corresponding calling party number field in telephone network 401 signaling. Carl's phone must be able to verify that it is receiving 402 a legitimate call from the calling party number it will render to 403 Carl. 405 +-------+ +-----+ -C 406 |PSTN | |SIP | |a 407 |Phone |<----------------+ |UA | |l 408 |of Carl| | |Alice| |l 409 +-------+ | +-----+ |i 410 --------------------------- | |n 411 //// \\\\ | |g 412 | PSTN | Invite | 413 | | | |P 414 \\\\ //// | |a 415 --------------------------- | |r 416 ^ | |t 417 | v |y 418 +------------+ +--------+| 419 |PSTN / VoIP |<--Invite----|VoIP ||D 420 |Gateway | |Service ||o 421 +------------+ |Provider||m 422 |of Alice||a 423 +--------+|i 424 -n 426 Figure 4: IP-to-PSTN Call. 428 4.5. PSTN-VoIP-PSTN Call 430 Consider Figure 5 where Carl calls Alice. Both users have PSTN 431 phones but interconnection between the two PSTN networks is 432 accomplished via an IP network. Consequently, Carl's operator uses a 433 PSTN-to-VoIP gateway to route the call via an IP network to a gateway 434 to break out into the PSTN again. 436 +----------+ 437 |PSTN Phone| 438 -------- |of Alice | 439 //// \\\\ +----------+ 440 +->| PSTN |------+ ^ 441 | | | | | 442 | \\\\ //// | | 443 | -------- | -------- 444 | v //// \\\\ 445 | ,-------+ | PSTN | 446 | |PSTN | | | 447 +---+------+ __|VoIP GW|_ \\\\ //// 448 |PSTN Phone| / '`''''''' \ -------- 449 |of Carl | // | \\ ^ 450 +----------+ // | \\\ | 451 /// -. Invite ----- | 452 //// `-. \\\\ | 453 / `.. \ | 454 | IP-based `._ ,--+----+ 455 | Network `.....>|VoIP | 456 | |PSTN GW| 457 \ '`''''''' 458 \\\\ //// 459 ------------------------- 461 Figure 5: PSTN-VoIP-PSTN Call. 463 4.6. PSTN-to-PSTN Call 465 For the "legacy" case of a PSTN-to-PSTN call, otherwise beyond 466 improvement, we may be able to use out-of-band IP connectivity at 467 both the originating and terminating carrier to validate the call 468 information. 470 5. Limitations of Current Solutions 472 From the inception of SIP, the From header field value has held an 473 arbitrary user-supplied identity, much like the From header field 474 value of an SMTP email message. During work on [RFC3261], efforts 475 began to provide a secure origin for SIP requests as an extension to 476 SIP. The so-called "short term" solution, the P-Asserted-Identity 477 header described in [RFC3325], is deployed fairly widely, even though 478 it is limited to closed trusted networks where end-user devices 479 cannot alter or inspect SIP messages and offers no cryptographic 480 validation. As P-Asserted-Identity is used increasingly across 481 multiple networks, it cannot offer any protection against identity 482 spoofing by intermediaries or entities that allow untrusted entities 483 to set the P-Asserted-Identity information. An overview of 484 addressing spam in SIP, and explaining how it differs from simiilar 485 problems with email, appeared in [RFC5039]. 487 Subsequent efforts to prevent calling origin identity spoofing in SIP 488 include the SIP Identity effort (the "long term" identity solution) 489 [RFC4474] and Verification Involving PSTN Reachability (VIPR) 490 [I-D.jennings-vipr-overview]. SIP Identity attaches a new header 491 field to SIP requests containing a signature over the From header 492 field value combined with other message components to prevent replay 493 attacks. SIP Identity is meant to prevent both: (a) SIP UAs from 494 originating calls with spoofed From headers; and (b) intermediaries, 495 such as SIP proxies, from launching man-in-the-middle attacks by 496 altering calls as they pass through the intermediaries. The VIPR 497 architecture attacked a broader range of problems relating to spam, 498 routing and identity with a new infrastructure for managing 499 rendezvous and security, which operated alongside of SIP deployments. 501 As we will describe in more detail below, both SIP Identity and VIPR 502 suffer from serious limitations that have prevented their deployment 503 at significant scale, but they may still offer ideas and protocol 504 building blocks for a solution. 506 5.1. P-Asserted-Identity 508 The P-Asserted-Identity header field of SIP [RFC3325] provides a way 509 for trusted network entities to share with one another an 510 authoritative identifier for the originator of a call. The value of 511 P-Asserted-Identity cannot be populated by a user, though if a user 512 wants to suggest an identity to the trusted network, a separate 513 header (P-Preferred-Identity) enables them to do so. The features of 514 the P-Asserted-Identity header evolved as part of a broader effort to 515 reach parity with traditional telephone network signaling mechanisms 516 for selectively sharing and restricting presentation of the calling 517 party number at the user level, while still allowing core network 518 elements to know the identity of the user for abuse prevention and 519 accounting. 521 In order for P-Asserted-Identity to have these properties, it 522 requires the existence of a trust domain as described in [RFC3324]. 523 Any entity in the trust domain may add a P-Asserted-Identity header 524 to a SIP message, and any entity in the trust domain may forward a 525 message with a P-Asserted-Identity header to any other entity in the 526 trust domain. If a trusted entity forwards a SIP request to an 527 untrusted entity, however, the P-Asserted-Identity header must first 528 be removed; most sorts of end user devices are outside trust domains. 529 Sending a P-Asserted-Identity request to an untrusted entity could 530 leak potentially private information, such as the network-asserted 531 calling party number in a case where a caller has requested 532 presentation restriction. This concept of a trust domain is modeled 533 on the trusted network of devices that operate the traditional 534 telephone network. 536 P-Asserted-Identity has been very successful in telephone replacement 537 deployments of SIP. It is an extremely simple in-band mechanism, 538 requiring no cryptographic operations. Since it is so reminiscent of 539 legacy mechanisms in the traditional telephone network, and it 540 interworks so seamlessly with those protocols, it has naturally been 541 favored by providers comfortable with these operating principles. 543 In practice, a trust domain exhibits many of the same merits and 544 flaws as the traditional telephone network when it comes to securing 545 a calling party number. Any trusted entity may provide P-Asserted- 546 Identity, and a recipient of a SIP message has no direct assurance of 547 who generated the P-Asserted-Identity header field value: all trust 548 is transitive. Trust domains are dictated by business arrangements 549 more than by security standards, and thus the level of assurance of P 550 -Asserted-Identity is only as good as the least trustworthy member of 551 a trust domain. Since the contents of P-Asserted-Identity are not 552 intended for consumption by end users, end users must trust that 553 their service provider participates in an appropriate trust domain, 554 as there will be no direct evidence of the trust domain in SIP 555 signaling that end user devices receive. Since the mechanism is so 556 closely modeled on the traditional telephone network, it is unlikely 557 to provide a higher level of security than that. 559 Since [RFC3325] was written, the whole notion of P- headers intended 560 for use in private SIP domains has also been deprecated (see 561 [RFC5727], largely because of overwhelming evidence that these 562 headers were being used outside of private contexts and leaking into 563 the public Internet. It is unclear how many deployments that make 564 use of P-Asserted-Identity in fact conform with the Spec-T 565 requirements of RFC3324. 567 P-Asserted-Identity also complicates the question of which URI should 568 be presented to a user when a call is received. Per RFC3261, SIP 569 user agents would render the contents of the From header field to a 570 user when receiving an INVITE request, but what if the P-Asserted- 571 Identity contains a more trustworthy URI, and presentation is not 572 restricted? Subsequent proposals have suggested additional header 573 fields to carry different forms of identity related to the caller, 574 including billing identities. As the calling identities in a SIP 575 request proliferate, the question of how to select one to render to 576 the end user becomes more difficult to answer. 578 5.2. SIP Identity 580 The SIP Identity mechanism [RFC4474] provided two header fields for 581 securing identity information in SIP requests: the Identity and 582 Identity-Info header fields. Architecturally, the SIP Identity 583 mechanism assumes a classic "SIP trapezoid" deployment in which an 584 authentication service, acting on behalf of the originator of a SIP 585 request, attaches identity information to the request which provides 586 partial integrity protection; a verification service acting on behalf 587 of the recipient validates the integrity of the request when it is 588 received. 590 The Identity header field value contains a signature over a hash of 591 selected elements of a SIP request, including several header field 592 values (most significantly, the From header field value) and the 593 entirety of the body of the request. The set of header field values 594 was chosen specifically to prevent cut-and-paste attacks; it requires 595 the verification service to retain some state to guard against 596 replays. The signature over the body of a request has different 597 properties for different SIP methods, but all prevent tampering by 598 man-in-the-middle attacks. For a SIP MESSAGE request, for example, 599 the signature over the body covers the actual message conveyed by the 600 request: it is pointless to guarantee the source of a request if a 601 man-in-the-middle can change the content of the message, as in that 602 case the message content is created by an attacker. Similar threats 603 exist against the SIP NOTIFY method. For a SIP INVITE request, a 604 signature over the SDP body is intended to prevent a man-in-the- 605 middle from changing properties of the media stream, including the IP 606 address and port to which media should be sent, as this provides a 607 means for the man-in-the-middle to direct session media to resource 608 that the originator did not specify, and thus to impersonate an 609 intended listener. 611 The Identity-Info header field value contains a URI designating the 612 location of the certificate corresponding to the private key that 613 signed the hash in the Identity header. That certificate could be 614 passed by-value along with the SIP request, in which case a "cid" URI 615 appears in Identity-Info, or by-reference, for example when the 616 Identity-Info header field value has the URL of a service that 617 delivers the certificate. [RFC4474] imposes further constraints 618 governing the subject of that certificate: namely, that it must cover 619 the domain name indicated in the domain component of the URI in the 620 From header field value of the request. 622 The SIP Identity mechanism, however, has two fundamental limitations 623 that have precluded its deployment: first, that it provides Identity 624 only for domain names rather than other identifiers; second, that it 625 does not tolerate intermediaries that alter the bodies, or certain 626 header fields, of SIP requests. 628 As deployed, SIP predominantly mimics the structures of the telephone 629 network, and thus uses telephone numbers as identifiers. Telephone 630 numbers in the From header field value of a SIP request may appear as 631 the user part of a SIP URI, or alternatively in an independent tel 632 URI. The certificate designated by the Identity-Info header field as 633 specified, however, corresponds only to the domain portion of a SIP 634 URI in the From header field. As such, [RFC4474] does not have any 635 provision to identify the assignee of a telephone number. While it 636 could be the case that the domain name portion of a SIP URI signifies 637 a carrier (like "att.com") to whom numbers are assigned, the SIP 638 Identity mechanism provides no assurance that a number is assigned to 639 any carrier. For a tel URI, moreover, it is unclear in [RFC4474] 640 what entity should hold a corresponding certificate. A caller may 641 not want to reveal the identity of its service provider to the 642 callee, and may thus prefer tel URIs in the From header field. 644 This lack of authority gives rise to a whole class of SIP identity 645 problems when dealing with telephone numbers, as is explored in 646 [I-D.rosenberg-sip-rfc4474-concerns]. That document shows how the 647 Identity header of a SIP request targeting a telephone number 648 (embedded in a SIP URI) could be dropped by an intermediate domain, 649 which then modifies and re-signs the request, all without alerting 650 the verification service: the verification service has no way of 651 knowing which original domain signed the request. Provided that the 652 local authentication service is complicit, an originator can claim 653 virtually any telephone number, impersonating any chosen Caller ID 654 from the perspective of the verifier. Both of these attacks are 655 rooted in the inability of the verification service to ascertain a 656 specific certificate that is authoritative for a telephone number. 658 As deployed, SIP is moreover highly mediated, and mediated in ways 659 that [RFC3261] did not anticipate. As request routing commonly 660 depends on policies dissimilar to [RFC3263], requests transit 661 multiple intermediate domains to reach a destination; some forms of 662 intermediaries in those domains may effectively re-initiate the 663 session. 665 One of the main reasons that SIP deployments mimic the PSTN 666 architecture is because the requirement for interconnection with the 667 PSTN remains paramount: a call may originate in SIP and terminate on 668 the PSTN, or vice versa; and worse still, a PSTN-to-PSTN call may 669 transit a SIP network in the middle, or vice versa. This necessarily 670 reduces SIP's feature set to the least common dominator of the 671 telephone network, and mandates support for telephone numbers as a 672 primary calling identifier. 674 Interworking with non-SIP networks makes end-to-end identity 675 problematic. When a PSTN gateway sends a call to a SIP network, it 676 creates the INVITE request anew, regardless of whether a previous leg 677 of the call originated in a SIP network that later dropped the call 678 to the PSTN. As these gateways are not necessarily operated by 679 entities that have any relationship to the number assignee, it is 680 unclear how they could provide an identity signature that a verifier 681 should trust. Moreover, how could the gateway know that the calling 682 party number it receives from the PSTN is actually authentic? And 683 when a gateway receives a call via SIP and terminates a call to the 684 PSTN, how can that gateway verify that a telephone number in the From 685 header field value is authentic, before it presents that number as 686 the calling party number in the PSTN? 688 Similarly, some SIP networks deploy intermediaries that act as back- 689 to-back user agents (B2BUAs), typically in order to provide policy or 690 interworking functions at network boundaries (hence the nickname 691 "Session Border Controller"). These functions range from topology 692 hiding, to alterations necessary to interoperate successfully with 693 particular SIP implementations, to simple network address translation 694 from private address space. To achieve these aims, these entities 695 modify SIP INVITE requests in transit, potentially changing the From, 696 Contact and Call-ID header field values, as well as aspects of the 697 SDP, including especially the IP addresses and ports associated with 698 media. Consequently, a SIP request exiting a B2BUA has no necessary 699 relationship to the original request received by the B2BUA, much like 700 a request exiting a PSTN gateway has no necessary relationship to any 701 SIP request in a pre-PSTN leg of the call. An Identity signature 702 provided for the original INVITE has no bearing on the post-B2BUA 703 INVITE, and, were the B2BUA to preserve the original Identity header, 704 any verification service would detect a violation of the integrity 705 protection. 707 The SIP community has long been aware of these problems with 708 [RFC4474] in practical deployments. Some have therefore proposed 709 weakening the security constraints of [RFC4474] so that at least some 710 deployments of B2BUAs will be compatible with integrity protection of 711 SIP requests. However, such solutions do not address one key problem 712 identified above: the lack of any clear authority for telephone 713 numbers, and the fact that some INVITE requests are generated by 714 intermediaries rather than endpoints. Removing the signature over 715 the SDP from the Identity header will not, for example, make it any 716 clearer how a PSTN gateway should assert identity in an INVITE 717 request. 719 5.3. VIPR 721 Verification Involving PSTN Reachability (VIPR) directly attacks the 722 twin problems of identifying number assignees on the Internet and 723 coping with intermediaries that may modify signaling. To address the 724 first problem, VIPR relies on the PSTN itself: it discovers which 725 endpoints on the Internet are reachable via a particular PSTN number 726 by calling the number on the PSTN to determine whom a call to that 727 number will reach. As VIPR-enabled Internet endpoints associated 728 with PSTN numbers are discovered, VIPR provides a rendez-vous service 729 that allows the endpoints of a call to form an out-of-band connection 730 over the Internet; this connection allows the endpoints to exchange 731 information that secures future communications and permits direct, 732 unmediated SIP connections. 734 VIPR provides these services within a fairly narrow scope of 735 applicability. Its seminal use case is the enterprise IP PBX, a 736 device that has both PSTN connectivity and Internet connectivity, 737 which serves a set of local users with telephone numbers; after a 738 PSTN call has connected successfully and then ended, the PBX searches 739 a distributed hash-table to see if any VIPR-compatible devices have 740 advertised themselves as a route for the unfamiliar number on the 741 Internet. If advertisements exist, the originating PBX then 742 initiates a verification process to determine whether the entity 743 claiming to be the assignee of the unfamiliar number in fact received 744 the successful call: this involves verifying details such as the 745 start and stop times of the call. If the destination verifies 746 successfully, the originating PBX provisions a local database with a 747 route for that telephone number to the URI provided by the proven 748 destination. The destination moreover gives a token to the 749 originator that can be inserted in future call setup messages to 750 authenticate the source of future communications. 752 Through this mechanism, the VIPR system provides a suite of 753 properties, ones that go well beyond merely securing the origins of 754 communications. It also provides a routing system which dynamically 755 discovers mappings between telephone numbers and URIs, effectively 756 building an ad hoc ENUM database in every VIPR implementation. The 757 tokens exchanged over the out-of-band connection established by VIPR 758 moreover provide an authorization mechanism for accepting calls over 759 the Internet that significantly reduces the potential for spam. 760 Because the token can act as a cookie due to the presence of this 761 out-of-band connectivity, the VIPR token is less susceptible to cut- 762 and-paste attacks and thus needs to cover with its signature far less 763 of a SIP request. 765 Due to its narrow scope of applicability, and the details of its 766 implementation, VIPR has some significant limitations. The most 767 salient for the purposes of this document is that it only has bearing 768 on repeated communications between entities: it has no solution to 769 the classic "robocall" problem, where the target typically receives a 770 call from a number that has never called before. All of VIPR's 771 strengths in establishing identity and spam prevention kick in only 772 after an initial PSTN call has been completed, and subsequent 773 attempts at communication begin. Every VIPR-compliant entity 774 moreover maintains its own stateful database of previous contacts and 775 authorizations, which lends itself to more aggregators like IP PBXs 776 that may front for thousands of users than to individual phones. 777 That database must be refreshed by periodic PSTN calls to determine 778 that control over the number has not shifted to some other entity; 779 figuring out when data has grown stale is one the challenges of the 780 architecture. As VIPR requires compliant implementations to operate 781 both a PSTN interface and an IP interface, it has little apparent 782 applicability to ordinary desktop PCs or similar devices with no 783 ability to place direct PSTN calls. 785 The distributed hash table also creates a new attack surface for 786 impersonation. Attackers who want to pose as the owners of telephone 787 numbers can advertise themselves as routes to a number in the hash 788 table. VIPR has no inherent restriction on the number of entities 789 that may advertise themselves as routes for a number, and thus an 790 originator may find multiple advertisements for a number on the DHT 791 even when an attack is not in progress. As for attackers, even if 792 they cannot successfully verify themselves to the originators of 793 calls (because they lack the call detail information), they may learn 794 from those verification attempts which VIPR entities recently placed 795 calls to the target number: it may be that this information is all 796 the attacker hopes to glean. The fact that advertisements and 797 verifications are public results from the public nature of the DHT 798 that VIPR creates. The public DHT prevents any centralized control, 799 or attempts to impede communications, but those come at the cost of 800 apparently unavoidable privacy losses. 802 Because of these limitations, VIPR, much like SIP Identity, has had 803 little impact in the marketplace. Ultimately, VIPR's utility as an 804 identity mechanism is limited by its reliance on the PSTN, especially 805 its need for an initial PSTN call to complete before any of VIPR's 806 benefits can be realized, and by the drawbacks of the highly-public 807 exchanges requires to create the out-of-band connection between VIPR 808 entities. As such, there is no obvious solution to providing secure 809 origin services for SIP on the Internet today. 811 6. Environmental Changes 813 6.1. Shift to Mobile Communication 815 In the years since [RFC4474] was conceived, there have been a number 816 of fundamental shifts in the communications marketplace. The most 817 transformative has been the precipitous rise of mobile smart phones, 818 which are now arguably the dominant communications device in the 819 developed world. Smart phones have both a PSTN and an IP interface, 820 as well as an SMS and MMS capabilities. This suite of tools suggests 821 that some of the techniques proposed by VIPR could be adapted to the 822 smart phone environment. The installed base of smart phones is 823 moreover highly upgradable, and permits rapid adoption of out-of-band 824 rendezvous services for smart phones that circumvent the PSTN. 825 Mobile messaging services that use telephone numbers as identities 826 allow smart phone users to send text messages to one another over the 827 Internet rather than over the PSTN. Like VIPR, such services create 828 an out-of-band connection over the Internet between smart phones; 829 unlike VIPR, the rendezvous service is provided by a trusted 830 centralized database rather than by a DHT, and it is the centralized 831 database that effectively verifies and asserts the telephone number 832 of the sender of a message. While such messaging services are 833 specific to the users of the specific service, it seems clear that 834 similar databases could be provided by neutral third parties in a 835 position to coordinate between endpoints. 837 6.2. Failure of Public ENUM 839 At the time [RFC4474] was written, the hopes for establishing a 840 certificate authority for telephone numbers on the Internet largely 841 rested on public ENUM deployment. The e164.arpa DNS tree established 842 for ENUM could have grown to include certificates for telephone 843 numbers or at least for number ranges. It is now clear however that 844 public ENUM as originally envisioned has little prospect for 845 adoption. That said, some national authorities for telephone numbers 846 are migrating their provisioning services to the Internet, and 847 issuing credentials that express authority for telephone numbers to 848 secure those services. These new authorities for numbers could 849 provide to the public Internet the necessary signatory authority for 850 securing calling partys' numbers. While these systems are far from 851 universal, the authors of this draft believe that a solution devised 852 for the North American Numbering Plan could have applicability to 853 other country codes. 855 6.3. Public Key Infrastructure Developments 857 Also, there have been a number of recent high-profile compromises of 858 web certificate authorities. The presence of numerous (in some 859 cases, of hundreds) of trusted certificate authorities in modern web 860 browsers has become a significant security liability. As [RFC4474] 861 relied on web certificate authorities, this too provides new lessons 862 for any work on revising [RFC4474]: namely, that innovations like 863 DANE [RFC6698] that designate a specific certificate preferred by the 864 owner of a DNS name could greatly improve the security of a SIP 865 identity mechanism; and moreover, that when considering new 866 certificate authorities for telephone numbers, we should be wary of 867 excessive pluralism. While a chain of delegation with a 868 progressively narrowing scope of authority (e.g., from a regulatory 869 entity to a carrier to a reseller to an end user) is needed to 870 reflect operational practices, there is no need to have multiple 871 roots, or peer entities that both claim authority for the same 872 telephone number or number range. 874 6.4. Prevalence of B2BUA Deployments 876 Given the prevalence of established B2BUA deployments, we may have a 877 further opportunity to review the elements signed by [RFC4474] and to 878 decide on the value of alternative signature mechanisms. Separating 879 the elements necessary for (a) securing the From header field value 880 and preventing replays, from (b) the elements necessary to prevent 881 men-in-the-middle from tampering with messages, may also yield a 882 strategy for identity that will be practicable in some highly 883 mediated networks. Solutions in this space must however remain 884 mindful of the requirements for securing cryptographic material 885 necessary to support DTLS-SRTP or future security mechanisms. 887 6.5. Stickiness of Deployed Infrastructure 889 One thing that has not changed, and is not likely to change in the 890 future, is the transitive nature of trust in the PSTN. When a call 891 from the PSTN arrives at a SIP gateway with a calling party number, 892 the gateway will have little chance of determining whether the 893 originator of the call was authorized to claim that calling party 894 number. Due to roaming and countless other factors, calls on the 895 PSTN may emerge from administrative domains that were not assigned 896 the originating number. This use case will remain the most difficult 897 to tackle for an identity system, and may prove beyond repair. It 898 does however seem that with the changes in the solution space, and a 899 better understanding of the limits of [RFC4474] and VIPR, we are 900 today in a position to reexamine the problem space and find solutions 901 that can have a significant impact on the secure origins problem. 903 6.6. Concerns about Pervasive Monitoring 905 While spoofing the origins of communication is a source of numerous 906 security concerns, solutions for identifying communications must also 907 be mindful of the security risks of pervasive monitoring (see 908 [I-D.farrell-perpass-attack]). Identifying information, once it is 909 attached to communications, can potentially be inspected by parties 910 other than the intended recipient and collected for any number of 911 reasons. As stated above, the purpose of this work is not to 912 eliminate anonymity, but furthermore, to be viable and in the public 913 interest, solutions should not facilitate the unauthorized collection 914 of calling data. 916 6.7. Relationship with Number Assignment and Management 918 Currently, telephone numbers are typically managed in a loose 919 delegation hierarchy. For example, a national regulatory agency may 920 task a private, neutral entity with administering numbering 921 resources, such as area codes, and a similar entity with assigning 922 number blocks to carriers and other authorized entities, who in turn 923 then assign numbers to customers. Resellers with looser regulatory 924 obligations can complicate the picture, and in many cases it is 925 difficult to distinguish the roles of enterprises from carriers. In 926 many countries, individual numbers are portable between carriers, at 927 least within the same technology (e.g., wireline-to-wireline). 928 Separate databases manage the mapping of numbers to switch 929 identifiers, companies and textual caller ID information. 931 As the PSTN transitions to using VoIP technologies, new assignment 932 policies and management mechanisms are likely to emerge. For 933 example, it has been proposed that geography could play a smaller 934 role in number assignments, and that individual numbers are assigned 935 to end users directly rather than only to service providers, or that 936 the assignment of numbers does not depend on providing actual call 937 delivery services. 939 Databases today already map telephone numbers to entities that have 940 been assigned the number, e.g., through the LERG (originally, Local 941 Exchange Routing Guide) in the United States. Thus, the transition 942 to IP-based networks may offer an opportunity to integrate 943 cryptographic bindings between numbers or number ranges and service 944 providers into databases. 946 7. Basic Requirements 948 This section describes only the high level requirements of the 949 effort, which we expected will be further articulated as work 950 continues: 952 Generation: Intermediaries as well as end system must be able to 953 generate the source identity information. 955 Validation: Intermediaries as well as end system must be able to 956 validate the source identity information. 958 Usability: Any validation mechanism must work without human 959 intervention, that is, without for exammple CAPTCHA-like 960 mechanisms. 962 Deployability: Must survive transition of the call to the PSTN and 963 the presence of B2BUAs. 965 Reflecting existing authority: Must stage credentials on existing 966 national-level number delegations, without assuming the need for 967 an international golden root on the Internet. 969 Accommodating current practices: Must allow number portability among 970 carriers and must support legitimate usage of number spoofing 971 (doctor's office and call centers) 973 Minimal payload overhead: Must lead to minimal expansion of SIP 974 headers fields to avoid fragmentation in deployments that use UDP. 976 Efficiency: Must minimize RTTs for any network lookups and minimize 977 any necessary cryptographic operations. 979 Privacy: A solution must prevent unauthorized third parties from 980 learning what numbers have been called by a specific caller. 982 Some requirements specifically outside the scope of the effort 983 include: 985 Display name: This effort does not consider how the display name of 986 the caller might be validated. 988 Response authentication: This effort only considers the problem of 989 providing secure telephone identity for requests, not for 990 responses to requests; no solution is here proposed for the 991 problem of determining to which number a call has connected. 993 8. Acknowledgments 995 We would like to thank Sanjay Mishra, Fernando Mousinho, David 996 Frankel, Penn Pfautz, Mike Hammer, Dan York, Andrew Allen, Philippe 997 Fouquart, Hadriel Kaplan, Richard Shockey, Russ Housley, Alissa 998 Cooper, Bernard Aboba, Sean Turner, Brian Rosen, Eric Burger, and 999 Eric Rescorla for their discussion input that lead to this document. 1001 9. IANA Considerations 1003 This memo includes no request to IANA. 1005 10. Security Considerations 1007 This document is about improving the security of call origin 1008 identification; security considerations for specific solutions will 1009 be discussed in solutions documents. 1011 11. Informative References 1013 [I-D.cooper-iab-secure-origin] 1014 Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, 1015 "Secure Call Origin Identification", draft-cooper-iab- 1016 secure-origin-00 (work in progress), November 2012. 1018 [I-D.farrell-perpass-attack] 1019 Farrell, S. and H. Tschofenig, "Pervasive Monitoring is an 1020 Attack", draft-farrell-perpass-attack-06 (work in 1021 progress), February 2014. 1023 [I-D.jennings-vipr-overview] 1024 Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 1025 Huguenin, "Verification Involving PSTN Reachability: 1026 Requirements and Architecture Overview", draft-jennings- 1027 vipr-overview-06 (work in progress), December 2013. 1029 [I-D.peterson-sipping-retarget] 1030 Peterson, J., "Retargeting and Security in SIP: A 1031 Framework and Requirements", draft-peterson-sipping- 1032 retarget-00 (work in progress), February 2005. 1034 [I-D.rosenberg-sip-rfc4474-concerns] 1035 Rosenberg, J., "Concerns around the Applicability of RFC 1036 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 1037 progress), February 2008. 1039 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1040 A., Peterson, J., Sparks, R., Handley, M., and E. 1041 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1042 June 2002. 1044 [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1045 Protocol (SIP): Locating SIP Servers", RFC 3263, June 1046 2002. 1048 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 1049 Identity", RFC 3324, November 2002. 1051 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 1052 Extensions to the Session Initiation Protocol (SIP) for 1053 Asserted Identity within Trusted Networks", RFC 3325, 1054 November 2002. 1056 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 1057 3966, December 2004. 1059 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1060 Authenticated Identity Management in the Session 1061 Initiation Protocol (SIP)", RFC 4474, August 2006. 1063 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 1064 Protocol (SIP)", RFC 4916, June 2007. 1066 [RFC5039] Rosenberg, J. and C. Jennings, "The Session Initiation 1067 Protocol (SIP) and Spam", RFC 5039, January 2008. 1069 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 1070 for the Session Initiation Protocol (SIP) and the Real- 1071 time Applications and Infrastructure Area", BCP 67, RFC 1072 5727, March 2010. 1074 [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1075 of Named Entities (DANE) Transport Layer Security (TLS) 1076 Protocol: TLSA", RFC 6698, August 2012. 1078 [TDOS] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on 1079 Public Emergency Networks", URL: 1080 http://krebsonsecurity.com/2013/04/dhs-warns-of-tdos- 1081 extortion-attacks-on-public-emergency-networks/, Apr 2013. 1083 [news-hack] 1084 Wikipedia, , "News International phone hacking scandal", 1085 URL: http://en.wikipedia.org/wiki/ 1086 News_International_phone_hacking_scandal, Apr 2013. 1088 [robocall-competition] 1089 FTC, , "FTC Robocall Challenge", URL: 1090 http://robocall.challenge.gov/, Apr 2013. 1092 [robocall-fcc] 1093 FCC, , "Robocalls", URL: 1094 http://www.fcc.gov/guides/robocalls, Apr 2013. 1096 [swatting] 1097 Wikipedia, , "Don't Make the Call: The New Phenomenon of 1098 'Swatting'", URL: http://www.fbi.gov/news/stories/2008/ 1099 february/swatting020408, Feb 2008. 1101 Authors' Addresses 1103 Jon Peterson 1104 Neustar, Inc. 1105 1800 Sutter St Suite 570 1106 Concord, CA 94520 1107 US 1109 Email: jon.peterson@neustar.biz 1111 Henning Schulzrinne 1112 Columbia University 1113 Department of Computer Science 1114 450 Computer Science Building 1115 New York, NY 10027 1116 US 1118 Phone: +1 212 939 7004 1119 Email: hgs@cs.columbia.edu 1120 URI: http://www.cs.columbia.edu 1122 Hannes Tschofenig 1123 Nokia Siemens Networks 1124 Linnoitustie 6 1125 Espoo 02600 1126 Finland 1128 Phone: +358 (50) 4871445 1129 Email: Hannes.Tschofenig@gmx.net 1130 URI: http://www.tschofenig.priv.at