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