idnits 2.17.1 draft-peterson-stir-rfc4916-update-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 copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 2, 2020) is 1268 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8862' is mentioned on line 132, but not defined == Unused Reference: 'I-D.ietf-modern-problem-framework' is defined on line 295, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-modern-teri' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 340, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) -- Obsolete informational reference (is this intentional?): RFC 7159 (Obsoleted by RFC 8259) Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 3 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 C. Wendt 5 Expires: May 6, 2021 Comcast 6 November 2, 2020 8 Connected Identity for STIR 9 draft-peterson-stir-rfc4916-update-02 11 Abstract 13 The SIP Identity header conveys cryptographic identity information 14 about the originators of SIP requests. The Secure Telephone Identity 15 Revisited (STIR) framework however provides no means for determining 16 the identity of the called party in a traditional telephone calling 17 scenario. This document updates prior guidance on the "connected 18 identity" problem to reflect the changes to SIP Identity that 19 accompanied STIR, and considers a revised problem space for connected 20 identity as a means of detecting calls that have been retargeted to a 21 party impersonating the intended destination, as well as spoofing of 22 mid-dialog or dialog-terminating events by intermediaries or third 23 parties. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 6, 2021. 42 Copyright Notice 44 Copyright (c) 2020 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 60 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 3. Connected Identity Problem Statement for STIR . . . . . . . . 3 62 4. Authorization Policy for Callers . . . . . . . . . . . . . . 5 63 5. Pre-Association with Destinations . . . . . . . . . . . . . . 6 64 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 7. Updates to RFC4916 . . . . . . . . . . . . . . . . . . . . . 6 66 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 67 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 68 10. Security Considerations . . . . . . . . . . . . . . . . . . . 7 69 11. Informative References . . . . . . . . . . . . . . . . . . . 7 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 72 1. Introduction 74 The Session Initiation Protocol (SIP) [RFC3261] initiates sessions, 75 and as a step in establishing sessions, it exchanges information 76 about the parties at both ends of a session. Users review 77 information about the calling party, for example, to determine 78 whether to accept communications initiated by a SIP, in the same way 79 that users of the telephone network assess "Caller ID" information 80 before picking up calls. This information may sometimes be consumed 81 by automata to make authorization decisions. 83 STIR [RFC8224] provides a cryptographic assurance of the identity of 84 calling parties in order to prevent impersonation, which is a key 85 enabler of unwanted robocalls, swatting, vishing, voicemail hacking, 86 and similar attacks (see [RFC7340]). There also exists a related 87 problem: the identity of the party who answers a call can differ from 88 that of the initial called party for various innocuous reasons such 89 as call forwarding, but in certain network environments it is 90 possible for attackers to hijack the route of a called number and 91 direct it to a resource controlled by the attacker. It can 92 potentially be difficult to determine why a call reached a target 93 other than the one originally intended, and whether the party 94 ultimately reached by the call is one that the caller should trust. 95 The property of providing identity in the backwards direction of a 96 call is here called "connected identity." 97 Previous work on connected identity focused on fixing the core 98 semantics of SIP. [RFC4916] allowed a mid-dialog request, such as an 99 UPDATE [RFC3311], to convey identity in either direction within the 100 context of an existing INVITE-initiated dialog. In an update to the 101 original [RFC3261] behavior, [RFC4916] allowed that UPDATE to alter 102 the From header field value for requests in the backwards direction: 103 previously [RFC3261] required that the From header field values sent 104 in requests in the backwards direction reflect the To header field 105 value of the dialog-forming request, for various backwards- 106 compatibility reasons. In other words, if Alice sent a dialog- 107 forming request to Bob, then under the original [RFC3261] rules, even 108 if Bob's SIP service forwarded that dialog-forming request to Carol, 109 Carol would still be required to put Bob's identity in the From 110 header field value in any mid-dialog requests in the backwards 111 direction. 113 One of the original motivating use cases for [RFC4916] was the use of 114 connected identity with the SIP Identity [RFC4474] header field. 115 While a mid-dialog request in the backwards direction (e.g. UPDATE) 116 can be signed with Identity like any other SIP request, forwarded 117 requests would not be signable without the ability to change the mid- 118 dialog From header field value: Carol, say, would not be able to 119 furnish a key to sign for Bob's identity, if Carol wanted to sign 120 requests in the backwards direction. Carol would however be able to 121 sign for her own identity in the From header field value, if mid- 122 dialog requests in the backwards direction were permitted to vary 123 from the original To header field value. 125 With the obsolence of [RFC4474] by [RFC8224], this specification 126 updates [RFC4916] to reflect the changes to the SIP Identity header 127 and the revised problem space of STIR. It also explores some new 128 features that would be enabled by connected identity for STIR, 129 including the use of connected identity to prevent route hijacking 130 and to notify callers when an expected called party has successfully 131 been reached. This document also addresses concerns about applying 132 [RFC4916] connected identity to STIR as given in [RFC8862]. 134 2. Terminology 136 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 137 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 139 3. Connected Identity Problem Statement for STIR 141 The STIR problem statement [RFC7340] enumerates robocalling, 142 voicemail hacking, vishing, and swatting as problems with the modern 143 telephone network that are enabled, or abetted, by impersonation: by 144 the ability of a calling party to arbitrarily set the telephone 145 number that will be rendered to end users to identify the caller. 147 Today, sophisticated adversaries can redirect calls on the PSTN to 148 destinations other than the intended called party. For some call 149 centers, like those associated with financial institutions, 150 healthcare, and emergency services, an attacker could hope to gain 151 valuable information about people or to prevent some classes of 152 important services. Moreover, on the Internet, the lack of any 153 centralized or even federated routing system for telephone numbers 154 has resulted in deployments where the routing of calls is arbitrary: 155 calls to telephone numbers might be unceremoniously dumped on a PSTN 156 gateway, they might be sent to a default intermediary that makes 157 forwarding decisions based on a local flat file, various mechanisms 158 like private ENUM might be consulted, or routing might be determined 159 in some other, domain specific way. In short, there are numerous 160 attack surfaces that an adversary could explore to attempt to 161 redirect calls to a particular number to someplace other than the 162 intended destination. 164 Another motivating use case for connected identity is mid-dialog 165 requests, including BYE. The potential for an intermediary to 166 generate a forged BYE in the backwards direction has always been 167 built-in to the stateful dialog management of SIP. There is a class 168 of mobile fraud attacks ("short-stopping") that rely on intermediary 169 networks making it appear as if a call has terminated to one side, 170 while maintaining that the call is still active to the other, in 171 order to create a billing discrepancy that could be pocketed by the 172 intermediary. If BYE requests in both directions of a SIP dialog 173 could be authenticated with STIR, just like dialog-forming requests, 174 then another impersonation vector leading to fraud in the telephone 175 network could be shut down. 177 There are however practical limits to what securing the signaling can 178 achieve. [RFC4916] rightly observed that once a SIP call has been 179 answered, the called party can be replaced by a different party with 180 a different identity due to call transfer, call park and retrieval, 181 and so on. In some cases, due to the presence of a back-to-back user 182 agent, it can be effectively impossible for the calling party to know 183 that this has happened. The problem statement considered for STIR 184 focuses solely on signaling, not whether media from the connected 185 party should be rendered to the caller when a dialog has been 186 established. This specification does not consider further any 187 threats that arise from a substitution of media. 189 4. Authorization Policy for Callers 191 In a traditional telephone call, the called party receives an 192 alerting signal and can make a decision about whether or not to pick 193 up a phone. They may have access to displayed information, like 194 "Caller ID", to help them arrive at an authorization decision. The 195 situation is more complicated for callers, however: callers typically 196 expect to be connected to the proper destination and are often 197 holding telephones in a position that would not enable them to see 198 displayed information, if any were available for them to review--and 199 moreover, their most direct response to a security breach would be to 200 hang up the call they were in the middle of placing. 202 While this specification will not prescribe any user experience 203 associated with placing a call, it assumes that callers might have 204 some way to a set an authorization posture that will result in the 205 right thing happening when the connected identity is not expected. 206 This is analogous to a situation where SRTP negotiation fails because 207 the keys exchanges at the media layer do not match fingerprints 208 exchanged at the signaling layer: when a user requests 209 confidentiality services, and they are unavailable, media should not 210 be exchanged. Thus we assume that users have a way in their 211 interface to require this criticality, on a per-call basis, or 212 perhaps on a per-destination basis. Similarly, users will not always 213 place calls where the connected identity is crucial--but when they 214 do, they should have a way to tell their devices that the call should 215 not be completed if it arrives at an unexpected party. 217 Ultimately, authorization policy for called parties is difficult to 218 set, as calls can end up at unexpected places for legitimate reasons. 219 Some work has been done to make sure that secure diversion works with 220 STIR, in for example [I-D.ietf-stir-passport-divert]. Those 221 indications can be consumed by on the terminating side by 222 verification services to determine that a call has reached its 223 eventual destination for the right reasons. The only way those 224 diversion PASSporTs will be seen by the calling party is if 225 redirection is used (SIP 3XX responses) instead of retargeting; while 226 some network policies may want to conceal service logic from the 227 originating party, sending redirections in the backwards direction is 228 the only current defined way for secure indications of redirection to 229 be revealed to the calling party. That in turn would allow the 230 calling user agent to have a strong assurance that legitimate 231 entities in the call path caused the request to reach a party that 232 the caller did not anticipate. 234 5. Pre-Association with Destinations 236 Any connected identity mechanism will work best if the user knows 237 before initiating a call that connected identity is supported by the 238 destination side. Not every institution that a user wants to connect 239 to securely will support STIR and connected identity out of the gate. 241 The user interface of modern smartphones support an address book from 242 which users select telephone numbers to dial. Even when dialing a 243 number manually, the interface frequently checks the address book and 244 will display to users any provisioned name for the target of the call 245 if one exists. Similarly, when clicking on a telephone number viewed 246 on a web page, or similar service, smartphone often prompt users 247 approve the access to the outbound dialer. These sorts of decision 248 points, when the user is still interacting with the user interface, 249 provide an opportunity to form a pre-association with the 250 destination, and potentially even to exchange STIR PASSporTs in order 251 to validate whether or not the expected destination can be reached 252 securely. Again, this is probably most meaningful for contacting 253 financial, government, or emergency services, for cases where 254 reaching an unintended destination may have serious consequences. 256 Future versions of this specification will explore how the security 257 features of destinations can be discovered before calls are set up so 258 that calling parties can make more informed authorization decisions. 259 This may rely on the establishment of a provisional, media-less SIP 260 dialog which can then negotiate media when the user approves of the 261 destination. In some environments, that may require the use of 262 mechanisms defined by [I-D.ietf-stir-oob]. 264 6. Examples 266 [TBD: Revise RFC4916 examples to show new Identity header present in 267 UPDATE and in a backwards-direction BYE.] 269 7. Updates to RFC4916 271 [TBD - ways that UPDATEs in the backwards direction can carry 272 additional information in support of the above] 274 In general, the guidance of RFC4916 remains valid for RFC8224. 276 The deprecation of the Identity-Info header has a number of 277 implications for RFC4916; all of the protocol examples need to be 278 updated to reflect that. 280 8. Acknowledgments 282 We would like to thank YOU for your contributions to this 283 specification. 285 9. IANA Considerations 287 This memo includes no request to IANA. 289 10. Security Considerations 291 TBD. 293 11. Informative References 295 [I-D.ietf-modern-problem-framework] 296 Peterson, J. and T. McGarry, "Modern Problem Statement, 297 Use Cases, and Framework", draft-ietf-modern-problem- 298 framework-04 (work in progress), March 2018. 300 [I-D.ietf-stir-oob] 301 Rescorla, E. and J. Peterson, "STIR Out-of-Band 302 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 303 in progress), March 2020. 305 [I-D.ietf-stir-passport-divert] 306 Peterson, J., "PASSporT Extension for Diverted Calls", 307 draft-ietf-stir-passport-divert-09 (work in progress), 308 July 2020. 310 [I-D.peterson-modern-teri] 311 Peterson, J., "An Architecture and Information Model for 312 Telephone-Related Information (TeRI)", draft-peterson- 313 modern-teri-04 (work in progress), March 2018. 315 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 316 Requirement Levels", BCP 14, RFC 2119, 317 DOI 10.17487/RFC2119, March 1997, 318 . 320 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 321 A., Peterson, J., Sparks, R., Handley, M., and E. 322 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 323 DOI 10.17487/RFC3261, June 2002, 324 . 326 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 327 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 328 2002, . 330 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 331 Authenticated Identity Management in the Session 332 Initiation Protocol (SIP)", RFC 4474, 333 DOI 10.17487/RFC4474, August 2006, 334 . 336 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 337 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 338 2007, . 340 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 341 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 342 2014, . 344 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 345 Telephone Identity Problem Statement and Requirements", 346 RFC 7340, DOI 10.17487/RFC7340, September 2014, 347 . 349 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 350 "Authenticated Identity Management in the Session 351 Initiation Protocol (SIP)", RFC 8224, 352 DOI 10.17487/RFC8224, February 2018, 353 . 355 Authors' Addresses 357 Jon Peterson 358 Neustar, Inc. 359 1800 Sutter St Suite 570 360 Concord, CA 94520 361 US 363 Email: jon.peterson@team.neustar 365 Chris Wendt 366 Comcast 367 One Comcast Center 368 Philadelphia, PA 19103 369 USA 371 Email: chris-ietf@chriswendt.net