idnits 2.17.1 draft-ietf-stir-servprovider-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 22, 2021) is 1160 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-stir-passport-divert' is defined on line 329, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 339, but no explicit reference was found in the text == Unused Reference: 'RFC3311' is defined on line 345, but no explicit reference was found in the text == Unused Reference: 'RFC4916' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 353, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-ietf-stir-cert-delegation-03 -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Peterson 3 Internet-Draft Neustar 4 Intended status: Informational February 22, 2021 5 Expires: August 26, 2021 7 Out-of-Band STIR for Service Providers 8 draft-ietf-stir-servprovider-oob-01 10 Abstract 12 The Secure Telephone Identity Revisited (STIR) framework defines 13 means of carrying its Persona Assertion Tokens (PASSporTs) either in- 14 band, within the headers of a SIP request, or out-of-band, through a 15 service that stores PASSporTs for retrieval by relying parties. This 16 specification defines a way that the out-of-band conveyance of 17 PASSporTs can be used to support large service providers, for cases 18 in which in-band STIR conveyance is not universally available. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on August 26, 2021. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (https://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Service Provider Deployment Architecture for Out-of-Band STIR 3 57 4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 3 58 5. Submitting a PASSporT . . . . . . . . . . . . . . . . . . . . 5 59 6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 6 60 7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 11. Informative References . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 STIR [RFC8224] provides a cryptographic assurance of the identity of 70 calling parties in order to prevent impersonation, which is a key 71 enabler of unwanted robocalls, swatting, vishing, voicemail hacking, 72 and similar attacks (see [RFC7340]). The STIR out-of-band 73 [I-D.ietf-stir-oob] framework enables the delivery of PASSporT 74 [RFC8225] objects through a Call Placement Service (CPS), rather than 75 carrying them within a signaling protocol such as SIP. Out-of-band 76 conveyance is valuable when end-to-end SIP delivery of calls is 77 partly or entirely unavailable due to network border policies, calls 78 routinely transitting a gateway to the PSTN, or similar 79 circumstances. 81 While out-of-band STIR can be implemented as an open Internet 82 service, it then requires complex security measures to enable the CPS 83 function without allowing the CPS to collect data about the parties 84 placing calls. This specification describes CPS implementations that 85 act specifically on behalf of service providers who will be 86 processing the calls that STIR secures, and who thus will learn about 87 the parties to communication independently, so an alternative 88 security architecture becomes possible. These functions may be 89 crucial to the adoption of STIR in some environments, like mobile 90 networks, where in-band transmission of STIR may not be feasible. 92 Environments that might support this flavor of STIR out-of-band 93 include carriers, large enterprises, call centers, or any Internet 94 service that aggregates on behalf of a large number of telephone 95 endpoints. That last case may include certain classes of gateway or 96 transit providers. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 106 3. Service Provider Deployment Architecture for Out-of-Band STIR 108 The architecture in this specification assumes that every 109 participating service provider is associated with one or more 110 designated CPS instances. A service provider's CPS serves as a place 111 where callers, or in some cases gateways, can deposit a PASSporT when 112 attempting to place a call to a subscriber of the destination service 113 provider; if the caller's domain supports in-band STIR, this can be 114 done at the same time as an in-band STIR call is placed. The 115 terminating service provider could operate the CPS themselves, or a 116 third party could operate the CPS on the destination's behalf. This 117 model does not assume a monolithic CPS that acts on behalf of all 118 service providers, but nor does it prohibit multiple service 119 providers from sharing a CPS provider. Moreover, a particular CPS 120 can be a logically distributed entity compromised of several 121 geographically distant entities that flood PASSporTs among themselves 122 to support an anycast-like service. 124 The process of locating a destination CPS and submitting a PASSporT 125 naturally requires Internet connectivity to the CPS. If the CPS is 126 deployed in the terminating service provider network, that network 127 connectivity could be leveraged by a caller to initiate a SIP 128 session, during which in-band STIR could be used normally. The 129 applicability of this architecture is therefore to those cases where, 130 for whatever reason, SIP requests cannot reliably convey PASSporTs 131 end-to-end, but an HTTP transaction can reliably be sent to the 132 destination network from the out-of-band authentication service (OOB- 133 AS). It is hoped that as IP connectivity between telephone providers 134 increases, there will be less need for an out-of-band mechanism, but 135 it can serve as a fallback mechanism in cases where service providers 136 cannot predict whether end-to-end delivery of SIP calls will occur. 138 4. Advertising a CPS 140 If more than one CPS exists for a given deployment, there will need 141 to be some means of discovering CPSs, either administratively or 142 programmatically. Many services providers have bilateral agreements 143 to peer with one another, and in those environments, identifying 144 their respective CPS's could be a simple matter of provisioning. A 145 consortium of service providers could simply agree to choose from a 146 list of available CPS providers, say. In more pluralist 147 environments, some mechanism is needed to discover the CPS associated 148 with the target of a call. 150 In order to allow the CPS chosen by a service provider to be 151 discovered securely, this specification defines a CPS advertisement. 152 Effectively, a CPS advertisement is a document which contains the URL 153 of a CPS, as well as any information needed to determine which 154 PASSporTs should be submitted to that CPS (e.g., Service Provider 155 Codes (SPCs) or telephone number ranges). An advertisement may be 156 signed with a STIR [RFC8226] credential, or another credential that 157 is trusted by the participants in a given STIR environment. The 158 advantage to signing with STIR certificates is that they contain a 159 "TNAuthList" value indicating the telephone network resources that a 160 service provider controls. This information can be matched with a 161 TNAuthList value in the CPS advertisement to determine whether the 162 signer has the authority to advertise a particular CPS as the proper 163 destination for PASSporTs. 165 The format of a service provider CPS advertisement is a simple JSON 166 object containing one or more pairs of TNAuthList values pointing to 167 the URIs of CPSs, e.g. { "1234":"https://cps.example.com" }. 168 TNAuthList values can be either Service Provider Codes (SPCs) or 169 telephone numbers or number ranges. CPS URIs MUST be HTTPS URIs. 170 These CPS URIs SHOULD be publicly reachable, as service providers 171 cannot usually anticipate all of the potential callers that might 172 want to connect with them, but in more constrained environments, they 173 MAY be only reachable over a closed network. 175 CPS advertisements could be made available through existing or new 176 databases, potentially aggregated across multiple service providers 177 and distributed to call originators as necessary. They could be 178 discovered during the call routing process, including through a DNS 179 lookup. They could be shared through a distributed database among 180 the participants in a multilateral peering arrangement. 182 An alternative to CPS advertisements that may be usable in some 183 environments is adding a field to STIR [RFC8226] certificates 184 identifying the CPS URI issued to individual service providers. As 185 these certificates are themselves signed by a CA, and contain their 186 own TNAuthList, the URI would be bound securely to the proper 187 telephone network identifiers. As STIR assumes a community of 188 relying parties who trust these credentials, this method perhaps best 189 mirrors the trust model required to allow a CPS to authorize PASSporT 190 submission and retrieval. 192 5. Submitting a PASSporT 194 Submitting a PASSporT to a CPS as specified in the STIR out-of-band 195 framework [I-D.ietf-stir-oob] requires security measures which are 196 intended to prevent the CPS from learning the identity of the caller 197 (or callee), to the degree possible. In this service provider case, 198 however, the CPS is operated by the service provider of the callee 199 (or an entity operating on their behalf), and as such the information 200 that appears in the PASSporT is redundant with call signaling that 201 the terminating party will receive anyway. Therefore, the service 202 provider out-of-band framework does not attempt to conceal the 203 identity of the originating or terminating party from the CPS. 205 An out-of-band authentication service (OOB-AS) forms a secure 206 connection with the target CPS. This may happen at the time a call 207 is being placed, or it may be a persistent connection, if there is a 208 significant volume of traffic sent over this interface. The OOB-AS 209 SHOULD authenticate itself to the CPS via mutual TLS using its STIR 210 credential [RFC8226], the same one it would use to sign calls; this 211 helps mitigate the risk of flooding that more open OOB 212 implementations may face. Furthermore, use of mutual TLS prevents 213 attackers from replaying captured PASSporTs to the CPS. A CPS makes 214 its own policy decision as to whether it will accept calls from a 215 particular OOB-AS, and at what volumes. A CPS can use this mechanism 216 can authorize service providers who already hold STIR credentials to 217 submit PASSporTs to a CPS, but alternative mechanisms would be 218 required for any entities that do not hold a STIR credential, 219 including gateway or transit providers who want to submit PASSporTs. 220 See Section 7 below for more on their behavior. 222 Service provider out-of-band PASSporTs do not need to be encrypted 223 for storage at the CPS, although use of transport-layer security to 224 prevent eavesdropping on the connection between the CPS and OOB-ASs 225 is REQUIRED. PASSporTs will typically be submitted to the CPS at the 226 time they are created by an AS; if the PASSporT is also being used 227 for in-band transit within a SIP request, the PASSporT can be 228 submitted to the CPS before or after the SIP request is sent, at the 229 discretion of the originating domain. An OOB-AS will use a REST 230 interface to submit PASSporTs to the CPS as described in 231 [I-D.ietf-stir-oob] Section 9 [more TBD]. PASSporTs persist at the 232 CPS for as long as is required for them to be retrieved (see the next 233 section), but in any event for no longer than the freshness interval 234 of the PASSporT itself (a maximum of sixty seconds). 236 6. PASSporT Retrieval 238 The STIR out-of-band framework [I-D.ietf-stir-oob] proposes two means 239 that called parties can acquire PASSporTs out-of-band: through a 240 retrieval interface, or through a subscription interface. In the 241 service provider context, where many calls to or from the same number 242 may pass through a CPS simultaneous, an out-of-band capable 243 verification service may therefore operate in one of two modes: it 244 can either pull PASSporTs from the CPS after calls arrive, or receive 245 push notifications from the CPS for incoming calls. 247 If a CPS serves only one service provider, then all PASSporTs 248 submitted to the CPS are made available to the OOB-VS of that 249 provider; indeed, the CPS and OOB-VS may be colocated or effectively 250 operated as a consolidated system. In a multi-provider environment, 251 the STIR credential of the terminating domain can be used by the CPS 252 to determine the range of TNAuthLists for which an OOB-VS is entitled 253 to receive PASSporTs; this may be through a mechanism like mutual 254 TLS, or through using the STIR credential to sign a token that is 255 submitted to the CPS by the retrieving OOB-VS. Note that a multi- 256 provider CPS will need to inspect the "dest" element of a PASSporT to 257 determine which OOB-VS should receive the PASSporT. 259 [TBD: Which sub/not protocol to use for the case where the CPS and 260 OOB-VS are not composed in a single function?] 262 Pulling of PASSporTs from the CPS will follow the basic REST flow 263 described in [I-D.ietf-stir-oob] Section 9. Exactly how a CPS 264 determines which PASSporTs an OOB-VS is eligible to receive is a 265 matter of implementation. An OOB-VS could for example subscribe to a 266 range of telephone numbers, which will be directed to that OOB-VS by 267 the CPS (provided the OOB-VS is authorized to receive them by the 268 CPS). In the pull model, a terminating service provider polls the 269 CPS via its OOB-VS after having received a call, in those cases where 270 the call signaling does not itself carry a PASSporT. In the push 271 model, a PASSporT might be sent to the OOB-VS either before or after 272 unsigned call signaling has been received by the terminating domain. 273 Domains using the push model may therefore need to adopt a model 274 where the display of call verification for alerting is held 275 momentarily in order to await the potential arrival of a PASSporT at 276 the OOB-VS. The exact timing of this, and its interaction with the 277 substitution attack described in [I-D.ietf-stir-oob] Section 7.4, 278 will be the covered by future versions of this specification. 280 7. Gateways 282 In some deployment architectures, gateways might perform a function 283 that interfaces with a CPS for the retrieval or storage of PASSporTs, 284 especially in cases when in-band STIR service providers need to 285 exchange secure calls with providers that can only be reached by STIR 286 out-of-band. For example, a closed network of in-band STIR providers 287 may send SIP INVITEs to a gateway in front of a traditional PSTN 288 tandem that services a set of legacy service providers. In that 289 environment, a gateway might extract a PASSporT from an in-band SIP 290 INVITE and store it in a CPS that was established to handle requests 291 for one or more legacy providers, who in turn consume those PASSporTs 292 through an OOB-VS to assist in robocall mitigation and similar 293 functions. 295 The simplest way to interface a gateway performing this sort of 296 function for a service provider CPS system is to issue credentials to 297 the gateway that allow it to act on behalf of the legacy service 298 providers it supports: this would allow it to both add PASSporTs to 299 the CPS acting on behalf of the legacy providers, and also to create 300 PASSporTs for in-band STIR conveyance from the legacy-providers to 301 terminating service providers in the closed STIR network. For 302 example, a service provider could issue a delegate certificate 303 [I-D.ietf-stir-cert-delegation] for this purpose. 305 8. Acknowledgments 307 We would like to thank Alex Fenichel for contributions to this 308 specification. 310 9. IANA Considerations 312 This memo includes no request to IANA. 314 10. Security Considerations 316 It is the aim of this mechanism to provide 318 11. Informative References 320 [I-D.ietf-stir-cert-delegation] 321 Peterson, J., "STIR Certificate Delegation", draft-ietf- 322 stir-cert-delegation-03 (work in progress), July 2020. 324 [I-D.ietf-stir-oob] 325 Rescorla, E. and J. Peterson, "STIR Out-of-Band 326 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 327 in progress), March 2020. 329 [I-D.ietf-stir-passport-divert] 330 Peterson, J., "PASSporT Extension for Diverted Calls", 331 draft-ietf-stir-passport-divert-09 (work in progress), 332 July 2020. 334 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 335 Requirement Levels", BCP 14, RFC 2119, 336 DOI 10.17487/RFC2119, March 1997, 337 . 339 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 340 A., Peterson, J., Sparks, R., Handley, M., and E. 341 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 342 DOI 10.17487/RFC3261, June 2002, 343 . 345 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 346 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 347 2002, . 349 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 350 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 351 2007, . 353 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 354 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 355 2014, . 357 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 358 Telephone Identity Problem Statement and Requirements", 359 RFC 7340, DOI 10.17487/RFC7340, September 2014, 360 . 362 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 363 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 364 May 2017, . 366 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 367 "Authenticated Identity Management in the Session 368 Initiation Protocol (SIP)", RFC 8224, 369 DOI 10.17487/RFC8224, February 2018, 370 . 372 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 373 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 374 . 376 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 377 Credentials: Certificates", RFC 8226, 378 DOI 10.17487/RFC8226, February 2018, 379 . 381 Author's Address 383 Jon Peterson 384 Neustar, Inc. 386 Email: jon.peterson@neustar.biz