idnits 2.17.1 draft-ietf-stir-oob-07.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 (March 9, 2020) is 1507 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Disconnect' is mentioned on line 721, but not defined == Outdated reference: A later version (-09) exists of draft-ietf-stir-passport-divert-07 == Outdated reference: A later version (-15) exists of draft-ietf-tls-subcerts-06 -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). 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: Informational J. Peterson 5 Expires: September 10, 2020 Neustar 6 March 9, 2020 8 STIR Out-of-Band Architecture and Use Cases 9 draft-ietf-stir-oob-07 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, or cannot reliably deliver SIP header fields end-to-end. This 18 document describes use cases that require the delivery of PASSporT 19 objects outside of the signaling path, and defines architectures and 20 semantics to provide this functionality. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on September 10, 2020. 39 Copyright Notice 41 Copyright (c) 2020 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (https://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Operating Environments . . . . . . . . . . . . . . . . . . . 4 59 4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 7 62 5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 7 63 5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7 64 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 8 65 5.5. Case 5: Enterprise Call Center . . . . . . . . . . . . . 9 66 6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 9 67 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 10 68 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 11 69 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 12 70 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 71 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 13 72 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 73 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 14 74 7.5. Rate Control for CPS Storage . . . . . . . . . . . . . . 16 75 8. Authentication and Verification Service Behavior for Out-of- 76 Band . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 77 8.1. Authentication Service (AS) . . . . . . . . . . . . . . . 17 78 8.2. Verification Service (VS) . . . . . . . . . . . . . . . . 18 79 8.3. Gateway Placement Services . . . . . . . . . . . . . . . 19 80 9. Example HTTPS Interface to the CPS . . . . . . . . . . . . . 20 81 10. CPS Discovery . . . . . . . . . . . . . . . . . . . . . . . . 21 82 11. Encryption Key Lookup . . . . . . . . . . . . . . . . . . . . 23 83 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 84 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 85 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 24 86 15. Security Considerations . . . . . . . . . . . . . . . . . . . 25 87 16. Informative References . . . . . . . . . . . . . . . . . . . 26 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 28 90 1. Introduction 92 The STIR problem statement [RFC7340] describes widespread problems 93 enabled by impersonation in the telephone network, including illegal 94 robocalling, voicemail hacking, and swatting. As telephone services 95 are increasingly migrating onto the Internet, and using Voice over IP 96 (VoIP) protocols such as SIP [RFC3261], it is necessary for these 97 protocols to support stronger identity mechanisms to prevent 98 impersonation. For example, [RFC8224] defines a SIP Identity header 99 field capable of carrying PASSporT [RFC8225] objects in SIP as a 100 means to cryptographically attest that the originator of a telephone 101 call is authorized to use the calling party number (or, for native 102 SIP cases, SIP URI) associated with the originator of the call. 104 Not all telephone calls use SIP today, however, and even those that 105 do use SIP do not always carry SIP signaling end-to-end. Calls from 106 telephone numbers still routinely traverse the Public Switched 107 Telephone Network (PSTN) at some point. Broadly, calls fall into one 108 of three categories: 110 1. One or both of the endpoints is actually a PSTN endpoint. 112 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the 113 call transits the PSTN at some point. 115 3. Non-PSTN calls which do not transit the PSTN at all (such as 116 native SIP end-to-end calls). 118 The first two categories represent the majority of telephone calls 119 associated with problems like illegal robocalling: many robocalls 120 today originate on the Internet but terminate at PSTN endpoints. 121 However, the core network elements that operate the PSTN are legacy 122 devices that are unlikely to be upgradable at this point to support 123 an in-band authentication system. As such, those devices largely 124 cannot be modified to pass signatures originating on the Internet--or 125 indeed any inband signaling data--intact. Even if fields for 126 tunneling arbitrary data can be found in traditional PSTN signaling, 127 in some cases legacy elements would strip the signatures from those 128 fields; in others, they might damage them to the point where they 129 cannot be verified. For those first two categories above, any in- 130 band authentication scheme does not seem practical in the current 131 environment. 133 While the core network of the PSTN remains fixed, the endpoints of 134 the telephone network are becoming increasingly programmable and 135 sophisticated. Landline "plain old telephone service" deployments, 136 especially in the developed world, are shrinking, and increasingly 137 being replaced by three classes of intelligent devices: smart phones, 138 IP PBXs, and terminal adapters. All three are general purpose 139 computers, and typically all three have Internet access as well as 140 access to the PSTN; they may be used for residential, mobile, or 141 enterprise telephone services. Additionally, various kinds of 142 gateways increasingly front for deployments of legacy PBX and PSTN 143 switches. All of this provides a potential avenue for building an 144 authentication system that implements stronger identity while leaving 145 PSTN systems intact. 147 This capability also provides an ideal transitional technology while 148 in-band STIR adoption is ramping up. It permits early adopters to 149 use the technology even when intervening network elements are not yet 150 STIR-aware, and through various kinds of gateways, it may allow 151 providers with a significant PSTN investment to still secure their 152 calls with STIR. 154 The techniques described in this document therefore build on the 155 PASSporT [RFC8225] mechanism and the work of [RFC8224] to describe a 156 way that a PASSporT object created in the originating network of a 157 call can reach the terminating network even when it cannot be carried 158 end-to-end in-band in the call signaling. This relies on a new 159 service defined in this document called a Call Placement Service 160 (CPS) that permits the PASSporT object to be stored during call 161 processing and retrieved for verification purposes. 163 Potential implementors should note that this document merely defines 164 the operating environments in which this out-of-band STIR mechanism 165 is intended to operate. It provides use cases, gives a broad 166 description of the components and a potential solution architecture. 167 Various environments may have their own security requirements: a 168 public deployment of out-of-band STIR faces far greater challenges 169 than a constrained intranetwork deployment. To flesh out the storage 170 and retrieval of PASSporTs in the CPS within this context, this 171 document includes a strawman protocol suitable for that purpose. 172 Deploying this framework in any given environment would require 173 additional specification outside the scope of the current document. 175 2. Terminology 177 TThe key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 179 "OPTIONAL" in this document are to be interpreted as described in BCP 180 14 [RFC2119] [RFC8174] when, and only when, they appear in all 181 capitals, as shown here. 183 3. Operating Environments 185 This section describes the environments in which the proposed out-of- 186 band STIR mechanism is intended to operate. In the simplest setting, 187 Alice is calling Bob, and her call is routed through some set of 188 gateways and/or the PSTN which do not support end-to-end delivery of 189 STIR. Both Alice and Bob have smart devices which can access the 190 Internet (perhaps enterprise devices, or even end user ones), but 191 they do not have a clear telephone signaling connection between them: 193 Alice cannot inject any data into signaling which Bob can read, with 194 the exception of the asserted destination and origination E.164 195 numbers. The calling party number might originate from her own 196 device or from the network. These numbers are effectively the only 197 data that can be used for coordination between the endpoints. 199 +---------+ 200 / \ 201 +--- +---+ 202 +----------+ / \ +----------+ 203 | | | Gateways | | | 204 | Alice |<----->| and/or |<----->| Bob | 205 | (caller) | | PSTN | | (callee) | 206 +----------+ \ / +----------+ 207 +--- +---+ 208 \ / 209 +---------+ 211 In a more complicated setting, Alice and/or Bob may not have a smart 212 or programmable device, but instead just a traditional telephone. 213 However, one or both of them are behind a STIR-aware gateway that can 214 participate in out-of-band coordination, as shown below: 216 +---------+ 217 / \ 218 +--- +---+ 219 +----------+ +--+ / \ +--+ +----------+ 220 | | | | | Gateways | | | | | 221 | Alice |<-|GW|->| and/or |<-|GW|->| Bob | 222 | (caller) | | | | PSTN | | | | (callee) | 223 +----------+ +--+ \ / +--+ +----------+ 224 +--- +---+ 225 \ / 226 +---------+ 228 In such a case, Alice might have an analog (e.g., PSTN) connection to 229 her gateway/ switch which is responsible for her identity. 230 Similarly, the gateway would verify Alice's identity, generate the 231 right calling party number information and provide that number to Bob 232 using ordinary Plain Ol' Telephone Service (POTS) mechanisms. 234 4. Dataflows 236 Because in these operating environments endpoints cannot pass 237 cryptographic information to one another directly through signaling, 238 any solution must involve some rendezvous mechanism to allow 239 endpoints to communicate. We call this rendezvous service a "call 240 placement service" (CPS), a service where a record of call placement, 241 in this case a PASSporT, can be stored for future retrieval. In 242 principle this service could communicate any information, but 243 minimally we expect it to include a full-form PASSporT that attests 244 the caller, callee, and the time of the call. The callee can use the 245 existence of a PASSporT for a given incoming call as rough validation 246 of the asserted origin of that call. (See Section 11 for limitations 247 of this design.) 249 This architecture does not mandate that any particular sort of entity 250 operate a CPS, or mandate any means to discover a CPS. A CPS could 251 be run internally within a network, or made publicly available. One 252 or more CPSes could be run by a carrier, as repositories for 253 PASSporTs for calls sent to its customers, or a CPS could be built-in 254 to an enterprise PBX, or even a smartphone. To the degree possible, 255 it is specified here generically, as an idea that may have 256 applicability to a variety of STIR deployments. 258 There are roughly two plausible dataflow architectures for the CPS: 260 1. The callee registers with the CPS. When the caller wishes to 261 place a call to the callee, it sends the PASSporT to the CPS, 262 which immediately forwards it to the callee, or, 264 2. The caller stores the PASSporT with the CPS at the time of call 265 placement. When the callee receives the call, it contacts the 266 CPS and retrieves the PASSporT. 268 While the first architecture is roughly isomorphic to current VoIP 269 protocols, it shares their drawbacks. Specifically, the callee must 270 maintain a full-time connection to the CPS to serve as a notification 271 channel. This comes with the usual networking costs to the callee 272 and is especially problematic for mobile endpoints. Indeed, if the 273 endpoints had the capabilities to implement such an architecture, 274 they could surely just use SIP or some other protocol to set up a 275 secure session; even if the media were going through the traditional 276 PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we 277 focus on the second architecture in which the PSTN incoming call 278 serves as the notification channel and the callee can then contact 279 the CPS to retrieve the PASSporT. In specialized environments, for 280 example a call center that receives a large volume of incoming calls 281 that originated in the PSTN, the notification channel approach might 282 be viable. 284 5. Use Cases 286 The following are the motivating use cases for this mechanism. Bear 287 in mind that just as in [RFC8224] there may be multiple Identity 288 headers in a single SIP INVITE, so there may be multiple PASSporTs in 289 this out-of-band mechanism associated with a single call. For 290 example, a SIP user agent might create a PASSporT for a call with an 291 end user credential, and as the call exits the originating 292 administrative domain the network authentication service might create 293 its own PASSporT for the same call. As such, these use cases may 294 overlap in the processing of a single call. 296 5.1. Case 1: VoIP to PSTN Call 298 A call originates in a SIP environment in a STIR-aware administrative 299 domain. The local authentication service for that administrative 300 domain creates a PASSporT which is carried in band in the call per 301 [RFC8224]. The call is routed out of the originating administrative 302 domain and reaches a gateway to the PSTN. Eventually, the call will 303 terminate on a mobile smartphone that supports this out-of-band 304 mechanism. 306 In this use case, the originating authentication service can store 307 the PASSporT with the appropriate CPS (per the practices of 308 Section 10) for the target telephone number as a fallback in case SIP 309 signaling will not reach end-to-end. When the destination mobile 310 smartphone receives the call over the PSTN, it consults the CPS and 311 discovers a PASSporT from the originating telephone number waiting 312 for it. It uses this PASSporT to verify the calling party number. 314 5.2. Case 2: Two Smart PSTN endpoints 316 A call originates with an enterprise PBX that has both Internet 317 access and a built-in gateway to the PSTN, which communicates through 318 traditional telephone signaling protocols. The PBX immediately 319 routes the call to the PSTN, but before it does, it provisions a 320 PASSporT on the CPS associated with the target telephone number. 322 After normal PSTN routing, the call lands on a smart mobile handset 323 that supports the STIR out-of-band mechanism. It queries the 324 appropriate CPS over the Internet to determine if a call has been 325 placed to it by a STIR-aware device. It finds the PASSporT 326 provisioned by the enterprise PBX and uses it to verify the calling 327 party number. 329 5.3. Case 3: PSTN to VoIP Call 331 A call originates with an enterprise PBX that has both Internet 332 access and a built-in gateway to the PSTN. It will immediately route 333 the call to the PSTN, but before it does, it provisions a PASSporT 334 with the CPS associated with the target telephone number. However, 335 it turns out that the call will eventually route through the PSTN to 336 an Internet gateway, which will translate this into a SIP call and 337 deliver it to an administrative domain with a STIR verification 338 service. 340 In this case, there are two subcases for how the PASSporT might be 341 retrieved. In subcase 1, the Internet gateway that receives the call 342 from the PSTN could query the appropriate CPS to determine if the 343 original caller created and provisioned a PASSporT for this call. If 344 so, it can retrieve the PASSporT and, when it creates a SIP INVITE 345 for this call, add a corresponding Identity header field per 346 [RFC8224]. When the SIP INVITE reaches the destination 347 administrative domain, it will be able to verify the PASSporT 348 normally. Note that to avoid discrepancies with the Date header 349 field value, only full-form PASSporT should be used for this purpose. 350 In subcase 2, the gateway does not retrieve the PASSporT itself, but 351 instead the verification service at the destination administrative 352 domain does so. Subcase 1 would perhaps be valuable for deployments 353 where the destination administrative domain supports in-band STIR but 354 not out-of-band STIR. 356 5.4. Case 4: Gateway Out-of-band 358 A call originates in the SIP world in a STIR-aware administrative 359 domain. The local authentication service for that administrative 360 domain creates a PASSporT which is carried in band in the call per 361 [RFC8224]. The call is routed out of the originating administrative 362 domain and eventually reaches a gateway to the PSTN. 364 In this case, the originating authentication service does not support 365 the out-of-band mechanism, so instead the gateway to the PSTN 366 extracts the PASSporT from the SIP request and provisions it to the 367 CPS. (When the call reaches the gateway to the PSTN, the gateway 368 might first check the CPS to see if a PASSporT object had already 369 been provisioned for this call, and only provision a PASSporT if none 370 is present). 372 Ultimately, the call may terminate on the PSTN, or be routed back to 373 a SIP environment. In the former case, perhaps the destination 374 endpoint queries the CPS to retrieve the PASSporT provisioned by the 375 first gateway. Or if the call ultimately returns to a SIP 376 environment, it might be the gateway from the PSTN back to the 377 Internet that retrieves the PASSporT from the CPS and attaches it to 378 the new SIP INVITE it creates, or it might be the terminating 379 administrative domain's verification service that checks the CPS when 380 an INVITE arrives with no Identity header field. Either way the 381 PASSporT can survive the gap in SIP coverage caused by the PSTN leg 382 of the call. 384 5.5. Case 5: Enterprise Call Center 386 A call originates from a mobile user, and a STIR authentication 387 service operated by their carrier creates a PASSporT for the call. 388 As the carrier forwards the call via SIP, it attaches the PASSporT to 389 the SIP call with an Identity header field. As a fallback in case 390 the call will not go end-to-end over SIP, the carrier also stores the 391 PASSporT in a CPS. 393 The call is then routed over SIP for a time, before it transitions to 394 the PSTN and ultimately is handled by a legacy PBX at a high-volume 395 call center. The call center supports the out-of-band service, and 396 has a high-volume interface to a CPS to retrieve PASSporTs for 397 incoming calls; agents at the call center use a general purpose 398 computer to manage inbound calls and can receive STIR notifications 399 through it. When the PASSporT arrives at the CPS, it is sent through 400 a subscription/notification interface to a system that can correlate 401 incoming calls with valid PASSporTs. The call center agent sees that 402 a valid call from the originating number has arrived. 404 6. Storing and Retrieving PASSporTs 406 The use cases show a variety of entities accessing the CPS to store 407 and retrieve PASSporTs. The question of how the CPS authorizes the 408 storage and retrieval of PASSporT is thus a key design decision in 409 the architecture. The STIR architecture assumes that service 410 providers and in some cases end user devices will have credentials 411 suitable for attesting authority over telephone numbers per 412 [RFC8226]. These credentials provide the most obvious way that a CPS 413 can authorize the storage and retrieval of PASSporTs. However, as 414 use cases 3, 4 and 5 in Section 5 show, it may sometimes make sense 415 for the entity storing or retrieving PASSporTs to be an intermediary 416 rather than a device associated with either the originating or 417 terminating side of a call, and those intermediaries often would not 418 have access to STIR credentials covering the telephone numbers in 419 question. Requiring authorization based on a credential to store 420 PASSporTs is therefore undesirable, though potentially acceptable if 421 sufficient steps are taken to mitigate any privacy risk of leaking 422 data. 424 It is an explicit design goal of this mechanism to minimize the 425 potential privacy exposure of using a CPS. Ideally, the out-of-band 426 mechanism should not result in a worse privacy situation than in-band 427 [RFC8224] STIR: for in-band, we might say that a SIP entity is 428 authorized to receive a PASSporT if it is an intermediate or final 429 target of the routing of a SIP request. As the originator of a call 430 cannot necessarily predict the routing path a call will follow, an 431 out-of-band mechanism could conceivably even improve on the privacy 432 story. 434 Broadly, the architecture recommended here thus is one focused on 435 permitting any entity to store encrypted PASSporTs at the CPS, 436 indexed under the called number. PASSporTs will be encrypted with a 437 public key associated with the called number, so these PASSporTs may 438 safely be retrieved by any entity, as only holders of the 439 corresponding private key will be able to decrypt the PASSporT. This 440 also prevents the CPS itself from learning the contents of PASSporTs, 441 and thus metadata about calls in progress, which makes the CPS a less 442 attractive target for pervasive monitoring (see [RFC7258]). As a 443 first step, transport-level security can provide confidentiality from 444 eavesdroppers for both the storing and retrieval of PASSporTs. To 445 bolster the privacy story, prevent denial-of-service flooding of the 446 CPS, and to complicate traffic analysis, a few additional mechanisms 447 are also recommended below. 449 6.1. Storage 451 There are a few dimensions to authorizing the storage of PASSporTs. 452 Encrypting PASSporTs prior to storage entails that a CPS has no way 453 to tell if a PASSporT is valid; it simply conveys encrypted blocks 454 that it cannot access itself, and can make no authorization decision 455 based on the PASSporT contents. There is certainly no prospect for 456 the CPS to verify the PASSporTs itself. 458 Note that this architecture requires clients that store PASSporTs to 459 have access to an encryption key associated with the intended called 460 party to be used to encrypt the PASSporT. Discovering this key 461 requires the existence of a key lookup service (see Section 11); 462 depending on how the CPS is architected, however, some kind of key 463 store or repository could be implemented adjacent to it, and perhaps 464 even incorporated into its operation. Key discovery is made more 465 complicated by the fact that there can potentially be multiple 466 entities that have authority over a telephone number: a carrier, a 467 reseller, an enterprise, and an end user might all have credentials 468 permitting them to attest that they are allowed to originate calls 469 from a number, say. PASSporTs for out-of-band use therefore might 470 need to be encrypted with multiple keys in the hopes that one will be 471 decipherable by the relying party. 473 Again, the most obvious way to authorize storage is to require the 474 originator to authenticate themselves to the CPS with their STIR 475 credential. However, since the call is indexed at the CPS under the 476 called number, this can weaken the privacy story of the architecture, 477 as it reveals to the CPS both the identity of the caller and the 478 callee. Moreover, it does not work for the gateway use cases 479 described above; to support those use cases, we must effectively 480 allow any entity to store PASSporTs at a CPS. This does not degrade 481 the anti-impersonation security of STIR, because entities who do not 482 possess the necessary credentials to sign the PASSporT will not be 483 able to create PASSporTs that will be treated as valid by verifiers. 484 In this architecture, it does not matter whether the CPS received a 485 PASSporT from the authentication service that created it or from an 486 intermediary gateway downstream in the routing path as in case 4 487 above. However, if literally anyone can store PASSporTs in the CPS, 488 an attacker could easily flood the CPS with millions of bogus 489 PASSporTs indexed under a calling number, and thereby prevent the 490 called party from finding a valid PASSporT for an incoming call 491 buried in a haystack of fake entries. 493 The solution architecture must therefore include some sort of traffic 494 control system to prevent flooding. Preferably, this should not 495 require authenticating the source, as this will reveal to the CPS 496 both the source and destination of traffic. A potential solution is 497 discussed below in Section 7.5. 499 6.2. Retrieval 501 For retrieval of PASSporTs, this architecture assumes that clients 502 will contact the CPS through some sort of polling or notification 503 interface to receive all current PASSporTs for calls destined to a 504 particular telephone number, or block of numbers. 506 As PASSporTs stored at the CPS are encrypted with a key belonging to 507 the intended destination, the CPS can safely allow anyone to download 508 PASSporTs for a called number without much fear of compromising 509 private information about calls in progress - provided that the CPS 510 always returns at least one encrypted blob in response to a request, 511 even if there was no call in progress. Otherwise, entities could 512 poll the CPS constantly, or eavesdrop on traffic, to learn whether or 513 not calls were in progress. The CPS MUST generate at least one 514 unique and plausible encrypted response to all retrieval requests, 515 and these dummy encrypted PASSporTs MUST NOT be repeated for later 516 calls. An encryption scheme needs to be carefully chosen to make 517 messages look indistinguishable from random when encrypted, so that 518 information about called party is not discoverable from legitimate 519 encrypted PASSporTs. 521 Because the entity placing a call may discover multiple keys 522 associated with the called party number, multiple valid PASSporTs may 523 be stored in the CPS. A particular called party who retrieves 524 PASSporTs from the CPS may have access to only one of those keys. 525 Thus, the presence of one or more PASSporTs that the called party 526 cannot decrypt - which would be indistinguishable from the "dummy" 527 PASSporTS created by the CPS when no calls are in progress - does not 528 entail that there is no call in progress. A retriever likely will 529 need to decrypt all PASSporTs retrieved from the CPS, and may find 530 only one that is valid. 532 In order to prevent the CPS from learning the numbers that a callee 533 controls, callees might also request PASSporTs for numbers that they 534 do not own, that they have no hope of decrypting. Implementations 535 could even allow a callee to request PASSporTs for a range or prefix 536 of numbers: a trade-off where that callee is willing to sift through 537 bulk quantities of undecryptable PASSporTs for the sake of hiding 538 from the CPS what numbers it controls. 540 Note that in out-of-band call forwarding cases, special behavior is 541 required to manage the relationship between PASSporTs using the 542 diversion extension [I-D.ietf-stir-passport-divert]. The originating 543 authentication service would encrypt the initial PASSporT with the 544 public encryption key of the intended destination, but once a call is 545 forwarded, it may go to a destination that does not possess the 546 corresponding private key and thus could not decrypt the original 547 PASSporT. This requires the retargeting entity to generate encrypted 548 PASSporTs that show a secure chain of diversion: a retargeting storer 549 SHOULD use the "div-o" PASSporT type, with its "opt" extension, as 550 specified in [I-D.ietf-stir-passport-divert] in order to nest the 551 original PASSporT within the encrypted diversion PASSporT. 553 7. Solution Architecture 555 In this section, we discuss a high-level architecture for providing 556 the service described in the previous sections. This discussion is 557 deliberately sketchy, focusing on broad concepts and skipping over 558 details. The intent here is merely to provide an overall 559 architecture, not an implementable specification. A more concrete 560 example of how this might be specified is given in Section 9. 562 7.1. Credentials and Phone Numbers 564 We start from the premise of the STIR problem statement [RFC7340] 565 that phone numbers can be associated with credentials which can be 566 used to attest ownership of numbers. For purposes of exposition, we 567 will assume that ownership is associated with the endpoint (e.g., a 568 smartphone) but it might well be associated with a provider or 569 gateway acting for the endpoint instead. It might be the case that 570 multiple entities are able to act for a given number, provided that 571 they have the appropriate authority. [RFC8226] describes a 572 credential system suitable for this purpose; the question of how an 573 entity is determined to have control of a given number is out of 574 scope for the current document. 576 7.2. Call Flow 578 An overview of the basic calling and verification process is shown 579 below. In this diagram, we assume that Alice has the number 580 +1.111.555.1111 and Bob has the number +2.222.555.2222. 582 Alice Call Placement Service Bob 583 -------------------------------------------------------------------- 585 Store Encrhypted PASSporT for 2.222.555.2222 -> 587 Call from 1.111.555.1111 ------------------------------------------> 589 <-------------- Request PASSporT(s) 590 for 2.222.555.2222 592 Obtain Encrypted PASSporT --------> 593 (2.222.555.2222, 1.111.555.1111) 595 [Ring phone with verified callerid 596 = 1.111.555.1111] 598 When Alice wishes to make a call to Bob, she contacts the CPS and 599 stores an encrypted PASSporT on the CPS indexed under Bob's number. 600 The CPS then awaits retrievals for that number. 602 When Alice places the call, Bob's phone would usually ring and 603 display Alice's number (+1.111.555.1111), which is informed by the 604 existing PSTN mechanisms for relaying a calling party number (e.g., 605 the CIN field of the IAM). Instead, Bob's phone transparently 606 contacts the CPS and requests any current PASSporTs for calls to his 607 number. The CPS responds with any such PASSporTs (or dummy PASSporTs 608 if no relevant ones are currently stored). If such a PASSporT 609 exists, and the verification service in Bob's phone decrypts it using 610 his private key, validates it, then Bob's phone can present the 611 calling party number information as valid. Otherwise, the call is 612 unverifiable. Note that this does not necessarily mean that the call 613 is bogus; because we expect incremental deployment, many legitimate 614 calls will be unverifiable. 616 7.3. Security Analysis 618 The primary attack we seek to prevent is an attacker convincing the 619 callee that a given call is from some other caller C. There are two 620 scenarios to be concerned with: 622 1. The attacker wishes to impersonate a target when no call from 623 that target is in progress. 625 2. The attacker wishes to substitute himself for an existing call 626 setup. 628 If an attacker can inject fake PASSporTs into the CPS or in the 629 communication from the CPS to the callee, he can mount either attack. 630 As PASSporTs should be digitally signed by an appropriate authority 631 for the number and verified by the callee (see Section 7.1), this 632 should not arise in ordinary operations. Any attacker who is aware 633 of calls in progress can attempt to mount a race to subtitute 634 themselves as described in Section 7.4. For privacy and robustness 635 reasons, using TLS [RFC8446] on the originating side when storing the 636 PASSporT at the CPS is RECOMMENDED. 638 The entire system depends on the security of the credential 639 infrastructure. If the authentication credentials for a given number 640 are compromised, then an attacker can impersonate calls from that 641 number. However, that is no different from in-band [RFC8224] STIR. 643 A secondary attack we must also prevent is denial-of-service against 644 the CPS, which requires some form of rate control solution that will 645 not degrade the privacy properties of the architecture. 647 7.4. Substitution Attacks 649 All the receipt of the PASSporT from the CPS proves to the called 650 party is that Alice is trying to call Bob (or at least was as of very 651 recently) - it does not prove that any particular incoming call is 652 from Alice. Consider the scenario in which we have a service which 653 provides an automatic callback to a user-provided number. In that 654 case, the attacker can try to arrange for a false caller-id value, as 655 shown below: 657 Attacker Callback Service CPS Bob 658 -------------------------------------------------------------------- 659 Place call to Bob ----------> 660 (from 111.555.1111) 661 Store PASSporT for 662 CS:Bob -------------> 664 Call from Attacker (forged CS caller-id info) --------------------> 666 Call from CS ------------------------> X 668 <-- Retrieve PASSporT 669 for CS:Bob 671 PASSporT for CS:Bob ------------------------> 673 [Ring phone with callerid = 674 111.555.1111] 676 In order to mount this attack, the attacker contacts the Callback 677 Service (CS) and provides it with Bob's number. This causes the CS 678 to initiate a call to Bob. As before, the CS contacts the CPS to 679 insert an appropriate PASSporT and then initiates a call to Bob. 680 Because it is a valid CS injecting the PASSporT, none of the security 681 checks mentioned above help. However, the attacker simultaneously 682 initiates a call to Bob using forged caller-id information 683 corresponding to the CS. If he wins the race with the CS, then Bob's 684 phone will attempt to verify the attacker's call (and succeed since 685 they are indistinguishable) and the CS's call will go to busy/voice 686 mail/call waiting. 688 In order to prevent a passive attacker from using traffic analysis or 689 similar means to learn precisely when a call is placed, it is 690 essential that the connection between the caller and the CPS be 691 encrypted as recommended above. Authentication services could store 692 dummy PASSporTs at the CPS at random intervals in order to make it 693 more difficult for an eavesdropper to use traffic analysis to 694 determine that a call was about to be placed. 696 Note that in a SIP environment, the callee might notice that there 697 were multiple INVITEs and thus detect this attack, but in some PSTN 698 interworking scenarios, or highly intermediated networks, only one 699 call setup attempt will reach the target. Also note that the success 700 of this substitution attack depends on the attacker landing their 701 call within the narrow window that the PASSporT is retained in the 702 CPS, so shortening that window will reduce the opportunity for the 703 attack. Finally, smart endpoints could implement some sort of state 704 coordination to ensure that both sides believe the call is in 705 progress, though methods of supporting that are outside the scope of 706 this document. 708 7.5. Rate Control for CPS Storage 710 In order to prevent the flooding of a CPS with bogus PASSporTs, we 711 propose the use of "blind signatures" (see [RFC5636]). A sender will 712 initially authenticate to the CPS using its STIR credentials, and 713 acquire a signed token from the CPS that will be presented later when 714 storing a PASSporT. The flow looks as follows: 716 Sender CPS 718 Authenticate to CPS ---------------------> 719 Blinded(K_temp) -------------------------> 720 <------------- Sign(K_cps, Blinded(K_temp)) 721 [Disconnect] 723 Sign(K_cps, K_temp) 724 Sign(K_temp, E(K_receiver, PASSporT)) ---> 726 At an initial time when no call is yet in progress, a potential 727 client connects to the CPS, authenticates, and sends a blinded 728 version of a freshly generated public key. The CPS returns a signed 729 version of that blinded key. The sender can then unblind the key and 730 gets a signature on K_temp from the CPS. 732 Then later, when a client wants to store a PASSporT, it connects to 733 the CPS anonymously (preferably over a network connection that cannot 734 be correlated with the token acquisition) and sends both the signed 735 K_temp and its own signature over the encrypted PASSporT. The CPS 736 verifies both signatures and if they verify, stores the encrypted 737 passport (discarding the signatures). 739 This design lets the CPS rate limit how many PASSporTs a given sender 740 can store just by counting how many times K_temp appears; perhaps CPS 741 policy might reject storage attempts and require acquisition of a new 742 K_temp after storing more than a certain number of PASSporTs indexed 743 under the same destination number in a short interval. This does not 744 of course allow the CPS to tell when bogus data is being provisioned 745 by an attacker, simply the rate at which data is being provisioned. 746 Potentially, feedback mechanisms could be developed that would allow 747 the called parties to tell the CPS when they are receiving unusual or 748 bogus PASSporTs. 750 This architecture also assumes that the CPS will age out PASSporTs. 751 A CPS SHOULD NOT keep any stored PASSporT for no longer than a value 752 that might be selected for the verification service policy for 753 freshness of the "iat" value as described in [RFC8224] (i.e. sixty 754 seconds). Any reduction in this window makes substitution attacks 755 (see Section 7.4) harder to mount, but making the window too small 756 might conceivably age PASSporTs out while a heavily redirected call 757 is still alerting. 759 An alternative potential approach to blind signatures would be the 760 use of oblivious pseudorandom functions (VOPRFs, per 761 [I-D.privacy-pass]), which move prove faster. 763 8. Authentication and Verification Service Behavior for Out-of-Band 765 [RFC8224] defines an authentication service and a verification 766 service as functions that act in the context of SIP requests and 767 responses. This specification thus provides a more generic 768 description of authentication service and verification service 769 behavior that might or might not involve any SIP transactions, but 770 depends only on placing a request for communications from an 771 originating identity to one or more destination identities. 773 8.1. Authentication Service (AS) 775 Out-of-band authentication services perform steps similar to those 776 defined in [RFC8224] with some exceptions: 778 Step 1: The authentication service MUST determine whether it is 779 authoritative for the identity of the originator of the request, that 780 is, the identity it will populate in the "orig" claim of the 781 PASSporT. It can do so only if it possesses the private key of one 782 or more credentials that can be used to sign for that identity, be it 783 a domain or a telephone number or some other identifier. For 784 example, the authentication service could hold the private key 785 associated with a STIR certificate [RFC8225]. 787 Step 2: The authentication service MUST determine that the originator 788 of communications can claim the originating identity. This is a 789 policy decision made by the authentication service that depends on 790 its relationship to the originator. For an out-of-band application 791 built-in to the calling device, for example, this is the same check 792 performed in Step 1: does the calling device hold a private key, one 793 corresponding to a STIR certificate, that can sign for the 794 originating identity? 796 Step 3: The authentication service MUST acquire the public encryption 797 key of the destination, which will be used to encrypt the PASSporT 798 (see Section 11). It MUST also discover (see Section 10) the CPS 799 associated with the destination. The authentication service may 800 already have the encryption key and destination CPS cached, or may 801 need to query a service to acquire the key. Note that per 802 Section 7.5 the authentication service may also need to acquire a 803 token for PASSporT storage from the CPS upon CPS discovery. It is 804 anticipated that the discovery mechanism (see Section 10) used to 805 find the appropriate CPS will also find the proper key server for the 806 public key of the destination. In some cases, a destination may have 807 multiple public encryption keys associated with it. In that case, 808 the authentication service MUST collect all of those keys. 810 Step 4: The authentication service MUST create the PASSporT object. 811 This includes acquiring the system time to populate the "iat" claim, 812 and populating the "orig" and "dest" claims as described in 813 [RFC8225]. The authentication service MUST then encrypt the 814 PASSporT. If in Step 3 the authentication service discovered 815 multiple public keys for the destination, it MUST create one 816 encrypted copy for each public key it discovered. 818 Finally, the authentication service stores the encrypted PASSporT(s) 819 at the CPS discovered in Step 3. Only after that is completed should 820 any call be initiated. Note that a call might be initiated over SIP, 821 and the authentication service would place the same PASSporT in the 822 Identity header field value of the SIP request - though SIP would 823 carry a cleartext version rather than an encrypted version sent to 824 the CPS. In that case, out-of-band would serve as a fallback 825 mechanism in case the request was not conveyed over SIP end-to-end. 826 Also, note that the authentication service MAY use a compact form of 827 the PASSporT for a SIP request, whereas the version stored at the CPS 828 MUST always be a full form PASSporT. 830 8.2. Verification Service (VS) 832 When a call arrives, an out-of-band verification service performs 833 steps similar to those defined in [RFC8224] with some exceptions: 835 Step 1: The verification service contacts the CPS and requests all 836 current PASSporTs for its destination number; or alternatively it may 837 receive PASSporTs through a push interface from the CPS in some 838 deployments. The verification service MUST then decrypt all 839 PASSporTs using its private key. Some PASSporTs may not be 840 decryptable for any number of reasons: they may be intended for a 841 different verification service, or they may be "dummy" values 842 inserted by the CPS for privacy purposes. The next few steps will 843 narrow down the set of PASSporTs that the verification service will 844 examine from that initial decryptable set. 846 Step 2: The verification service MUST determine if any "ppt" 847 extensions in the PASSporTs are unsupported. It takes only the set 848 of supported PASSporTs and applies the next step to them. 850 Step 3: The verification service MUST determine if there is an 851 overlap between the calling party number presented in call signaling 852 and the "orig" field of any decrypted PASSporTs. It takes the set of 853 matching PASSporTs and applies the next step to them. 855 Step 4: The verification service MUST determine if the credentials 856 that signed each PASSporT are valid, and if the verification service 857 trusts the CA that issued the credentials. It takes the set of 858 trusted PASSporTs to the next step. 860 Step 5: The verification service MUST check the freshness of the 861 "iat" claim of each PASSporT. The exact interval of time that 862 determines freshness is left to local policy. It takes the set of 863 fresh PASSporTs to the next step. 865 Step 6: The verification service MUST check the validity of the 866 signature over each PASSporT, as described in [RFC8225]. 868 Finally, the verification service will end up with one or more valid 869 PASSporTs corresponding to the call it has received. In keeping with 870 baseline STIR, this document does not dictate any particular 871 treatment of calls that have valid PASSporTs associated with them; 872 the handling of the call after the verification process depends on 873 how the verification service is implemented and on local policy. 874 However, it is anticipated that local policies could involve making 875 different forwarding decisions in intermediary implementations, or 876 changing how the user is alerted or how identity is rendered in UA 877 implementations. 879 8.3. Gateway Placement Services 881 The STIR out-of-band mechanism also supports the presence of gateway 882 placement services, which do not create PASSporTs themselves, but 883 instead take PASSporTs out of signaling protocols and store them at a 884 CPS before gatewaying to a protocol that cannot carry PASSporTs 885 itself. For example, a SIP gateway that sends calls to the PSTN 886 could receive a call with an Identity header field, extract a 887 PASSporT from the Identity header field, and store that PASSporT at a 888 CPS. 890 To place a PASSporT at a CPS, a gateway MUST perform Step 3 of 891 Section 8.1 above: that is, it must discover the CPS and public key 892 associated with the destination of the call, and may need to acquire 893 a PASSporT storage token (see Section 6.1). Per Step 3 of 894 Section 8.1 this may entail discovering several keys. The gateway 895 then collects the in-band PASSporT(s) from the in-band signaling, 896 encrypts the PASSporT(s), and stores them at the CPS. 898 A similar service could be performed by a gateway that retrieves 899 PASSporTs from a CPS and inserts them into signaling protocols that 900 support carrying PASSporTS in-band. This behavior may be defined by 901 future specifications. 903 9. Example HTTPS Interface to the CPS 905 As a rough example, we show a Call Placement Service implementation 906 here which uses a REST API to store and retrieve objects at the CPS. 907 The calling party stores the PASSporT at the CPS prior to initiating 908 the call; the PASSporT is stored at a location at the CPS that 909 corresponds to the called number. Note that it is possible for 910 multiple parties to be calling a number at the same time, and that 911 for called numbers such as large call centers, many PASSporTs could 912 legitimately be stored simultaneously, and it might prove difficult 913 to correlate these with incoming calls. 915 Assume that an authentication service has created the following 916 PASSporT for a call to the telephone number 2.222.555.2222 (note that 917 these are dummy values): 919 eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9 920 jZXJ0LmV4YW1wbGUub3JnL3Bhc3Nwb3J0LmNlciJ9.eyJkZXN0Ijp7InRuIjpbI 921 jIyMjI1NTUyMjIyIl19LCJpYXQiOiIxNTgzMjUxODEwIiwib3JpZyI6eyJ0biI6 922 IjExMTE1NTUxMTExIn19.pnij4IlLHoR4vxID0u3CT1e9Hq4xLngZUTv45Vbxmd 923 3IVyZug4KOSa378yfP4x6twY0KTdiDypsereS438ZHaQ 925 Through some discovery mechanism (see Section 10), the authentication 926 service discovers the network location of a web service that acts as 927 the CPS for 2.222.555.2222. Through the same mechanism, we will say 928 that it has also discovered one public encryption key for that 929 destination. It uses that encryption key to encrypt the PASSporT, 930 resulting in the encrypted PASSporT: 932 rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w 933 MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm 934 nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV 935 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 936 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j 938 Having concluded the numbered steps in Section 8.1, including 939 acquiring any token (per Section 6.1) needed to store the PASSporT at 940 the CPS, the authentication service then stores the encrypted 941 PASSporT: 943 POST /cps/2.222.555.2222/ppts HTTP/1.1 944 Host: cps.example.com 945 Content-Type: application/passport 947 rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w 948 MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm 949 nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV 950 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 951 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j 953 The web service assigns a new location for this encrypted PASSporT in 954 the collection, returning a 201 OK with the location of 955 /cps/2.222.222.2222/ppts/ppt1. Now the authentication service can 956 place the call, which may be signaled by various protocols. Once the 957 call arrives at the terminating side, a verification service contacts 958 its CPS to ask for the set of incoming calls for its telephone number 959 (2.222.222.2222). 961 GET /cps/2.222.555.2222/ppts 962 Host: cps.example.com 964 This returns to the verification service a list of the PASSporTs 965 currently in the collection, which currently consists of only 966 /cps/2.222.222.2222/ppts/ppt1. The verification service then sends a 967 new GET for /cps/2.222.555.2222/ppts/ppt1/ which yields: 969 HTTP/1.1 200 OK 970 Content-Type: application/passport 971 Link: 973 rlWuoTpvBvWSHmV1AvVfVaE5pPV6VaOup3Ajo3W0VvjvrQI1VwbvnUE0pUZ6Yl9w 974 MKW0YzI4LJ1joTHho3WaY3Oup3Ajo3W0YzAypvW9rlWxMKA0Vwc7VaIlnFV6JlWm 975 nKN6LJkcL2INMKuuoKOfMF5wo20vKK0fVzyuqPV6VwR0AQZlZQtmAQHvYPWipzyaV 976 wc7VaEhVwbvZGVkAGH1AGRlZGVvsK0ed3cwG1ubEjnxRTwUPaJFjHafuq0-mW6S1 977 IBtSJFwUOe8Dwcwyx-pcSLcSLfbwAPcGmB3DsCBypxTnF6uRpx7j 979 That concludes Step 1 of Section 8.2; the verification service then 980 goes on to the next step, processing that PASSporT through its 981 various checks. A complete protocol description for CPS interactions 982 is left to future work. 984 10. CPS Discovery 986 In order for the two ends of the out-of-band dataflow to coordinate, 987 they must agree on a way to discover a CPS and retrieve PASSporT 988 objects from it based solely on the rendezvous information available: 989 the calling party number and the called number. Because the storage 990 of PASSporTs in this architecture is indexed by the called party 991 number, it makes sense to discover a CPS based on the called party 992 number as well. There are a number of potential service discovery 993 mechanisms that could be used for this purpose. The means of service 994 discovery may vary by use case. 996 Although the discussion above is written largely in terms of a single 997 CPS, having a significant fraction of all telephone calls result in 998 storing and retrieving PASSporTs at a single monolithic CPS has 999 obvious scaling problems, and would as well allow the CPS to gather 1000 metadata about a very wide set of callers and callees. These issues 1001 can be alleviated by operational models with a federated CPS; any 1002 service discovery mechanism for out-of-band STIR should enable 1003 federation of the CPS function. Likely models include ones where a 1004 carrier operates one or more CPS instances on behalf of its 1005 customers, enterprises run a CPS instance on behalf of their PBX 1006 users, or where third-party service providers offer a CPS as a cloud 1007 service. 1009 Some service discovery possibilities under consideration include the 1010 following: 1012 For some deployments in closed (e.g. intranetwork) environments, 1013 the CPS location can simply be provisioned in implementations, 1014 obviating the need for a discovery protocol. 1016 If a credential lookup service is already available (see 1017 Section 11), the CPS location can also be recorded in the callee's 1018 credentials; an extension to [RFC8226] could for example provide a 1019 link to the location of the CPS where PASSporTs should be stored 1020 for a destination. 1022 There exist a number of common directory systems that might be 1023 used to translate telephone numbers into the URIs of a CPS. ENUM 1024 [RFC6116] is commonly implemented, though no "golden root" central 1025 ENUM administration exists that could be easily reused today to 1026 help the endpoints discover a common CPS. Other protocols 1027 associated with queries for telephone numbers, such as the TeRI 1028 [I-D.ietf-modern-teri] protocol, could also serve for this 1029 application. 1031 Another possibility is to use a single distributed service for 1032 this function. VIPR [I-D.jennings-vipr-overview] proposed a 1033 RELOAD [RFC6940] usage for telephone numbers to help direct calls 1034 to enterprises on the Internet. It would be possible to describe 1035 a similar RELOAD usage to identify the CPS where calls for a 1036 particular telephone number should be stored. One advantage that 1037 the STIR architecture has over VIPR is that it assumes a 1038 credential system that proves authority over telephone numbers; 1039 those credentials could be used to determine whether or not a CPS 1040 could legitimately claim to be the proper store for a given 1041 telephone number. 1043 This document does not prescribe any single way to do service 1044 discovery for a CPS; it is envisioned that initial deployments will 1045 provision the location of the CPS at the Authentication Service and 1046 Verification Service. 1048 11. Encryption Key Lookup 1050 In order to encrypt a PASSporT (see Section 6.1), the caller needs 1051 access to the callee's public encryption key. Note that because STIR 1052 uses ECDSA for signing PASSporTs, the public key used to verify 1053 PASSporTs is not suitable for this function, and thus the encryption 1054 key must be discovered separately. This requires some sort of 1055 directory/lookup system. 1057 Some initial STIR deployments have fielded certificate repositories 1058 so that verification services can acquire the signing credentials for 1059 PASSporTs, which are linked through a URI in the "x5u" element of the 1060 PASSporT. These certificate repositories could clearly be repurposed 1061 for allowing authentication services to download the public 1062 encryption key for the called party - provided they can be discovered 1063 by calling parties. This document does not specify any particular 1064 discovery scheme, but instead offers some general guidance about 1065 potential approaches. 1067 It is a desirable property that the public encryption key for a given 1068 party be linked to their STIR credential. An ECDH [RFC7748] public- 1069 private key pair might be generated for a subcert 1070 [I-D.ietf-tls-subcerts] of the STIR credential. That subcert could 1071 be looked up along with the STIR credential of the called party. 1072 Further details of this subcert, and the exact lookup mechanism 1073 involved, are deferred for future protocol work. 1075 Obviously, if there is a single central database that the caller and 1076 callee each access in real time to download the other's keys, then 1077 this represents a real privacy risk, as the central key database 1078 learns about each call. A number of mechanisms are potentially 1079 available to mitigate this: 1081 Have endpoints pre-fetch keys for potential counterparties (e.g., 1082 their address book or the entire database). 1084 Have caching servers in the user's network that proxy their 1085 fetches and thus conceal the relationship between the user and the 1086 keys they are fetching. 1088 Clearly, there is a privacy/timeliness tradeoff in that getting up- 1089 to-date knowledge about credential validity requires contacting the 1090 credential directory in real-time (e.g., via OCSP [RFC2560]). This 1091 is somewhat mitigated for the caller's credentials in that he can get 1092 short-term credentials right before placing a call which only reveals 1093 his calling rate, but not who he is calling. Alternately, the CPS 1094 can verify the caller's credentials via OCSP, though of course this 1095 requires the callee to trust the CPS's verification. This approach 1096 does not work as well for the callee's credentials, but the risk 1097 there is more modest since an attacker would need to both have the 1098 callee's credentials and regularly poll the database for every 1099 potential caller. 1101 We consider the exact best point in the tradeoff space to be an open 1102 issue. 1104 12. Acknowledgments 1106 The ideas in this document come out of discussions with Richard 1107 Barnes and Cullen Jennings. We'd also like to thank Russ Housley, 1108 Chris Wendt, Eric Burger, Mary Barnes, Ben Campbell, Ted Huang, 1109 Jonathan Rosenberg and Robert Sparks for helpful suggestions. 1111 13. IANA Considerations 1113 This memo includes no request to IANA. 1115 14. Privacy Considerations 1117 Delivering PASSporTs out-of-band offers a different set of privacy 1118 properties than traditional in-band STIR. In-band operations convey 1119 PASSporTs as headers in SIP messages in cleartext, which any 1120 forwarding intermediaries can potentially inspect. By contrast, out- 1121 of-band STIR stores these PASSporTs at a service after encrypting 1122 them as described in Section 6, effectively creating a path between 1123 the authentication and verification service in which the CPS is the 1124 sole intermediary, but the CPS cannot read the PASSporTs. 1125 Potentially, out-of-band PASSporT delivery could thus improve on the 1126 privacy story of STIR. 1128 The principle actors in the operation of out-of-band are the AS, VS, 1129 and CPS. The AS and VS functions differ from baseline [RFC8224] 1130 behavior, in that they interact with an CPS over a non-SIP interface, 1131 of which the REST interface in Section 9 serves as an example. Some 1132 out-of-band deployments may also require a discovery service for the 1133 CPS itself (Section 10) and/or encryption keys (Section 11). Even 1134 with encrypted PASSporTs, the network interactions by which the AS 1135 and VS interact with the CPS, and to a lesser extent any discovery 1136 services, thus create potential opportunities for data leakage about 1137 calling and called parties. 1139 The process of storing and retrieving PASSporTs at a CPS can itself 1140 reveal information about calls being placed. The mechanism takes 1141 care not to require that the AS authenticate itself to the CPS, 1142 relying instead on a blind signature mechanism for flood control 1143 prevention. Section 7.4 discusses the practice of storing "dummy" 1144 PASSporTs at random intervals to thwart traffic analysis, and as 1145 Section 8.2 notes, a CPS is required to return a dummy PASSporT even 1146 if there is no PASSporT indexed for that calling number, which 1147 similarly enables the retrieval side to randomly request PASSporTs 1148 when there are no calls in progress. These measures can help to 1149 mitigiate information disclosure in the system. In implementations 1150 that require service discovery (see Section 10), perhaps through key 1151 discovery (Section 11), similar measures could be used to make sure 1152 that service discovery does not itself disclose information about 1153 calls. 1155 Ultimately, this document only provides a framework for future 1156 implementation of out-of-band systems, and the privacy properties of 1157 a given implementation will depend on architectural assumptions made 1158 in those environments. More closed systems for intranet operations 1159 may adopt a weaker security posture but otherwise mitigate the risks 1160 of information disclosure, where more open environment will require 1161 careful implementation of the practices described here. 1163 For general privacy risks associated with the operations of STIR, 1164 also see the Privacy Considerations of [RFC8224]. 1166 15. Security Considerations 1168 This entire document is about security, but the detailed security 1169 properties will vary depending on how the framework is applied and 1170 deployed. General guidance for dealing with the most obvious 1171 security challenges posed by this framework is given in Section 7.3 1172 and Section 7.4, along proposed solutions for problems like denial- 1173 of-service attacks or traffic analysis against the CPS. 1175 Although there are considerable security challenges associated with 1176 widespread deployment of a public CPS, those must be weighed against 1177 the potential usefulness of a service that delivers a STIR assurance 1178 without requiring the passage of end-to-end SIP. Ultimately, the 1179 security properties of this mechanism are at least comparable to in- 1180 band STIR: the substitution attack documented in Section 7.4 could be 1181 implemented by any in-band SIP intermediary or eavesdropper who 1182 happened to see the PASSporT in transit, say, and launch its own call 1183 with a copy of that PASSporT to race against the original to the 1184 destination. 1186 16. Informative References 1188 [I-D.ietf-modern-teri] 1189 Peterson, J., "An Architecture and Information Model for 1190 Telephone-Related Information (TeRI)", draft-ietf-modern- 1191 teri-00 (work in progress), July 2018. 1193 [I-D.ietf-stir-passport-divert] 1194 Peterson, J., "PASSporT Extension for Diverted Calls", 1195 draft-ietf-stir-passport-divert-07 (work in progress), 1196 November 2019. 1198 [I-D.ietf-tls-subcerts] 1199 Barnes, R., Iyengar, S., Sullivan, N., and E. Rescorla, 1200 "Delegated Credentials for TLS", draft-ietf-tls- 1201 subcerts-06 (work in progress), February 2020. 1203 [I-D.jennings-vipr-overview] 1204 Barnes, M., Jennings, C., Rosenberg, J., and M. Petit- 1205 Huguenin, "Verification Involving PSTN Reachability: 1206 Requirements and Architecture Overview", draft-jennings- 1207 vipr-overview-06 (work in progress), December 2013. 1209 [I-D.privacy-pass] 1210 Davidson, A. and N. Sullivan, "The Privacy Pass Protocol", 1211 draft-privacy-pass-00 (work in progress), November 2019. 1213 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1214 Requirement Levels", BCP 14, RFC 2119, 1215 DOI 10.17487/RFC2119, March 1997, 1216 . 1218 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1219 Adams, "X.509 Internet Public Key Infrastructure Online 1220 Certificate Status Protocol - OCSP", RFC 2560, 1221 DOI 10.17487/RFC2560, June 1999, 1222 . 1224 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1225 A., Peterson, J., Sparks, R., Handley, M., and E. 1226 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1227 DOI 10.17487/RFC3261, June 2002, 1228 . 1230 [RFC5636] Park, S., Park, H., Won, Y., Lee, J., and S. Kent, 1231 "Traceable Anonymous Certificate", RFC 5636, 1232 DOI 10.17487/RFC5636, August 2009, 1233 . 1235 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 1236 Uniform Resource Identifiers (URI) Dynamic Delegation 1237 Discovery System (DDDS) Application (ENUM)", RFC 6116, 1238 DOI 10.17487/RFC6116, March 2011, 1239 . 1241 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 1242 and H. Schulzrinne, "REsource LOcation And Discovery 1243 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 1244 January 2014, . 1246 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1247 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 1248 2014, . 1250 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 1251 Telephone Identity Problem Statement and Requirements", 1252 RFC 7340, DOI 10.17487/RFC7340, September 2014, 1253 . 1255 [RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves 1256 for Security", RFC 7748, DOI 10.17487/RFC7748, January 1257 2016, . 1259 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1260 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1261 May 2017, . 1263 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 1264 "Authenticated Identity Management in the Session 1265 Initiation Protocol (SIP)", RFC 8224, 1266 DOI 10.17487/RFC8224, February 2018, 1267 . 1269 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 1270 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 1271 . 1273 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 1274 Credentials: Certificates", RFC 8226, 1275 DOI 10.17487/RFC8226, February 2018, 1276 . 1278 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 1279 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 1280 . 1282 Authors' Addresses 1284 Eric Rescorla 1285 Mozilla 1287 Email: ekr@rtfm.com 1289 Jon Peterson 1290 Neustar, Inc. 1291 1800 Sutter St Suite 570 1292 Concord, CA 94520 1293 US 1295 Email: jon.peterson@team.neustar