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