idnits 2.17.1 draft-ietf-stir-problem-statement-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (December 7, 2013) is 3791 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 993, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1010, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 1023, but no explicit reference was found in the text == Unused Reference: '13' is defined on line 1031, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (ref. '1') (Obsoleted by RFC 8224) -- Duplicate reference: RFC3261, mentioned in '3', was also mentioned in '2'. == Outdated reference: A later version (-04) exists of draft-ietf-straw-b2bua-loop-detection-02 == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-04 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft NeuStar, Inc. 4 Intended status: Informational H. Schulzrinne 5 Expires: June 10, 2014 Columbia University 6 H. Tschofenig 7 Nokia Siemens Networks 8 December 7, 2013 10 Secure Telephone Identity Problem Statement 11 draft-ietf-stir-problem-statement-01.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 June 10, 2014. 48 Copyright Notice 50 Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 66 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 67 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . 9 74 4.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 10 75 5. Limitations of Current Solutions . . . . . . . . . . . . . . 10 76 5.1. P-Asserted-Identity . . . . . . . . . . . . . . . . . . . 11 77 5.2. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 12 78 5.3. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 15 79 6. Environmental Changes . . . . . . . . . . . . . . . . . . . . 17 80 6.1. Shift to Mobile Communication . . . . . . . . . . . . . . 17 81 6.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 18 82 6.3. Public Key Infrastructure Developments . . . . . . . . . 18 83 6.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 18 84 6.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 19 85 6.6. Relationship with Number Assignment and Management . . . 19 86 7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 20 87 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 88 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 89 10. Security Considerations . . . . . . . . . . . . . . . . . . . 21 90 11. Informative References . . . . . . . . . . . . . . . . . . . 21 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 93 1. Introduction 94 In many communication architectures that allow users to communicate 95 with other users, the need for identifying the originating party that 96 initiates a call or a messaging interaction arises. The desire for 97 identifying the communication parties in the end-to-end communication 98 attempt derives from the need to implement authorization policies (to 99 grant or reject call attempts) but has also been utilized for 100 charging. While there are a number of ways to enable identification 101 this functionality has been provided by the Session Initiation 102 Protocol (SIP) [2] by using two main types of approaches, namely 103 using P-Asserted-Identity (PAI) [5] and SIP Identity [1], which are 104 described in more detail in Section 5. The goal of these mechanisms 105 is to validate that originator of a call is authorized to claim an 106 originating identifier. Protocols, like XMPP, use mechanisms that 107 are conceptually similar to those offered by SIP. 109 Although solutions have been standardized, it turns out that the 110 current deployment situation is unsatisfactory and, even worse, there 111 is little indication that it will be improved in the future. In [10] 112 we illustrate what challenges arise. In particular, interworking 113 with different communication architectures (e.g., SIP, PSTN, XMPP, 114 RTCWeb) or other forms of mediation breaks the end-to-end semantic of 115 the communication interaction and destroys any identification 116 capabilities. Furthermore, the use of different identifiers (e.g., 117 E.164 numbers vs. SIP URIs) creates challenges for determining who is 118 able to claim "ownership" for a specific identifier; although domain- 119 based identifiers (sip:user@example.com) might use certificate or 120 DNS-related approaches to determine who is able to claim "ownership" 121 of the URI, telephone numbers do not yet have any similar mechanism 122 defined. 124 After the publication of the PAI and SIP Identity specifications 125 various further attempts have been made to tackle the topic but 126 unfortunately with little success. The complexity resides in the 127 deployment situation and the long list of (often conflicting) 128 requirements. A number of years have passed since the last attempts 129 were made to improve the situation and we therefore believe it is 130 time to give it another try. With this document we would like to 131 start an attempt to develop a common understanding of the problem 132 statement as well as requirements to develop a vision on how to 133 advance the state of the art and to initiate technical work to enable 134 secure call origin identification. 136 2. Problem Statement 138 In the classical public-switched telephone network, a limited number 139 of carriers trusted each other, without any cryptographic validation, 140 to provide accurate caller origination information. In some cases, 141 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 [16] 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 [17] on 171 this topic). Robocalls is a problem that has been recognized already 172 by various regulators, for example the Federal Communications 173 Commission (FCC) recently organized a robocall competition to solicit 174 ideas for creating solutions that will block illegal robocalls [18]. 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 [20]). 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 [19] 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. 192 For numbers where the caller has suppressed textual caller 193 identification, number spoofing can be used to retrieve this 194 information, stored in the so-called Calling Name (CNAM) database. 195 For anonymization, the caller does not necessarily care whether the 196 number is in service, or who it is assigned to, and may switch 197 rapidly and possibly randomly between numbers. Anonymization 198 facilitates automated illegal telemarketing or telephony denial-of- 199 service attacks, as described above, as it makes it difficult to 200 blacklist numbers. It also makes tracing such calls much more labor- 201 intensive, as each such call has to be identified in each transit 202 carrier hop-by-hop, based on 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. Ultimately, any SIP entity can receive an INVITE 217 and forward it any other entity, and the recipient of a forwarded 218 message has little means to ascertain which recipient a call should 219 legitimately target. Also, in some cases, third parties may need to 220 temporarily use the identity of another individual or organization, 221 with full consent of the "owner" of the identifier. For example: 223 The doctor's office: Physicians calling their patients using their 224 cell phones would like to replace their mobile phone number with 225 the number of their office to avoid being called back by patients 226 on their personal phone. 228 Call centers: Call centers operate on behalf of companies and the 229 called party expects to see the Caller ID of the company, not the 230 call center. 232 3. Terminology 234 The following terms are defined in this document: 236 In-band Identity Conveyance: In-band conveyance is the presence of 237 call origin identification information conveyed within the control 238 plane protocol(s) setting up a call. Any in-band solution must 239 accommodate prevalence of in-band intermdiaries such as B2BUAs. 241 Out-of-Band Identity Verification: Out-of-band verification 242 determines whether the E.164 number used by the calling party 243 actually exists, whether the calling entity is entitled to use the 244 number and whether a call has recently been made from this phone 245 number. This approach is needed when the in-band technique does 246 not work due to intermediaries or due to interworking with PSTN 247 networks. 249 Authority Delegation Infrastructure: This functionality defines how 250 existing authority over E.164 telephone numbers are used in number 251 portability and delegation cases. It also describes how the 252 existing numbering infrastructure is re-used to maintain the 253 lifecycle of number assignments. 255 Canonical Telephone Number: In order for either in-band conveyance 256 or out-of-band verification to work, entities in this architecture 257 must be able to canonicalize telephone numbers to arrive at a 258 common syntactical form. 260 4. Use Cases 262 In order to explain the requirements and other design assumptions we 263 will explain some of the scenarios that need to be supported by any 264 solution. To reduce clutter, the figures do not show call routing 265 elements, such as SIP proxies, of voice or text service providers. 266 We generally assume that the PSTN component of any call path cannot 267 be altered. 269 4.1. VoIP-to-VoIP Call 271 For the IP-to-IP communication case, a group of service providers 272 that offer interconnected VoIP service exchange calls using SIP end- 273 to-end, but may also deliver some calls via circuit-switched 274 facilities, as described in separate use cases below. These service 275 providers use telephone numbers as source and destination 276 identifiers, either as the user component of a SIP URI (e.g., 277 sip:12125551234@example.com) or as a tel URI [8]. 279 As illustrated in Figure 1, if Alice calls Bob, the call will use SIP 280 end-to-end. (The call may or may not traverse the Internet.) 282 +------------+ 283 | IP-based | 284 | SIP Phone |<--+ 285 | of Bob | | 286 |+19175551234| | 287 +------------+ | 288 | 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. The gateway must verify that Alice can claim the 393 E.164 number she is using before it populates the corresponding 394 calling party number field in telephone network signaling. Carl's 395 phone must be able to verify that it is receiving a legitimate call 396 from the calling party number it will render to Carl. 398 +-------+ +-----+ -C 399 |PSTN | |SIP | |a 400 |Phone |<----------------+ |UA | |l 401 |of Carl| | |Alice| |l 402 +-------+ | +-----+ |i 403 --------------------------- | |n 404 //// \\\\ | |g 405 | PSTN | Invite | 406 | | | |P 407 \\\\ //// | |a 408 --------------------------- | |r 409 ^ | |t 410 | v |y 411 +------------+ +--------+| 412 |PSTN / VoIP |<--Invite----|VoIP ||D 413 |Gateway | |Service ||o 414 +------------+ |Provider||m 415 |of Alice||a 416 +--------+|i 417 -n 419 Figure 4: IP-to-PSTN Call. 421 4.5. PSTN-VoIP-PSTN Call 423 Consider Figure 5 where Carl calls Alice. Both users have PSTN 424 phones but interconnection between the two PSTN networks is 425 accomplished via an IP network. Consequently, Carl's operator uses a 426 PSTN-to-VoIP gateway to route the call via an IP network to a gateway 427 to break out into the PSTN again. 429 +----------+ 430 |PSTN Phone| 431 -------- |of Alice | 432 //// \\\\ +----------+ 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 [5], 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 [9]. 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) [14]. 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 [5] 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 [4]. 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 [5] was written, the whole notion of P- headers intended for 553 use in private SIP domains has also been deprecated, largely because 554 of overwhelming evidence that these headers were being used outside 555 of private contexts and leaking into the public Internet. It is 556 unclear how many deployments that make use of P-Asserted-Identity in 557 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 [15], 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 [6] 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 864 Given the prevalence of established B2BUA deployments, we may have a 865 further opportunity to review the elements signed by [1] and to 866 decide on the value of alternative signature mechanisms. Separating 867 the elements necessary for (a) securing the From header field value 868 and preventing replays, from (b) the elements necessary to prevent 869 men-in-the-middle from tampering with messages, may also yield a 870 strategy for identity that will be practicable in some highly 871 mediated networks. Solutions in this space must however remain 872 mindful of the requirements for securing cryptographic material 873 necessary to support DTLS-SRTP or future security mechanisms. 875 6.5. Stickiness of Deployed Infrastructure 877 One thing that has not changed, and is not likely to change in the 878 future, is the transitive nature of trust in the PSTN. When a call 879 from the PSTN arrives at a SIP gateway with a calling party number, 880 the gateway will have little chance of determining whether the 881 originator of the call was authorized to claim that calling party 882 number. Due to roaming and countless other factors, calls on the 883 PSTN may emerge from administrative domains that were not assigned 884 the originating number. This use case will remain the most difficult 885 to tackle for an identity system, and may prove beyond repair. It 886 does however seem that with the changes in the solution space, and a 887 better understanding of the limits of [1] and VIPR, we are today in a 888 position to reexamine the problem space and find solutions that can 889 have a significant impact on the secure origins problem. 891 6.6. Relationship with Number Assignment and Management 893 Currently, telephone numbers are typically managed in a loose 894 delegation hierarchy. For example, a national regulatory agency may 895 task a private, neutral entity with administering numbering 896 resources, such as area codes, and a similar entity with assigning 897 number blocks to carriers and other authorized entities, who in turn 898 then assign numbers to customers. Resellers with looser regulatory 899 obligations can complicate the picture, and in many cases it is 900 difficult to distinguish the roles of enterprises from carriers. In 901 many countries, individual numbers are portable between carriers, at 902 least within the same technology (e.g., wireline-to-wireline). 903 Separate databases manage the mapping of numbers to switch 904 identifiers, companies and textual caller ID information. 906 As the PSTN transitions to using VoIP technologies, new assignment 907 policies and management mechanisms are likely to emerge. For 908 example, it has been proposed that geography could play a smaller 909 role in number assignments, and that individual numbers are assigned 910 to end users directly rather than only to service providers, or that 911 the assignment of numbers does not depend on providing actual call 912 delivery services. 914 Databases today already map telephone numbers to entities that have 915 been assigned the number, e.g., through the LERG (originally, Local 916 Exchange Routing Guide) in the United States. Thus, the transition 917 to IP-based networks may offer an opportunity to integrate 918 cryptographic bindings between numbers or number ranges and service 919 providers into databases. 921 7. Requirements 923 This section describes the high level requirements of the effort: 925 Generation: Intermediaries as well as end system must be able to 926 generate the source identity information. 928 Validation: Intermediaries as well as end system must be able to 929 validate the source identity information. 931 Usability: Any validation mechanism must work without human 932 intervention, e.g., CAPTCHA-like mechanisms. 934 Deployability: Must survive transition of the call to the PSTN and 935 the presence of B2BUAs. 937 Reflecting existing authority: Must stage credentials on existing 938 national-level number delegations, without assuming the need for 939 an international golden root on the Internet. 941 Accommodating current practices: Must allow number portability among 942 carriers and must support legitimate usage of number spoofing 943 (doctor's office and call centers) 945 Minimal payload overhead: Must lead to minimal expansion of SIP 946 headers fields to avoid fragmentation in deployments that use UDP. 948 Efficiency: Must minimize RTTs for any network lookups and minimize 949 any necessary cryptographic operations. 951 Privacy: Any out-of-band validation protocol must not allows third 952 parties to learn what numbers have been called by a specific 953 caller. 955 Some requirements specifically outside the scope of the effort 956 include: 958 Display name: This effort does not consider how the display name of 959 the caller might be validated. 961 Response authentication: This effort only considers the problem of 962 providing secure telephone identity for requests, not for 963 responses to requests; no solution is here proposed for the 964 problem of determining to which number a call has connected. 966 8. Acknowledgments 968 We would like to thank Mike Hammer, Dan York, Andrew Allen, Philippe 969 Fouquart, Hadriel Kaplan, Russ Housley, Alissa Cooper, Bernard Aboba, 970 Sean Turner, Brian Rosen, Eric Burger, and Eric Rescorla for their 971 discussion input that lead to this document. 973 9. IANA Considerations 975 This memo includes no request to IANA. 977 10. Security Considerations 979 This document is about improving the security of call origin 980 identification. 982 11. Informative References 984 [1] Peterson, J. and C. Jennings, "Enhancements for 985 Authenticated Identity Management in the Session 986 Initiation Protocol (SIP)", RFC 4474, August 2006. 988 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 989 A., Peterson, J., Sparks, R., Handley, M., and E. 990 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 991 June 2002. 993 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 994 A., Peterson, J., Sparks, R., Handley, M., and E. 995 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 996 June 2002. 998 [4] Watson, M., "Short Term Requirements for Network Asserted 999 Identity", RFC 3324, November 2002. 1001 [5] Jennings, C., Peterson, J., and M. Watson, "Private 1002 Extensions to the Session Initiation Protocol (SIP) for 1003 Asserted Identity within Trusted Networks", RFC 3325, 1004 November 2002. 1006 [6] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 1007 of Named Entities (DANE) Transport Layer Security (TLS) 1008 Protocol: TLSA", RFC 6698, August 2012. 1010 [7] Elwell, J., "Connected Identity in the Session Initiation 1011 Protocol (SIP)", RFC 4916, June 2007. 1013 [8] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 1014 3966, December 2004. 1016 [9] Rosenberg, J. and C. Jennings, "The Session Initiation 1017 Protocol (SIP) and Spam", RFC 5039, January 2008. 1019 [10] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, 1020 "Secure Call Origin Identification", draft-cooper-iab- 1021 secure-origin-00 (work in progress), November 2012. 1023 [11] Peterson, J., "Retargeting and Security in SIP: A 1024 Framework and Requirements", draft-peterson-sipping- 1025 retarget-00 (work in progress), February 2005. 1027 [12] Rosenberg, J., "Concerns around the Applicability of RFC 1028 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 1029 progress), February 2008. 1031 [13] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for 1032 Session Initiation Protocol (SIP) Back-to- Back User 1033 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-02 1034 (work in progress), September 2013. 1036 [14] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 1037 Huguenin, "Verification Involving PSTN Reachability: 1038 Requirements and Architecture Overview", draft-jennings- 1039 vipr-overview-04 (work in progress), February 2013. 1041 [15] Rosenberg, J. and H. Schulzrinne, "Session Initiation 1042 Protocol (SIP): Locating SIP Servers", RFC 3263, June 1043 2002. 1045 [16] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on 1046 Public Emergency Networks", URL: http:// 1047 krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion- 1048 attacks-on-public-emergency-networks/, Apr 2013. 1050 [17] FCC, , "Robocalls", URL: 1051 http://www.fcc.gov/guides/robocalls, Apr 2013. 1053 [18] FCC, , "FCC Robocall Challenge", URL: 1054 http://robocall.challenge.gov/, Apr 2013. 1056 [19] Wikipedia, , "News International phone hacking scandal", 1057 URL: http://en.wikipedia.org/wiki/ 1058 News_International_phone_hacking_scandal, Apr 2013. 1060 [20] Wikipedia, , "Don't Make the Call: The New Phenomenon of 1061 'Swatting'", URL: http://www.fbi.gov/news/stories/2008/ 1062 february/swatting020408, Feb 2008. 1064 Authors' Addresses 1066 Jon Peterson 1067 Neustar, Inc. 1068 1800 Sutter St Suite 570 1069 Concord, CA 94520 1070 US 1072 Email: jon.peterson@neustar.biz 1074 Henning Schulzrinne 1075 Columbia University 1076 Department of Computer Science 1077 450 Computer Science Building 1078 New York, NY 10027 1079 US 1081 Phone: +1 212 939 7004 1082 Email: hgs+ecrit@cs.columbia.edu 1083 URI: http://www.cs.columbia.edu 1085 Hannes Tschofenig 1086 Nokia Siemens Networks 1087 Linnoitustie 6 1088 Espoo 02600 1089 Finland 1091 Phone: +358 (50) 4871445 1092 Email: Hannes.Tschofenig@gmx.net 1093 URI: http://www.tschofenig.priv.at