idnits 2.17.00 (12 Aug 2021) /tmp/idnits30626/draft-ietf-stir-servprovider-oob-02.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 document date (21 April 2022) is 23 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3261' is defined on line 347, 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 == Unused Reference: 'RFC3311' is defined on line 383, but no explicit reference was found in the text == Unused Reference: 'RFC4916' is defined on line 387, but no explicit reference was found in the text == Unused Reference: 'RFC8946' is defined on line 400, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). 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 21 April 2022 5 Expires: 23 October 2022 7 Out-of-Band STIR for Service Providers 8 draft-ietf-stir-servprovider-oob-02 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 23 October 2022. 37 Copyright Notice 39 Copyright (c) 2022 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 (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Service Provider Deployment Architecture for Out-of-Band 56 STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . . . . . . . . . . . . 8 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 11.1. Normative References . . . . . . . . . . . . . . . . . . 8 66 11.2. Informative References . . . . . . . . . . . . . . . . . 9 67 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 69 1. Introduction 71 STIR [RFC8224] provides a cryptographic assurance of the identity of 72 calling parties in order to prevent impersonation, which is a key 73 enabler of unwanted robocalls, swatting, vishing, voicemail hacking, 74 and similar attacks (see [RFC7340]). The STIR out-of-band [RFC8816] 75 framework enables the delivery of PASSporT [RFC8225] objects through 76 a Call Placement Service (CPS), rather than carrying them within a 77 signaling protocol such as SIP. Out-of-band conveyance is valuable 78 when end-to-end SIP delivery of calls is partly or entirely 79 unavailable due to network border policies, calls routinely 80 transitting a gateway to the PSTN, or similar circumstances. 82 While out-of-band STIR can be implemented as an open Internet 83 service, it then requires complex security measures to enable the CPS 84 function without allowing the CPS to collect data about the parties 85 placing calls. This specification describes CPS implementations that 86 act specifically on behalf of service providers who will be 87 processing the calls that STIR secures, and who thus will learn about 88 the parties to communication independently, so an alternative 89 security architecture becomes possible. These functions may be 90 crucial to the adoption of STIR in some environments, like mobile 91 networks, where in-band transmission of STIR may not be feasible. 93 Environments that might support this flavor of STIR out-of-band 94 include carriers, large enterprises, call centers, or any Internet 95 service that aggregates on behalf of a large number of telephone 96 endpoints. That last case may include certain classes of gateway or 97 transit providers. 99 2. Terminology 101 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 102 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 103 "OPTIONAL" in this document are to be interpreted as described in BCP 104 14 [RFC2119] [RFC8174] when, and only when, they appear in all 105 capitals, as shown here. 107 3. Service Provider Deployment Architecture for Out-of-Band STIR 109 The architecture in this specification assumes that every 110 participating service provider is associated with one or more 111 designated CPS instances. A service provider's CPS serves as a place 112 where callers, or in some cases gateways, can deposit a PASSporT when 113 attempting to place a call to a subscriber of the destination service 114 provider; if the caller's domain supports in-band STIR, this can be 115 done at the same time as an in-band STIR call is placed. The 116 terminating service provider could operate the CPS themselves, or a 117 third party could operate the CPS on the destination's behalf. This 118 model does not assume a monolithic CPS that acts on behalf of all 119 service providers, but nor does it prohibit multiple service 120 providers from sharing a CPS provider. Moreover, a particular CPS 121 can be a logically distributed entity compromised of several 122 geographically distant entities that flood PASSporTs among themselves 123 to support an anycast-like service. 125 The process of locating a destination CPS and submitting a PASSporT 126 naturally requires Internet connectivity to the CPS. If the CPS is 127 deployed in the terminating service provider network, any such 128 network connectivity could instead be leveraged by a caller to 129 initiate a SIP session, during which in-band STIR could be used 130 normally. The applicability of this architecture is therefore to 131 those cases where, for whatever reason, SIP requests cannot reliably 132 convey PASSporTs end-to-end, but an HTTP transaction can reliably be 133 sent to the CPS from the out-of-band authentication service (OOB-AS). 134 It is hoped that as IP connectivity between telephone providers 135 increases, there will be less need for an out-of-band mechanism, but 136 it can serve as a fallback mechanism in cases where service providers 137 cannot predict whether end-to-end delivery of SIP calls will occur. 139 4. Advertising a CPS 141 If more than one CPS exists for a given deployment, there will need 142 to be some means of discovering CPSs, either administratively or 143 programmatically. Many services providers have bilateral agreements 144 to peer with one another, and in those environments, identifying 145 their respective CPS's could be a simple matter of provisioning. A 146 consortium of service providers could simply agree to choose from a 147 list of available CPS providers, say. In more pluralist 148 environments, some mechanism is needed to discover the CPS associated 149 with the target of a call. 151 In order to allow the CPS chosen by a service provider to be 152 discovered securely, this specification defines a CPS advertisement. 153 Effectively, a CPS advertisement is a document which contains the URL 154 of a CPS, as well as any information needed to determine which 155 PASSporTs should be submitted to that CPS (e.g., Service Provider 156 Codes (SPCs) or telephone number ranges). An advertisement may be 157 signed with a STIR [RFC8226] credential, or another credential that 158 is trusted by the participants in a given STIR environment. The 159 advantage to signing with STIR certificates is that they contain a 160 "TNAuthList" value indicating the telephone network resources that a 161 service provider controls. This information can be matched with a 162 TNAuthList value in the CPS advertisement to determine whether the 163 signer has the authority to advertise a particular CPS as the proper 164 destination for PASSporTs. 166 The format of a service provider CPS advertisement is a simple JSON 167 object containing one or more pairs of TNAuthList values pointing to 168 the URIs of CPSs, e.g. { "1234":"https://cps.example.com" }. 169 TNAuthList values can be either Service Provider Codes (SPCs) or 170 telephone numbers or number ranges. CPS URIs MUST be HTTPS URIs. 171 These CPS URIs SHOULD be publicly reachable, as service providers 172 cannot usually anticipate all of the potential callers that might 173 want to connect with them, but in more constrained environments, they 174 MAY be only reachable over a closed network. 176 CPS advertisements could be made available through existing or new 177 databases, potentially aggregated across multiple service providers 178 and distributed to call originators as necessary. They could be 179 discovered during the call routing process, including through a DNS 180 lookup. They could be shared through a distributed database among 181 the participants in a multilateral peering arrangement. 183 An alternative to CPS advertisements that may be usable in some 184 environments is adding a field to STIR [RFC8226] certificates 185 identifying the CPS URI issued to individual service providers. As 186 these certificates are themselves signed by a CA, and contain their 187 own TNAuthList, the URI would be bound securely to the proper 188 telephone network identifiers. As STIR assumes a community of 189 relying parties who trust these credentials, this method perhaps best 190 mirrors the trust model required to allow a CPS to authorize PASSporT 191 submission and retrieval. 193 5. Submitting a PASSporT 195 Submitting a PASSporT to a CPS as specified in the STIR out-of-band 196 framework [RFC8816] requires security measures which are intended to 197 prevent the CPS from learning the identity of the caller (or callee), 198 to the degree possible. In this service provider case, however, the 199 CPS is operated by the service provider of the callee (or an entity 200 operating on their behalf), and as such the information that appears 201 in the PASSporT is redundant with call signaling that the terminating 202 party will receive anyway. Therefore, the service provider out-of- 203 band framework does not attempt to conceal the identity of the 204 originating or terminating party from the CPS. 206 An out-of-band authentication service (OOB-AS) forms a secure 207 connection with the target CPS. This may happen at the time a call 208 is being placed, or it may be a persistent connection, if there is a 209 significant volume of traffic sent over this interface. The OOB-AS 210 SHOULD authenticate itself to the CPS via mutual TLS using its STIR 211 credential [RFC8226], the same one it would use to sign calls; this 212 helps mitigate the risk of flooding that more open OOB 213 implementations may face. Furthermore, use of mutual TLS prevents 214 attackers from replaying captured PASSporTs to the CPS. A CPS makes 215 its own policy decision as to whether it will accept calls from a 216 particular OOB-AS, and at what volumes. A CPS can use this mechanism 217 can authorize service providers who already hold STIR credentials to 218 submit PASSporTs to a CPS, but alternative mechanisms would be 219 required for any entities that do not hold a STIR credential, 220 including gateway or transit providers who want to submit PASSporTs. 221 See Section 7 below for more on their behavior. 223 Service provider out-of-band PASSporTs do not need to be encrypted 224 for storage at the CPS, although use of transport-layer security to 225 prevent eavesdropping on the connection between the CPS and OOB-ASs 226 is REQUIRED. PASSporTs will typically be submitted to the CPS at the 227 time they are created by an AS; if the PASSporT is also being used 228 for in-band transit within a SIP request, the PASSporT can be 229 submitted to the CPS before or after the SIP request is sent, at the 230 discretion of the originating domain. An OOB-AS will use a REST 231 interface to submit PASSporTs to the CPS as described in [RFC8816] 232 Section 9. PASSporTs persist at the CPS for as long as is required 233 for them to be retrieved (see the next section), but in any event for 234 no longer than the freshness interval of the PASSporT itself (a 235 maximum of sixty seconds). 237 6. PASSporT Retrieval 239 The STIR out-of-band framework [RFC8816] proposes two means that 240 called parties can acquire PASSporTs out-of-band: through a retrieval 241 interface, or through a subscription interface. In the service 242 provider context, where many calls to or from the same number may 243 pass through a CPS simultaneously, an out-of-band capable 244 verification service (OOB-VS) may therefore operate in one of two 245 modes: it can either pull PASSporTs from the CPS after calls arrive, 246 or receive push notifications from the CPS for incoming calls. 248 Pulling of PASSporTs from the CPS will follow the basic REST flow 249 described in [RFC8816] Section 9. In the pull model, a terminating 250 service provider polls the CPS via its OOB-VS after having received a 251 call for those cases in which the call signaling does not itself 252 carry a PASSporT. Exactly how a CPS determines which PASSporTs an 253 OOB-VS is eligible to receive over this interface is a matter of 254 local policy. If a CPS serves only one service provider, then all 255 PASSporTs submitted to the CPS are made available to the OOB-VS of 256 that provider; indeed, the CPS and OOB-VS may be colocated or 257 effectively operated as a consolidated system. In a multi-provider 258 environment, the STIR credential of the terminating domain can be 259 used by the CPS to determine the range of TNAuthLists for which an 260 OOB-VS is entitled to receive PASSporTs; this may be through a 261 mechanism like mutual TLS, or through using the STIR credential to 262 sign a token that is submitted to the CPS by the retrieving OOB-VS. 263 Note that a multi-provider CPS will need to inspect the "dest" 264 element of a PASSporT to determine which OOB-VS should receive the 265 PASSporT. 267 In a push model, an OOB-VS could for example subscribe to a range of 268 telephone numbers, which will be directed to that OOB-VS by the CPS 269 (provided the OOB-VS is authorized to receive them by the CPS). 270 PASSporT might be sent to the OOB-VS either before or after unsigned 271 call signaling has been received by the terminating domain. In 272 either model, the terminating side may need to delay rendering a call 273 verification indicator when alerting, in order to await the potential 274 arrival of a PASSporT at the OOB-VS. The exact timing of this, and 275 its interaction with the substitution attack described in [RFC8816] 276 Section 7.4, is left for future work. 278 7. Gateways 280 In some deployment architectures, gateways might perform a function 281 that interfaces with a CPS for the retrieval or storage of PASSporTs, 282 especially in cases when in-band STIR service providers need to 283 exchange secure calls with providers that can only be reached by STIR 284 out-of-band. For example, a closed network of in-band STIR providers 285 may send SIP INVITEs to a gateway in front of a traditional PSTN 286 tandem that services a set of legacy service providers. In that 287 environment, a gateway might extract a PASSporT from an in-band SIP 288 INVITE and store it in a CPS that was established to handle requests 289 for one or more legacy providers, who in turn consume those PASSporTs 290 through an OOB-VS to assist in robocall mitigation and similar 291 functions. 293 The simplest way to interface a gateway performing this sort of 294 function for a service provider CPS system is to issue credentials to 295 the gateway that allow it to act on behalf of the legacy service 296 providers it supports: this would allow it to both add PASSporTs to 297 the CPS acting on behalf of the legacy providers, and also to create 298 PASSporTs for in-band STIR conveyance from the legacy-providers to 299 terminating service providers in the closed STIR network. For 300 example, a service provider could issue a delegate certificate 301 [RFC9060] for this purpose. 303 8. Acknowledgments 305 We would like to thank Alex Fenichel for contributions to this 306 specification. 308 9. IANA Considerations 310 This memo includes no request to IANA. 312 10. Security Considerations 314 The Security Considerations of [RFC8816] apply to those document as 315 well, including concerns about potential denial-of-service vectors 316 and traffic analysis. However, that specification's model focused a 317 great deal on the privacy implications of uploading PASSporTs to a 318 third-party web service. This draft mitigates those concerns by 319 making the CPS one of the two parties to call setup (or an entity 320 contractual acting on their behalf). That said, any architecture in 321 which PASSporTs are shared with a federated or centralized CPS raises 322 potential concerns about data collection [RFC7258]. 324 Unlike [RFC8816], this document proposes the use of STIR certificates 325 to authenticate transactions with a CPS as well as signatures for CPS 326 advertisements. This presumes an environment where STIR certificates 327 are issued by known trust anchors which are known to the CPS, 328 potentially including gateways and similar services. Common STIR 329 deployments use Service Provider Codes (SPCs) instead of telephone 330 numbers ranges to identify service providers today; determining 331 whether a given SPC entitles a service provider to access PASSporTs 332 for a given telephone number is not trivial, but is a necessary 333 component of this CPS architecture. If anyone with a STIR 334 certificate is able to publish or access PASSporTs for any telephone 335 number, the potential data collection implications are significant. 336 As 338 11. References 340 11.1. Normative References 342 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 343 Requirement Levels", BCP 14, RFC 2119, 344 DOI 10.17487/RFC2119, March 1997, 345 . 347 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 348 A., Peterson, J., Sparks, R., Handley, M., and E. 349 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 350 DOI 10.17487/RFC3261, June 2002, 351 . 353 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 354 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 355 2014, . 357 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 358 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 359 May 2017, . 361 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 362 "Authenticated Identity Management in the Session 363 Initiation Protocol (SIP)", RFC 8224, 364 DOI 10.17487/RFC8224, February 2018, 365 . 367 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 368 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 369 . 371 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 372 Credentials: Certificates", RFC 8226, 373 DOI 10.17487/RFC8226, February 2018, 374 . 376 [RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity 377 Revisited (STIR) Out-of-Band Architecture and Use Cases", 378 RFC 8816, DOI 10.17487/RFC8816, February 2021, 379 . 381 11.2. Informative References 383 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 384 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 385 2002, . 387 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 388 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 389 2007, . 391 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 392 Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 393 2014, . 395 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 396 Telephone Identity Problem Statement and Requirements", 397 RFC 7340, DOI 10.17487/RFC7340, September 2014, 398 . 400 [RFC8946] Peterson, J., "Personal Assertion Token (PASSporT) 401 Extension for Diverted Calls", RFC 8946, 402 DOI 10.17487/RFC8946, February 2021, 403 . 405 [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) 406 Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, 407 September 2021, . 409 Author's Address 411 Jon Peterson 412 Neustar, Inc. 413 Email: jon.peterson@team.neustar