idnits 2.17.1 draft-ietf-stir-servprovider-oob-00.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 (November 2, 2020) is 1264 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'More TBD' is mentioned on line 166, but not defined == Unused Reference: 'I-D.ietf-stir-passport-divert' is defined on line 308, but no explicit reference was found in the text == Unused Reference: 'RFC3261' is defined on line 318, but no explicit reference was found in the text == Unused Reference: 'RFC3311' is defined on line 324, but no explicit reference was found in the text == Unused Reference: 'RFC4916' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 332, but no explicit reference was found in the text -- 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 November 2, 2020 5 Expires: May 6, 2021 7 Out-of-Band STIR for Service Providers 8 draft-ietf-stir-servprovider-oob-00 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 May 6, 2021. 37 Copyright Notice 39 Copyright (c) 2020 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 . . . . . . . . . . . . . . . . . . . . 4 59 6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 5 60 7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 63 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 64 11. Informative References . . . . . . . . . . . . . . . . . . . 7 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 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. 90 Environments that might support this flavor of STIR out-of-band 91 include carriers, large enterprises, call centers, or any Internet 92 service that aggregates on behalf of a large number of telephone 93 endpoints. 95 2. Terminology 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 3. Service Provider Deployment Architecture for Out-of-Band STIR 105 The architecture in this specification assumes that every 106 participating service provider will advertise one or more designated 107 CPS instances. A service provider's CPS serves as a place where 108 callers can deposit a PASSporT when attempting to place a call to a 109 subscriber of the destination service provider; if the caller's 110 domain supports in-band STIR, this can be done at the same time as an 111 in-band STIR call is placed. The terminating service provider could 112 operate the CPS themselves, or a third party could operate the CPS on 113 the destination's behalf. This model does not assume a monolithic 114 CPS that acts on behalf of all service providers, but nor does it 115 prohibit multiple service providers from sharing a CPS provider. 116 Moreover, a particular CPS can be a logically distributed entity 117 compromised of several geographically distant entities that flood 118 PASSporTs among themselves to support an anycast-like service. 120 The process of locating a destination CPS and submitting a PASSporT 121 requires Internet connectivity between the call originator and the 122 CPS. If the CPS is deployed in the terminating service provider 123 network, that network connectivity could be leveraged to initiate a 124 SIP session, during which in-band STIR could be used. The 125 applicability of this architecture is therefore to those cases where, 126 for whatever reason, SIP calls cannot reliably be placed end-to-end, 127 but an HTTP transaction can reliably be sent to the destination 128 network from the out-of-band authentication service (OOB-AS) in the 129 caller's network. It is hoped that as IP connectivity between 130 telephone providers increases, there will be less need for an out-of- 131 band mechanism, but it can serve as a fallback mechanism in cases 132 where service providers cannot predict whether end-to-end delivery of 133 SIP calls will occur. 135 4. Advertising a CPS 137 If more than one CPS exists for a given deployment, there will need 138 to be some means of discovering CPSs, either administratively or 139 programmatically. Many services providers have bilateral agreements 140 to peer with one another, and in those environments, identifying 141 their respective CPS's could be a simple matter of provisioning. A 142 consortium of service providers could simply agree to choose from a 143 list of available CPS providers, say. In more pluralist 144 environments, some mechanism is needed to discover the CPS associated 145 with the target of a call. 147 In order to allow the CPS chosen by a service provider to be 148 discovered securely, this specification defines a CPS advertisement. 149 Effectively, a CPS advertisement is a document which contains the URL 150 of a CPS, as well as any information needed to determine which 151 PASSporTs should be submitted to that CPS. An advertisement may be 152 signed with a STIR [RFC8226] credential, or another credential that 153 is trusted by the participants in a given STIR environment. The 154 advantage to signing with STIR certificates is that they contain a 155 "TNAuthList" value indicating the telephone network resources that a 156 service provider controls. This information can be matched with a 157 TNAuthList value in the CPS advertisement to determine whether the 158 signer has the authority to advertise a particular CPS as the proper 159 destination for PASSporTs. 161 The format of a service provider CPS advertisement is a simple JSON 162 object containing one or more pairs of TNAuthList values pointing to 163 the URIs of CPSs, e.g. { "1234":"https://cps.example.com" }. 164 TNAuthList values can be either Service Provider Codes (SPCs) or 165 telephone numbers or number ranges. CPS URIs MUST be HTTPS URIs. 166 [More TBD]. 168 CPS advertisements could be made available through existing or new 169 databases, potentially aggregated across multiple service providers 170 and distributed to call originators as necessary. They could be 171 discovered during the call routing process, including through a DNS 172 lookup. They could be shared through a distributed database among 173 the participants in a multilateral peering arrangement. 175 An alternative to CPS advertisements that may be usable in some 176 environments is adding a field to STIR [RFC8226] credentials issued 177 to individual service providers. As these certificates are 178 themselves signed by a CA, the URI would be bound securely to the 179 service provider. As STIR assumes a community of relying parties who 180 trust these credentials, this method perhaps best mirrors the trust 181 model required to allow a CPS to authorize PASSporT submission and 182 retrieval. 184 5. Submitting a PASSporT 186 Submitting a PASSporT to a CPS as specified in the STIR out-of-band 187 framework [I-D.ietf-stir-oob] requires security measures which are 188 intended to prevent the CPS from learning the identity of the caller 189 (or callee), to the degree possible. In this service provider case, 190 however, the CPS is operated by the service provider of the callee 191 (or an entity operating on their behalf), and as such the information 192 that appears in the PASSporT is redundant with call signaling that 193 the terminating party will receive anyway. Therefore, the service 194 provider out-of-band framework does not attempt to conceal the 195 identity of the originating or terminating party from the CPS. 197 An out-of-band authentication service (OOB-AS) forms a secure 198 connection with the target CPS. This may happen at the time a call 199 is being placed, or it may be a persistent connection, if there is a 200 significant volume of traffic sent over this interface. The OOB-AS 201 SHOULD authenticate itself to the CPS using its STIR credential 202 [RFC8226]the same one it would use to sign calls via mutual TLS; this 203 helps mitigate the risk of flooding that more open OOB 204 implementations may face. Furthermore, use of mutual TLS prevents 205 attackers from replaying captured PASSporTs to the CPS. A CPS makes 206 its own policy decision as to whether it will accept calls from a 207 particular OOB-AS, and at what volumes. 209 Service provider out-of-band PASSporTs do not need to be encrypted 210 for storage at the CPS, although use of transport-layer security to 211 prevent eavesdropping on the connection between the CPS and OOB-ASs 212 is REQUIRED. PASSporTs will be submitted to the CPS at the time they 213 are created by an AS; if the PASSporT is also being used for in-band 214 transit within a SIP request, the PASSporT can be submitted to the 215 CPS before or after the SIP request is sent, at the discretion of the 216 originating domain. An OOB-AS will use a REST interface to submit 217 PASSporTs to the CPS as described in [I-D.ietf-stir-oob] Section 9 218 [more TBD]. PASSporTs are persisted by the CPS for as long as is 219 required for them to be retrieved (see the next section), but in any 220 event for no longer than the freshness interval of the PASSporT 221 itself (a maximum of sixty seconds). 223 6. PASSporT Retrieval 225 The STIR out-of-band framework [I-D.ietf-stir-oob] proposes two means 226 that called parties can acquire PASSporTs out-of-band: through a 227 retrieval interface, or through a subscription interface. In the 228 service provider context, where many calls occur simultaneously, an 229 out-of-band capable verification service may therefore operate in one 230 of two modes: it can either pull PASSporTs from the CPS after calls 231 arrive, or receive push notifications from the CPS for incoming 232 calls. 234 If a CPS serves only one service provider, then all PASSporTs 235 submitted to the CPS are made available to the OOB-VS of that 236 provider; indeed, the CPS and OOB-VS may be colocated or effectively 237 operated as a consolidated system. In a multi-provider environment, 238 the STIR credential of the terminating domain can be used by the CPS 239 to determine the range of TNAuthLists for which an OOB-VS is entitled 240 to receive PASSporTs; this may be through a mechanism like mutual 241 TLS, or through using the STIR credential to sign a token that is 242 submitted to the CPS by the retrieving OOB-VS. Note that a CPS will 243 need to inspect the "dest" element of a PASSporT to determine which 244 OOB-VS should receive the PASSporT in this case. [TBD: Which sub/not 245 protocol to use for the case where the CPS and OOB-VS are not 246 composed in a single function?] 248 Pulling of PASSporTs from the CPS will follow the basic REST flow 249 described in [I-D.ietf-stir-oob] Section 9. In the push interface 250 case, exactly how a CPS determines which PASSporTs to send to an out- 251 of-band verification service is a matter of implementation. An OOB- 252 VS could for example subscribe to a range of telephone numbers, which 253 will be directed to that OOB-VS by the CPS (provided the OOB-VS is 254 authorized to receive them by the CPS). 256 In the pull model, a terminating service provider contacts the CPS 257 via its OOB-VS after having received a call in cases when the call 258 signaling does not itself carry a STIR signature. In the push model, 259 a PASSporT might be sent to the OOB-VS either before or after 260 unsigned call signaling has been received by the terminating domain. 261 Domains using the push model may therefore need to adopt a model 262 where call signaling is held momentarily in order to await the 263 potential arrival of a PASSporT at the OOB-VS. The exact timing of 264 this, and its interaction with the substitution attack described in 265 [I-D.ietf-stir-oob] Section 7.4, will be the covered by future 266 versions of this specification. 268 7. Gateways 270 In some deployment architectures, gateways might perform a function 271 that interfaces with a CPS for the retrieval or storage of PASSporTs. 272 For example, a closed network of in-band STIR providers may send SIP 273 INVITEs to a gateway in front of a traditional PSTN tandem that 274 services a set of legacy service providers. In that environment, a 275 gateway might take a PASSporT out of in-band SIP INVITEs and store it 276 in a CPS that was established to handle requests for one or more 277 legacy providers, who in turn consume those PASSporTs through an OOB- 278 VS to assist in robocall mitigation and similar functions. 280 The simplest way to interface a gateway performing this sort of 281 function for a service provider CPS system is to issue credentials to 282 the gateway that allow it to act on behalf of the legacy service 283 providers it supports: this would allow it to both add PASSporTs to 284 the CPS acting on behalf of the legacy providers, and also to create 285 PASSporTs for in-band STIR conveyance from the legacy-providers to 286 terminating service providers in the closed STIR network. 288 8. Acknowledgments 290 We would like to thank Alex Fenichel for contributions to this 291 specification. 293 9. IANA Considerations 295 This memo includes no request to IANA. 297 10. Security Considerations 299 TBD. 301 11. Informative References 303 [I-D.ietf-stir-oob] 304 Rescorla, E. and J. Peterson, "STIR Out-of-Band 305 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 306 in progress), March 2020. 308 [I-D.ietf-stir-passport-divert] 309 Peterson, J., "PASSporT Extension for Diverted Calls", 310 draft-ietf-stir-passport-divert-09 (work in progress), 311 July 2020. 313 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 314 Requirement Levels", BCP 14, RFC 2119, 315 DOI 10.17487/RFC2119, March 1997, 316 . 318 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 319 A., Peterson, J., Sparks, R., Handley, M., and E. 320 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 321 DOI 10.17487/RFC3261, June 2002, 322 . 324 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 325 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 326 2002, . 328 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 329 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 330 2007, . 332 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 333 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 334 2014, . 336 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 337 Telephone Identity Problem Statement and Requirements", 338 RFC 7340, DOI 10.17487/RFC7340, September 2014, 339 . 341 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 342 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 343 May 2017, . 345 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 346 "Authenticated Identity Management in the Session 347 Initiation Protocol (SIP)", RFC 8224, 348 DOI 10.17487/RFC8224, February 2018, 349 . 351 [RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion 352 Token", RFC 8225, DOI 10.17487/RFC8225, February 2018, 353 . 355 [RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity 356 Credentials: Certificates", RFC 8226, 357 DOI 10.17487/RFC8226, February 2018, 358 . 360 Author's Address 362 Jon Peterson 363 Neustar, Inc. 365 Email: jon.peterson@neustar.biz