idnits 2.17.1 draft-peterson-stir-rfc4916-update-03.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 seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (February 22, 2021) is 1156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC8862' is mentioned on line 139, but not defined == Unused Reference: 'I-D.ietf-modern-problem-framework' is defined on line 410, but no explicit reference was found in the text == Unused Reference: 'I-D.peterson-modern-teri' is defined on line 425, but no explicit reference was found in the text == Unused Reference: 'RFC7159' is defined on line 471, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-peterson-stir-messaging-00 -- 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 (~~), 7 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: August 26, 2021 Comcast 6 February 22, 2021 8 Connected Identity for STIR 9 draft-peterson-stir-rfc4916-update-03 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 the spoofing 22 of 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 August 26, 2021. 42 Copyright Notice 44 Copyright (c) 2021 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Connected Identity Problem Statement for STIR . . . . . . . . 4 62 4. Connected Identity in Provisional Dialogs . . . . . . . . . . 5 63 5. Connected Identity in Mid-Dialog and Dialog-Terminating 64 Requests . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 6. Interaction with Divert PASSporT . . . . . . . . . . . . . . 6 66 7. Authorization Policy for Callers . . . . . . . . . . . . . . 7 67 8. Pre-Association with Destinations . . . . . . . . . . . . . . 8 68 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 69 10. Updates to RFC4916 . . . . . . . . . . . . . . . . . . . . . 9 70 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 71 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 72 13. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 14. Informative References . . . . . . . . . . . . . . . . . . . 9 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 76 1. Introduction 78 The Session Initiation Protocol (SIP) [RFC3261] initiates sessions, 79 and as a step in establishing sessions, it exchanges information 80 about the parties at both ends of a session. Users review 81 information about the calling party, for example, to determine 82 whether to accept communications initiated by a SIP, in the same way 83 that users of the telephone network assess "Caller ID" information 84 before picking up calls. This information may sometimes be consumed 85 by automata to make authorization decisions. 87 STIR [RFC8224] provides a cryptographic assurance of the identity of 88 calling parties in order to prevent impersonation, which is a key 89 enabler of unwanted robocalls, swatting, vishing, voicemail hacking, 90 and similar attacks (see [RFC7340]). There also exists a related 91 problem: the identity of the party who answers a call can differ from 92 that of the initial called party for various innocuous reasons such 93 as call forwarding, but in certain network environments, it is 94 possible for attackers to hijack the route of a called number and 95 direct it to a resource controlled by the attacker. It can 96 potentially be difficult to determine why a call reached a target 97 other than the one originally intended, and whether the party 98 ultimately reached by the call is one that the caller should trust. 99 The lack of mutual authentication of parties moreover makes it 100 possible for outside attackers to inject forged messages (e.g. BYE) 101 into a SIP session. 103 The property of providing identity in the backwards direction of a 104 call is here called "connected identity." Previous work on connected 105 identity focused on fixing the core semantics of SIP. [RFC4916] 106 allowed a mid-dialog request, such as an UPDATE [RFC3311], to convey 107 identity in either direction within the context of an existing 108 INVITE-initiated dialog. In an update to the original [RFC3261] 109 behavior, [RFC4916] allowed that UPDATE to alter the From header 110 field value for requests in the backwards direction: previously 111 [RFC3261] required that the From header field values sent in requests 112 in the backwards direction reflect the To header field value of the 113 dialog-forming request, for various backwards-compatibility reasons. 114 In other words, if Alice sent a dialog-forming request to Bob, then 115 under the original [RFC3261] rules, even if Bob's SIP service 116 forwarded that dialog-forming request to Carol, Carol would still be 117 required to put Bob's identity in the From header field value in any 118 mid-dialog requests in the backwards direction. 120 One of the original motivating use cases for [RFC4916] was the use of 121 connected identity with the SIP Identity [RFC4474] header field. 122 While a mid-dialog request in the backwards direction (e.g. UPDATE) 123 can be signed with Identity like any other SIP request, forwarded 124 requests would not be signable without the ability to change the mid- 125 dialog From header field value: Carol, say, would not be able to 126 furnish a key to sign for Bob's identity, if Carol wanted to sign 127 requests in the backwards direction. Carol would however be able to 128 sign for her own identity in the From header field value, if mid- 129 dialog requests in the backwards direction were permitted to vary 130 from the original To header field value. 132 With the obsolence of [RFC4474] by [RFC8224], this specification 133 updates [RFC4916] to reflect the changes to the SIP Identity header 134 and the revised problem space of STIR. It also explores some new 135 features that would be enabled by connected identity for STIR, 136 including the use of connected identity to prevent route hijacking 137 and to notify callers when an expected called party has successfully 138 been reached. This document also addresses concerns about applying 139 [RFC4916] connected identity to STIR as given in [RFC8862]. 141 2. Terminology 143 In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD", 144 and "SHOULD NOT", are to be interpreted as described in [RFC2119]. 146 3. Connected Identity Problem Statement for STIR 148 The STIR problem statement [RFC7340] enumerates robocalling, 149 voicemail hacking, vishing, and swatting as problems with the modern 150 telephone network that are enabled, or abetted, by impersonation: by 151 the ability of a calling party to arbitrarily set the telephone 152 number that will be rendered to end users to identify the caller. 154 Today, sophisticated adversaries can redirect calls on the PSTN to 155 destinations other than the intended called party. For some call 156 centers, like those associated with financial institutions, 157 healthcare, and emergency services, an attacker could hope to gain 158 valuable information about people or to prevent some classes of 159 important services. Moreover, on the Internet, the lack of any 160 centralized or even federated routing system for telephone numbers 161 has resulted in deployments where the routing of calls is arbitrary: 162 calls to telephone numbers might be unceremoniously dumped on a PSTN 163 gateway, they might be sent to a default intermediary that makes 164 forwarding decisions based on a local flat file, various mechanisms 165 like private ENUM might be consulted, or routing might be determined 166 in some other, domain specific way. In short, there are numerous 167 attack surfaces that an adversary could explore to attempt to 168 redirect calls to a particular number to someplace other than the 169 intended destination. 171 Another motivating use case for connected identity is mid-dialog 172 requests, including BYE. The potential for an intermediary to 173 generate a forged BYE in the backwards direction has always been 174 built-in to the stateful dialog management of SIP. For example, 175 there is a class of mobile fraud attacks ("short-stopping") that rely 176 on intermediary networks making it appear as if a call has terminated 177 to one side, while maintaining that the call is still active to the 178 other, in order to create a billing discrepancy that could be 179 pocketed by the intermediary. If BYE requests in both directions of 180 a SIP dialog could be authenticated with STIR, just like dialog- 181 forming requests, then another impersonation vector leading to fraud 182 in the telephone network could be shut down. 184 There are however practical limits to what securing the signaling can 185 achieve. [RFC4916] rightly observed that once a SIP call has been 186 answered, the called party can be replaced by a different party with 187 a different identity due to call transfer, call park and retrieval, 188 and so on. In some cases, due to the presence of a back-to-back user 189 agent, it can be effectively impossible for the calling party to know 190 that this has happened. The problem statement considered for STIR 191 focuses solely on signaling, not whether media from the connected 192 party should be rendered to the caller when a dialog has been 193 established. This specification does not consider further any 194 threats that arise from a substitution of media. 196 4. Connected Identity in Provisional Dialogs 198 [RFC4916] identified a means of sending Identity header field values 199 in the backwards direction before a final response to a dialog has 200 been received by the UAC. It relied on the use of the UPDATE method 201 to send the connected identity in the backwards direction after the 202 UAS had received and responded to a PRACK [RFC3262] from the UAC, 203 which would in turn have been triggered by a provisional 1xx response 204 sent earlier by the UAC. [RFC4916] permits the From header field of 205 the UPDATE to change the address of record of the recipient: if the 206 original INVITE had been sent with a To header field value of 207 "sip:bob@example.com", the UAS in its UPDATE could set the From 208 header field value to "sip:carol@example.com." For STIR, this is a 209 very important property, as Carol might not even possess a credential 210 that can legitimately sign for Bob. 212 Per [RFC3262], UAC's that require connected identity MUST thus send a 213 Require header field with the option tag 100rel in INVITEs in 214 addition to an Identity header field value containing a PASSporT. 215 UAS's that support this mechanism will first send a Require header 216 field with the option tag 100rel in 1xx class responses to INVITEs 217 that they receive, along with the necessary RSeq header field. The 218 UAC will send a PRACK when it receives the reliable 1xx response from 219 the UAS; the UAS, upon receiving a PRACK, responds with a 200 OK. At 220 this point, the terminating UA is free to send an UPDATE [RFC3311] 221 request in the backwards direction to the originating UA. This 222 update will contain an Identity header, with a PASSporT that signs 223 for the connected identity in its "orig" claim. If the PASSporT is 224 valid, the originating UA will respond with an OK, and may perform 225 any behaviors associated with the updated identity (see Section 7). 226 Even if connected identity is not required by the originator of an 227 INVITE request, it can still be solicited if available by sending the 228 100rel option tag in a Supported header field when sending an INVITE 229 with an Identity header, which will trigger the preceding flow if the 230 UAS supports connected identity. 232 Usually, the updated Identity reflects a changed to the From header 233 field value. But in many operating environments, the From header 234 field value does not contain the identity of the caller that has been 235 asserted by the network, which is instead conveyed by the P-Asserted- 236 Identity header field [RFC3325]. The contents of PAID are not used 237 for dialog matching, and so in environments where PAID is used, it 238 can be altered more dynamically. However, in order for the connected 239 identity and a PASSporT to be conveyed in the backwards direction, a 240 provisional dialog still needs to be established, and an UPDATE sent: 241 in this case, it will be the UDPATE that contains the connected 242 identity in its P-Asserted-Identity header field value, and that 243 value will be signed by the PASSporT. 245 5. Connected Identity in Mid-Dialog and Dialog-Terminating Requests 247 The use of the connected identity mechanism here specified is not 248 limited to provisional dialog requests. Once a dialog has been 249 established with connected identity, any re-INVITEs from either the 250 originating and terminating side, as well as any BYE requests, MUST 251 contain Identity headers with valid PASSporTs based on the current 252 To/From header field values for the dialog. This prevents third- 253 parties from spoofing any mid-dialog requests in order to redirect 254 media or similarly interfere with communications, as well as 255 preventing denial of service teardowns by attackers. 257 Theoretically, any SIP requests in a dialog could be signed in this 258 fashion, though it is unclear how valuable it would be for some (e.g. 259 OPTIONS). Requests with specialized payloads such as INFO or 260 MESSAGE, however, would require additional specification for how 261 integrity protection for their bodies could be implemented. Some 262 work has been done toward that for MESSAGE (see 263 [I-D.peterson-stir-messaging]. This specification thus does not 264 mandate PASSporTs for any requests sent in a dialog other than 265 INVITE, UPDATE, and BYE. 267 It might seem tempting to require that, if an INVITE has been with an 268 Identity header containing a PASSporT, any CANCEL request received 269 for the dialog initiated by that INVITE must also contain an Identity 270 header with a PASSporT. However, because CANCEL requests can also 271 sent be sent by stateful proxy servers engaged in parallel forking, 272 for example, when branches need to be canceled because a final 273 response has been received from a UAS. It is however REQUIRED by 274 this specification that if a UAC sends a CANCEL for its own PASSporT- 275 protected INVITE request, that it include an Identity header with a 276 valid PASSporT in the CANCEL. UAS policy will have to determine the 277 instances where it will accept unsigned CANCEL requests for a dialog 278 initiated with a signed INVITE. 280 6. Interaction with Divert PASSporT 282 Many of the use cases that motivate connected identity involve 283 retargeting: when a call acquires a new target (in its Request-URI) 284 during transit, the terminating side needs a way to express to the 285 originating side which destination the INVITE reached. In STIR, the 286 "div PASSporT type [I-D.ietf-stir-passport-divert] was created to 287 securely record when a call was retargeted from one destination to 288 another. Those "div" PASSporTs can be consumed on the terminating 289 side by verification services to determine that a call has reached 290 its eventual destination for the right reasons. 292 As specified in [I-D.ietf-stir-passport-divert], the only way those 293 diversion PASSporTs will be seen by the calling party is if 294 redirection is used (SIP 3XX responses) instead of retargeting; while 295 some network policies may want to conceal service logic from the 296 originating party, sending redirections in the backwards direction is 297 the only current defined way for secure indications of redirection to 298 be revealed to the calling party. That in turn would allow the 299 calling user agent to have a strong assurance that legitimate 300 entities in the call path caused the request to reach a party that 301 the caller did not anticipate. 303 This specification introduces another alternative. When per 304 Section 4 the terminating side sends an UPDATE with an Identity 305 header containing a PASSporT for its current From (or PAID) header 306 field value, it MAY include in Identity header field values any "div" 307 PASSporTs it received in the INVITE that initiated this provisional 308 dialog. These "div" PASSporTs will enable the originating side to 309 receive a secure assurance that the call is being fielded by the 310 proper recipient per the routing of the call. Note however that 311 "div" is not universally supported, and thus calls may be retargeted 312 with generating a "div" PASSporT, so sending those PASSporTs in the 313 backwards direction cannot be mandated. 315 7. Authorization Policy for Callers 317 In a traditional telephone call, the called party receives an 318 alerting signal and can make a decision about whether or not to pick 319 up a phone. They may have access to displayed information, like 320 "Caller ID", to help them arrive at an authorization decision. The 321 situation is more complicated for callers, however: callers typically 322 expect to be connected to the proper destination and are often 323 holding telephones in a position that would not enable them to see 324 displayed information, if any were available for them to review--and 325 moreover, their most direct response to a security breach would be to 326 hang up the call they were in the middle of placing. 328 While this specification will not prescribe any user experience 329 associated with placing a call, it assumes that callers might have 330 some way to a set an authorization posture that will result in the 331 right thing happening when the connected identity is not expected. 332 This is analogous to a situation where SRTP negotiation fails because 333 the keys exchanges at the media layer do not match fingerprints 334 exchanged at the signaling layer: when a user requests 335 confidentiality services, and they are unavailable, media should not 336 be exchanged. Thus we assume that users have a way in their 337 interface to require this criticality, on a per-call basis, or 338 perhaps on a per-destination basis, that would cause their user agent 339 to send the INVITE with a Require for 100rel. Similarly, users will 340 not always place calls where the connected identity is crucial--but 341 when they do, they should have a way to tell their devices that the 342 call should not be completed if it arrives at an unexpected party. 344 Ultimately, authorization policy for called parties is difficult to 345 set, as calls can end up at unexpected places for legitimate reasons. 346 Some work has been done to make sure that secure diversion works with 347 STIR, as described in Section 6. 349 8. Pre-Association with Destinations 351 Any connected identity mechanism will work best if the user knows 352 before initiating a call that connected identity is supported by the 353 destination side. Not every institution that a user wants to connect 354 to securely will support STIR and connected identity out of the gate. 356 The user interface of modern smartphones support an address book from 357 which users select telephone numbers to dial. Even when dialing a 358 number manually, the interface frequently checks the address book and 359 will display to users any provisioned name for the target of the call 360 if one exists. Similarly, when clicking on a telephone number viewed 361 on a web page, or similar service, smartphone often prompt users 362 approve the access to the outbound dialer. These sorts of decision 363 points, when the user is still interacting with the user interface, 364 provide an opportunity to form a pre-association with the 365 destination, and potentially even to exchange STIR PASSporTs in order 366 to validate whether or not the expected destination can be reached 367 securely. Again, this is probably most meaningful for contacting 368 financial, government, or emergency services, for cases where 369 reaching an unintended destination may have serious consequences. 371 Future versions of this specification will explore how the security 372 features of destinations can be discovered before calls are set up so 373 that calling parties can make more informed authorization decisions. 374 This may rely on the establishment of a provisional, media-less SIP 375 dialog which can then negotiate media when the user approves of the 376 destination. In some environments, that may require the use of 377 mechanisms defined by [I-D.ietf-stir-oob]. 379 9. Examples 381 [TBD: Revise RFC4916 examples to show new Identity header present in 382 UPDATE and in a backwards-direction BYE.] 384 10. Updates to RFC4916 386 [TBD - ways that UPDATEs in the backwards direction can carry 387 additional information in support of the above] 389 In general, the guidance of RFC4916 remains valid for RFC8224. 391 The deprecation of the Identity-Info header has a number of 392 implications for RFC4916; all of the protocol examples need to be 393 updated to reflect that. 395 11. Acknowledgments 397 We would like to thank YOU for your contributions to this 398 specification. 400 12. IANA Considerations 402 This memo includes no request to IANA. 404 13. Security Considerations 406 TBD. 408 14. Informative References 410 [I-D.ietf-modern-problem-framework] 411 Peterson, J. and T. McGarry, "Modern Problem Statement, 412 Use Cases, and Framework", draft-ietf-modern-problem- 413 framework-04 (work in progress), March 2018. 415 [I-D.ietf-stir-oob] 416 Rescorla, E. and J. Peterson, "STIR Out-of-Band 417 Architecture and Use Cases", draft-ietf-stir-oob-07 (work 418 in progress), March 2020. 420 [I-D.ietf-stir-passport-divert] 421 Peterson, J., "PASSporT Extension for Diverted Calls", 422 draft-ietf-stir-passport-divert-09 (work in progress), 423 July 2020. 425 [I-D.peterson-modern-teri] 426 Peterson, J., "An Architecture and Information Model for 427 Telephone-Related Information (TeRI)", draft-peterson- 428 modern-teri-04 (work in progress), March 2018. 430 [I-D.peterson-stir-messaging] 431 Peterson, J. and C. Wendt, "Messaging Use Cases for STIR", 432 draft-peterson-stir-messaging-00 (work in progress), 433 November 2020. 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, 437 DOI 10.17487/RFC2119, March 1997, 438 . 440 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 441 A., Peterson, J., Sparks, R., Handley, M., and E. 442 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 443 DOI 10.17487/RFC3261, June 2002, 444 . 446 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 447 Provisional Responses in Session Initiation Protocol 448 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 449 . 451 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 452 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 453 2002, . 455 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 456 Extensions to the Session Initiation Protocol (SIP) for 457 Asserted Identity within Trusted Networks", RFC 3325, 458 DOI 10.17487/RFC3325, November 2002, 459 . 461 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 462 Authenticated Identity Management in the Session 463 Initiation Protocol (SIP)", RFC 4474, 464 DOI 10.17487/RFC4474, August 2006, 465 . 467 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 468 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 469 2007, . 471 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 472 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 473 2014, . 475 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 476 Telephone Identity Problem Statement and Requirements", 477 RFC 7340, DOI 10.17487/RFC7340, September 2014, 478 . 480 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 481 "Authenticated Identity Management in the Session 482 Initiation Protocol (SIP)", RFC 8224, 483 DOI 10.17487/RFC8224, February 2018, 484 . 486 Authors' Addresses 488 Jon Peterson 489 Neustar, Inc. 490 1800 Sutter St Suite 570 491 Concord, CA 94520 492 US 494 Email: jon.peterson@team.neustar 496 Chris Wendt 497 Comcast 498 One Comcast Center 499 Philadelphia, PA 19103 500 USA 502 Email: chris-ietf@chriswendt.net