idnits 2.17.1 draft-ietf-stir-oob-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 : ---------------------------------------------------------------------------- == There are 11 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 3, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 == Outdated reference: A later version (-04) exists of draft-peterson-modern-teri-02 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Standards Track J. Peterson 5 Expires: January 4, 2018 Neustar 6 July 3, 2017 8 STIR Out of Band Architecture and Use Cases 9 draft-ietf-stir-oob-00.txt 11 Abstract 13 The PASSporT format defines a token that can be carried by signaling 14 protocols, including SIP, to cryptographically attest the identify of 15 callers. Not all telephone calls use Internet signaling protocols, 16 however, and some calls use them for only part of their signaling 17 path. This document describes use cases that require the delivery of 18 PASSporT objects outside of the signaling path, and defines 19 architectures and semantics to provide this functionality. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 4, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Operating Environments . . . . . . . . . . . . . . . . . . . 4 58 4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 6 61 5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 6 62 5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7 63 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 7 64 6. Authorization for Storing and Retrieving PASSporTs . . . . . 8 65 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 8 66 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 9 67 6.2.1. Authentication . . . . . . . . . . . . . . . . . . . 10 68 6.2.2. Encryption . . . . . . . . . . . . . . . . . . . . . 10 69 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 12 70 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 71 7.2. Solution Architecture . . . . . . . . . . . . . . . . . . 12 72 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 73 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 14 74 8. Call Placement Service Discovery . . . . . . . . . . . . . . 15 75 9. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 9.1. Credential Lookup . . . . . . . . . . . . . . . . . . . . 16 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 79 12. Security Considerations . . . . . . . . . . . . . . . . . . . 17 80 13. Informative References . . . . . . . . . . . . . . . . . . . 17 81 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 83 1. Introduction 85 The STIR problem statement [RFC7340] describes widespread problems 86 enabled by impersonation in the telephone network, including illegal 87 robocalling, voicemail hacking, and swatting. As telephone services 88 are increasingly migrating onto the Internet, and using Voice over IP 89 (VoIP) protocols such as SIP [RFC3261], it is necessary for these 90 protocols to support stronger identity mechanisms to prevent 91 impersonation. For example, [I-D.ietf-stir-rfc4474bis] defines an 92 Identity header of SIP requests capable of carrying a PASSporT 93 [I-D.ietf-stir-passport] object in SIP as a means to 94 cryptographically attest that the originator of a telephone call is 95 authorized to use the calling party number (or, for native SIP cases, 96 SIP URI) associated with the originator of the call. of the request. 98 Not all telephone calls use SIP today, however; and even those that 99 do use SIP do not always carry SIP signaling end-to-end. Most calls 100 from telephone numbers still traverse the Public Switched Telephone 101 Network (PSTN) at some point. Broadly, calls fall into one of three 102 categories: 104 1. One or both of the endpoints is actually a PSTN endpoint. 106 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the 107 call transits the PSTN at some point. 109 3. Non-PSTN calls which do not transit the PSTN at all (such as 110 native SIP end-to-end calls). 112 The first two categories represent the majority of telephone calls 113 associated with problems like illegal robocalling: many robocalls 114 today originate on the Internet but terminate at PSTN endpoints. 115 However, the core network elements that operate the PSTN are legacy 116 devices that are unlikely to be upgradable at this point to support 117 an in-band authentication system. As such, those devices largely 118 cannot be modified to pass signatures originating on the Internet--or 119 indeed any inband signaling data--intact. Even if fields for 120 tunneling arbtirary data can be found in traditional PSTN signaling, 121 in some cases legacy elements would strip the signatures from those 122 fields; in others, they might damage them to the point where they 123 cannot be verified. For those first two categories above, any in- 124 band authentication scheme does not seem practical in the current 125 environment. 127 But while the core network of the PSTN remains fixed, the endpoints 128 of the telephone network are becoming increasingly programmable and 129 sophisticated. Landline "plain old telephone service" deployments, 130 especially in the developed world, are shrinking, and increasingly 131 being replaced by three classes of intelligent devices: smart phones, 132 IP PBXs, and terminal adapters. All three are general purpose 133 computers, and typically all three have Internet access as well as 134 access to the PSTN. Additionally, various kinds of gateways 135 increasingly front for legacy equipment. All of this provides a 136 potential avenue for building an authentication system that 137 implements stronger identity while leaving PSTN systems intact. 139 This capability also provides an ideal transitional technology while 140 in-band STIR adoption is ramping up. It permits early adopters to 141 use the technology even when intervening network elements are not yet 142 STIR-aware, and through various kinds of gateways it may allow 143 providers with a significant PSTN investment to still secure their 144 calls with STIR. 146 This specification therefore builds on the PASSporT 147 [I-D.ietf-stir-passport] mechanism and the work of 148 [I-D.ietf-stir-rfc4474bis] to define a way that a PASSporT object 149 created in the originating network of a call can reach the 150 terminating network even when it cannot be carried end-to-end in-band 151 in the call signaling. This relies on a new service defined in this 152 document that permits the PASSporT object to be stored during call 153 processing and retrieved for verification purposes. 155 2. Terminology 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 158 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described in RFC 160 2119 [RFC2119]. 162 3. Operating Environments 164 This section describes the environments in which the proposed 165 mechanism is intended to operate. In the simplest setting, Alice is 166 calling Bob through some set of gateways and/or the PSTN. Both Alice 167 and Bob have smart devices which can be modified, but they do not 168 have a clear connection between them: Alice cannot inject any data 169 into signaling which Bob can read, with the exception of the asserted 170 destination and origination E.164 numbers. The calling party number 171 might originate from her own device or from the network. These 172 numbers are effectively the only data that can be used for 173 coordination between the endpoints. 175 +---------+ 176 / \ 177 +--- +---+ 178 +----------+ / \ +----------+ 179 | | | Gateways | | | 180 | Alice |<----->| and/or |<----->| Bob | 181 | (caller) | | PSTN | | (callee) | 182 +----------+ \ / +----------+ 183 +--- +---+ 184 \ / 185 +---------+ 187 In a more complicated setting, Alice and/or Bob may not have a smart 188 or programmable device, but one or both of them are behind a STIR- 189 aware gateway that can participate in out-of-band coordination, as 190 shown below: 192 +---------+ 193 / \ 194 +--- +---+ 195 +----------+ +--+ / \ +--+ +----------+ 196 | | | | | Gateways | | | | | 197 | Alice |<-|GW|->| and/or |<-|GW|->| Bob | 198 | (caller) | | | | PSTN | | | | (callee) | 199 +----------+ +--+ \ / +--+ +----------+ 200 +--- +---+ 201 \ / 202 +---------+ 204 In such a case, Alice might have an analog connection to her gateway/ 205 switch which is responsible for her identity. Similarly, the gateway 206 would verify Alice's identity, generate the right calling party 207 number information and provide that number to Bob using ordinary POTS 208 mechanisms. 210 4. Dataflows 212 Because in these operating environments endpoints cannot pass 213 cryptographic information to one another directly through signaling, 214 any solution must involve some rendezvous mechanism to allow 215 endpoints to communicate. We call this rendezvous service a "call 216 placement service" (CPS), a service where a record of call placement, 217 in this case a PASSporT, can be stored for future retrieval. In 218 principle this service could communicate any information, but 219 minimally we expect it to include a full-form PASSporT that attests 220 the caller, callee, and the time of the call. The callee can use the 221 existence of a PASSporT for a given incoming call as rough validation 222 of the asserted origin of that call. (See Section 9.1 for 223 limitations of this design.) 225 There are roughly two plausible dataflow architectures for the CPS: 227 The callee registers with the CPS. When the caller wishes to 228 place a call to the callee, it sends the PASSporT to the CPS, 229 which immediately forwards it to the callee. 231 The caller stores the PASSporT with the CPS at the time of call 232 placement. When the callee receives the call, it contacts the CPS 233 and retrieves the PASSporT. 235 While the first architecture is roughly isomorphic to current VoIP 236 protocols, it shares their drawbacks. Specifically, the callee must 237 maintain a full-time connection to the CPS to serve as a notification 238 channel. This comes with the usual networking costs to the callee 239 and is especially problematic for mobile endpoints. Indeed, if the 240 endpoints had the capabilities to implement such an architecture, 241 they could surely just use SIP or some other protocol to set up a 242 secure session; even if the media were going through the traditional 243 PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we 244 focus on the second architecture in which the PSTN incoming call 245 serves as the notification channel and the callee can then contact 246 the CPS to retrieve the PASSporT. 248 5. Use Cases 250 The following are the motivating use cases for this mechanism. Bear 251 in mind that just as in [I-D.ietf-stir-rfc4474bis] there may be 252 multiple Identity headers in a single SIP INVITE, so there may be 253 multiple PASSporTs in this out-of-band mechanism associated with a 254 single call. For example, a SIP user agent might create a PASSporT 255 for a call with an end user credential, and as the call exits the 256 originating administrative domain the network authentication service 257 might create its own PASSporT for the same call. As such, these use 258 cases may overlap in the processing of a single call. 260 5.1. Case 1: VoIP to PSTN Call 262 A call originates in the SIP world in a STIR-aware administrative 263 domain. The local authentication service for that administrative 264 domain creates a PASSporT which is carried in band in the call per 265 [I-D.ietf-stir-rfc4474bis]. The call is routed out of the 266 originating administrative domain and reaches a gateway to the PSTN. 267 Eventually, the call will terminate on a mobile smartphone that 268 supports this out-of-band mechanism. 270 In this use case, the originating authentication service can store 271 the PASSporT with the appropriate CPS for the target telephone number 272 as a fallback in case SIP signaling will not reach end-to-end. When 273 the destination mobile smartphone receives the call over the PSTN, it 274 consults the CPS and discovers a PASSporT from the originating 275 telephone number waiting for it. It uses this PASSporT to verify the 276 calling party number. 278 5.2. Case 2: Two Smart PSTN endpoints 280 A call originates with an enterprise PBX that has both Internet 281 access and a built-in gateway to the PSTN. It will immediately drop 282 its call to the PSTN, but before it does, it provisions a PASSporT on 283 the CPS associated with the target telephone number. 285 After normal PSTN routing, the call lands on a smart mobile handset 286 that supports the STIR out-of-band mechanism. It queries the 287 appropriate CPS over the Internet to determine if a call has been 288 placed to it by a STIR-aware device. It finds the PASSporT 289 provisioned by the enterprise PBX and uses it to verify the calling 290 party number. 292 5.3. Case 3: PSTN to VoIP Call 294 A call originates with an enterprise PBX that has both Internet 295 access and a built-in gateway to the PSTN. It will immediate drop 296 the call to the PSTN, but before it does, it provisions a PASSporT 297 with the CPS associated with the target telephone number. However, 298 it turns out that the call will eventually route through the PSTN to 299 an Internet gateway, which will translate this into a SIP call and 300 deliver it to an administrative domain with a STIR verification 301 service. 303 In this case, there are two subcases for how the PASSporT might be 304 retrieved. In subcase 1, the Internet gateway that receives the call 305 from the PSTN could query the appropriate CPS to determine if the 306 original caller created and provisioned a PASSporT for this call. If 307 so, it can retrieve the PASSporT and, when it creates a SIP INVITE 308 for this call, add a corresponding Identity header per 309 [I-D.ietf-stir-rfc4474bis]. When the SIP INVITE reaches the 310 destination administrative domain, it will be able to verify the 311 PASSporT normally. Note that to avoid discrepancies with the Date 312 header field value, only full-form PASSporT should be used for this 313 purpose. In subcase 2, the gateway does not retrieve the PASSporT 314 itself, but instead the verification service at the destination 315 administrative domain does so. Subcase 1 would perhaps be valuable 316 for deployments where the destination administrative domain supports 317 in-band STIR but not out-of-band STIR. 319 5.4. Case 4: Gateway Out-of-band 321 A call originates in the SIP world in a STIR-aware administrative 322 domain. The local authentication service for that administrative 323 domain creates a PASSporT which is carried in band in the call per 324 [I-D.ietf-stir-rfc4474bis]. The call is routed out of the 325 originating administrative domain and eventually reaches a gateway to 326 the PSTN. 328 In this case, the originating authentication service does not support 329 the out-of-band mechanism, so instead the gateway to the PSTN 330 extracts the PASSporT from the SIP request and provisions it to the 331 CPS. (When the call reaches the gateway to the PSTN, the gateway 332 might first check the CPS to see if a PASSporT object had already 333 been provisioned for this call, and only provision a PASSporT if none 334 is present). 336 Ultimately, the call may terminate on the PSTN, or be routed back to 337 the IP world. In the former case, perhaps the destination endpoints 338 queries the CPS to retrieve the PASSporT provisioned by the first 339 gateway. Or if the call ultimately returns to the IP world, it might 340 be the gateway from the PSTN back to the Internet that retrieves the 341 PASSporT from the CPS and attaches it to the new SIP INVITE it 342 creates, or it might be the terminating administrative domain's 343 verification service that checks the CPS when an INVITE arrives with 344 no Identity header field. Either way the PASSporT can survive the 345 gap in SIP coverage caused by the PSTN leg of the call. 347 6. Authorization for Storing and Retrieving PASSporTs 349 The use cases show a variety of entities accessing the CPS to store 350 and retrieve PASSporTs. The question of how the CPS authorizes the 351 storage and retrieval of PASSporT is thus a key design decision in 352 the architecture. 354 The STIR architecture assumes that service providers and in some 355 cases end user devices will have credentials suitable for attesting 356 authority over telephone numbers per [I-D.ietf-stir-certificates]. 357 These credentials provide the most obvious way that a CPS can 358 authorize the storage and retrieval of PASSporTs. However, as use 359 cases 3 and 4 in Section 5 show, it may sometimes make sense for the 360 entity storing or retrieving PASSporTs to be an intermediary rather 361 than a device associated with either the originating or terminating 362 side of a call, and those intermediaries often would not have access 363 to STIR credentials covering the telephone numbers in question. 365 It is an explicit design goal of this mechanism to minimize the 366 potential privacy exposure of using a CPS. Ideally, the out-of-band 367 mechanism should not result in a worse privacy situation than in-band 368 [I-D.ietf-stir-rfc4474bis] STIR: for in-band, we might say that a SIP 369 entity is authorized to receive a PASSporT if it is an intermediate 370 or final target of the routing of a SIP request. As the originator 371 of a call cannot necessarily predict the routing path a call will 372 follow, an out-of-band mechanism could conceivably even improve on 373 the privacy story. As a first step, transport-level security can 374 provide confidentiality from eavesdroppers for both the storage and 375 retrieval of PASSporTs. 377 6.1. Storage 379 For authorizing the storage of PASSporTs, the architecture can permit 380 some flexibility. A CPS could adopt a policy where it will store any 381 valid PASSporT - that is, the CPS could act as a limited verification 382 service and validate the PASSporT, only storing it if the timestamp 383 and signature are valid. In that case, it would not matter whether 384 the CPS received a PASSporT from the authentication service that 385 created it or from an intermediary gateway downstream in the routing 386 path as in case 4: so long as the PASSporT is valid, it would be 387 stored. 389 6.2. Retrieval 391 For retrieval of PASSporTs, the story is a bit more complicated. 392 Beyond using transport-level security when storing and retrieving 393 PASSporTs, the architecture must include some way to constrain access 394 to the PASSporTs stored at a CPS. How those constraints should 395 operate depends on the semantics of the request used to retrieve 396 PASSporTs. A retrieval request could have one of the following three 397 semantics: 399 a) Are there any current PASSporTs for calls originating from 400 1.111.111.1111? 402 b) Are there any current PASSporTs for calls destined to 403 2.222.222.2222? 405 c) Are there any current PASSporTs for calls originating from 406 1.111.111.1111 and destined to 2.222.222.2222? 408 Each of these three semantics results in very different properties 409 for the architecture. If a CPS permitted just anyone to ask for all 410 PASSporTs that happen to exist for current calls to or from a given 411 telephone number, that would be an unacceptable privacy situation. 412 Although on the surface semantic (c) may seem sufficiently strict, a 413 particular adversary might only be interested in learning when one 414 specific party calls another, and there are certainly cases in which 415 that could pose a significant security risk. While a CPS could 416 eventually refuse to answer repeated requests from a single device 417 that is obviously polling to collect the state of calls in progress, 418 more sophisticated adversaries could outwit any attempt to do source 419 filtering on requests at the CPS. 421 The semantics of (a) or (b) vs. (c) could be very significant when 422 the originating and destination numbers are for call centers or 423 similar organizations that send or receive a vast amount of calls for 424 a single number. In a case where many thousands of people are trying 425 to call a number where tickets have just gone on sale, for example, 426 it might be difficult using semantics (b) to sift through all of the 427 call setup attempts in progress to find a PASSporT matching any 428 particular call. A more narrow semantic like (c) would make it far 429 easier. 431 Sometimes the more narrow semantics of (c) can pose an obstacle to 432 acquiring the right PASSporT, for example in call forwarding cases 433 where retargeting of the request has occurred. Even using semantic 434 (b) would be problematic if the PASSporT stored by the originating 435 authentication service had a different original "dest". Mechanisms 436 have been proposed for STIR to patch this by creating PASSporTs that 437 record the diversion (see [I-D.peterson-passport-divert]), and 438 potentially a CPS could store these additional PASSporT objects and 439 supply them through the retrieval interface. 441 If we assume that the party retrieving PASSporTs from the CPS has a 442 STIR credential attesting authority over the terminating number, then 443 two more attractive mechanisms become possible: using authentication 444 and encryption. Note however that in some use cases, like case 3 445 subcase 1 above, the retrieving party is an intermediary who would 446 not have access to the necessary credentials. However, this might 447 argue that subcase 1 should be disallowed for security reasons, and 448 only subcase 2 should be permitted. 450 6.2.1. Authentication 452 For any of the three proposed retrieval semantics, a CPS could 453 authenticate a request to retrieve PASSporTs and only release 454 PASSporTs that have a destination that matches the credential 455 provided by the requestor. Per semantic (b), if a smart endpoint has 456 a credential for 2.222.222.2222, it could send a request to the CPS 457 signed with that credential to retrieve any PASSporTs for calls in 458 progress to 2.222.222.2222. In this case, (a) and (c) have very 459 similar semantics: when the requestor asks for (a), effectively they 460 would receive only those PASSporTs coming from 1.111.111.1111 that 461 are destined to 2.222.222.2222 - though perhaps in cases where the 462 call had been forwarded, a CPS aware of the situation could 463 understand that the new destination should be authorized to see the 464 original PASSporT. 466 On balance, an approach along the lines of requiring authenticating 467 requests with semantic (a) appears attractive as a direction for out- 468 of-band. 470 6.2.2. Encryption 472 Some of the privacy risks on the retrieval side could potentially be 473 mitigated with encryption. If all PASSporTs stored at a CPS were 474 encrypted with a key belonging to the intended destination, then 475 potentially the CPS could allow almost anyone to download PASSporTs 476 using semantics (a) or (b) without much fear of compromising private 477 information about calls in progress - provided that the CPS always 478 provided at least one encrypted blob in response to a request, even 479 if there was no call in progress. It would also prevent the CPS 480 itself from learning the contents of PASSporTs, and thus metadata 481 about calls in progress, which would make the CPS a less attractive 482 target for pervasive monitoring (see [RFC7258]). However, encrypting 483 PASSporTs faces some substantial difficulties. 485 First, this requires the entity that stores the PASSporT to have 486 access to a public key associated with the intended called party to 487 be used to encrypt the PASSporT. Discovering this key would require 488 some new service that does not exist today; depending on how the CPS 489 is architected, however, some kind of key store or repository could 490 be implemented adjacent to it, and perhaps even incorporated into its 491 operation. This key discovery problem is compounded by the fact that 492 there can potentially be multiple entities that have authority over a 493 telephone number: a carrier, a reseller, an enterprise, and an end 494 user might all have credentials permitting them to attest that they 495 are allowed to originate calls from a number, say. PASSporTs might 496 need to be encrypted with multiple keys in the hopes that one will be 497 decipherable by the relying party. 499 Second, in call forwarding cases, the difficulties in managing the 500 relationship between PASSporTs with the diversion extension 501 [I-D.peterson-passport-divert] become more serious. The originating 502 authentication service would encrypt the PASSporT with the public key 503 of the intended destination, but when a call is forwarded, it may go 504 to a destination that does not possess the corresponding private key. 505 It would require special behavior on the part of the retargeting 506 entity, and probably the CPS as well, to accommodate encrypted 507 PASSporTs that show a secure chain of diversion. A storer could for 508 example notify the CPS that the divert PASSporT it is storing relates 509 to a specific PASSporT already in the CPS, but in so doing, the 510 storer will inevitably reveal more metadata to the CPS. 512 Another side effect of encrypting PASSporTs before storing them is 513 that the CPS can no longer validate the PASSporTs since it cannot in 514 fact read them. However, a CPS needs to know enough about PASSporTs 515 so that it can respond to requests to retrieve them, whichever 516 semantics are used - which means the CPS will always process some 517 amount of metadata (even if some sort of hash function is used to 518 index PASSporTs). Unless the storer of PASSporTs is authenticated, 519 it may be possible for attackers to inject bogus PASSporTs into the 520 system: and an authentication and authorization process in the CPS 521 again will inevitably help the CPS to collect precisely the data that 522 encryption is supposed to hide. Moreover, note that merely injecting 523 a bogus PASSporT into a CPS will not allow attackers to impersonate 524 parties. That is because verification services trust a PASSporT 525 based its own internal signature, not based on where the verification 526 service found it. This is orthogonal to the current question of how 527 the CPS authorizes an endpoint to acquire a PASSporT; though of 528 course spamming a CPS with large numbers of bogus PASSporTs could 529 cause a denial of service or similar problems with retrieval of 530 PASSporTs. 532 7. Solution Architecture 534 In this section, we discuss a strawman architecture for providing the 535 service described in the previous sections. This discussion is 536 deliberately sketchy, focusing on broad concepts and skipping over 537 details. The intent here is merely to provide a rough concept, not a 538 complete solution. 540 7.1. Credentials and Phone Numbers 542 We start from the premise of the STIR problem statement [RFC7340] 543 that phone numbers can be associated with credentials which can be 544 used to attest ownership of numbers. For purposes of exposition, we 545 will assume that ownership is associated with the endpoint (e.g., a 546 smartphone) but it might well be associated with a provider or 547 gateway acting for the endpoint instead. It might be the case that 548 multiple entities are able to act for a given number, provided that 549 they have the appropriate authority. [I-D.ietf-stir-certificates] 550 describes a credentials system suitable for this purpose; the 551 question of how an entity is determined to have control of a given 552 number is out of scope for the current document. 554 7.2. Solution Architecture 556 An overview of the basic calling and verification process is shown 557 below. In this diagram, we assume that Alice has the number 558 +1.111.111.1111 and Bob has the number +2.222.222.2222. 560 Alice Call Placement Service Bob 561 ----------------------------------------------------------------------- 562 Store PASSporT ----------------> 564 Call from 1.111.111.1111 ----------------------------------------------> 566 <- Authenticate as 1.222.222.2222 ----> 568 <-------------- Retrieve call record 569 from 1.111.111.1111? 571 (1.222.222.2222,1.111.111.1111) --> 573 [Ring phone with callerid 574 = 1.111.111.1111] 576 When Alice wishes to make a call to Bob, she contacts the CPS and 577 stores a PASSporT on the CPS. The CPS validates the PASSporT before 578 indexing it so that it can be acquired with a request from Bob's 579 number 581 Once Alice has stored the PASSporT, she then places the call to Bob 582 as usual. At this point, Bob's phone would usually ring and display 583 Alice's number (+1.111.111.1111), which is informed by the existing 584 PSTN mechanisms for relying a calling party number (i.e., the CIN 585 field of the IAM). Instead, Bob's phone transparently contacts the 586 CPS, authenticates itself, and requests any current PASSporTs for 587 calls from Alice. The CPS responds with any such PASSporTs (assuming 588 they exist). If such a PASSpoRT exists, and the verification service 589 in Bob's phone validates it, then Bob's phone can then present the 590 calling party number information as valid. Otherwise, the call is 591 unverifiable. Note that this does not necessarily mean that the call 592 is bogus; because we expect incremental deployment many legitimate 593 calls will be unverifiable. 595 7.3. Security Analysis 597 The primary attack we seek to prevent is an attacker convincing the 598 callee that a given call is from some other caller C. There are two 599 scenarios to be concerned with: 601 The attacker wishes to impersonate a target when no call from that 602 target is in progress. 604 The attacker wishes to substitute himself for an existing call 605 setup as described in Section 7.4. 607 If an attacker can inject fake PASSporT into the CPS or in the 608 communication from the CPS to the callee, he can mount either attack. 609 As PASSporTs should be digitally signed by an appropriate authority 610 for the number and verified by the callee (see Section 7.1), this 611 should not arise in ordinary operations. For privacy and robustness 612 reasons, using TLS on the originating side when storing the PASSporT 613 at the CPS is recommended. 615 The entire system depends on the security of the credential 616 infrastructure. If the authentication credentials for a given number 617 are compromised, then an attacker can impersonate calls from that 618 number. However, that is no different from in-band 619 [I-D.ietf-stir-rfc4474bis] STIR. 621 7.4. Substitution Attacks 623 All that receipt of the PASSporT from the CPS proves to the called 624 party is that Alice is trying to call Bob (or at least was as of very 625 recently) - it does not prove that any particular incoming call is 626 from Alice. Consider the scenario in which we have a service which 627 provides an automatic callback to a user-provided number. In that 628 case, the attacker can try to arrange for a false caller-id value, as 629 shown below: 631 Attacker Callback Service CPS Bob 632 ----------------------------------------------------------------------- 633 Place call to Bob ----------> 635 Store PASSporT for 636 CS:Bob --------------> 638 Call from CS (forged caller-id info) --------------------------------> 640 Call from CS ---------------------------> X 642 <----- Retrieve PASSporT 643 for CS:Bob 645 PASSporT for CS:Bob ---------------------------> 647 [Ring phone with callerid = CS] 649 In order to mount this attack, the attacker contacts the Callback 650 Service (CS) and provides it with Bob's number. This causes the CS 651 to initiate a call to Bob. As before, the CS contacts the CPS to 652 insert an appropriate PASSporT and then initiates a call to Bob. 653 Because it is a valid CS injecting the PASSporT, none of the security 654 checks mentioned above help. However, the attacker simultaneously 655 initiates a call to Bob using forged caller-id information 656 corresponding to the CS. If he wins the race with the CS, then Bob's 657 phone will attempt to verify the attacker's call (and succeed since 658 they are indistinguishable) and the CS's call will go to busy/voice 659 mail/call waiting. Note: in a SIP environment, the callee might 660 notice that there were multiple INVITEs and thus detect this attack. 662 8. Call Placement Service Discovery 664 In order for the two ends of the out-of-band dataflow to coordinate, 665 they must agree on a way to discover a CPS and retrieve PASSporT 666 objects from it based solely on the rendezvous information available: 667 the calling party number and the called number. There are a number 668 of potential service discovery mechanisms that could be used for this 669 purpose. The means of service discovery may vary by use case. 671 Although the discussion above is written in terms of a single CPS, 672 having a significant fraction of all telephone calls result in 673 storing and retrieving PASSporTs at a single monolithic CPS has 674 obvious scaling problems, and would as well allow the CPS to gather 675 metadata about a very wide set of callers and callees. These issues 676 can be alleviated by operational models with a federated CPS; any 677 service discovery mechanism for out-of-band STIR should enable 678 federation of the CPS function. 680 Some service discovery possibilities under consideration include the 681 following: 683 If a credential lookup service is already available, the CPS 684 location can also be recorded in the callee's credentials; an 685 extension to [I-D.ietf-stir-certificates] could for example 686 provide a link to the location of the CPS where PASSporTs should 687 be stored for a destination. 689 There exist a number of common directory systems that might be 690 used to translate telephone numbers into the URIs of a CPS. ENUM 691 [RFC6116] is commonly implemented, though no "golden root" central 692 ENUM administration exists that could be easily reused today to 693 help the endpoints discover a common CPS. Other protocols 694 associated with queries for telephone numbers, such as the TeRI 695 [I-D.peterson-modern-teri] protocol, could also serve for this 696 application. 698 Another possibility is to use a single distributed service for 699 this function. VIPR [I-D.rosenberg-dispatch-vipr-overview] 700 proposed a RELOAD [RFC6940] usage for telephone numbers to help 701 direct calls to enterprises on the Internet. It would be possible 702 to describe a similar RELOAD usage to identify the CPS where calls 703 for a particular telephone number should be stored. One advantage 704 that the STIR architecture has over VIPR is that it assumes a 705 credential system that proves authority over telephone numbers; 706 those credentials could be used to determine whether or not a CPS 707 could legitimately claim to be the proper store for a given 708 telephone number. 710 Future versions of this specification will identify suitable service 711 discovery mechanisms for out-of-band STIR. 713 9. To Do 715 Section 4 provides a broad sketch of an approach. In this section, 716 we consider some areas for additional work. Readers can feel free to 717 skip this section, as it is not necessary to get the flavor of the 718 document. 720 9.1. Credential Lookup 722 In order to encrypt a PASSporT (see Section 6.2.2), the caller needs 723 access to the callee's credentials (specifically their public key). 724 This requires some sort of directory/lookup system. This document 725 does not specify any particular scheme, but a list of requirements 726 would be something like: 728 Obviously, if there is a single central database and the caller and 729 callee each contact it in real time to determine the other's 730 credentials, then this represents a real privacy risk, as the central 731 database learns about each call. A number of mechanisms are 732 potentially available to mitigate this: 734 Have endpoints pre-fetch credentials for potential counterparties 735 (e.g., their address book or the entire database). 737 Have caching servers in the user's network that proxy their 738 fetches and thus conceal the relationship between the user and the 739 credentials they are fetching. 741 Clearly, there is a privacy/timeliness tradeoff in that getting 742 really up-to-date knowledge about credential validity requires 743 contacting the credential directory in real-time (e.g., via OCSP). 744 This is somewhat mitigated for the caller's credentials in that he 745 can get short-term credentials right before placing a call which only 746 reveals his calling rate, but not who he is calling. Alternately, 747 the CPS can verify the caller's credentials via OCSP, though of 748 course this requires the callee to trust the CPS's verification. 749 This approach does not work as well for the callee's credentials, but 750 the risk there is more modest since an attacker would need to both 751 have the callee's credentials and regularly poll the database for 752 every potential caller. 754 We consider the exact best point in the tradeoff space to be an open 755 issue. 757 10. Acknowledgments 759 The ideas in this document come out of discussions with Richard 760 Barnes and Cullen Jennings. We'd also like to thank Robert Sparks 761 for helpful suggestions. 763 11. IANA Considerations 765 This memo includes no request to IANA. 767 12. Security Considerations 769 This entire document is about security, but the detailed security 770 properties depend on having a single concrete scheme to analyze. 772 13. Informative References 774 [I-D.ietf-stir-certificates] 775 Peterson, J. and S. Turner, "Secure Telephone Identity 776 Credentials: Certificates", draft-ietf-stir- 777 certificates-14 (work in progress), May 2017. 779 [I-D.ietf-stir-passport] 780 Wendt, C. and J. Peterson, "Personal Assertion Token 781 (PASSporT)", draft-ietf-stir-passport-11 (work in 782 progress), February 2017. 784 [I-D.ietf-stir-rfc4474bis] 785 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 786 "Authenticated Identity Management in the Session 787 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 788 (work in progress), February 2017. 790 [I-D.peterson-modern-teri] 791 Peterson, J., "An Architecture and Information Model for 792 Telephone-Related Information (TeRI)", draft-peterson- 793 modern-teri-02 (work in progress), October 2016. 795 [I-D.peterson-passport-divert] 796 Peterson, J., "PASSporT Extension for Diverted Calls", 797 draft-peterson-passport-divert-01 (work in progress), June 798 2017. 800 [I-D.rosenberg-dispatch-vipr-overview] 801 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 802 "Verification Involving PSTN Reachability: Requirements 803 and Architecture Overview", draft-rosenberg-dispatch-vipr- 804 overview-04 (work in progress), October 2010. 806 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 807 Requirement Levels", BCP 14, RFC 2119, 808 DOI 10.17487/RFC2119, March 1997, 809 . 811 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 812 A., Peterson, J., Sparks, R., Handley, M., and E. 813 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 814 DOI 10.17487/RFC3261, June 2002, 815 . 817 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 818 Uniform Resource Identifiers (URI) Dynamic Delegation 819 Discovery System (DDDS) Application (ENUM)", RFC 6116, 820 DOI 10.17487/RFC6116, March 2011, 821 . 823 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 824 and H. Schulzrinne, "REsource LOcation And Discovery 825 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 826 January 2014, . 828 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 829 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 830 2014, . 832 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 833 Telephone Identity Problem Statement and Requirements", 834 RFC 7340, DOI 10.17487/RFC7340, September 2014, 835 . 837 Authors' Addresses 839 Eric Rescorla 840 Mozilla 842 Email: ekr@rtfm.com 843 Jon Peterson 844 Neustar, Inc. 845 1800 Sutter St Suite 570 846 Concord, CA 94520 847 US 849 Email: jon.peterson@neustar.biz