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