idnits 2.17.1 draft-ietf-stir-oob-03.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 7 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 date (July 2, 2018) is 2122 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) == Missing Reference: 'Disconnect' is mentioned on line 434, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-stir-passport-divert-02 Summary: 0 errors (**), 0 flaws (~~), 4 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 3, 2019 Neustar 6 July 2, 2018 8 STIR Out-of-Band Architecture and Use Cases 9 draft-ietf-stir-oob-03.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 https://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 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 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 (https://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. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 8 65 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 69 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 71 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13 72 8. Authentication and Verification Service Behavior for Out-of- 73 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 8.1. Authentication Service . . . . . . . . . . . . . . . . . 14 75 8.2. Verification Service . . . . . . . . . . . . . . . . . . 16 76 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 17 77 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 17 78 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 19 79 11. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 20 80 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 21 81 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 82 14. Security Considerations . . . . . . . . . . . . . . . . . . . 21 83 15. Informative References . . . . . . . . . . . . . . . . . . . 21 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 The STIR problem statement [RFC7340] describes widespread problems 89 enabled by impersonation in the telephone network, including illegal 90 robocalling, voicemail hacking, and swatting. As telephone services 91 are increasingly migrating onto the Internet, and using Voice over IP 92 (VoIP) protocols such as SIP [RFC3261], it is necessary for these 93 protocols to support stronger identity mechanisms to prevent 94 impersonation. For example, [RFC8224] defines an Identity header of 95 SIP requests capable of carrying a PASSporT [RFC8225] object in SIP 96 as a means to cryptographically attest that the originator of a 97 telephone call is authorized to use the calling party number (or, for 98 native SIP cases, SIP URI) associated with the originator of the 99 call. of the request. 101 Not all telephone calls use SIP today, however; and even those that 102 do use SIP do not always carry SIP signaling end-to-end. Most calls 103 from telephone numbers still traverse the Public Switched Telephone 104 Network (PSTN) at some point. Broadly, calls fall into one of three 105 categories: 107 1. One or both of the endpoints is actually a PSTN endpoint. 109 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the 110 call transits the PSTN at some point. 112 3. Non-PSTN calls which do not transit the PSTN at all (such as 113 native SIP end-to-end calls). 115 The first two categories represent the majority of telephone calls 116 associated with problems like illegal robocalling: many robocalls 117 today originate on the Internet but terminate at PSTN endpoints. 118 However, the core network elements that operate the PSTN are legacy 119 devices that are unlikely to be upgradable at this point to support 120 an in-band authentication system. As such, those devices largely 121 cannot be modified to pass signatures originating on the Internet--or 122 indeed any inband signaling data--intact. Even if fields for 123 tunneling arbtirary data can be found in traditional PSTN signaling, 124 in some cases legacy elements would strip the signatures from those 125 fields; in others, they might damage them to the point where they 126 cannot be verified. For those first two categories above, any in- 127 band authentication scheme does not seem practical in the current 128 environment. 130 But while the core network of the PSTN remains fixed, the endpoints 131 of the telephone network are becoming increasingly programmable and 132 sophisticated. Landline "plain old telephone service" deployments, 133 especially in the developed world, are shrinking, and increasingly 134 being replaced by three classes of intelligent devices: smart phones, 135 IP PBXs, and terminal adapters. All three are general purpose 136 computers, and typically all three have Internet access as well as 137 access to the PSTN. Additionally, various kinds of gateways 138 increasingly front for legacy equipment. All of this provides a 139 potential avenue for building an authentication system that 140 implements stronger identity while leaving PSTN systems intact. 142 This capability also provides an ideal transitional technology while 143 in-band STIR adoption is ramping up. It permits early adopters to 144 use the technology even when intervening network elements are not yet 145 STIR-aware, and through various kinds of gateways it may allow 146 providers with a significant PSTN investment to still secure their 147 calls with STIR. 149 This specification therefore builds on the PASSporT [RFC8225] 150 mechanism and the work of [RFC8224] to define a way that a PASSporT 151 object created in the originating network of a call can reach the 152 terminating network even when it cannot be carried end-to-end in-band 153 in the call signaling. This relies on a new service defined in this 154 document that permits the PASSporT object to be stored during call 155 processing and retrieved for verification purposes. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 161 "OPTIONAL" in this document are to be interpreted as described in RFC 162 2119 [RFC2119]. 164 3. Operating Environments 166 This section describes the environments in which the proposed 167 mechanism is intended to operate. In the simplest setting, Alice is 168 calling Bob through some set of gateways and/or the PSTN. Both Alice 169 and Bob have smart devices which can be modified, but they do not 170 have a clear connection between them: Alice cannot inject any data 171 into signaling which Bob can read, with the exception of the asserted 172 destination and origination E.164 numbers. The calling party number 173 might originate from her own device or from the network. These 174 numbers are effectively the only data that can be used for 175 coordination between the endpoints. 177 +---------+ 178 / \ 179 +--- +---+ 180 +----------+ / \ +----------+ 181 | | | Gateways | | | 182 | Alice |<----->| and/or |<----->| Bob | 183 | (caller) | | PSTN | | (callee) | 184 +----------+ \ / +----------+ 185 +--- +---+ 186 \ / 187 +---------+ 189 In a more complicated setting, Alice and/or Bob may not have a smart 190 or programmable device, but one or both of them are behind a STIR- 191 aware gateway that can participate in out-of-band coordination, as 192 shown below: 194 +---------+ 195 / \ 196 +--- +---+ 197 +----------+ +--+ / \ +--+ +----------+ 198 | | | | | Gateways | | | | | 199 | Alice |<-|GW|->| and/or |<-|GW|->| Bob | 200 | (caller) | | | | PSTN | | | | (callee) | 201 +----------+ +--+ \ / +--+ +----------+ 202 +--- +---+ 203 \ / 204 +---------+ 206 In such a case, Alice might have an analog connection to her gateway/ 207 switch which is responsible for her identity. Similarly, the gateway 208 would verify Alice's identity, generate the right calling party 209 number information and provide that number to Bob using ordinary POTS 210 mechanisms. 212 4. Dataflows 214 Because in these operating environments endpoints cannot pass 215 cryptographic information to one another directly through signaling, 216 any solution must involve some rendezvous mechanism to allow 217 endpoints to communicate. We call this rendezvous service a "call 218 placement service" (CPS), a service where a record of call placement, 219 in this case a PASSporT, can be stored for future retrieval. In 220 principle this service could communicate any information, but 221 minimally we expect it to include a full-form PASSporT that attests 222 the caller, callee, and the time of the call. The callee can use the 223 existence of a PASSporT for a given incoming call as rough validation 224 of the asserted origin of that call. (See Section 11 for limitations 225 of this design.) 227 There are roughly two plausible dataflow architectures for the CPS: 229 The callee registers with the CPS. When the caller wishes to 230 place a call to the callee, it sends the PASSporT to the CPS, 231 which immediately forwards it to the callee. 233 The caller stores the PASSporT with the CPS at the time of call 234 placement. When the callee receives the call, it contacts the CPS 235 and retrieves the PASSporT. 237 While the first architecture is roughly isomorphic to current VoIP 238 protocols, it shares their drawbacks. Specifically, the callee must 239 maintain a full-time connection to the CPS to serve as a notification 240 channel. This comes with the usual networking costs to the callee 241 and is especially problematic for mobile endpoints. Indeed, if the 242 endpoints had the capabilities to implement such an architecture, 243 they could surely just use SIP or some other protocol to set up a 244 secure session; even if the media were going through the traditional 245 PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we 246 focus on the second architecture in which the PSTN incoming call 247 serves as the notification channel and the callee can then contact 248 the CPS to retrieve the PASSporT. 250 5. Use Cases 252 The following are the motivating use cases for this mechanism. Bear 253 in mind that just as in [RFC8224] there may be multiple Identity 254 headers in a single SIP INVITE, so there may be multiple PASSporTs in 255 this out-of-band mechanism associated with a single call. For 256 example, a SIP user agent might create a PASSporT for a call with an 257 end user credential, and as the call exits the originating 258 administrative domain the network authentication service might create 259 its own PASSporT for the same call. As such, these use cases may 260 overlap in the processing of a single call. 262 5.1. Case 1: VoIP to PSTN Call 264 A call originates in the SIP world in a STIR-aware administrative 265 domain. The local authentication service for that administrative 266 domain creates a PASSporT which is carried in band in the call per 267 [RFC8224]. The call is routed out of the originating administrative 268 domain and reaches a gateway to the PSTN. Eventually, the call will 269 terminate on a mobile smartphone that supports this out-of-band 270 mechanism. 272 In this use case, the originating authentication service can store 273 the PASSporT with the appropriate CPS for the target telephone number 274 as a fallback in case SIP signaling will not reach end-to-end. When 275 the destination mobile smartphone receives the call over the PSTN, it 276 consults the CPS and discovers a PASSporT from the originating 277 telephone number waiting for it. It uses this PASSporT to verify the 278 calling party number. 280 5.2. Case 2: Two Smart PSTN endpoints 282 A call originates with an enterprise PBX that has both Internet 283 access and a built-in gateway to the PSTN. It will immediately drop 284 its call to the PSTN, but before it does, it provisions a PASSporT on 285 the CPS associated with the target telephone number. 287 After normal PSTN routing, the call lands on a smart mobile handset 288 that supports the STIR out-of-band mechanism. It queries the 289 appropriate CPS over the Internet to determine if a call has been 290 placed to it by a STIR-aware device. It finds the PASSporT 291 provisioned by the enterprise PBX and uses it to verify the calling 292 party number. 294 5.3. Case 3: PSTN to VoIP Call 296 A call originates with an enterprise PBX that has both Internet 297 access and a built-in gateway to the PSTN. It will immediate drop 298 the call to the PSTN, but before it does, it provisions a PASSporT 299 with the CPS associated with the target telephone number. However, 300 it turns out that the call will eventually route through the PSTN to 301 an Internet gateway, which will translate this into a SIP call and 302 deliver it to an administrative domain with a STIR verification 303 service. 305 In this case, there are two subcases for how the PASSporT might be 306 retrieved. In subcase 1, the Internet gateway that receives the call 307 from the PSTN could query the appropriate CPS to determine if the 308 original caller created and provisioned a PASSporT for this call. If 309 so, it can retrieve the PASSporT and, when it creates a SIP INVITE 310 for this call, add a corresponding Identity header per [RFC8224]. 311 When the SIP INVITE reaches the destination administrative domain, it 312 will be able to verify the PASSporT normally. Note that to avoid 313 discrepancies with the Date header field value, only full-form 314 PASSporT should be used for this purpose. In subcase 2, the gateway 315 does not retrieve the PASSporT itself, but instead the verification 316 service at the destination administrative domain does so. Subcase 1 317 would perhaps be valuable for deployments where the destination 318 administrative domain supports in-band STIR but not out-of-band STIR. 320 5.4. Case 4: Gateway Out-of-band 322 A call originates in the SIP world in a STIR-aware administrative 323 domain. The local authentication service for that administrative 324 domain creates a PASSporT which is carried in band in the call per 325 [RFC8224]. The call is routed out of the originating administrative 326 domain and eventually reaches a gateway to 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. 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. Broadly, the architecture described here is one 353 focused on permitting any entity to store encrypted PASSporTs at the 354 CPS, indexed under the caller number. PASSporTs will be encrypted 355 with associated with the called number, so these PASSporTs may also 356 be retrieved by any entity, as only holders of the corresponding 357 private key will be able to decrypt the PASSporT. This also prevents 358 the CPS itself from learning the contents of PASSporTs, and thus 359 metadata about calls in progress, which would make the CPS a less 360 attractive target for pervasive monitoring (see [RFC7258]). Ho 361 bolster the privacy story, prevent denial-of-service flooding of the 362 CPS, and to complicate traffic analysis, a few additional mechanisms 363 are also recommended. 365 The STIR architecture assumes that service providers and in some 366 cases end user devices will have credentials suitable for attesting 367 authority over telephone numbers per [RFC8226]. These credentials 368 provide the most obvious way that a CPS can authorize the storage and 369 retrieval of PASSporTs. However, as use cases 3 and 4 in Section 5 370 show, it may sometimes make sense for the entity storing or 371 retrieving PASSporTs to be an intermediary rather than a device 372 associated with either the originating or terminating side of a call, 373 and those intermediaries often would not have access to STIR 374 credentials covering the telephone numbers in question. Requiring 375 authorization based on a credential to store PASSporTs is therefore 376 undesirable, though potentially acceptible if sufficient steps are 377 taken to mitigate the privacy risk as described in the next section. 379 Furthermore, it is an explicit design goal of this mechanism to 380 minimize the potential privacy exposure of using a CPS. Ideally, the 381 out-of-band mechanism should not result in a worse privacy situation 382 than in-band [RFC8224] STIR: for in-band, we might say that a SIP 383 entity is authorized to receive a PASSporT if it is an intermediate 384 or final target of the routing of a SIP request. As the originator 385 of a call cannot necessarily predict the routing path a call will 386 follow, an out-of-band mechanism could conceivably even improve on 387 the privacy story. As a first step, transport-level security can 388 provide confidentiality from eavesdroppers for both the storage and 389 retrieval of PASSporTs. 391 6.1. Storage 393 For authorizing the storage of PASSporTs, the architecture can permit 394 some flexibility. Note that in this architecture a CPS has no way to 395 tell if a PASSporT is valid; it simply conveys encrypted blocks that 396 it cannot access itself. In that architecture, it does not matter 397 whether the CPS received a PASSporT from the authentication service 398 that created it or from an intermediary gateway downstream in the 399 routing path as in case 4. 401 Note that this architecture requires clients that stores PASSporTs to 402 have access to a public key associated with the intended called party 403 to be used to encrypt the PASSporT. Discovering this key requires 404 some new service that does not exist today; depending on how the CPS 405 is architected, however, some kind of key store or repository could 406 be implemented adjacent to it, and perhaps even incorporated into its 407 operation. Key discovery is made more complicated by the fact that 408 there can potentially be multiple entities that have authority over a 409 telephone number: a carrier, a reseller, an enterprise, and an end 410 user might all have credentials permitting them to attest that they 411 are allowed to originate calls from a number, say. PASSporTs 412 therefore might need to be encrypted with multiple keys in the hopes 413 that one will be decipherable by the relying party. 415 However, if literally anyone can store PASSporTs in the CPS, an 416 attacker could easily flood the CPS with millions of bogus PASSporTs 417 indexed under a target number, and thereby prevent that called party 418 from finding a valid PASSporT for an incoming call buried in a 419 haystack of fake entries. A CPS must therefore implement some sort 420 of traffic control system to prevent flooding. Preferably, this 421 should not require authenticating the source, as this will reveal to 422 the CPS both ths source and destination of traffic. 424 In order to do this, we propose the use of "blind signatures". A 425 sender will initially authenticate to the CPS, and acquire a signed 426 token for the CPS that will be presented later when storing a 427 PASSporT. The flow looks as follows: 429 Sender CPS 431 Authenticate to CPS ---------------------> 432 Blinded(K_temp) -------------------------> 433 <------------- Sign(K_cps, Blinded(K_temp)) 434 [Disconnect] 436 Sign(K_cps, K_temp)) 437 Sign(K_temp, E(K_receiver, PASSporT)) ---> 439 At an initial time when no call is yet in progress, a potential 440 client connects to the CPS, authenticates, and sends a blinded 441 version of a freshly generated public key. The CPS returns a signed 442 version of that blinded key. The sender can then unblind the key and 443 gets a signature on K_temp from the CPS 445 Then later, when a client wants to store a PASSporT, it connects to 446 the CPS anonymously (preferably over a network connection that cannot 447 be correlated with the token acquisition) and sends both the signed 448 K_temp and its own signature over the encrypted PASSporT. The CPS 449 verifies both signatures and if they verify, stores the encrypted 450 passport (discarding the signatures). 452 This design lets the CPS rate limit how many PASSporTs a given sender 453 can store just by counting how many times K_temp appears; perhaps CPS 454 policy might reject storage attempts and require acqusition of a new 455 K_temp after storing more than a certain number of PASSporTs indexed 456 under the same destination number in a short interval. This does not 457 of course allow the CPS to tell when bogus data is being provisioned 458 by an attacker, simply the rate at which data is being provisioned. 459 Potentially, feedback mechanisms could be developed that would allow 460 the called parties to tell the CPS when they are receiving unusual or 461 bogus PASSporTs. 463 This architecture also assumes that the CPS will age out PASSporTs. 464 A CPS SHOULD NOT keep any stored PASSporT for more than sixty 465 seconds. Any reduction in this window makes substitution attacks 466 (see Section 7.4) harder to mount, but making the window too small 467 might conceivably age PASSporTs out while a heavily redirected call 468 is still alerting. harder to mount 470 6.2. Retrieval 472 For retrieval of PASSporTs, this architecture assumes that clients 473 contact the CPS to send requests of the form: 475 Are there any current PASSporTs for calls destined to 476 2.222.222.2222? 478 As all PASSporTs stored at the CPS are encrypted with a key belonging 479 to the intended destination, then potentially the CPS could allow 480 anyone to download PASSporTs for a called number without much fear of 481 compromising private information about calls in progress - provided 482 that the CPS always provides at least one encrypted blob in response 483 to a request, even if there was no call in progress. Otherwise, 484 entities could poll the CPS constantly, or eavesdrop on traffic, to 485 learn whether or not calls were in progress. The CPS MUST generate 486 at least one unique and plausible encrypted response to all retrieval 487 requests, and these dummy encrypted PASSporTs MUST NOT be repeated 488 for later calls. 490 Because the entity placing a call may discover multiple keys 491 associated with the called party number, multiple valid PASSporTs may 492 be stored in the CPS. A particular called party who retrieves 493 PASSporTs from the CPS may have access to only one of those keys. 494 Thus, the presence of one or more PASSporTs that the called party 495 cannot decrypt - which would be indistinguishable from the "dummy" 496 PASSporTS created by the CPS when no calls are in progress - does not 497 entail that there is no call in progress. A retriever likely will 498 need decrypt all PASSporTs retrieved from the CPS, and may find only 499 one that is valid. 501 Note that in out-of-band call forwarding cases, special behavior is 502 required to manage the relationship between PASSporTs using the 503 diversion extension [I-D.ietf-stir-passport-divert]. The originating 504 authentication service would encrypt the initial PASSporT with the 505 public key of the intended destination, but once a call is forwarded, 506 it may go to a destination that does not possess the corresponding 507 private key and thus could not decrypt the original PASSporT. This 508 requires the retargeting entity to generated encrypted PASSporTs that 509 show a secure chain of diversion: a retargeting storer SHOULD use the 510 "opt" extension to "div" specified in [I-D.ietf-stir-passport-divert] 511 in order to nest the original PASSporT within the encrypted diversion 512 PASSporT. 514 7. Solution Architecture 516 In this section, we discuss a high-level architecture for providing 517 the service described in the previous sections. This discussion is 518 deliberately sketchy, focusing on broad concepts and skipping over 519 details. The intent here is merely to provide an overall 520 architecture, not an implementable specification. A more concrete 521 example of how this might be specified is given in Section 9. 523 7.1. Credentials and Phone Numbers 525 We start from the premise of the STIR problem statement [RFC7340] 526 that phone numbers can be associated with credentials which can be 527 used to attest ownership of numbers. For purposes of exposition, we 528 will assume that ownership is associated with the endpoint (e.g., a 529 smartphone) but it might well be associated with a provider or 530 gateway acting for the endpoint instead. It might be the case that 531 multiple entities are able to act for a given number, provided that 532 they have the appropriate authority. [RFC8226] describes a 533 credentials system suitable for this purpose; the question of how an 534 entity is determined to have control of a given number is out of 535 scope for the current document. 537 7.2. Call Flow 539 An overview of the basic calling and verification process is shown 540 below. In this diagram, we assume that Alice has the number 541 +1.111.111.1111 and Bob has the number +2.222.222.2222. 543 Alice Call Placement Service Bob 544 ----------------------------------------------------------------------- 546 Store PASSporT for 2.222.222.2222--> 548 Call from 1.111.111.1111 ---------------------------------------------> 550 <------------- Retrieve PASSporT(s) 551 for 2.222.222.2222? 553 Encrypted PASSporT 554 -(2.222.222.2222,1.111.111.1111)--> 556 [Ring phone with callerid 557 = 1.111.111.1111] 559 When Alice wishes to make a call to Bob, she contacts the CPS and 560 stores an encrypted PASSporT on the CPS indexed under Bob's number. 561 The CPS then awaits retrievals for that number. 563 Once Alice has stored the PASSporT, she then places the call to Bob 564 as usual. At this point, Bob's phone would usually ring and display 565 Alice's number (+1.111.111.1111), which is informed by the existing 566 PSTN mechanisms for relying a calling party number (i.e., the CIN 567 field of the IAM). Instead, Bob's phone transparently contacts the 568 CPS and requests any current PASSporTs for calls to his number. The 569 CPS responds with any such PASSporTs (assuming they exist). If such 570 a PASSpoRT exists, and the verification service in Bob's phone 571 decrypts it using his private key, validates it, then Bob's phone can 572 then present the calling party number information as valid. 573 Otherwise, the call is unverifiable. Note that this does not 574 necessarily mean that the call is bogus; because we expect 575 incremental deployment many legitimate calls will be unverifiable. 577 7.3. Security Analysis 579 The primary attack we seek to prevent is an attacker convincing the 580 callee that a given call is from some other caller C. There are two 581 scenarios to be concerned with: 583 The attacker wishes to impersonate a target when no call from that 584 target is in progress. 586 The attacker wishes to substitute himself for an existing call 587 setup as described in Section 7.4. 589 If an attacker can inject fake PASSporT into the CPS or in the 590 communication from the CPS to the callee, he can mount either attack. 591 As PASSporTs should be digitally signed by an appropriate authority 592 for the number and verified by the callee (see Section 7.1), this 593 should not arise in ordinary operations. For privacy and robustness 594 reasons, using TLS on the originating side when storing the PASSporT 595 at the CPS is recommended. 597 The entire system depends on the security of the credential 598 infrastructure. If the authentication credentials for a given number 599 are compromised, then an attacker can impersonate calls from that 600 number. However, that is no different from in-band [RFC8224] STIR. 602 7.4. Substitution Attacks 604 All that receipt of the PASSporT from the CPS proves to the called 605 party is that Alice is trying to call Bob (or at least was as of very 606 recently) - it does not prove that any particular incoming call is 607 from Alice. Consider the scenario in which we have a service which 608 provides an automatic callback to a user-provided number. In that 609 case, the attacker can try to arrange for a false caller-id value, as 610 shown below: 612 Attacker Callback Service CPS Bob 613 ----------------------------------------------------------------------- 614 Place call to Bob ----------> 616 Store PASSporT for 617 CS:Bob --------------> 619 Call from CS (forged caller-id info) --------------------------------> 621 Call from CS ---------------------------> X 623 <----- Retrieve PASSporT 624 for CS:Bob 626 PASSporT for CS:Bob ---------------------------> 628 [Ring phone with callerid = CS] 630 In order to mount this attack, the attacker contacts the Callback 631 Service (CS) and provides it with Bob's number. This causes the CS 632 to initiate a call to Bob. As before, the CS contacts the CPS to 633 insert an appropriate PASSporT and then initiates a call to Bob. 634 Because it is a valid CS injecting the PASSporT, none of the security 635 checks mentioned above help. However, the attacker simultaneously 636 initiates a call to Bob using forged caller-id information 637 corresponding to the CS. If he wins the race with the CS, then Bob's 638 phone will attempt to verify the attacker's call (and succeed since 639 they are indistinguishable) and the CS's call will go to busy/voice 640 mail/call waiting. Note: in a SIP environment, the callee might 641 notice that there were multiple INVITEs and thus detect this attack. 643 8. Authentication and Verification Service Behavior for Out-of-Band 645 [RFC8224] defines an authentication service and a verification 646 service as functions that act in the context of SIP requests and 647 responses. This specification thus provides a more generic 648 description of authentication service and verification service 649 behavior that might or might not involve any SIP transactions, but 650 depends only on placing a request for communications from an 651 originating identity to one or more destination identities. 653 8.1. Authentication Service 655 Out-of-band authentication services perform steps similar to those 656 defined in [RFC8224] with some exceptions: 658 Step 1: The authentication service MUST determine whether it is 659 authoritative for the identity of the originator of the request, that 660 is, the identity it will populate in the "orig" claim of the 661 PASSporT. It can do so only if it possesses the private key of one 662 or more credentials that can be used to sign for that identity, be it 663 a domain or a telephone number or something other identifier. For 664 example, the authentication service could hold the private key 665 associated with a STIR certificate [RFC8225]. 667 Step 2: The authentication service MUST determine that the originator 668 of communications can claim the originating identity. This is a 669 policy decision made by the authentication service that depends on 670 its relationship to the originator. For an out-of-band application 671 built in to the calling device, for example, this is the same check 672 performed in Step 1: does the calling device have a private key, such 673 one corresponding to a STIR certificate, that can sign for the 674 originating identity? 676 Step 3: The authentication service MUST acquire the public key of the 677 destination, which will be used to encrypt the PASSporT. It must 678 also discover (see Section 10) the CPS associated with the 679 destination. The authentication service may already have the key and 680 destination CPS cached, or may need to query a service to acquire the 681 key. Note that per Section 6.1 the authentication service may also 682 need to acquire a token for PASSporT storage from the CPS upon CPS 683 discovery. It is anticipated that the discovery mechanism (see 684 Section 10) used to find the appropriate CPS will also find the 685 proper key server for the public key of the destination. In some 686 cases, a destination may have multiple public keys associated with 687 it. In that case, the authentication service MUST collect all of 688 those keys. 690 Step 4: The authentication service MUST create the PASSporT object. 691 This includes acquiring the system time to populate the "iat" claim, 692 and populating the "orig" and "dest" claims as described in 693 [RFC8225]. The authentication service MUST then encrypt the 694 PASSporT. If in Step 3 the authentication service discovered 695 multiple public keys for the destination, it MUST create one 696 encrypted copy for each public key it discovered. 698 Finally, the authentication service stores the encrypted PASSporT(s) 699 at the CPS discovered in Step 3. Only after that is completed should 700 any call initiated. Note that a call might be initiated over SIP, 701 and the authentication service would place the same PASSporT in the 702 Identity header field value of the SIP request - though SIP would 703 carry cleartext version rather than an encrypted version sent to the 704 CPS. In that case, out-of-band would serve as a fallback mechanism 705 in case the request was not conveyed over SIP end-to-end. Also, note 706 that the authentication service MAY use a compact form of the 707 PASSporT for a SIP request, whereas the version stored at the CPS 708 MUST always be a full form PASSporT. 710 8.2. Verification Service 712 When a call arrives, an out-of-band verification service performs 713 steps similar to those defined in [RFC8224] with some exceptions: 715 Step 1: The verification service contacts the CPS and requests all 716 current PASSporTs for its destination number. The verification 717 service MUST then decrypt all PASSporTs using its private key. Some 718 PASSporTs may not be decryptable for any number of reasons: they may 719 be intended for a different verification service, or they may be 720 "dummy" values inserted by the CPS for privacy purposes. The next 721 few steps will narrow down the set of PASSporTs that the verification 722 service will examine from that initial decryptable set. 724 Step 2: The verification service MUST determine if any "ppt" 725 extensions in the PASSporTs are unsupported. It takes only the set 726 of supported PASSporTs and applies the next step to them. 728 Step 3: The verification service MUST determine if there is an 729 overlap between the called party number number presented in call 730 signaling and the "orig" field of any decrypted PASSporTs. It takes 731 the set of matching PASSporTs and applies the next step to them. 733 Step 4: The verification service MUST determine if the credentials 734 that signed each PASSporT are valid, and if the verification service 735 trusts the CA that issued the credentials. It takes the set of 736 trusted PASSporTs to the next step. 738 Step 5: The verification service MUST check the freshness of the 739 "iat" claim of each PASSporT. The exact interval of time that 740 determines freshness is left to local policy. It takes the set of 741 fresh PASSporTs to the next step. 743 Step 6: The verification service MUST check the validity of the 744 signature over each PASSporT, as described in described in [RFC8225]. 746 Finally, the verification service will end up with one or more valid 747 PASSporTs corresponding to the call it has received. This document 748 does not prescribe any particular treatment of calls that have valid 749 PASSporTs associated with them. The handling of the message after 750 the verification process depends on how the verification service is 751 implemented and on local policy. However, it is anticipated that 752 local policies could involve making different forwarding decisions in 753 intermediary implementations, or changing how the user is alerted or 754 how identity is rendered in UA implementations. 756 8.3. Gateway Placement Services 758 The out-of-band mechanism also supports the presence of gateway 759 placement services, which do not create PASSporTs themselves, but 760 instead take PASSporTs out of signaling protocols and store them at a 761 CPS before gatewaying to a protocol that cannot carry PASSporTs 762 itself. For example, a SIP gateway that sends calls to the PSTN 763 could receive a call with an Identity header, extract a PASSporT from 764 the Identity header, and store that PASSporT at a CPS. 766 To place a PASSporT at a CPS, a gateway MUST perform Step 3 of 767 Section 8.1 above: that is, it must discover the CPS and public key 768 associated with the destination of the call, and may need to acquire 769 a PASSporT storage token (see Section 6.1). Per Step 3 this may 770 entail discovering several keys. The gateway then collects the in- 771 band PASSporT(s) from the in-band signaling, encrypts the 772 PASSporT(s), and stores them at the CPS. 774 A similar service could be performed by a gateway that retrieves 775 PASSporTs from a CPS and inserts them into signaling protocols that 776 support carrying PASSporTS in-band. This behavior may be defined by 777 future specifications. 779 9. Example HTTPS Interface to the CPS 781 As an rough example, we should a Call Placement Service 782 implementation here which uses a REST API to store and retrieve 783 objects at the CPS. The calling party stores the PASSporT at the CPS 784 prior to initiating the call; the PASSporT is stored at a location at 785 the CPS that corresponds to the called number. Note that it is 786 possible for multiple parties to be calling a number at the same 787 time, and that for called numbers such as large call centers, many 788 PASSporTs could legitimately be stored simultaneously, and it might 789 prove difficult to correlate these with incoming calls. 791 Assume that an authentication service has created the following 792 PASSporT for a call to the telephone number 2.222.222.2222 (note that 793 these are dummy values): 795 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9j 796 ZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InVyaSI6WyJz 797 aXA6YWxpY2VAZXhhbXBsZS5jb20iXX0sImlhdCI6IjE0NDMyMDgzNDUiLCJvcmlnI 798 jp7InRuIjoiMTIxNTU1NTEyMTIifX0.rq3pjT1hoRwakEGjHCnWSwUnshd0-zJ6F1 799 VOgFWSjHBr8Qjpjlk-cpFYpFYsojNCpTzO3QfPOlckGaS6hEck7w 801 Through some discovery mechanism (see Section 10), the authentication 802 service discovers the network location of a web service that acts as 803 the CPS for 2.222.222.2222. Through the same mechanism, we will say 804 that it has also discovered one public key for that destination. It 805 uses that public key to encrypt the PASSporT, resulting in the 806 encrypted PASSporT: 808 rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w 809 MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm 810 nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV 811 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 812 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j 814 Having concluded the numbered steps in Section 8.1, including 815 acquiring any token (per Section 6.1) needed to store the PASSporT at 816 the CPS, the authentication service then stores the encrypted 817 PASSporT: 819 POST /cps/2.222.222.2222/ppts HTTP/1.1 820 Host: cps.example.com 821 Content-Type: application/passport 823 rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w 824 MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm 825 nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV 826 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 827 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j 829 The web service assigns a new location for this encrypted PASSporT in 830 the collection, returning a 201 OK with the location of 831 /cps/2.222.222.2222/ppts/ppt1. Now the authentication service can 832 place the call, which may be signaled by various protocols. Once the 833 call arrives at the terminating side, a verification service 834 interrogates its CPS to ask for the set of incoming calls for its 835 telephone number (2.222.222.2222). 837 GET /cps/2.222.222.2222/ppts 838 Host: cps.example.com 840 This returns to the verification service a list of the PASSporTs 841 currently in the collection, which currently consists of only 842 /cps/2.222.222.2222/ppts/ppt1. The verification service then sends a 843 new GET for /cps/2.222.222.2222/ppts/ppt1/ which yields: 845 HTTP/1.1 200 OK 846 Content-Type: application/passport 847 Link: 849 rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w 850 MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm 851 nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV 852 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 853 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j 855 That concludes Step 1 of Section 8.2; the verification service then 856 goes on to the next step, processing that PASSporT through its 857 various checks. A complete protocol description for CPS interactions 858 is left to future work. 860 10. CPS Discovery 862 In order for the two ends of the out-of-band dataflow to coordinate, 863 they must agree on a way to discover a CPS and retrieve PASSporT 864 objects from it based solely on the rendezvous information available: 865 the calling party number and the called number. Because the storage 866 of PASSporTs in this architecture is indexed by the called party 867 number, it makes sense to discover a CPS based on the called party 868 number as well. There are a number of potential service discovery 869 mechanisms that could be used for this purpose. The means of service 870 discovery may vary by use case. 872 Although the discussion above is written in terms of a single CPS, 873 having a significant fraction of all telephone calls result in 874 storing and retrieving PASSporTs at a single monolithic CPS has 875 obvious scaling problems, and would as well allow the CPS to gather 876 metadata about a very wide set of callers and callees. These issues 877 can be alleviated by operational models with a federated CPS; any 878 service discovery mechanism for out-of-band STIR should enable 879 federation of the CPS function. 881 Some service discovery possibilities under consideration include the 882 following: 884 If a credential lookup service is already available (see 885 Section 11), the CPS location can also be recorded in the callee's 886 credentials; an extension to [RFC8226] could for example provide a 887 link to the location of the CPS where PASSporTs should be stored 888 for a destination. 890 There exist a number of common directory systems that might be 891 used to translate telephone numbers into the URIs of a CPS. ENUM 892 [RFC6116] is commonly implemented, though no "golden root" central 893 ENUM administration exists that could be easily reused today to 894 help the endpoints discover a common CPS. Other protocols 895 associated with queries for telephone numbers, such as the TeRI 896 [I-D.peterson-modern-teri] protocol, could also serve for this 897 application. 899 Another possibility is to use a single distributed service for 900 this function. VIPR [I-D.rosenberg-dispatch-vipr-overview] 901 proposed a RELOAD [RFC6940] usage for telephone numbers to help 902 direct calls to enterprises on the Internet. It would be possible 903 to describe a similar RELOAD usage to identify the CPS where calls 904 for a particular telephone number should be stored. One advantage 905 that the STIR architecture has over VIPR is that it assumes a 906 credential system that proves authority over telephone numbers; 907 those credentials could be used to determine whether or not a CPS 908 could legitimately claim to be the proper store for a given 909 telephone number. 911 This document does not prescribe any single way to do service 912 discovery for a CPS; it is envisioned that initial deployments will 913 provision at the AS and VS. 915 11. Credential Lookup 917 In order to encrypt a PASSporT (see Section 6.1), the caller needs 918 access to the callee's credentials (specifically their public key). 919 This requires some sort of directory/lookup system. This document 920 does not specify any particular scheme, but a list of requirements 921 would be something like: 923 Obviously, if there is a single central database and the caller and 924 callee each contact it in real time to determine the other's 925 credentials, then this represents a real privacy risk, as the central 926 database learns about each call. A number of mechanisms are 927 potentially available to mitigate this: 929 Have endpoints pre-fetch credentials for potential counterparties 930 (e.g., their address book or the entire database). 932 Have caching servers in the user's network that proxy their 933 fetches and thus conceal the relationship between the user and the 934 credentials they are fetching. 936 Clearly, there is a privacy/timeliness tradeoff in that getting up- 937 to-date knowledge about credential validity requires contacting the 938 credential directory in real-time (e.g., via OCSP). This is somewhat 939 mitigated for the caller's credentials in that he can get short-term 940 credentials right before placing a call which only reveals his 941 calling rate, but not who he is calling. Alternately, the CPS can 942 verify the caller's credentials via OCSP, though of course this 943 requires the callee to trust the CPS's verification. This approach 944 does not work as well for the callee's credentials, but the risk 945 there is more modest since an attacker would need to both have the 946 callee's credentials and regularly poll the database for every 947 potential caller. 949 We consider the exact best point in the tradeoff space to be an open 950 issue. 952 12. Acknowledgments 954 The ideas in this document come out of discussions with Richard 955 Barnes and Cullen Jennings. We'd also like to thank Robert Sparks 956 for helpful suggestions. 958 13. IANA Considerations 960 This memo includes no request to IANA. 962 14. Security Considerations 964 This entire document is about security, but the detailed security 965 properties depend on having a single concrete scheme to analyze. 967 15. Informative References 969 [I-D.ietf-stir-passport-divert] 970 Peterson, J., "PASSporT Extension for Diverted Calls", 971 draft-ietf-stir-passport-divert-02 (work in progress), 972 March 2018. 974 [I-D.peterson-modern-teri] 975 Peterson, J., "An Architecture and Information Model for 976 Telephone-Related Information (TeRI)", draft-peterson- 977 modern-teri-04 (work in progress), March 2018. 979 [I-D.rosenberg-dispatch-vipr-overview] 980 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 981 "Verification Involving PSTN Reachability: Requirements 982 and Architecture Overview", draft-rosenberg-dispatch-vipr- 983 overview-04 (work in progress), October 2010. 985 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 986 Requirement Levels", BCP 14, RFC 2119, 987 DOI 10.17487/RFC2119, March 1997, 988 . 990 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 991 A., Peterson, J., Sparks, R., Handley, M., and E. 992 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 993 DOI 10.17487/RFC3261, June 2002, 994 . 996 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 997 Uniform Resource Identifiers (URI) Dynamic Delegation 998 Discovery System (DDDS) Application (ENUM)", RFC 6116, 999 DOI 10.17487/RFC6116, March 2011, 1000 . 1002 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 1003 and H. Schulzrinne, "REsource LOcation And Discovery 1004 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 1005 January 2014, . 1007 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1008 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1009 2014, . 1011 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1012 Telephone Identity Problem Statement and Requirements", 1013 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1014 . 1016 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1017 "Authenticated Identity Management in the Session 1018 Initiation Protocol (SIP)", RFC 8224, 1019 DOI 10.17487/RFC8224, February 2018, 1020 . 1022 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1023 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1024 . 1026 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1027 Credentials: Certificates", RFC 8226, 1028 DOI 10.17487/RFC8226, February 2018, 1029 . 1031 Authors' Addresses 1033 Eric Rescorla 1034 Mozilla 1036 Email: ekr@rtfm.com 1037 Jon Peterson 1038 Neustar, Inc. 1039 1800 Sutter St Suite 570 1040 Concord, CA 94520 1041 US 1043 Email: jon.peterson@neustar.biz