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