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