idnits 2.17.1 draft-rescorla-stir-fallback-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == 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 (June 14, 2017) is 2508 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: December 16, 2017 Neustar 6 June 14, 2017 8 STIR Out of Band Architecture and Use Cases 9 draft-rescorla-stir-fallback-02.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 December 16, 2017. 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 . . . . . . . . . . . . . . . . . . 13 74 8. Call Placement Service Discovery . . . . . . . . . . . . . . 14 75 9. To Do . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 76 9.1. Credential Lookup . . . . . . . . . . . . . . . . . . . . 16 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 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. 509 Another side effect of encrypting PASSporTs before storing them is 510 that the CPS can no longer validate the PASSporTs since it cannot in 511 fact read them. However, a CPS needs to know enough about PASSporTs 512 so that it can respond to requests to retrieve them, whichever 513 semantics are used - which means the CPS will always process some 514 amount of metadata (even if some sort of hash function is used to 515 index PASSporTs). Unless the storer of PASSporTs is authenticated, 516 it may be possible for attackers to inject bogus PASSporTs into the 517 system. Note however that merely injecting a bogus PASSporT into a 518 CPS will not allow attackers to impersonate parties. That is because 519 verification services trust a PASSporT based its own internal 520 signature, not based on where the verification service found it. 521 This is orthogonal to the current question of how the CPS authorizes 522 an endpoint to acquire a PASSporT; though of course spamming a CPS 523 with large numbers of bogus PASSporTs could cause a denial of service 524 or similar problems with retrieval of PASSporTs. 526 7. Solution Architecture 528 In this section, we discuss a strawman architecture for providing the 529 service described in the previous sections. This discussion is 530 deliberately sketchy, focusing on broad concepts and skipping over 531 details. The intent here is merely to provide a rough concept, not a 532 complete solution. 534 7.1. Credentials and Phone Numbers 536 We start from the premise of the STIR problem statement [RFC7340] 537 that phone numbers can be associated with credentials which can be 538 used to attest ownership of numbers. For purposes of exposition, we 539 will assume that ownership is associated with the endpoint (e.g., a 540 smartphone) but it might well be associated with a provider or 541 gateway acting for the endpoint instead. It might be the case that 542 multiple entities are able to act for a given number, provided that 543 they have the appropriate authority. [I-D.ietf-stir-certificates] 544 describes a credentials system suitable for this purpose; the 545 question of how an entity is determined to have control of a given 546 number is out of scope for the current document. 548 7.2. Solution Architecture 550 An overview of the basic calling and verification process is shown 551 below. In this diagram, we assume that Alice has the number 552 +1.111.111.1111 and Bob has the number +2.222.222.2222. 554 Alice Call Placement Service Bob 555 ----------------------------------------------------------------------- 556 Store PASSporT ----------------> 558 Call from 1.111.111.1111 ----------------------------------------------> 560 <- Authenticate as 1.222.222.2222 ----> 562 <-------------- Retrieve call record 563 from 1.111.111.1111? 565 (1.222.222.2222,1.111.111.1111) --> 567 [Ring phone with callerid 568 = 1.111.111.1111] 570 When Alice wishes to make a call to Bob, she contacts the CPS and 571 stores a PASSporT on the CPS. The CPS validates the PASSporT before 572 indexing it so that it can be acquired with a request from Bob's 573 number 575 Once Alice has stored the PASSporT, she then places the call to Bob 576 as usual. At this point, Bob's phone would usually ring and display 577 Alice's number (+1.111.111.1111), which is informed by the existing 578 PSTN mechanisms for relying a calling party number (i.e., the CIN 579 field of the IAM). Instead, Bob's phone transparently contacts the 580 CPS, authenticates itself, and requests any current PASSporTs for 581 calls from Alice. The CPS responds with any such PASSporTs (assuming 582 they exist). If such a PASSpoRT exists, and the verification service 583 in Bob's phone validates it, then Bob's phone can then present the 584 calling party number information as valid. Otherwise, the call is 585 unverifiable. Note that this does not necessarily mean that the call 586 is bogus; because we expect incremental deployment many legitimate 587 calls will be unverifiable. 589 7.3. Security Analysis 591 The primary attack we seek to prevent is an attacker convincing the 592 callee that a given call is from some other caller C. There are two 593 scenarios to be concerned with: 595 The attacker wishes to impersonate a target when no call from that 596 target is in progress. 598 The attacker wishes to substitute himself for an existing call 599 setup as described in Section 7.4. 601 If an attacker can inject fake PASSporT into the CPS or in the 602 communication from the CPS to the callee, he can mount either attack. 603 As PASSporTs should be digitally signed by an appropriate authority 604 for the number and verified by the callee (see Section 7.1), this 605 should not arise in ordinary operations. For privacy and robustness 606 reasons, using TLS on the originating side when storing the PASSporT 607 at the CPS is recommended. 609 The entire system depends on the security of the credential 610 infrastructure. If the authentication credentials for a given number 611 are compromised, then an attacker can impersonate calls from that 612 number. However, that is no different from in-band 613 [I-D.ietf-stir-rfc4474bis] STIR. 615 7.4. Substitution Attacks 617 All that receipt of the PASSporT from the CPS proves to the called 618 party is that Alice is trying to call Bob (or at least was as of very 619 recently) - it does not prove that any particular incoming call is 620 from Alice. Consider the scenario in which we have a service which 621 provides an automatic callback to a user-provided number. In that 622 case, the attacker can try to arrange for a false caller-id value, as 623 shown below: 625 Attacker Callback Service CPS Bob 626 ----------------------------------------------------------------------- 627 Place call to Bob ----------> 629 Store PASSporT for 630 CS:Bob --------------> 632 Call from CS (forged caller-id info) --------------------------------> 634 Call from CS ---------------------------> X 636 <----- Retrieve PASSporT 637 for CS:Bob 639 PASSporT for CS:Bob ---------------------------> 641 [Ring phone with callerid = CS] 643 In order to mount this attack, the attacker contacts the Callback 644 Service (CS) and provides it with Bob's number. This causes the CS 645 to initiate a call to Bob. As before, the CS contacts the CPS to 646 insert an appropriate PASSporT and then initiates a call to Bob. 647 Because it is a valid CS injecting the PASSporT, none of the security 648 checks mentioned above help. However, the attacker simultaneously 649 initiates a call to Bob using forged caller-id information 650 corresponding to the CS. If he wins the race with the CS, then Bob's 651 phone will attempt to verify the attacker's call (and succeed since 652 they are indistinguishable) and the CS's call will go to busy/voice 653 mail/call waiting. Note: in a SIP environment, the callee might 654 notice that there were multiple INVITEs and thus detect this attack. 656 8. Call Placement Service Discovery 658 In order for the two ends of the out-of-band dataflow to coordinate, 659 they must agree on a way to discover a CPS and retrieve PASSporT 660 objects from it based solely on the rendezvous information available: 661 the calling party number and the called number. There are a number 662 of potential service discovery mechanisms that could be used for this 663 purpose. The means of service discovery may vary by use case. 665 Although the discussion above is written in terms of a single CPS, 666 having a significant fraction of all telephone calls result in 667 storing and retrieving PASSporTs at a single monolithic CPS has 668 obvious scaling problems, and would as well allow the CPS to gather 669 metadata about a very wide set of callers and callees. These issues 670 can be alleviated by operational models with a federated CPS; any 671 service discovery mechanism for out-of-band STIR should enable 672 federation of the CPS function. 674 Some service discovery possibilities under consideration include the 675 following: 677 If a credential lookup service is already available, the CPS 678 location can also be recorded in the callee's credentials; an 679 extension to [I-D.ietf-stir-certificates] could for example 680 provide a link to the location of the CPS where PASSporTs should 681 be stored for a destination. 683 There exist a number of common directory systems that might be 684 used to translate telephone numbers into the URIs of a CPS. ENUM 685 [RFC6116] is commonly implemented, though no "golden root" central 686 ENUM administration exists that could be easily reused today to 687 help the endpoints discover a common CPS. Other protocols 688 associated with queries for telephone numbers, such as the TeRI 689 [I-D.peterson-modern-teri] protocol, could also serve for this 690 application. 692 Another possibility is to use a single distributed service for 693 this function. VIPR [I-D.rosenberg-dispatch-vipr-overview] 694 proposed a RELOAD [RFC6940] usage for telephone numbers to help 695 direct calls to enterprises on the Internet. It would be possible 696 to describe a similar RELOAD usage to identify the CPS where calls 697 for a particular telephone number should be stored. One advantage 698 that the STIR architecture has over VIPR is that it assumes a 699 credential system that proves authority over telephone numbers; 700 those credentials could be used to determine whether or not a CPS 701 could legitimately claim to be the proper store for a given 702 telephone number. 704 Future versions of this specification will identify suitable service 705 discovery mechanisms for out-of-band STIR. 707 9. To Do 709 Section 4 provides a broad sketch of an approach. In this section, 710 we consider some areas for additional work. Readers can feel free to 711 skip this section, as it is not necessary to get the flavor of the 712 document. 714 9.1. Credential Lookup 716 In order to encrypt a PASSporT (see Section 6.2.2), the caller needs 717 access to the callee's credentials (specifically their public key). 718 This requires some sort of directory/lookup system. This document 719 does not specify any particular scheme, but a list of requirements 720 would be something like: 722 Obviously, if there is a single central database and the caller and 723 callee each contact it in real time to determine the other's 724 credentials, then this represents a real privacy risk, as the central 725 database learns about each call. A number of mechanisms are 726 potentially available to mitigate this: 728 Have endpoints pre-fetch credentials for potential counterparties 729 (e.g., their address book or the entire database). 731 Have caching servers in the user's network that proxy their 732 fetches and thus conceal the relationship between the user and the 733 credentials they are fetching. 735 Clearly, there is a privacy/timeliness tradeoff in that getting 736 really up-to-date knowledge about credential validity requires 737 contacting the credential directory in real-time (e.g., via OCSP). 738 This is somewhat mitigated for the caller's credentials in that he 739 can get short-term credentials right before placing a call which only 740 reveals his calling rate, but not who he is calling. Alternately, 741 the CPS can verify the caller's credentials via OCSP, though of 742 course this requires the callee to trust the CPS's verification. 743 This approach does not work as well for the callee's credentials, but 744 the risk there is more modest since an attacker would need to both 745 have the callee's credentials and regularly poll the database for 746 every potential caller. 748 We consider the exact best point in the tradeoff space to be an open 749 issue. 751 10. Acknowledgments 753 The ideas in this document come out of discussions with Richard 754 Barnes and Cullen Jennings. 756 11. IANA Considerations 758 This memo includes no request to IANA. 760 12. Security Considerations 762 This entire document is about security, but the detailed security 763 properties depend on having a single concrete scheme to analyze. 765 13. Informative References 767 [I-D.ietf-stir-certificates] 768 Peterson, J. and S. Turner, "Secure Telephone Identity 769 Credentials: Certificates", draft-ietf-stir- 770 certificates-14 (work in progress), May 2017. 772 [I-D.ietf-stir-passport] 773 Wendt, C. and J. Peterson, "Personal Assertion Token 774 (PASSporT)", draft-ietf-stir-passport-11 (work in 775 progress), February 2017. 777 [I-D.ietf-stir-rfc4474bis] 778 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 779 "Authenticated Identity Management in the Session 780 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 781 (work in progress), February 2017. 783 [I-D.peterson-modern-teri] 784 Peterson, J., "An Architecture and Information Model for 785 Telephone-Related Information (TeRI)", draft-peterson- 786 modern-teri-02 (work in progress), October 2016. 788 [I-D.peterson-passport-divert] 789 Peterson, J., "PASSporT Extension for Diverted Calls", 790 draft-peterson-passport-divert-01 (work in progress), June 791 2017. 793 [I-D.rosenberg-dispatch-vipr-overview] 794 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 795 "Verification Involving PSTN Reachability: Requirements 796 and Architecture Overview", draft-rosenberg-dispatch-vipr- 797 overview-04 (work in progress), October 2010. 799 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 800 Requirement Levels", BCP 14, RFC 2119, 801 DOI 10.17487/RFC2119, March 1997, 802 . 804 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 805 A., Peterson, J., Sparks, R., Handley, M., and E. 806 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 807 DOI 10.17487/RFC3261, June 2002, 808 . 810 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 811 Uniform Resource Identifiers (URI) Dynamic Delegation 812 Discovery System (DDDS) Application (ENUM)", RFC 6116, 813 DOI 10.17487/RFC6116, March 2011, 814 . 816 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 817 and H. Schulzrinne, "REsource LOcation And Discovery 818 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 819 January 2014, . 821 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 822 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 823 2014, . 825 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 826 Telephone Identity Problem Statement and Requirements", 827 RFC 7340, DOI 10.17487/RFC7340, September 2014, 828 . 830 Authors' Addresses 832 Eric Rescorla 833 Mozilla 835 Email: ekr@rtfm.com 837 Jon Peterson 838 Neustar, Inc. 839 1800 Sutter St Suite 570 840 Concord, CA 94520 841 US 843 Email: jon.peterson@neustar.biz