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