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