idnits 2.17.1 draft-ietf-stir-oob-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 date (October 29, 2017) is 2370 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'Disconnect' is mentioned on line 433, but not defined == Outdated reference: A later version (-18) exists of draft-ietf-stir-certificates-14 == Outdated reference: A later version (-09) exists of draft-ietf-stir-passport-divert-00 == Outdated reference: A later version (-04) exists of draft-peterson-modern-teri-03 Summary: 0 errors (**), 0 flaws (~~), 6 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 2, 2018 Neustar 6 October 29, 2017 8 STIR Out-of-Band Architecture and Use Cases 9 draft-ietf-stir-oob-01.txt 11 Abstract 13 The PASSporT format defines a token that can be carried by signaling 14 protocols, including SIP, to cryptographically attest the identify of 15 callers. Not all telephone calls use Internet signaling protocols, 16 however, and some calls use them for only part of their signaling 17 path. This document describes use cases that require the delivery of 18 PASSporT objects outside of the signaling path, and defines 19 architectures and semantics to provide this functionality. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on May 2, 2018. 38 Copyright Notice 40 Copyright (c) 2017 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 3. Operating Environments . . . . . . . . . . . . . . . . . . . 4 58 4. Dataflows . . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 5.1. Case 1: VoIP to PSTN Call . . . . . . . . . . . . . . . . 6 61 5.2. Case 2: Two Smart PSTN endpoints . . . . . . . . . . . . 6 62 5.3. Case 3: PSTN to VoIP Call . . . . . . . . . . . . . . . . 7 63 5.4. Case 4: Gateway Out-of-band . . . . . . . . . . . . . . . 7 64 6. Storing and Retrieving PASSporTs . . . . . . . . . . . . . . 8 65 6.1. Storage . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 6.2. Retrieval . . . . . . . . . . . . . . . . . . . . . . . . 10 67 7. Solution Architecture . . . . . . . . . . . . . . . . . . . . 11 68 7.1. Credentials and Phone Numbers . . . . . . . . . . . . . . 12 69 7.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7.3. Security Analysis . . . . . . . . . . . . . . . . . . . . 13 71 7.4. Substitution Attacks . . . . . . . . . . . . . . . . . . 13 72 8. Call Placement Service Discovery . . . . . . . . . . . . . . 14 73 9. Credential Lookup . . . . . . . . . . . . . . . . . . . . . . 15 74 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 13. Informative References . . . . . . . . . . . . . . . . . . . 16 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 80 1. Introduction 82 The STIR problem statement [RFC7340] describes widespread problems 83 enabled by impersonation in the telephone network, including illegal 84 robocalling, voicemail hacking, and swatting. As telephone services 85 are increasingly migrating onto the Internet, and using Voice over IP 86 (VoIP) protocols such as SIP [RFC3261], it is necessary for these 87 protocols to support stronger identity mechanisms to prevent 88 impersonation. For example, [I-D.ietf-stir-rfc4474bis] defines an 89 Identity header of SIP requests capable of carrying a PASSporT 90 [I-D.ietf-stir-passport] object in SIP as a means to 91 cryptographically attest that the originator of a telephone call is 92 authorized to use the calling party number (or, for native SIP cases, 93 SIP URI) associated with the originator of the call. of the request. 95 Not all telephone calls use SIP today, however; and even those that 96 do use SIP do not always carry SIP signaling end-to-end. Most calls 97 from telephone numbers still traverse the Public Switched Telephone 98 Network (PSTN) at some point. Broadly, calls fall into one of three 99 categories: 101 1. One or both of the endpoints is actually a PSTN endpoint. 103 2. Both of the endpoints are non-PSTN (SIP, Jingle, ...) but the 104 call transits the PSTN at some point. 106 3. Non-PSTN calls which do not transit the PSTN at all (such as 107 native SIP end-to-end calls). 109 The first two categories represent the majority of telephone calls 110 associated with problems like illegal robocalling: many robocalls 111 today originate on the Internet but terminate at PSTN endpoints. 112 However, the core network elements that operate the PSTN are legacy 113 devices that are unlikely to be upgradable at this point to support 114 an in-band authentication system. As such, those devices largely 115 cannot be modified to pass signatures originating on the Internet--or 116 indeed any inband signaling data--intact. Even if fields for 117 tunneling arbtirary data can be found in traditional PSTN signaling, 118 in some cases legacy elements would strip the signatures from those 119 fields; in others, they might damage them to the point where they 120 cannot be verified. For those first two categories above, any in- 121 band authentication scheme does not seem practical in the current 122 environment. 124 But while the core network of the PSTN remains fixed, the endpoints 125 of the telephone network are becoming increasingly programmable and 126 sophisticated. Landline "plain old telephone service" deployments, 127 especially in the developed world, are shrinking, and increasingly 128 being replaced by three classes of intelligent devices: smart phones, 129 IP PBXs, and terminal adapters. All three are general purpose 130 computers, and typically all three have Internet access as well as 131 access to the PSTN. Additionally, various kinds of gateways 132 increasingly front for legacy equipment. All of this provides a 133 potential avenue for building an authentication system that 134 implements stronger identity while leaving PSTN systems intact. 136 This capability also provides an ideal transitional technology while 137 in-band STIR adoption is ramping up. It permits early adopters to 138 use the technology even when intervening network elements are not yet 139 STIR-aware, and through various kinds of gateways it may allow 140 providers with a significant PSTN investment to still secure their 141 calls with STIR. 143 This specification therefore builds on the PASSporT 144 [I-D.ietf-stir-passport] mechanism and the work of 146 [I-D.ietf-stir-rfc4474bis] to define a way that a PASSporT object 147 created in the originating network of a call can reach the 148 terminating network even when it cannot be carried end-to-end in-band 149 in the call signaling. This relies on a new service defined in this 150 document that permits the PASSporT object to be stored during call 151 processing and retrieved for verification purposes. 153 2. Terminology 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described in RFC 158 2119 [RFC2119]. 160 3. Operating Environments 162 This section describes the environments in which the proposed 163 mechanism is intended to operate. In the simplest setting, Alice is 164 calling Bob through some set of gateways and/or the PSTN. Both Alice 165 and Bob have smart devices which can be modified, but they do not 166 have a clear connection between them: Alice cannot inject any data 167 into signaling which Bob can read, with the exception of the asserted 168 destination and origination E.164 numbers. The calling party number 169 might originate from her own device or from the network. These 170 numbers are effectively the only data that can be used for 171 coordination between the endpoints. 173 +---------+ 174 / \ 175 +--- +---+ 176 +----------+ / \ +----------+ 177 | | | Gateways | | | 178 | Alice |<----->| and/or |<----->| Bob | 179 | (caller) | | PSTN | | (callee) | 180 +----------+ \ / +----------+ 181 +--- +---+ 182 \ / 183 +---------+ 185 In a more complicated setting, Alice and/or Bob may not have a smart 186 or programmable device, but one or both of them are behind a STIR- 187 aware gateway that can participate in out-of-band coordination, as 188 shown below: 190 +---------+ 191 / \ 192 +--- +---+ 193 +----------+ +--+ / \ +--+ +----------+ 194 | | | | | Gateways | | | | | 195 | Alice |<-|GW|->| and/or |<-|GW|->| Bob | 196 | (caller) | | | | PSTN | | | | (callee) | 197 +----------+ +--+ \ / +--+ +----------+ 198 +--- +---+ 199 \ / 200 +---------+ 202 In such a case, Alice might have an analog connection to her gateway/ 203 switch which is responsible for her identity. Similarly, the gateway 204 would verify Alice's identity, generate the right calling party 205 number information and provide that number to Bob using ordinary POTS 206 mechanisms. 208 4. Dataflows 210 Because in these operating environments endpoints cannot pass 211 cryptographic information to one another directly through signaling, 212 any solution must involve some rendezvous mechanism to allow 213 endpoints to communicate. We call this rendezvous service a "call 214 placement service" (CPS), a service where a record of call placement, 215 in this case a PASSporT, can be stored for future retrieval. In 216 principle this service could communicate any information, but 217 minimally we expect it to include a full-form PASSporT that attests 218 the caller, callee, and the time of the call. The callee can use the 219 existence of a PASSporT for a given incoming call as rough validation 220 of the asserted origin of that call. (See Section 9 for limitations 221 of this design.) 223 There are roughly two plausible dataflow architectures for the CPS: 225 The callee registers with the CPS. When the caller wishes to 226 place a call to the callee, it sends the PASSporT to the CPS, 227 which immediately forwards it to the callee. 229 The caller stores the PASSporT with the CPS at the time of call 230 placement. When the callee receives the call, it contacts the CPS 231 and retrieves the PASSporT. 233 While the first architecture is roughly isomorphic to current VoIP 234 protocols, it shares their drawbacks. Specifically, the callee must 235 maintain a full-time connection to the CPS to serve as a notification 236 channel. This comes with the usual networking costs to the callee 237 and is especially problematic for mobile endpoints. Indeed, if the 238 endpoints had the capabilities to implement such an architecture, 239 they could surely just use SIP or some other protocol to set up a 240 secure session; even if the media were going through the traditional 241 PSTN, a "shadow" SIP session could convey the PASSporT. Thus, we 242 focus on the second architecture in which the PSTN incoming call 243 serves as the notification channel and the callee can then contact 244 the CPS to retrieve the PASSporT. 246 5. Use Cases 248 The following are the motivating use cases for this mechanism. Bear 249 in mind that just as in [I-D.ietf-stir-rfc4474bis] there may be 250 multiple Identity headers in a single SIP INVITE, so there may be 251 multiple PASSporTs in this out-of-band mechanism associated with a 252 single call. For example, a SIP user agent might create a PASSporT 253 for a call with an end user credential, and as the call exits the 254 originating administrative domain the network authentication service 255 might create its own PASSporT for the same call. As such, these use 256 cases may overlap in the processing of a single call. 258 5.1. Case 1: VoIP to PSTN Call 260 A call originates in the SIP world in a STIR-aware administrative 261 domain. The local authentication service for that administrative 262 domain creates a PASSporT which is carried in band in the call per 263 [I-D.ietf-stir-rfc4474bis]. The call is routed out of the 264 originating administrative domain and reaches a gateway to the PSTN. 265 Eventually, the call will terminate on a mobile smartphone that 266 supports this out-of-band mechanism. 268 In this use case, the originating authentication service can store 269 the PASSporT with the appropriate CPS for the target telephone number 270 as a fallback in case SIP signaling will not reach end-to-end. When 271 the destination mobile smartphone receives the call over the PSTN, it 272 consults the CPS and discovers a PASSporT from the originating 273 telephone number waiting for it. It uses this PASSporT to verify the 274 calling party number. 276 5.2. Case 2: Two Smart PSTN endpoints 278 A call originates with an enterprise PBX that has both Internet 279 access and a built-in gateway to the PSTN. It will immediately drop 280 its call to the PSTN, but before it does, it provisions a PASSporT on 281 the CPS associated with the target telephone number. 283 After normal PSTN routing, the call lands on a smart mobile handset 284 that supports the STIR out-of-band mechanism. It queries the 285 appropriate CPS over the Internet to determine if a call has been 286 placed to it by a STIR-aware device. It finds the PASSporT 287 provisioned by the enterprise PBX and uses it to verify the calling 288 party number. 290 5.3. Case 3: PSTN to VoIP Call 292 A call originates with an enterprise PBX that has both Internet 293 access and a built-in gateway to the PSTN. It will immediate drop 294 the call to the PSTN, but before it does, it provisions a PASSporT 295 with the CPS associated with the target telephone number. However, 296 it turns out that the call will eventually route through the PSTN to 297 an Internet gateway, which will translate this into a SIP call and 298 deliver it to an administrative domain with a STIR verification 299 service. 301 In this case, there are two subcases for how the PASSporT might be 302 retrieved. In subcase 1, the Internet gateway that receives the call 303 from the PSTN could query the appropriate CPS to determine if the 304 original caller created and provisioned a PASSporT for this call. If 305 so, it can retrieve the PASSporT and, when it creates a SIP INVITE 306 for this call, add a corresponding Identity header per 307 [I-D.ietf-stir-rfc4474bis]. When the SIP INVITE reaches the 308 destination administrative domain, it will be able to verify the 309 PASSporT normally. Note that to avoid discrepancies with the Date 310 header field value, only full-form PASSporT should be used for this 311 purpose. In subcase 2, the gateway does not retrieve the PASSporT 312 itself, but instead the verification service at the destination 313 administrative domain does so. Subcase 1 would perhaps be valuable 314 for deployments where the destination administrative domain supports 315 in-band STIR but not out-of-band STIR. 317 5.4. Case 4: Gateway Out-of-band 319 A call originates in the SIP world in a STIR-aware administrative 320 domain. The local authentication service for that administrative 321 domain creates a PASSporT which is carried in band in the call per 322 [I-D.ietf-stir-rfc4474bis]. The call is routed out of the 323 originating administrative domain and eventually reaches a gateway to 324 the PSTN. 326 In this case, the originating authentication service does not support 327 the out-of-band mechanism, so instead the gateway to the PSTN 328 extracts the PASSporT from the SIP request and provisions it to the 329 CPS. (When the call reaches the gateway to the PSTN, the gateway 330 might first check the CPS to see if a PASSporT object had already 331 been provisioned for this call, and only provision a PASSporT if none 332 is present). 334 Ultimately, the call may terminate on the PSTN, or be routed back to 335 the IP world. In the former case, perhaps the destination endpoints 336 queries the CPS to retrieve the PASSporT provisioned by the first 337 gateway. Or if the call ultimately returns to the IP world, it might 338 be the gateway from the PSTN back to the Internet that retrieves the 339 PASSporT from the CPS and attaches it to the new SIP INVITE it 340 creates, or it might be the terminating administrative domain's 341 verification service that checks the CPS when an INVITE arrives with 342 no Identity header field. Either way the PASSporT can survive the 343 gap in SIP coverage caused by the PSTN leg of the call. 345 6. Storing and Retrieving PASSporTs 347 The use cases show a variety of entities accessing the CPS to store 348 and retrieve PASSporTs. The question of how the CPS authorizes the 349 storage and retrieval of PASSporT is thus a key design decision in 350 the architecture. Broadly, the architecture described here is one 351 focused on permitting any entity to store encrypted PASSporTs at the 352 CPS, indexed under the caller number. PASSporTs will be encrypted 353 with associated with the called number, so these PASSporTs may also 354 be retrieved by any entity, as only holders of the corresponding 355 private key will be able to decrypt the PASSporT. This also prevents 356 the CPS itself from learning the contents of PASSporTs, and thus 357 metadata about calls in progress, which would make the CPS a less 358 attractive target for pervasive monitoring (see [RFC7258]). Ho 359 bolster the privacy story, prevent denial-of-service flooding of the 360 CPS, and to complicate traffic analysis, a few additional mechanisms 361 are also recommended. 363 The STIR architecture assumes that service providers and in some 364 cases end user devices will have credentials suitable for attesting 365 authority over telephone numbers per [I-D.ietf-stir-certificates]. 366 These credentials provide the most obvious way that a CPS can 367 authorize the storage and retrieval of PASSporTs. However, as use 368 cases 3 and 4 in Section 5 show, it may sometimes make sense for the 369 entity storing or retrieving PASSporTs to be an intermediary rather 370 than a device associated with either the originating or terminating 371 side of a call, and those intermediaries often would not have access 372 to STIR credentials covering the telephone numbers in question. 373 Requiring authorization based on a credential to store PASSporTs is 374 therefore undesirable, though potentially acceptible if sufficient 375 steps are taken to mitigate the privacy risk as described in the next 376 section. 378 Furthermore, it is an explicit design goal of this mechanism to 379 minimize the potential privacy exposure of using a CPS. Ideally, the 380 out-of-band mechanism should not result in a worse privacy situation 381 than in-band [I-D.ietf-stir-rfc4474bis] STIR: for in-band, we might 382 say that a SIP entity is authorized to receive a PASSporT if it is an 383 intermediate or final target of the routing of a SIP request. As the 384 originator of a call cannot necessarily predict the routing path a 385 call will follow, an out-of-band mechanism could conceivably even 386 improve on the privacy story. As a first step, transport-level 387 security can provide confidentiality from eavesdroppers for both the 388 storage and retrieval of PASSporTs. 390 6.1. Storage 392 For authorizing the storage of PASSporTs, the architecture can permit 393 some flexibility. Note that in this architecture a CPS has no way to 394 tell if a PASSporT is valid; it simply conveys encrypted blocks that 395 it cannot access itself. In that architecture, it does not matter 396 whether the CPS received a PASSporT from the authentication service 397 that created it or from an intermediary gateway downstream in the 398 routing path as in case 4. 400 Note that this architecture requires clients that stores PASSporTs to 401 have access to a public key associated with the intended called party 402 to be used to encrypt the PASSporT. Discovering this key requires 403 some new service that does not exist today; depending on how the CPS 404 is architected, however, some kind of key store or repository could 405 be implemented adjacent to it, and perhaps even incorporated into its 406 operation. Key discovery is made more complicated by the fact that 407 there can potentially be multiple entities that have authority over a 408 telephone number: a carrier, a reseller, an enterprise, and an end 409 user might all have credentials permitting them to attest that they 410 are allowed to originate calls from a number, say. PASSporTs 411 therefore might need to be encrypted with multiple keys in the hopes 412 that one will be decipherable by the relying party. 414 However, if literally anyone can store PASSporTs in the CPS, an 415 attacker could easily flood the CPS with millions of bogus PASSporTs 416 indexed under a target number, and thereby prevent that called party 417 from finding a valid PASSporT for an incoming call buried in a 418 haystack of fake entries. A CPS must therefore implement some sort 419 of traffic control system to prevent flooding. Preferably, this 420 should not require authenticating the source, as this will reveal to 421 the CPS both ths source and destination of traffic. 423 In order to do this, we propose the use of "blind signatures". A 424 sender will initially authenticate to the CPS, and acquire a signed 425 token for the CPS that will be presented later when storing a 426 PASSporT. The flow looks as follows: 428 Sender CPS 430 Authenticate to CPS ---------------------> 431 Blinded(K_temp) -------------------------> 432 <------------- Sign(K_cps, Blinded(K_temp)) 433 [Disconnect] 435 Sign(K_cps, K_temp)) 436 Sign(K_temp, E(K_receiver, PASSporT)) ---> 438 At an initial time when no call is yet in progress, a potential 439 client connects to the CPS, authenticates, and sends a blinded 440 version of a freshly generated public key. The CPS returns a signed 441 version of that blinded key. The sender can then unblind the key and 442 gets a signature on K_temp from the CPS 444 Then later, when a client wants to store a PASSporT, it connects to 445 the CPS anonymously (preferably over a network connection that cannot 446 be correlated with the token acquisition) and sends both the signed 447 K_temp and its own signature over the encrypted PASSporT. The CPS 448 verifies both signatures and if they verify, stores the encrypted 449 passport (discarding the signatures). 451 This design lets the CPS rate limit how many PASSporTs a given sender 452 can store just by counting how many times K_temp appears; perhaps CPS 453 policy might reject storage attempts and require acqusition of a new 454 K_temp after storing more than a certain number of PASSporTs indexed 455 under the same destination number in a short interval. This does not 456 of course allow the CPS to tell when bogus data is being provisioned 457 by an attacker, simply the rate at which data is being provisioned. 458 Potentially, feedback mechanisms could be developed that would allow 459 the called parties to tell the CPS when they are receiving unusual or 460 bogus PASSporTs. 462 This architecture also assumes that the CPS will age out PASSporTs. 463 A CPS SHOULD NOT keep any stored PASSporT for more than sixty 464 seconds. Any reduction in this window makes substitution attacks 465 (see Section 7.4) harder to mount, but making the window too small 466 might conceivably age PASSporTs out while a heavily redirected call 467 is still alerting. harder to mount 469 6.2. Retrieval 471 For retrieval of PASSporTs, this architecture assumes that clients 472 contact the CPS to send requests of the form: 474 Are there any current PASSporTs for calls destined to 475 2.222.222.2222? 477 As all PASSporTs stored at the CPS are encrypted with a key belonging 478 to the intended destination, then potentially the CPS could allow 479 anyone to download PASSporTs for a called number without much fear of 480 compromising private information about calls in progress - provided 481 that the CPS always provides at least one encrypted blob in response 482 to a request, even if there was no call in progress. Otherwise, 483 entities could poll the CPS constantly, or eavesdrop on traffic, to 484 learn whether or not calls were in progress. The CPS MUST generate 485 at least one unique and plausible encrypted response to all retrieval 486 requests, and these dummy encrypted PASSporTs MUST NOT be repeated 487 for later calls. 489 Because the entity placing a call may discover multiple keys 490 associated with the called party number, multiple valid PASSporTs may 491 be stored in the CPS. A particular called party who retrieves 492 PASSporTs from the CPS may have access to only one of those keys. 493 Thus, the presence of one or more PASSporTs that the called party 494 cannot decrypt - which would be indistinguishable from the "dummy" 495 PASSporTS created by the CPS when no calls are in progress - does not 496 entail that there is no call in progress. A retriever likely will 497 need decrypt all PASSporTs retrieved from the CPS, and may find only 498 one that is valid. 500 Note that in call forwarding cases, the difficulties in managing the 501 relationship between PASSporTs with the diversion extension 502 [I-D.ietf-stir-passport-divert] become more serious. The originating 503 authentication service would encrypt the PASSporT with the public key 504 of the intended destination, but when a call is forwarded, it may go 505 to a destination that does not possess the corresponding private key. 506 This requires special behavior on the part of the retargeting entity, 507 and probably the CPS as well, to accommodate encrypted PASSporTs that 508 show a secure chain of diversion. A storer could for example notify 509 the CPS that the divert PASSporT it is storing relates to a specific 510 PASSporT already in the CPS, but in so doing, the storer will 511 inevitably reveal more metadata to the CPS. 513 7. Solution Architecture 515 In this section, we discuss a strawman architecture for providing the 516 service described in the previous sections. This discussion is 517 deliberately sketchy, focusing on broad concepts and skipping over 518 details. The intent here is merely to provide an overall 519 architecture, not an implementable specification. 521 7.1. Credentials and Phone Numbers 523 We start from the premise of the STIR problem statement [RFC7340] 524 that phone numbers can be associated with credentials which can be 525 used to attest ownership of numbers. For purposes of exposition, we 526 will assume that ownership is associated with the endpoint (e.g., a 527 smartphone) but it might well be associated with a provider or 528 gateway acting for the endpoint instead. It might be the case that 529 multiple entities are able to act for a given number, provided that 530 they have the appropriate authority. [I-D.ietf-stir-certificates] 531 describes a credentials system suitable for this purpose; the 532 question of how an entity is determined to have control of a given 533 number is out of scope for the current document. 535 7.2. Call Flow 537 An overview of the basic calling and verification process is shown 538 below. In this diagram, we assume that Alice has the number 539 +1.111.111.1111 and Bob has the number +2.222.222.2222. 541 Alice Call Placement Service Bob 542 ----------------------------------------------------------------------- 544 Store PASSporT for 2.222.222.2222--> 546 Call from 1.111.111.1111 ---------------------------------------------> 548 <------------- Retrieve PASSporT(s) 549 for 2.222.222.2222? 551 Encrypted PASSporT 552 -(2.222.222.2222,1.111.111.1111)--> 554 [Ring phone with callerid 555 = 1.111.111.1111] 557 When Alice wishes to make a call to Bob, she contacts the CPS and 558 stores an encrypted PASSporT on the CPS indexed under Bob's number. 559 The CPS then awaits retrievals for that number. 561 Once Alice has stored the PASSporT, she then places the call to Bob 562 as usual. At this point, Bob's phone would usually ring and display 563 Alice's number (+1.111.111.1111), which is informed by the existing 564 PSTN mechanisms for relying a calling party number (i.e., the CIN 565 field of the IAM). Instead, Bob's phone transparently contacts the 566 CPS and requests any current PASSporTs for calls to his number. The 567 CPS responds with any such PASSporTs (assuming they exist). If such 568 a PASSpoRT exists, and the verification service in Bob's phone 569 decrypts it using his private key, validates it, then Bob's phone can 570 then present the calling party number information as valid. 571 Otherwise, the call is unverifiable. Note that this does not 572 necessarily mean that the call is bogus; because we expect 573 incremental deployment many legitimate calls will be unverifiable. 575 7.3. Security Analysis 577 The primary attack we seek to prevent is an attacker convincing the 578 callee that a given call is from some other caller C. There are two 579 scenarios to be concerned with: 581 The attacker wishes to impersonate a target when no call from that 582 target is in progress. 584 The attacker wishes to substitute himself for an existing call 585 setup as described in Section 7.4. 587 If an attacker can inject fake PASSporT into the CPS or in the 588 communication from the CPS to the callee, he can mount either attack. 589 As PASSporTs should be digitally signed by an appropriate authority 590 for the number and verified by the callee (see Section 7.1), this 591 should not arise in ordinary operations. For privacy and robustness 592 reasons, using TLS on the originating side when storing the PASSporT 593 at the CPS is recommended. 595 The entire system depends on the security of the credential 596 infrastructure. If the authentication credentials for a given number 597 are compromised, then an attacker can impersonate calls from that 598 number. However, that is no different from in-band 599 [I-D.ietf-stir-rfc4474bis] STIR. 601 7.4. Substitution Attacks 603 All that receipt of the PASSporT from the CPS proves to the called 604 party is that Alice is trying to call Bob (or at least was as of very 605 recently) - it does not prove that any particular incoming call is 606 from Alice. Consider the scenario in which we have a service which 607 provides an automatic callback to a user-provided number. In that 608 case, the attacker can try to arrange for a false caller-id value, as 609 shown below: 611 Attacker Callback Service CPS Bob 612 ----------------------------------------------------------------------- 613 Place call to Bob ----------> 615 Store PASSporT for 616 CS:Bob --------------> 618 Call from CS (forged caller-id info) --------------------------------> 620 Call from CS ---------------------------> X 622 <----- Retrieve PASSporT 623 for CS:Bob 625 PASSporT for CS:Bob ---------------------------> 627 [Ring phone with callerid = CS] 629 In order to mount this attack, the attacker contacts the Callback 630 Service (CS) and provides it with Bob's number. This causes the CS 631 to initiate a call to Bob. As before, the CS contacts the CPS to 632 insert an appropriate PASSporT and then initiates a call to Bob. 633 Because it is a valid CS injecting the PASSporT, none of the security 634 checks mentioned above help. However, the attacker simultaneously 635 initiates a call to Bob using forged caller-id information 636 corresponding to the CS. If he wins the race with the CS, then Bob's 637 phone will attempt to verify the attacker's call (and succeed since 638 they are indistinguishable) and the CS's call will go to busy/voice 639 mail/call waiting. Note: in a SIP environment, the callee might 640 notice that there were multiple INVITEs and thus detect this attack. 642 8. Call Placement Service Discovery 644 In order for the two ends of the out-of-band dataflow to coordinate, 645 they must agree on a way to discover a CPS and retrieve PASSporT 646 objects from it based solely on the rendezvous information available: 647 the calling party number and the called number. Because the storage 648 of PASSporTs in this architecture is indexed by the called party 649 number, it makes sense to discover a CPS based on the called party 650 number as well. There are a number of potential service discovery 651 mechanisms that could be used for this purpose. The means of service 652 discovery may vary by use case. 654 Although the discussion above is written in terms of a single CPS, 655 having a significant fraction of all telephone calls result in 656 storing and retrieving PASSporTs at a single monolithic CPS has 657 obvious scaling problems, and would as well allow the CPS to gather 658 metadata about a very wide set of callers and callees. These issues 659 can be alleviated by operational models with a federated CPS; any 660 service discovery mechanism for out-of-band STIR should enable 661 federation of the CPS function. 663 Some service discovery possibilities under consideration include the 664 following: 666 If a credential lookup service is already available (see 667 Section 9), the CPS location can also be recorded in the callee's 668 credentials; an extension to [I-D.ietf-stir-certificates] could 669 for example provide a link to the location of the CPS where 670 PASSporTs should be stored for a destination. 672 There exist a number of common directory systems that might be 673 used to translate telephone numbers into the URIs of a CPS. ENUM 674 [RFC6116] is commonly implemented, though no "golden root" central 675 ENUM administration exists that could be easily reused today to 676 help the endpoints discover a common CPS. Other protocols 677 associated with queries for telephone numbers, such as the TeRI 678 [I-D.peterson-modern-teri] protocol, could also serve for this 679 application. 681 Another possibility is to use a single distributed service for 682 this function. VIPR [I-D.rosenberg-dispatch-vipr-overview] 683 proposed a RELOAD [RFC6940] usage for telephone numbers to help 684 direct calls to enterprises on the Internet. It would be possible 685 to describe a similar RELOAD usage to identify the CPS where calls 686 for a particular telephone number should be stored. One advantage 687 that the STIR architecture has over VIPR is that it assumes a 688 credential system that proves authority over telephone numbers; 689 those credentials could be used to determine whether or not a CPS 690 could legitimately claim to be the proper store for a given 691 telephone number. 693 Future versions of this specification will identify suitable service 694 discovery mechanisms for out-of-band STIR. 696 9. Credential Lookup 698 In order to encrypt a PASSporT (see Section 6.1), the caller needs 699 access to the callee's credentials (specifically their public key). 700 This requires some sort of directory/lookup system. This document 701 does not specify any particular scheme, but a list of requirements 702 would be something like: 704 Obviously, if there is a single central database and the caller and 705 callee each contact it in real time to determine the other's 706 credentials, then this represents a real privacy risk, as the central 707 database learns about each call. A number of mechanisms are 708 potentially available to mitigate this: 710 Have endpoints pre-fetch credentials for potential counterparties 711 (e.g., their address book or the entire database). 713 Have caching servers in the user's network that proxy their 714 fetches and thus conceal the relationship between the user and the 715 credentials they are fetching. 717 Clearly, there is a privacy/timeliness tradeoff in that getting up- 718 to-date knowledge about credential validity requires contacting the 719 credential directory in real-time (e.g., via OCSP). This is somewhat 720 mitigated for the caller's credentials in that he can get short-term 721 credentials right before placing a call which only reveals his 722 calling rate, but not who he is calling. Alternately, the CPS can 723 verify the caller's credentials via OCSP, though of course this 724 requires the callee to trust the CPS's verification. This approach 725 does not work as well for the callee's credentials, but the risk 726 there is more modest since an attacker would need to both have the 727 callee's credentials and regularly poll the database for every 728 potential caller. 730 We consider the exact best point in the tradeoff space to be an open 731 issue. 733 10. Acknowledgments 735 The ideas in this document come out of discussions with Richard 736 Barnes and Cullen Jennings. We'd also like to thank Robert Sparks 737 for helpful suggestions. 739 11. IANA Considerations 741 This memo includes no request to IANA. 743 12. Security Considerations 745 This entire document is about security, but the detailed security 746 properties depend on having a single concrete scheme to analyze. 748 13. Informative References 750 [I-D.ietf-stir-certificates] 751 Peterson, J. and S. Turner, "Secure Telephone Identity 752 Credentials: Certificates", draft-ietf-stir- 753 certificates-14 (work in progress), May 2017. 755 [I-D.ietf-stir-passport] 756 Wendt, C. and J. Peterson, "Personal Assertion Token 757 (PASSporT)", draft-ietf-stir-passport-11 (work in 758 progress), February 2017. 760 [I-D.ietf-stir-passport-divert] 761 Peterson, J., "PASSporT Extension for Diverted Calls", 762 draft-ietf-stir-passport-divert-00 (work in progress), 763 July 2017. 765 [I-D.ietf-stir-rfc4474bis] 766 Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 767 "Authenticated Identity Management in the Session 768 Initiation Protocol (SIP)", draft-ietf-stir-rfc4474bis-16 769 (work in progress), February 2017. 771 [I-D.peterson-modern-teri] 772 Peterson, J., "An Architecture and Information Model for 773 Telephone-Related Information (TeRI)", draft-peterson- 774 modern-teri-03 (work in progress), July 2017. 776 [I-D.rosenberg-dispatch-vipr-overview] 777 Rosenberg, J., Jennings, C., and M. Petit-Huguenin, 778 "Verification Involving PSTN Reachability: Requirements 779 and Architecture Overview", draft-rosenberg-dispatch-vipr- 780 overview-04 (work in progress), October 2010. 782 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 783 Requirement Levels", BCP 14, RFC 2119, 784 DOI 10.17487/RFC2119, March 1997, 785 . 787 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 788 A., Peterson, J., Sparks, R., Handley, M., and E. 789 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 790 DOI 10.17487/RFC3261, June 2002, 791 . 793 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 794 Uniform Resource Identifiers (URI) Dynamic Delegation 795 Discovery System (DDDS) Application (ENUM)", RFC 6116, 796 DOI 10.17487/RFC6116, March 2011, 797 . 799 [RFC6940] Jennings, C., Lowekamp, B., Ed., Rescorla, E., Baset, S., 800 and H. Schulzrinne, "REsource LOcation And Discovery 801 (RELOAD) Base Protocol", RFC 6940, DOI 10.17487/RFC6940, 802 January 2014, . 804 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 805 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 806 2014, . 808 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 809 Telephone Identity Problem Statement and Requirements", 810 RFC 7340, DOI 10.17487/RFC7340, September 2014, 811 . 813 Authors' Addresses 815 Eric Rescorla 816 Mozilla 818 Email: ekr@rtfm.com 820 Jon Peterson 821 Neustar, Inc. 822 1800 Sutter St Suite 570 823 Concord, CA 94520 824 US 826 Email: jon.peterson@neustar.biz