idnits 2.17.1 draft-peterson-secure-origin-ps-02.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 == Line 823 has weird spacing: '...uctures must ...' -- The document date (September 04, 2013) is 3881 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: '3' is defined on line 892, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 924, 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-01 == Outdated reference: A later version (-06) exists of draft-jennings-vipr-overview-04 Summary: 0 errors (**), 0 flaws (~~), 6 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: March 08, 2014 Columbia University 6 H. Tschofenig 7 Nokia Siemens Networks 8 September 04, 2013 10 Secure Origin Identification: Problem Statement, Requirements, and 11 Roadmap 12 draft-peterson-secure-origin-ps-02.txt 14 Abstract 16 Over the past decade, SIP has become a major signaling protocol for 17 voice communications, one which has replaced many traditional 18 telephony deployments. However, interworking SIP with the 19 traditional telephone network has ultimately reduced the security of 20 Caller ID systems. Given the widespread interworking of SIP with the 21 telephone network, the lack of effective standards for identifying 22 the calling party in a SIP session has granted attackers new powers 23 as they impersonate or obscure calling party numbers when 24 orchestrating bulk commercial calling schemes, hacking voicemail 25 boxes or even circumventing multi-factor authentication systems 26 trusted by banks. This document therefore examines the reasons why 27 providing identity for telephone numbers on the Internet has proven 28 so difficult, and shows how changes in the last decade may provide us 29 with new strategies for attaching a secure identity to SIP 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 March 08, 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. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 3.1. VoIP-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 5 69 3.2. IP-PSTN-IP Call . . . . . . . . . . . . . . . . . . . . . 6 70 3.3. PSTN-to-VoIP Call . . . . . . . . . . . . . . . . . . . . 7 71 3.4. VoIP-to-PSTN Call Call . . . . . . . . . . . . . . . . . 8 72 3.5. PSTN-VoIP-PSTN Call . . . . . . . . . . . . . . . . . . . 8 73 3.6. PSTN-to-PSTN Call . . . . . . . . . . . . . . . . . . . . 9 74 4. Limitations of Current Solutions . . . . . . . . . . . . . . 9 75 4.1. SIP Identity . . . . . . . . . . . . . . . . . . . . . . 10 76 4.2. VIPR . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 5. Environmental Changes . . . . . . . . . . . . . . . . . . . . 15 78 5.1. Shift to Mobile Communication . . . . . . . . . . . . . . 15 79 5.2. Failure of Public ENUM . . . . . . . . . . . . . . . . . 15 80 5.3. Public Key Infrastructure Developments . . . . . . . . . 16 81 5.4. Pervasive Nature of B2BUA Deployments . . . . . . . . . . 16 82 5.5. Stickiness of Deployed Infrastructure . . . . . . . . . . 17 83 5.6. Relationship with Number Assignment and Management . . . 17 84 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 18 85 7. Roadmap . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 86 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 87 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 88 10. Security Considerations . . . . . . . . . . . . . . . . . . . 19 89 11. Informative References . . . . . . . . . . . . . . . . . . . 19 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 92 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 arises 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) [4] and SIP Identity [1], which are 104 described in more detail in Section 4. The goal of these mechanisms 105 is to validate that originator of a call is authorized to use the 106 From identifier. Protocols, like XMPP, use mechanisms that are 107 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 improve in the future. In [8] 112 we illustrate what challenges arise. In particular, the interworking 113 with different communication architectures (e.g., SIP, PSTN, XMPP, 114 RTCWeb) breaks the end-to-end semantic of the communication 115 interaction and destroys the identification capabilities. 116 Furthermore, the use of different identifiers (e.g., E.164 numbers 117 vs. SIP URIs) creates challenges for determining who is able to claim 118 "ownership" for a specific identifier. 120 After the publication of the PAI and SIP Identity specifications 121 various further attempts have been made to tackle the topic but 122 unfortunately with little success. The complexity resides in the 123 deployment situation and the long list of (often conflicting) 124 requirements. A number of years have passed since the last attempts 125 were made to improve the situation and we therefore believe it is 126 time to give it another try. With this document we would like to 127 start an attempt to develop a common understanding of the problem 128 statement as well as requirements to develop a vision on how to 129 advance the state of the art and to initiate technical work to enable 130 secure call origin identification. 132 2. Problem Statement 134 In the classical public-switched telephone network, a limited number 135 of carriers trusted each other, without any cryptographic validation, 136 to provide accurate caller origination information. In some cases, 137 national telecommunication regulation codified these obligations. 138 This model worked as long as the number of entities was relatively 139 small, easily identified (e.g., through the concept of certificated 140 carriers) and subject to effective legal sanctions in case of 141 misbehavior. However, for some time, these assumptions have no 142 longer held true. For example, entities that are not traditional 143 telecommunication carriers, possibly located outside the country 144 whose country code they are using, can act as voice service 145 providers. While in the past, there was a clear distinction between 146 customers and service providers, VoIP service providers can now 147 easily act as customers, originating and transit providers. For 148 telephony, Caller ID spoofing has become common, with a small subset 149 of entities either ignoring abuse of their services or willingly 150 serving to enable fraud and other illegal behavior. For example, 151 recently, enterprises and public safety organizations [14] have been 152 subjected to telephony denial-of-service attacks. In this case, an 153 individual claiming to represent a collections company for payday 154 loans starts the extortion scheme with a phone call to an 155 organization. Failing to get payment from an individual or 156 organization, the criminal organization launches a barrage of phone 157 calls, with spoofed numbers, preventing the targeted organization 158 from receiving legitimate phone calls. Other boiler-room 159 organizations use number spoofing to place illegal "robocalls" 160 (automated telemarketing, see, for example, the FCC webpage [15] on 161 this topic). Robocalls is a problem that has been recognized already 162 by various regulators, for example the Federal Communications 163 Commission (FCC) recently organized a robocall competition to solicit 164 ideas for creating solutions that will block illegal robocalls [16]. 165 Criminals may also use number spoofing to impersonate banks or bank 166 customers to gain access to information or financial accounts. 168 In general, number spoofing is used in two ways, impersonation and 169 anonymization. For impersonation, the attacker pretends to be a 170 specific individual. Impersonation can be used for pretexting, where 171 the attacker obtains information about the individual impersonated, 172 activates credit cards or for harassment, e.g., by causing utility 173 services to be disconnected, take-out food to be delivered, or by 174 causing police to respond to a non-existing hostage situation 175 ("swatting", see [18]). Some voicemail systems can be set up so that 176 they grant access to stored messages without a password, relying 177 solely on the caller identity. As an example, the News International 178 phone-hacking scandal [17] has also gained a lot of press attention 179 where employees of the newspaper were accused of engaging in phone 180 hacking by utilizing Caller ID spoofing to get access to a voicemail. 181 For numbers where the caller has suppressed textual caller 182 identification, number spoofing can be used to retrieve this 183 information, stored in the so-called Calling Name (CNAM) database. 184 For anonymization, the caller does not necessarily care whether the 185 number is in service, or who it is assigned to, and may switch 186 rapidly and possibly randomly between numbers. Anonymization 187 facilitates automated illegal telemarketing or telephony denial-of- 188 service attacks, as described above, as it makes it difficult to 189 blacklist numbers. It also makes tracing such calls much more labor- 190 intensive, as each such call has to be identified in each transit 191 carrier hop-by-hop, based on destination number and time of call. 193 Secure origin identification should prevent impersonation and, to a 194 lesser extent, anonymization. However, if numbers are easy and cheap 195 to obtain, and if the organizations assigning identifiers cannot or 196 will not establish the true corporate or individual identity of the 197 entity requesting such identifiers, robocallers will still be able to 198 switch between many different identities. 200 It is insufficient to simply outlaw all spoofing of originating 201 telephone numbers, because the entities spoofing numbers are already 202 committing other crimes and thus unlikely to be deterred by legal 203 sanctions. Also, in some cases, third parties may need to 204 temporarily use the identity of another individual or organization, 205 with full consent of the "owner" of the identifier. For example: 207 The doctor's office: Physicians calling their patients using their 208 cell phones would like to replace their mobile phone number with 209 the number of their office to avoid being called back by patients 210 on their personal phone. 212 Call centers: Call centers operate on behalf of companies and the 213 called party expects to see the Caller ID of the company, not the 214 call center. 216 3. Use Cases 218 In order to explain the requirements and other design assumptions we 219 will explain some of the scenarios that need to be supported by any 220 solution. To reduce clutter, the figures do not show call routing 221 elements, such as SIP proxies, of voice or text service providers. 222 We generally assume that the PSTN component of any call path cannot 223 be altered. 225 3.1. VoIP-to-VoIP Call 227 For the IP-to-IP communication case, a group of service providers 228 that offer interconnected VoIP service exchange calls using SIP end- 229 to-end, but may also deliver some calls via circuit-switched 230 facilities, as described below. These service providers use 231 telephone numbers as source and destination identifiers, either as 232 the user component of a SIP URI (e.g., sip:12125551234@example.com) 233 or as a tel URI [7]. 235 As illustrated in Figure 1, if Alice calls Bob, the call will use SIP 236 end-to-end. (The call may or may not traverse the Internet.) 238 +------------+ 239 | IP-based | 240 | SIP Phone |<--+ 241 | of Bob | | 242 |+19175551234| | 243 +------------+ | 244 | 245 +------------+ | 246 | IP-based | | 247 | SIP Phone | ------------ 248 | of Alice | / | \ 249 |+12121234567| // | \\ 250 +------------+ // ,' \\\ 251 | /// / ----- 252 | //// ,' \\\\ 253 | / ,' \ 254 | | ,' | 255 +---->|......: IP-based | 256 | Network | 257 \ / 258 \\\\ //// 259 ------------------------- 261 Figure 1: VoIP-to-VoIP Call. 263 3.2. IP-PSTN-IP Call 265 Frequently, two VoIP-based service providers are not directly 266 connected by VoIP and use TDM circuits to exchange calls, leading to 267 the IP-PSTN-IP use case. In this use case, Dan's VSP is not a member 268 of the interconnect federation Alice's and Bob's VSP belongs to. As 269 far as Alice is concerned Dan is not accessible via IP and the PSTN 270 is used as an interconnection network. Figure 2 shows the resulting 271 exchange. 273 -------- 274 //// \\\\ 275 +--- >| PSTN | 276 | | | 277 | \\\\ //// 278 | -------- 279 | | 280 | | 281 | | 282 +------------+ +--+----+ | 283 | IP-based | | PSTN | | 284 | SIP Phone | --+ VoIP +- v 285 | of Alice | / | GW | \ +---+---+ 286 |+12121234567| // `''''''' \\| PSTN | 287 +------------+ // | \+ VoIP + 288 | /// | | GW |\ 289 | //// | `'''''''\\ +------------+ 290 | / | | \ | IP-based | 291 | | | | | | Phone | 292 +---->|---------------+ +------|---->| of Dan | 293 | | |+12039994321| 294 \ IP-based / +------------+ 295 \\\\ Network //// 296 ------------------------- 298 Figure 2: IP-PSTN-IP Call. 300 3.3. PSTN-to-VoIP Call 302 Consider Figure 3 where Carl is using a PSTN phone and initiates a 303 call to Alice. Alice is using a VoIP-based phone. The call of Carl 304 traverses the PSTN and enters the Internet via a PSTN/VoIP gateway. 305 This gateway attaches some identity information to the call, for 306 example based on the information it had received through the PSTN, if 307 available. 309 -------- 310 //// \\\\ 311 +->| PSTN |--+ 312 | | | | 313 | \\\\ //// | 314 | -------- | 315 | | 316 | v 317 | +----+-------+ 318 +---+------+ |PSTN / VoIP | +-----+ 319 |PSTN Phone| |Gateway | |SIP | 320 |of Carl | +----+-------+ |UA | 321 +----------+ | |Alice| 322 Invite +-----+ 323 | ^ 324 V | 325 +---------------+ Invite 326 |VoIP | | 327 |Interconnection| Invite +-------+ 328 |Provider(s) |----------->+ | 329 +---------------+ |Alice's| 330 |VSP | 331 | | 332 +-------+ 334 Figure 3: PSTN-to-VoIP Call. 336 Note: A B2BUA/Session Border Controller (SBC) exhibits behavior that 337 looks similar to this scenario since the original call content would, 338 in the worst case, be re-created on the call origination side. 340 3.4. VoIP-to-PSTN Call Call 342 Consider Figure 4 where Alice calls Carl. Carl uses a PSTN phone and 343 Alice an IP-based phone. When Alice initiates the call the E.164 344 number needs to get translated to a SIP URI and subsequently to an IP 345 address. The call of Alice traverses her VoIP provider where the 346 call origin identification information is added. It then hits the 347 PSTN/VoIP gateway. Ideally, Alice would like to know whether she, 348 for example, talks to someone at her bank rather than to someone 349 intercepting the call. If Alice wants to be assured that she's being 350 connected to the right party, it is a slightly different aspect to 351 what [4][1]. Problem statements and solutions are offered with [9] 352 and [6]. 354 +-------+ +-----+ -C 355 |PSTN | |SIP | |a 356 |Phone |<----------------+ |UA | |l 357 |of Carl| | |Alice| |l 358 +-------+ | +-----+ |i 359 --------------------------- | |n 360 //// \\\\ | |g 361 | PSTN | Invite | 362 | | | |P 363 \\\\ //// | |a 364 --------------------------- | |r 365 ^ | |t 366 | v |y 367 +------------+ +--------+| 368 |PSTN / VoIP |<--Invite----|VoIP ||D 369 |Gateway | |Service ||o 370 +------------+ |Provider||m 371 |of Alice||a 372 +--------+|i 373 -n 375 Figure 4: IP-to-PSTN Call. 377 3.5. PSTN-VoIP-PSTN Call 379 Consider Figure 5 where Carl calls Alice. Both users have PSTN 380 phones but interconnection between the two PSTN networks is 381 accomplished via an IP network. Consequenly, Carl's operator uses a 382 PSTN-to-VoIP gateway to route the call via an IP network to a gateway 383 to break out into the PSTN again. 385 +----------+ 386 |PSTN Phone| 387 -------- |of Alice | 388 //// \\\\ +----------+ 389 +->| PSTN |------+ ^ 390 | | | | | 391 | \\\\ //// | | 392 | -------- | -------- 393 | v //// \\\\ 394 | ,-------+ | PSTN | 395 | |PSTN | | | 396 +---+------+ __|VoIP GW|_ \\\\ //// 397 |PSTN Phone| / '`''''''' \ -------- 398 |of Carl | // | \\ ^ 399 +----------+ // | \\\ | 400 /// -. Invite ----- | 401 //// `-. \\\\ | 402 / `.. \ | 403 | IP-based `._ ,--+----+ 404 | Network `.....>|VoIP | 405 | |PSTN GW| 406 \ '`''''''' 407 \\\\ //// 408 ------------------------- 410 Figure 5: PSTN-VoIP-PSTN Call. 412 3.6. PSTN-to-PSTN Call 414 For the "legacy" case of a PSTN-to-PSTN call, otherwise beyond 415 improvement, we may be able to use out-of-band IP connectivity at 416 both the originating and terminating carrier to validate the call 417 information. 419 4. Limitations of Current Solutions 421 From the inception of SIP, the From header field value has held an 422 arbitrary user-supplied identity, much like the From header field 423 value of an SMTP email message. During work on [2], efforts began to 424 provide a secure origin for SIP requests as an extension to SIP. The 425 so-called "short term" solution, the P-Asserted-Identity header 426 described in [4], is deployed fairly widely, even though it is 427 limited to closed trusted networks where end-user devices cannot 428 alter or inspect SIP messages and offers no cryptographic validation. 429 As P-Asserted-Identity is used increasingly across multiple networks, 430 it cannot offer any protection against identity spoofing by 431 intermediaries or entities that allow end users to set the P 432 -Asserted-Identity information. 434 Subsequent efforts to prevent calling origin identity spoofing in SIP 435 include the SIP Identity effort (the "long term" identity solution) 436 [1] and Verification Involving PSTN Reachability (VIPR) [12]. SIP 437 Identity attaches a new header field to SIP requests containing a 438 signature over the From header field value combined with other 439 message components to prevent replay attacks. SIP Identity is meant 440 both to prevent originating calls with spoofed From headers and 441 intermediaries, such as SIP proxies, from launching man-in-the-middle 442 attacks to alter calls passing through. The VIPR architecture 443 attacked a broader range of problems relating to spam, routing and 444 identity with a new infrastructure for managing rendezvous and 445 security, which operated alongside of SIP deployments. 447 As we will describe in more detail below, both SIP Identity and VIPR 448 suffer from serious limitations that have prevented their deployment 449 at significant scale, but they may still offer ideas and protocol 450 building blocks for a solution. 452 4.1. SIP Identity 454 The SIP Identity mechanism [1] provided two header fields for 455 securing identity information in SIP requests: the Identity and 456 Identity-Info header fields. Architecturally, the SIP Identity 457 mechanism assumes a classic "SIP trapezoid" deployment in which an 458 authentication service, acting on behalf of the originator of a SIP 459 request, attaches identity information to the request which provides 460 partial integrity protection; a verification service acting on behalf 461 of the recipient validates the integrity of the request when it is 462 received. 464 The Identity header field value contains a signature over a hash of 465 selected elements of a SIP request, including several header field 466 values (most significantly, the From header field value) and the 467 entirety of the body of the request. The set of header field values 468 was chosen specifically to prevent cut-and-paste attacks; it requires 469 the verification service to retain some state to guard against 470 replays. The signature over the body of a request has different 471 properties for different SIP methods, but all prevent tampering by 472 man-in-the-middle attacks. For a SIP MESSAGE request, for example, 473 the signature over the body covers the actual message conveyed by the 474 request: it is pointless to guarantee the source of a request if a 475 man-in-the-middle can change the content of the message, as in that 476 case the message content is created by an attacker. Similar threats 477 exist against the SIP NOTIFY method. For a SIP INVITE request, a 478 signature over the SDP body is intended to prevent a man-in-the- 479 middle from changing properties of the media stream, including the IP 480 address and port to which media should be sent, as this provides a 481 means for the man-in-the-middle to direct session media to resource 482 that the originator did not specify, and thus to impersonate an 483 intended listener. 485 The Identity-Info header field value contains a URI designating the 486 location of the certificate corresponding to the private key that 487 signed the hash in the Identity header. That certificate could be 488 passed by-value along with the SIP request, in which case a "cid" URI 489 appears in Identity-Info, or by-reference, for example when the 490 Identity-Info header field value has the URL of a service that 491 delivers the certificate. [1] imposes further constraints governing 492 the subject of that certificate: namely, that it must cover the 493 domain name indicated in the domain component of the URI in the From 494 header field value of the request. 496 The SIP Identity mechanism, however, has two fundamental limitations 497 that have precluded its deployment: first, that it provides Identity 498 only for domain names rather than other identifiers; second, that it 499 does not tolerate intermediaries that alter the bodies, or certain 500 header fields, of SIP requests. 502 As deployed, SIP predominantly mimics the structures of the telephone 503 network, and thus uses telephone numbers as identifiers. Telephone 504 numbers in the From header field value of a SIP request may appear as 505 the user part of a SIP URI, or alternatively in an independent tel 506 URI. The certificate designated by the Identity-Info header field as 507 specified, however, corresponds only to the domain portion of a SIP 508 URI in the From header field. As such, [1] does not have any 509 provision to identify the assignee of a telephone number. While it 510 could be the case that the domain name portion of a SIP URI signifies 511 a carrier (like "att.com") to whom numbers are assigned, the SIP 512 Identity mechanism provides no assurance that a number is assigned to 513 any carrier. For a tel URI, moreover, it is unclear in [1] what 514 entity should hold a corresponding certificate. A caller may not 515 want to reveal the identity of its service provider to the callee, 516 and may thus prefer tel URIs in the From header field. 518 This lack of authority gives rise to a whole class of SIP identity 519 problems when dealing with telephone numbers, as is explored in [10]. 520 That document shows how the Identity header of a SIP request 521 targeting a telephone number (embedded in a SIP URI) could be dropped 522 by an intermediate domain, which then modifies and resigns the 523 request, all without alerting the verification service: the 524 verification service has no way of knowing which original domain 525 signed the request. Provided that the local authentication service 526 is complicit, an originator can claim virtually any telephone number, 527 impersonating any chosen Caller ID from the perspective of the 528 verifier. Both of these attacks are rooted in the inability of the 529 verification service to ascertain a specific certificate that is 530 authoritative for a telephone number. 532 As deployed, SIP is moreover highly mediated, and mediated in ways 533 that [2] did not anticipate. As request routing commonly depends on 534 policies dissimilar to [13], requests transit multiple intermediate 535 domains to reach a destination; some forms of intermediaries in those 536 domains may effectively re-initiate the session. 538 One of the main reasons that SIP deployments mimic the PSTN 539 architecture is because the requirement for interconnection with the 540 PSTN remains paramount: a call may originate in SIP and terminate on 541 the PSTN, or vice versa; and worse still, a PSTN-to-PSTN call may 542 transit a SIP network in the middle, or vice versa. This necessarily 543 reduces SIP's feature set to the least common dominator of the 544 telephone network, and mandates support for telephone numbers as a 545 primary calling identifier. 547 Interworking with non-SIP networks makes end-to-end identity 548 problematic. When a PSTN gateway sends a call to a SIP network, it 549 creates the INVITE request anew, regardless of whether a previous leg 550 of the call originated in a SIP network that later dropped the call 551 to the PSTN. As these gateways are not necessarily operated by 552 entities that have any relationship to the number assignee, it is 553 unclear how they could provide an identity signature that a verifier 554 should trust. Moreover, how could the gateway know that the calling 555 party number it receives from the PSTN is actually authentic? And 556 when a gateway receives a call via SIP and terminates a call to the 557 PSTN, how can that gateway verify that a telephone number in the From 558 header field value is authentic, before it presents that number as 559 the calling party number in the PSTN? 561 Similarly, some SIP networks deploy intermediaries that act as back- 562 to-back user agents (B2BUAs), typically in order to enforce policy at 563 network boundaries (hence the nickname "Session Border Controller"). 564 As a common practice, these entities modify SIP INVITE requests in 565 transit in such a way that they no longer satisfy the transaction- 566 mapping semantics of [2], commonly changing the From, Contact and 567 Call-ID header field values, as well as aspects of the SDP, including 568 especially the IP addresses and ports associated with media. The 569 policies that motivate these changes may be associated with topology 570 hiding, or may alter messages to interoperate successfully with 571 particular SIP implementations, or may simply involve network address 572 translation from private address space. But effectively, a SIP 573 request exiting a B2BUA has no necessary relationship to the original 574 request received by the B2BUA, much like a request exiting a PSTN 575 gateway has no necessary relationship to any SIP request in a pre- 576 PSTN leg of the call. An Identity signature provided for the 577 original INVITE has no bearing on the post-B2BUA INVITE, and, were 578 the B2BUA to preserve the original Identity header, any verification 579 service would detect a violation of the integrity protection. 581 The SIP community has long been aware of these problems with [1] in 582 practical deployments. Some have therefore proposed weakening the 583 security constraints of [1] so that at least some deployments of 584 B2BUAs will not violate (or remove) the integrity protection of SIP 585 requests. However, such solutions do not address one key problem 586 identified above: the lack of any clear authority for telephone 587 numbers, and the fact that some INVITE requests are generated by 588 intermediaries rather than endpoints. Removing the signature over 589 the SDP from the Identity header will not, for example, make it any 590 clearer how a PSTN gateway should assert identity in an INVITE 591 request. 593 4.2. VIPR 595 Verification Involving PSTN Reachability (VIPR) directly attacks the 596 twin problems of identifying number assignees on the Internet and 597 coping with intermediaries that may modify signaling. To address the 598 first problem, VIPR relies on the PSTN itself: it discovers which 599 endpoints on the Internet are reachable via a particular PSTN number 600 by calling the number on the PSTN to determine whom a call to that 601 number will reach. As VIPR-enabled Internet endpoints associated 602 with PSTN numbers are discovered, VIPR provides a rendez-vous service 603 that allows the endpoints of a call to form an out-of-band connection 604 over the Internet; this connection allows the endpoints to exchange 605 information that secures future communications and permits direct, 606 unmediated SIP connections. 608 VIPR provides these services within a fairly narrow scope of 609 applicability. Its seminal use case is the enterprise IP PBX, a 610 device that has both PSTN connectivity and Internet connectivity, 611 which serves a set of local users with telephone numbers; after a 612 PSTN call has connected successfully and then ended, the PBX searches 613 a distributed hash-table to see if any VIPR-compatible devices have 614 advertised themselves as a route for the unfamiliar number on the 615 Internet. If advertisements exist, the originating PBX then 616 initiates a verification process to determine whether the entity 617 claiming to be the assignee of the unfamiliar number in fact received 618 the successful call: this involves verifying details such as the 619 start and stop times of the call. If the destination verifies 620 successfully, the originating PBX provisions a local database with a 621 route for that telephone number to the URI provided by the proven 622 destination. The destination moreover gives a token to the 623 originator that can be inserted in future call setup messages to 624 authenticate the source of future communications. 626 Through this mechanism, the VIPR system provides a suite of 627 properties, ones that go well beyond merely securing the origins of 628 communications. It also provides a routing system which dynamically 629 discovers mappings between telephone numbers and URIs, effectively 630 building an ad hoc ENUM database in every VIPR implementation. The 631 tokens exchanged over the out-of-band connection established by VIPR 632 moreover provide an authorization mechanism for accepting calls over 633 the Internet that significantly reduces the potential for spam. 634 Because the token can act as a nonce due to the presence of this out- 635 of-band connectivity, the VIPR token is less susceptible to cut-and- 636 paste attacks and thus needs to cover with its signature far less of 637 a SIP request. 639 Due to its narrow scope of applicability, and the details of its 640 implementation, VIPR has some significant limitations. The most 641 salient for the purposes of this document is that it only has bearing 642 on repeated communications between entities: it has no bearing on the 643 classic "robocall" problem, where the target receives a call from a 644 number that has never called before. All of VIPRs strengths in 645 establishing identity and spam prevention kick in only after an 646 initial PSTN call has been completed, and subsequent attempts at 647 communication begin. Every VIPR-compliant entity moreover maintains 648 its own stateful database of previous contacts and authorizations, 649 which lends itself to more aggregators like IP PBXs that may front 650 for thousands of users than to individual phones. That database must 651 be refreshed by periodic PSTN calls to determine that control over 652 the number has not shifted to some other entity; figuring out when 653 data has grown stale is one the challenges of the architecture. As 654 VIPR requires compliant implementations to operate both a PSTN 655 interface and an IP interface, it has little apparent applicability 656 to ordinary desktop PCs or similar devices with no ability to place 657 direct PSTN calls. 659 The distributed hash table also creates a new attack surface for 660 impersonation. Attackers who want to pose as the owners of telephone 661 numbers can advertise themselves as routes to a number in the hash 662 table. VIPR has no inherent restriction on the number of entities 663 that may advertise themselves as routes for a number, and thus an 664 originator may find multiple advertisements for a number on the DHT 665 even when an attack is not in progress. As for attackers, even if 666 they cannot successfully verify themselves to the originators of 667 calls (because they lack the call detail information), they may learn 668 from those verification attempts which VIPR entities recently placed 669 calls to the target number: it may be that this information is all 670 the attacker hopes to glean. The fact that advertisements and 671 verifications are public results from the public nature of the DHT 672 that VIPR creates. The public DHT prevents any centralized control, 673 or attempts to impede communications, but those come at the cost of 674 apparently unavoidable privacy losses. 676 Because of these limitations, VIPR, much like SIP Identity, has had 677 little impact in the marketplace. Ultimately, VIPR's utility as an 678 identity mechanism is limited by its reliance on the PSTN, especially 679 its need for an initial PSTN call to complete before any of VIPR's 680 benefits can be realized, and by the drawbacks of the highly-public 681 exchanges requires to create the out-of-band connection between VIPR 682 entities. As such, there is no obvious solution to providing secure 683 origin services for SIP on the Internet today. 685 5. Environmental Changes 687 5.1. Shift to Mobile Communication 689 In the years since [1] was conceived, there have been a number of 690 fundamental shifts in the communications marketplace. The most 691 transformative has been the precipitous rise of mobile smart phones, 692 which are now arguably the dominant communications device in the 693 developed world. Smart phones have both a PSTN and an IP interface, 694 as well as an SMS and MMS capabilities. This suite of tools suggests 695 that some of the techniques proposed by VIPR could be adapted to the 696 smart phone environment. The installed base of smart phones is 697 moreover highly upgradable, and permits rapid adoption out-of-band 698 rendezvous services for smart phones that circumvent the PSTN: for 699 example, the Apple iMessage service, which allows iPhone users to 700 send SMS messages to one another over the Internet rather than over 701 the PSTN. Like VIPR, iMessage creates an out-of-band connection over 702 the Internet between iPhones; unlike VIPR, the rendezvous service is 703 provided by a trusted centralized database of iPhones rather than by 704 a DHT. While Apple's service is specific to customers of its smart 705 phones, it seems clear that similar databases could be provided by 706 neutral third parties in a position to coordinate between endpoints. 708 5.2. Failure of Public ENUM 709 At the time [1] was written, the hopes for establishing a certificate 710 authority for telephone numbers on the Internet largely rested on 711 public ENUM deployment. The e164.arpa DNS tree established for ENUM 712 could have grown to include certificates for telephone numbers or at 713 least for number ranges. It is now clear however that public ENUM as 714 originally envisioned has little prospect for adoption. That said, 715 national authorities for telephone numbers are increasingly migrating 716 their provisioning services to the Internet, and issuing credentials 717 that express authority for telephone numbers to secure those 718 services. These new authorities for numbers could provide to the 719 public Internet the necessary signatory authority for securing 720 calling partys' numbers. While these systems are far from universal, 721 the authors of this draft believe that a solution devised for the 722 North American Numbering Plan could have applicability to other 723 country codes. 725 5.3. Public Key Infrastructure Developments 727 Also, there have been a number of recent high-profile compromises of 728 web certificate authorities. The presence of numerous (in some 729 cases, of hundreds) of trusted certificate authorities in modern web 730 browsers has become a significant security liability. As [1] relied 731 on web certificate authorities, this too provides new lessons for any 732 work on revising [1]: namely, that innovations like DANE [5] that 733 designate a specific certificate preferred by the owner of a DNS name 734 could greatly improve the security of a SIP identity mechanism; and 735 moreover, that when architecting new certificate authorities for 736 telephone numbers, we should be wary of excessive pluralism. While a 737 chain of delegation with a progressively narrowing scope of authority 738 (e.g., from a regulatory entity to a carrier to a reseller to an end 739 user) is needed to reflect operational practices, there is no need to 740 have multiple roots, or peer entities that both claim authority for 741 the same telephone number or number range. 743 5.4. Pervasive Nature of B2BUA Deployments 745 Given the prevalence of established B2BUA deployments, we may have a 746 further opportunity to review the elements signed by [1] and to 747 decide on the value of alternative signature mechanisms. Separating 748 the elements necessary for (a) securing the From header field value 749 and preventing replays, from (b) the elements necessary to prevent 750 men-in-the-middle from tampering with messages, may also yield a 751 strategy for identity that will be practicable in some highly 752 mediated networks. It could be possible, for example, to provide two 753 signatures: one over the elements required for (b), and then a 754 separate signature over the elements necessary for (a) and the 755 signature over (b); this would allow verification services in 756 mediated networks to ignore the failure of a (b) signature while 757 still verifying (a). Any solution along these lines must however 758 always secure any cryptographic material necessary to support DTLS- 759 SRTP or future security mechanisms. 761 5.5. Stickiness of Deployed Infrastructure 763 One thing that has not changed, and is not likely to change in the 764 future, is the transitive nature of trust in the PSTN. When a call 765 from the PSTN arrives at a SIP gateway with a calling party number, 766 the gateway will have little chance of determining whether the 767 originator of the call was authorized to claim that calling party 768 number. Due to roaming and countless other factors, calls on the 769 PSTN may emerge from administrative domains that have no relationship 770 with the number assignee. This use case will remain the most 771 difficult to tackle for an identity system, and may prove beyond 772 repair. It does however seem that with the changes in the solution 773 space, and a better understanding of the limits of [1] and VIPR, we 774 are today in a position to reexamine the problem space and find 775 solutions that can have a significant impact on the secure origins 776 problem. 778 5.6. Relationship with Number Assignment and Management 780 Currently, telephone numbers are typically managed in a loose 781 delegation hierarchy. For example, a national regulatory agency may 782 task a private, neutral entity with administering numbering 783 resources, such as area codes, and a similar entity with assigning 784 number blocks to carriers and other authorized entities, who in turn 785 then assign numbers to customers. In many countries, individual 786 numbers are portable between carriers, at least within the same 787 technology (e.g., wireline-to-wireline). Separate databases manage 788 the mapping of numbers to switch identifiers, companies and textual 789 caller ID information. 791 As the PSTN transitions to using VoIP technologies, new assignment 792 policies and management mechanisms are likely to emerge. For 793 example, it has been proposed that geography could play a smaller 794 role in number assignments, and that individual numbers are assigned 795 to end users directly rather than only to service providers, or that 796 the assignment of numbers does not depend on providing actual call 797 delivery services. 799 Databases today already map telephone numbers to entities that have 800 been assigned the number, e.g., through the LERG (originally, Local 801 Exchange Routing Guide) in the United States. Thus, the transition 802 to IP-based networks may offer an opportunity to integrate 803 cryptographic bindings between numbers or number ranges and service 804 providers into databases. 806 6. Requirements 808 This section describes the high level requirements: 810 Usability Any validation mechanism must work without human 811 intervention, e.g., CAPTCHA-like mechanisms. 813 Deployability Must survive transition of the call to the PSTN and 814 the presence of B2BUAs. 816 Validation by intermediaries Intermediaries as well as end system 817 must be able to validate the source identity information. 819 Display name The display name of the caller must also be validated 820 or the callee must be able to determine that only the calling 821 number has been validated. 823 Consider existing structures must allow number portability among 824 carriers and must support legitimate usage of number spoofing 825 (doctor's office and call centers) 827 Minimal payload overhead Must lead to minimal expansion of SIP 828 headers fields to avoid fragmentation in deployments that use UDP. 830 Privacy Any out-of-band validation protocol must not allows third 831 parties to learn what numbers have been called by a specific 832 caller. 834 7. Roadmap 836 The authors of this document believe that the entire solution scope 837 consists of a couple of separable aspects: 839 In-band caller ID Conveyance: This functionality allows call origin 840 identification information to be conveyed within SIP, and takes 841 the nature of E.164 numbers and the prevalence of B2BUAs into 842 account. This may consist of a revised version of the SIP 843 Identity specification that takes E.164 numbers into account and 844 allows for separate validation of the SIP request headers and the 845 SIP request body. This approach addresses the case where 846 intermediaries do not remove header fields. 848 Out-of-Band Caller-ID Verification: This functionality determines 849 whether the E.164 number used by the calling party actually 850 exists, the calling entity is entitled to use the number and 851 whether a call has recently been made from this phone number. 852 This approach is needed when the in-band technique does not work 853 due to intermediaries or due to interworking with PSTN networks. 855 Authority Delegation Infrastructure: This functionality defines how 856 existing authority over E.164 numbers are used in number 857 portability, and delegation cases. It also describes how the 858 existing numbering infrastructure is re-used to maintain the 859 lifecycle of number assignments. 861 Extended Validation: This functionality describes how to describes 862 attributes of the calling party beyond the caller-id and these 863 attributes (e.g., the calling party is a bank) need to be verified 864 upfront. 866 8. Acknowledgments 868 We would like to thank Alissa Cooper, Bernard Aboba, Sean Turner, 869 Eric Burger, and Eric Rescorla for their discussion input that lead 870 to this document. 872 9. IANA Considerations 874 This memo includes no request to IANA. 876 10. Security Considerations 878 This document is about improving the security of call origin 879 identification. 881 11. Informative References 883 [1] Peterson, J. and C. Jennings, "Enhancements for 884 Authenticated Identity Management in the Session 885 Initiation Protocol (SIP)", RFC 4474, August 2006. 887 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 888 A., Peterson, J., Sparks, R., Handley, M., and E. 889 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 890 June 2002. 892 [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 893 A., Peterson, J., Sparks, R., Handley, M., and E. 894 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 895 June 2002. 897 [4] Jennings, C., Peterson, J., and M. Watson, "Private 898 Extensions to the Session Initiation Protocol (SIP) for 899 Asserted Identity within Trusted Networks", RFC 3325, 900 November 2002. 902 [5] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication 903 of Named Entities (DANE) Transport Layer Security (TLS) 904 Protocol: TLSA", RFC 6698, August 2012. 906 [6] Elwell, J., "Connected Identity in the Session Initiation 907 Protocol (SIP)", RFC 4916, June 2007. 909 [7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 910 3966, December 2004. 912 [8] Cooper, A., Tschofenig, H., Peterson, J., and B. Aboba, 913 "Secure Call Origin Identification", draft-cooper-iab- 914 secure-origin-00 (work in progress), November 2012. 916 [9] Peterson, J., "Retargeting and Security in SIP: A 917 Framework and Requirements", draft-peterson-sipping- 918 retarget-00 (work in progress), February 2005. 920 [10] Rosenberg, J., "Concerns around the Applicability of RFC 921 4474", draft-rosenberg-sip-rfc4474-concerns-00 (work in 922 progress), February 2008. 924 [11] Kaplan, H. and V. Pascual, "Loop Detection Mechanisms for 925 Session Initiation Protocol (SIP) Back-to- Back User 926 Agents (B2BUAs)", draft-ietf-straw-b2bua-loop-detection-01 927 (work in progress), August 2013. 929 [12] Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 930 Huguenin, "Verification Involving PSTN Reachability: 931 Requirements and Architecture Overview", draft-jennings- 932 vipr-overview-04 (work in progress), February 2013. 934 [13] Rosenberg, J. and H. Schulzrinne, "Session Initiation 935 Protocol (SIP): Locating SIP Servers", RFC 3263, June 936 2002. 938 [14] Krebs, B., "DHS Warns of 'TDoS' Extortion Attacks on 939 Public Emergency Networks", URL: http:// 940 krebsonsecurity.com/2013/04/dhs-warns-of-tdos-extortion- 941 attacks-on-public-emergency-networks/, Apr 2013. 943 [15] FCC, ., "Robocalls", URL: 944 http://www.fcc.gov/guides/robocalls, Apr 2013. 946 [16] FCC, ., "FCC Robocall Challenge", URL: 947 http://robocall.challenge.gov/, Apr 2013. 949 [17] Wikipedia, ., "News International phone hacking scandal", 950 URL: http://en.wikipedia.org/wiki/ 951 News_International_phone_hacking_scandal, Apr 2013. 953 [18] Wikipedia, ., "Don't Make the Call: The New Phenomenon of 954 'Swatting'", URL: http://www.fbi.gov/news/stories/2008/ 955 february/swatting020408, Feb 2008. 957 Authors' Addresses 959 Jon Peterson 960 NeuStar, Inc. 961 1800 Sutter St Suite 570 962 Concord, CA 94520 963 US 965 Email: jon.peterson@neustar.biz 967 Henning Schulzrinne 968 Columbia University 969 Department of Computer Science 970 450 Computer Science Building 971 New York, NY 10027 972 US 974 Phone: +1 212 939 7004 975 Email: hgs+ecrit@cs.columbia.edu 976 URI: http://www.cs.columbia.edu 978 Hannes Tschofenig 979 Nokia Siemens Networks 980 Linnoitustie 6 981 Espoo 02600 982 Finland 984 Phone: +358 (50) 4871445 985 Email: Hannes.Tschofenig@gmx.net 986 URI: http://www.tschofenig.priv.at