idnits 2.17.1 draft-rescorla-stir-fallback-01.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 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (October 31, 2016) is 2732 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-10 == Outdated reference: A later version (-11) exists of draft-ietf-stir-passport-10 == Outdated reference: A later version (-16) exists of draft-ietf-stir-rfc4474bis-14 == Outdated reference: A later version (-04) exists of draft-peterson-modern-teri-01 Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Rescorla 3 Internet-Draft Mozilla 4 Intended status: Standards Track J. Peterson 5 Expires: May 4, 2017 Neustar 6 October 31, 2016 8 STIR Out of Band Architecture and Use Cases 9 draft-rescorla-stir-fallback-01.txt 11 Abstract 13 Existing work has defined ways to secure the identity of SIP calls, 14 but the in-band mechanisms defined in that work do not properly 15 transit the PSTN. This document defines out-of-band mechanisms which 16 do not require modifying the messages that pass over the PSTN. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on May 4, 2017. 35 Copyright Notice 37 Copyright (c) 2016 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Operating Environments . . . . . . . . . . . . . . . . . . . 4 55 4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 6 58 5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 6 59 5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 6 60 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 7 61 6. Solution Architecture . . . . . . . . . . . . . . . . . . . . 7 62 6.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 7 63 6.2. Solution Architecture . . . . . . . . . . . . . . . . . . 8 64 6.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 9 65 6.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 9 66 7. Call Placement Service Discovery and Interface . . . . . . . 10 67 8. Some Potential Enhancements . . . . . . . . . . . . . . . . . 11 68 8.1. Encrypted PASSporTs . . . . . . . . . . . . . . . . . . . 11 69 8.1.1. Credential Lookup . . . . . . . . . . . . . . . . . . 12 70 8.2. Federated Call Placement Services . . . . . . . . . . . . 12 71 8.3. Escalation to VoIP . . . . . . . . . . . . . . . . . . . 13 72 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 73 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 74 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 75 12. Informative References . . . . . . . . . . . . . . . . . . . 13 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 78 1. Introduction 80 The STIR problem statement [RFC7340] describes widespread problems 81 enabled by impersonation in the telephone network, including illegal 82 robocalling, voicemail hacking, and swatting. As telephone services 83 are increasingly migrating onto the Internet, and using Voice over IP 84 (VoIP) protocols such as SIP [RFC3261], it is necessary for these 85 protocols to support stronger identity mechanisms to prevent 86 impersonation. For example, [I-D.ietf-stir-rfc4474bis] defines an 87 Identity header of SIP requests capable of carrying a PASSporT 88 [I-D.ietf-stir-passport] object in SIP as a means to 89 cryptographically attest that the originator of a telephone call is 90 authorized to use the calling party number (or, for native SIP cases, 91 SIP URI) associated with the originator of the call. of the request. 93 Not all telephone calls use SIP today, however; and even those that 94 do use SIP do not always carry SIP signaling end-to-end. Most calls 95 from telephone numbers still traverse the Public Switched Telephone 96 Network (PSTN) at some point. Broadly, calls fall into one of three 97 categories: 99 1. One or both of the endpoints is actually a PSTN endpoint. 101 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the 102 call transits the PSTN at some point. 104 3. Non-PSTN calls which do not transit the PSTN at all (such as 105 native SIP end-to-end calls). 107 The first two categories represent the majority of telephone calls 108 associated with problems like illegal robocalling: many robocalls 109 today originate on the Internet but terminate at PSTN endpoints. 110 However, the core network elements that operate the PSTN are legacy 111 devices that are unlikely to be upgradable at this point to support 112 an in-band authentication system. As such, those devices largely 113 cannot be modified to pass signatures originating on the Internet--or 114 indeed any inband signaling data--intact. In some cases they will 115 strip the signatures from PSTN signaling; in others, they might 116 damage them to the point where they cannot be verified. For those 117 first two categories above, any in-band authentication scheme does 118 not seem practical in the current environment. 120 But while the core network of the PSTN remains fixed, the endpoints 121 of the telephone network are becoming increasingly programmable and 122 sophisticated. Landline "plain old telephone service" deployments, 123 especially in the developed world, are shrinking, and increasingly 124 being replaced by three classes of intelligent devices: smart phones, 125 IP PBXs, and terminal adapters. All three are general purpose 126 computers, and typically all three have Internet access as well as 127 access to the PSTN. This provides a potential avenue for building an 128 authentication system that changes only the endpoints while leaving 129 the PSTN intact. 131 This specification therefore builds on the PASSporT 132 [I-D.ietf-stir-passport] mechanism and the work of 133 [I-D.ietf-stir-rfc4474bis] to define a way that a PASSporT object 134 created in the originating network of the call can reach the 135 terminating network even when it cannot be carried end-to-end in-band 136 in the call signaling. This relies on a new service defined in this 137 document that permits the PASSporT object to be stored during call 138 processing and retrieved for verification purposes. 140 2. Terminology 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 144 "OPTIONAL" in this document are to be interpreted as described in RFC 145 2119 [RFC2119]. 147 3. Operating Environments 149 This section describes the environment in which the proposed 150 mechanism is intended to operate. In the simplest setting, Alice is 151 calling Bob through some set of gateways and/or the PSTN. Both Alice 152 and Bob have smart devices which can be modified, but they do not 153 have a clear connection between them: Alice cannot inject any data 154 into signaling which Bob can read, with the exception of the asserted 155 destination and origination E.164 numbers. The calling party number 156 might originate from her own device or from the network. These 157 numbers are effectively the only data that can be used for 158 coordination between the endpoints. 160 +---------+ 161 / \ 162 +--- +---+ 163 +----------+ / \ +----------+ 164 | | | Gateways | | | 165 | Alice |<----->| and/or |<----->| Bob | 166 | (caller) | | PSTN | | (callee) | 167 +----------+ \ / +----------+ 168 +--- +---+ 169 \ / 170 +---------+ 172 In a more complicated setting, Alice and/or Bob may not have a smart 173 or programmable device, but one or both of them are behind a STIR- 174 aware gateway that can participate in out-of-band coordination, as 175 shown below: 177 +---------+ 178 / \ 179 +--- +---+ 180 +----------+ +--+ / \ +--+ +----------+ 181 | | | | | Gateways | | | | | 182 | Alice |<-|GW|->| and/or |<-|GW|->| Bob | 183 | (caller) | | | | PSTN | | | | (callee) | 184 +----------+ +--+ \ / +--+ +----------+ 185 +--- +---+ 186 \ / 187 +---------+ 189 In such a case, Alice might have an analog connection to her gateway/ 190 switch which is responsible for her identity. Similarly, the gateway 191 would verify Alice's identity, generate the right calling party 192 number information and provide that number to Bob using ordinary POTS 193 mechanisms. 195 4. Dataflows 197 Because in these operating environments endpoints cannot pass 198 cryptographic information to one another directly through signaling, 199 any solution must involve some rendezvous mechanism to allow 200 endpoints to communicate. We call this rendezvous service a "call 201 placement service" (CPS), a service where a record of call placement, 202 in this case a PASSporT, can be stored for future retrieval. In 203 principle this service could communicate any information, but 204 minimally we expect it to include a full-form PASSporT that attests 205 the caller, callee, and the time of the call. The callee can use the 206 existence of a PASSporT for a given incoming call as rough validation 207 of the asserted origin of that call. (See Section 8.1.1 for 208 limitations of this design.) 210 There are roughly two plausible dataflow architectures for the CPS: 212 The callee registers with the CPS. When the caller wishes to 213 place a call to the callee, it sends the PASSporT to the CPS which 214 forwards it to the callee. 216 The caller stores the PASSporT with the CPS at the time of call 217 placement. When the callee receives the call, it contacts the CPS 218 and retrieves the CDR. 220 While the first architecture is roughly isomorphic to current VoIP 221 protocols, it shares their drawbacks. Specifically, the callee must 222 maintain a full-time connection to the CPS to serve as a notification 223 channel. This comes with the usual networking costs to the callee 224 and is especially problematic for mobile endpoints. Thus, we focus 225 on the second architecture in which the PSTN incoming call serves as 226 the notification channel and the callee can then contact the CPS to 227 retrieve the PASSporT. 229 5. Use Cases 231 The following are the motivating use cases for this mechanism. Bear 232 in mind that just as in [I-D.ietf-stir-rfc4474bis] there may be 233 multiple Identity headers in a single SIP INVITE, so there may be 234 multiple PASSporTs in this out-of-band mechanism associated with a 235 single call. For example, a SIP user agent might create a PASSporT 236 for a call with an end user credential, and as the call exits the 237 originating administrative domain the network authentication service 238 might create its own PASSporT for the same call. As such, these use 239 cases may overlap in the processing of a single call. 241 5.1. Case 1: VoIP to PSTN Call 243 A call originates in the SIP world in a STIR-aware administrative 244 domain. The local authentication service for that administrative 245 domain creates a PASSporT which is carried in band in the call per 246 [I-D.ietf-stir-rfc4474bis]. The call is routed out of the 247 originating administrative domain and eventually reaches a gateway to 248 the PSTN. Eventually, the call will terminate on a mobile smartphone 249 that supports this out-of-band mechanism. 251 In this use case, the originating authentication service can store 252 the PASSporT with the appropriate CPS for the target telephone number 253 as a fallback in case SIP signaling will not reach end-to-end. When 254 the destination mobile smartphone receives the call over the PSTN, it 255 consults the CPS and discovers a PASSporT from the originating 256 telephone number waiting for it. It uses this PASSporT to verify the 257 calling party number. 259 5.2. Case 2: Two Smart PSTN endpoints 261 A call originates with an enterprise PBX that has both Internet 262 access and a built-in gateway to the PSTN. It will immediately drop 263 its call to the PSTN, but before it does, it provisions a PASSporT on 264 the CPS associated with the target telephone number. 266 After normal PSTN routing, the call lands on a smart mobile handset 267 that supports the STIR out-of-band mechanism. It queries the 268 appropriate CPS over the Internet to determine if a call has been 269 placed to it by a STIR-aware device. It finds the PASSporT 270 provisioned by the enterprise PBX and uses it to verify the calling 271 party number. 273 5.3. Case 3: PSTN to VoIP Call 275 A call originates with an enterprise PBX that has both Internet 276 access and a built-in gateway to the PSTN. It will immediate drop 277 the call to the PSTN, but before it does, it provisions a PASSporT 278 with the CPS associated with the target telephone number. However, 279 it turns out that the call will eventually route through the PSTN to 280 an Internet gateway, which will translate this into a SIP call and 281 deliver it to an administrative domain with a STIR verification 282 service. 284 In this case, the Internet gateway that receives the call from the 285 PSTN can query the appropriate CPS to determine if the original 286 caller created and provisioned a PASSporT for this call. If so, it 287 can retrieve the PASSporT and, when it creates a SIP INVITE for this 288 call, add a corresponding Identity header per 290 [I-D.ietf-stir-rfc4474bis]. When the SIP INVITE reaches the 291 destination administrative domain, it will be able to verify the 292 PASSporT normally. Note that to avoid discrepancies with the Date 293 header field value, only full-form PASSporT should be used for this 294 purpose. 296 5.4. Case 4: Gateway Out-of-band 298 A call originates in the SIP world in a STIR-aware administrative 299 domain. The local authentication service for that administrative 300 domain creates a PASSporT which is carried in band in the call per 301 [I-D.ietf-stir-rfc4474bis]. The call is routed out of the 302 originating administrative domain and eventually reaches a gateway to 303 the PSTN. 305 In this case, the originating authentication service does not support 306 the out-of-band mechanism, so instead the gateway to the PSTN 307 extracts the PASSporT from the SIP request and provisions it to the 308 CPS. (When the call reaches the gateway to the PSTN, the gateway 309 might first check the CPS to see if a PASSporT object had already 310 been provisioned for this call, and only provision a PASSporT if none 311 is present). 313 Ultimately, the call may terminate on the PSTN, or be routed back to 314 the IP world. In the former case, perhaps the destination endpoints 315 queries the CPS to retrieve the PASSporT provisioned by the first 316 gateway. Or if the call ultimately returns to the IP world, it might 317 be the gateway from the PSTN back to the Internet that retrieves the 318 PASSporT from the CPS and attaches it to the new SIP INVITE it 319 creates, or it might be the terminating administrative domain's 320 verification service that checks the CPS when an INVITE arrives with 321 no Identity header field. Either way the PASSporT can survive the 322 gap in SIP coverage caused by the PSTN leg of the call. 324 6. Solution Architecture 326 In this section, we discuss a strawman architecture along the lines 327 described in the previous section. This discussion is deliberately 328 sketchy, focusing on broad concepts and skipping over details. The 329 intent here is merely to provide a rough concept, not a complete 330 solution. 332 6.1. Credentials and Phone Numbers 334 We start from the premise of the STIR problem statement [RFC7340] 335 that phone numbers can be associated with credentials which can be 336 used to attest ownership of numbers. For purposes of exposition, we 337 will assume that ownership is associated with the endpoint (e.g., a 338 smartphone) but it might well be associated with a provider or 339 gateway acting for the endpoint instead. It might be the case that 340 multiple entities are able to act for a given number, provided that 341 they have the appropriate authority. [I-D.ietf-stir-certificates] 342 describes a credentials system suitable for this purpose; the 343 question of how an entity is determined to have control of a given 344 number is out of scope for the current document. 346 6.2. Solution Architecture 348 An overview of the basic calling and verification process is shown 349 below. In this diagram, we assume that Alice has the number 350 +1.111.111.1111 and Bob has the number +2.222.222.2222. 352 Alice Call Placement Service Bob 353 ----------------------------------------------------------------------- 354 <- Authenticate as 1.111.111.1111 ----> 356 Store PASSporT -> 358 Call from 1.111.111.1111 ----------------------------------------------> 360 <- Authenticate as 1.222.222.2222 ----> 362 <-------------- Retrieve call record 363 from 1.111.111.1111? 365 (1.222.222.2222,1.111.111.1111) --> 367 [Ring phone with callerid 368 = 1.111.111.1111] 370 When Alice wishes to make a call to Bob, she contacts the CPS and 371 authenticates to prove her ownership of her E.164 number. Once she 372 has authenticated, she then stores a PASSporT on the CPS. The 373 PASSpoRT is stored under Bob's number. 375 Once Alice has stored the PASSporT, she then places the call to Bob 376 as usual. At this point, Bob's phone would usually ring and display 377 Alice's number (+1.111.111.1111), which is informed by the existing 378 caller-id mechanisms (i.e., the CIN field of the IAM). Instead, 379 Bob's phone transparently contacts the CPS and requests any current 380 PASSporTs for calls to Bob. The CPS responds with any such PASSporTs 381 (assuming they exists). If such a PASSpoRT exists, Bob's phone can 382 then present the callerid information as valid. Otherwise, the call 383 is unverifiable. Note that this does not necessarily mean that the 384 call is bogus; because we expect incremental deployment many 385 legitimate calls will be unverifiable. 387 6.3. Security Analysis 389 The primary attack we seek to prevent is an attacker convincing the 390 callee that a given call is from some other caller C. There are two 391 scenarios to be concerned with: 393 The attacker wishes to simulate a call when none exists. 395 The attacker wishes to substitute himself for an existing call as 396 described in Section 6.4. 398 If an attacker can inject fake PASSporT into the CPS or in the 399 communication from the CPS to the callee, he can mount either attack. 400 As PASSporTs should be digitally signed by an appropriate authority 401 for the number and verified by the callee (see Section 6.1), this 402 should not arise in ordinary operations. For privacy and robustness 403 reasons, using TLS on the originating side when storing the PASSporT 404 at the CPS is recommended. 406 The entire system depends on the security of the credential 407 infrastructure. If the authentication credentials for a given number 408 are compromised, then an attacker can impersonate calls from that 409 number. 411 6.4. Substitution Attacks 413 All that receipt of the PASSporT from the CPS proves to the called 414 party is that Alice is trying to call Bob (or at least was as of very 415 recently). It does not prove that any particular incoming call is 416 from Alice. Consider the scenario in which we have a service which 417 provides an automatic callback to a user-provided number. In that 418 case, the attacker try to arrange for a false caller-id value, as 419 shown below: 421 Attacker Callback Service CPS Bob 422 ----------------------------------------------------------------------- 423 Place call to Bob ----------> 425 Store PASSporT for 426 CS:Bob --------------> 428 Call from CS (forged caller-id info) --------------------------------> 430 Call from CS ---------------------------> X 432 <----- Retrieve PASSporT 433 for CS:Bob 435 PASSporT for CS:Bob ---------------------------> 437 [Ring phone with callerid = CS] 439 In order to mount this attack, the attacker contacts the Callback 440 Service (CS) and provides it with Bob's number. This causes the CS 441 to initiate a call to Bob. As before, the CS contacts the CPS to 442 insert an appropriate PASSporT and then initiates a call to Bob. 443 Because it is a valid CS injecting the PASSporT, none of the security 444 checks mentioned above help. However, the attacker simultaneously 445 initiates a call to Bob using forged caller-id information 446 corresponding to the CS. If he wins the race with the CS, then Bob's 447 phone will attempt to verify the attacker's call (and succeed since 448 they are indistinguishable) and the CS's call will go to busy/voice 449 mail/call waiting. Note: in a SIP environment, the callee might 450 notice that there were multiple INVITEs and thus detect this attack. 452 7. Call Placement Service Discovery and Interface 454 In order for the two ends of the out-of-band dataflow to coordinate, 455 they must agree on a way to discover a CPS and retrieve PASSporT 456 objects from it based solely on the rendezvous information available: 457 the calling party number and the called number. There are a number 458 of potential service discovery mechanisms that could be used for this 459 purpose. The means of service discovery may vary by use case. 461 There exist a number of common directory systems that might be used 462 to translate telephone numbers into the URIs of a CPS. ENUM 463 [RFC6116] is commonly implemented, though no "golden root" central 464 ENUM administration exists that could be easily reused today to help 465 the endpoints discover a common CPS. Other protocols associated with 466 queries for telephone numbers, such as the TeRI 468 [I-D.peterson-modern-teri] protocol, could also serve for this 469 application. 471 Another possibility is to use a single distributed service for this 472 function. VIPR [I-D.rosenberg-dispatch-vipr-overview] proposed a 473 RELOAD [RFC6940] usage for telephone numbers to help direct calls to 474 enterprises on the Internet. It would be possible to describe a 475 similar RELOAD usage to identify the CPS where calls for a particular 476 telephone number should be stored. One advantage that the STIR 477 architecture has over VIPR is that it assumes a credential system 478 that proves authority over telephone numbers; those credentials could 479 be used to determine whether or not a CPS could legitimately claim to 480 be the proper store for a given telephone number. 482 Future versions of this specification will identify suitable service 483 discovery mechanisms for out-of-band STIR. 485 8. Some Potential Enhancements 487 Section 4 provides a broad sketch of an approach. In this section, 488 we consider some potential enhancements. Readers can feel free to 489 skip this section, as it is not necessary to get the flavor of the 490 document. 492 8.1. Encrypted PASSporTs 494 In the system described in Section 4, the CPS learns the PASSporT for 495 every call, which is undesirable from a privacy perspective. The 496 situation can be improved by having the caller store encrypted 497 PASSporTs. A number of schemes are possible, but for concreteness we 498 sketch one possibility. 500 The general idea is that each user's credentials are not just 501 suitable for authentication to the CPS but also are an asymmetric key 502 pair suitable for use in an encryption mode. When Alice wants to 503 store a PASSporT for Bob she retrieves Bob's credentials (see 504 Section 8.1.1) and then encrypts the PASSporT under Bob's public key. 505 [The encryption needs to be done in such a way that if you don't have 506 Bob's key, the message is indistinguishable from random. This is 507 straightforward, but not compatible with typical secure message 508 formats, which tend to indicate the recipient's identity.] The 509 PASSporT is then stored with the CPS under Alice's identity. When 510 Bob receives a call, he just asks the CPS (anonymously) for any calls 511 from Alice to anyone. He then trial-decrypts each and if any of them 512 is for him, he proceeds as before. In this way, the CPS learns 513 Alice's call velocity but not who she is calling. This mechanism is 514 suitable for cases where credentials are issued to end-user devices, 515 rather than large operators. 517 8.1.1. Credential Lookup 519 In order to encrypt a PASSporT, the caller needs access to the 520 callee's credentials (specifically their public key). This requires 521 some sort of directory/lookup system. This document does not specify 522 any particular scheme, but a list of requirements would be something 523 like: 525 Obviously, if there is a single central database and the caller and 526 callee each contact it in real time to determine the other's 527 credentials, then this represents a real privacy risk, as the central 528 database learns about each call. A number of mechanisms are 529 potentially available to mitigate this: 531 Have endpoints pre-fetch credentials for potential counterparties 532 (e.g., their address book or the entire database). 534 Have caching servers in the user's network that proxy their 535 fetches and thus conceal the relationship between the user and the 536 credentials they are fetching. 538 Clearly, there is a privacy/timeliness tradeoff in that getting 539 really up-to-date knowledge about credential validity requires 540 contacting the credential directory in real-time (e.g., via OCSP). 541 This is somewhat mitigated for the caller's credentials in that he 542 can get short-term credentials right before placing a call which only 543 reveals his calling rate, but not who he is calling. Alternately, 544 the CPS can verify the caller's credentials via OCSP, though of 545 course this requires the callee to trust the CPS's verification. 546 This approach does not work as well for the callee's credentials, but 547 the risk there is more modest since an attacker would need to both 548 have the callee's credentials and regularly poll the database for 549 every potential caller. 551 We consider the exact best point in the tradeoff space to be an open 552 issue. 554 8.2. Federated Call Placement Services 556 The discussion above is written in terms of a single CPS, but this 557 potentially has scaling problems, as well as allowing the CPS to 558 learn about every call. These issues can be alleviated by having a 559 federated CPS. If a credential lookup service is already available, 560 the CPS location can also be stored in the callee's credentials. 562 A service discovery mechanism for out-of-band STIR should ideally 563 enable federation of the CPS function. 565 8.3. Escalation to VoIP 567 If the call is to be carried over the PSTN, then the security 568 properties described above are about the best we can do. However, if 569 Alice and Bob are both VoIP capable, then there is an opportunity to 570 provide a higher quality of service and security. The basic idea is 571 that the PASSporT contains an addition claim containing rendezvous 572 information for Alice (e.g., Alice's SIP URI). Once Bob has verified 573 Alice's PASSporT, he can initiate a VoIP connection directly to 574 Alice, thus bypassing the PSTN. Mechanisms of this type are out of 575 scope of this document. 577 9. Acknowledgments 579 The ideas in this document come out of discussions with Richard 580 Barnes and Cullen Jennings. 582 10. IANA Considerations 584 This memo includes no request to IANA. 586 11. Security Considerations 588 This entire document is about security, but the detailed security 589 properties depend on having a single concrete scheme to analyze. 591 12. Informative References 593 [I-D.ietf-stir-certificates] 594 Peterson, J. and S. Turner, "Secure Telephone Identity 595 Credentials: Certificates", draft-ietf-stir- 596 certificates-10 (work in progress), October 2016. 598 [I-D.ietf-stir-passport] 599 Wendt, C. and J. Peterson, "Personal Assertion Token 600 (PASSporT)", draft-ietf-stir-passport-10 (work in 601 progress), October 2016. 603 [I-D.ietf-stir-rfc4474bis] 604 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 605 "Authenticated Identity Management in the Session 606 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-14 607 (work in progress), October 2016. 609 [I-D.peterson-modern-teri] 610 Peterson, J., "An Architecture and Information Model for 611 Telephone-Related Information (TeRI)", draft-peterson- 612 modern-teri-01 (work in progress), July 2016. 614 [I-D.rosenberg-dispatch-vipr-overview] 615 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 616 "Verification Involving PSTN Reachability: Requirements 617 and Architecture Overview", draft-rosenberg-dispatch-vipr- 618 overview-04 (work in progress), October 2010. 620 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 621 Requirement Levels", BCP 14, RFC 2119, 622 DOI 10.17487/RFC2119, March 1997, 623 . 625 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 626 A., Peterson, J., Sparks, R., Handley, M., and E. 627 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 628 DOI 10.17487/RFC3261, June 2002, 629 . 631 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 632 Uniform Resource Identifiers (URI) Dynamic Delegation 633 Discovery System (DDDS) Application (ENUM)", RFC 6116, 634 DOI 10.17487/RFC6116, March 2011, 635 . 637 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 638 and H. Schulzrinne, "REsource LOcation And Discovery 639 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 640 January 2014, . 642 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 643 Telephone Identity Problem Statement and Requirements", 644 RFC 7340, DOI 10.17487/RFC7340, September 2014, 645 . 647 Authors' Addresses 649 Eric Rescorla 650 Mozilla 652 Email: ekr@rtfm.com 654 Jon Peterson 655 Neustar, Inc. 656 1800 Sutter St Suite 570 657 Concord, CA 94520 658 US 660 Email: jon.peterson@neustar.biz