idnits 2.17.00 (12 Aug 2021) /tmp/idnits31473/draft-ietf-stir-rfc4916-update-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document date (21 April 2022) is 23 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 568, but no explicit reference was found in the text == Unused Reference: 'RFC8396' is defined on line 587, 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 (~~), 2 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: 23 October 2022 Somos 6 21 April 2022 8 Connected Identity for STIR 9 draft-ietf-stir-rfc4916-update-00 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 23 October 2022. 42 Copyright Notice 44 Copyright (c) 2022 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 (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Revised BSD License text as 53 described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Revised BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Connected Identity Problem Statement for STIR . . . . . . . . 4 61 4. Connected Identity in Provisional Dialogs . . . . . . . . . . 5 62 5. Connected Identity in Mid-Dialog and Dialog-Terminating 63 Requests . . . . . . . . . . . . . . . . . . . . . . . . 6 64 6. Interaction with Divert PASSporTs . . . . . . . . . . . . . . 7 65 7. Authorization Policy for Callers . . . . . . . . . . . . . . 8 66 8. Creating Pre-Association with Destinations . . . . . . . . . 9 67 8.1. Media-less Dialogs for Connected Identity . . . . . . . . 9 68 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 10 69 9.1. Connected Identity During Normal Call Setup . . . . . . . 10 70 9.2. Connected Identity During Retargeted Call Setup . . . . . 11 71 10. Updates to RFC4916 . . . . . . . . . . . . . . . . . . . . . 12 72 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 73 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 74 13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 75 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 76 14.1. Informative References . . . . . . . . . . . . . . . . . 12 77 14.2. Informative References . . . . . . . . . . . . . . . . . 14 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 80 1. Introduction 82 The Session Initiation Protocol (SIP) [RFC3261] initiates sessions, 83 and as a step in establishing sessions, it exchanges information 84 about the parties at both ends of a session. Users review 85 information about the calling party, for example, to determine 86 whether to accept communications initiated by a SIP, in the same way 87 that users of the telephone network assess "Caller ID" information 88 before picking up calls. This information may sometimes be consumed 89 by automata to make authorization decisions. 91 STIR [RFC8224] provides a cryptographic assurance of the identity of 92 calling parties in order to prevent impersonation, which is a key 93 enabler of unwanted robocalls, swatting, vishing, voicemail hacking, 94 and similar attacks (see [RFC7340]). There also exists a related 95 problem: the identity of the party who answers a call can differ from 96 that of the initial called party for various innocuous reasons such 97 as call forwarding, but in certain network environments, it is 98 possible for attackers to hijack the route of a called number and 99 direct it to a resource controlled by the attacker. It can 100 potentially be difficult to determine why a call reached a target 101 other than the one originally intended, and whether the party 102 ultimately reached by the call is one that the caller should trust. 103 The lack of mutual authentication of parties moreover makes it 104 possible for outside attackers to inject forged messages (e.g. BYE) 105 into a SIP session. 107 The property of providing identity in the backwards direction of a 108 call is here called "connected identity." Previous work on connected 109 identity focused on fixing the core semantics of SIP. [RFC4916] 110 allowed a mid-dialog request, such as an UPDATE [RFC3311], to convey 111 identity in either direction within the context of an existing 112 INVITE-initiated dialog. In an update to the original [RFC3261] 113 behavior, [RFC4916] allowed that UPDATE to alter the From header 114 field value for requests in the backwards direction: previously 115 [RFC3261] required that the From header field values sent in requests 116 in the backwards direction reflect the To header field value of the 117 dialog-forming request, for various backwards-compatibility reasons. 118 Under the original [RFC3261] rules, if Alice sent a dialog-forming 119 request to Bob, then even if Bob's SIP service forwarded that dialog- 120 forming request to Carol, Carol would still be required to put Bob's 121 identity in the From header field value in any mid-dialog requests in 122 the backwards direction. 124 One of the original motivating use cases for [RFC4916] was the use of 125 connected identity with the SIP Identity [RFC4474] header field. 126 While a mid-dialog request in the backwards direction (e.g. UPDATE) 127 can be signed with Identity like any other SIP request, forwarded 128 requests would not be signable without the ability to change the mid- 129 dialog From header field value: Carol, say, would not be able to 130 furnish a key to sign for Bob's identity, if Carol wanted to sign 131 requests in the backwards direction. Carol would however be able to 132 sign for her own identity in the From header field value, if mid- 133 dialog requests in the backwards direction were permitted to vary 134 from the original To header field value. 136 With the obsolence of [RFC4474] by [RFC8224], this specification 137 updates [RFC4916] to reflect the changes to the SIP Identity header 138 and the revised problem space of STIR. It also explores some new 139 features that would be enabled by connected identity for STIR, 140 including the use of connected identity to prevent route hijacking 141 and to notify callers when an expected called party has successfully 142 been reached. This document also addresses concerns about applying 143 [RFC4916] connected identity to STIR discussed in the SIPBRANDY 144 framework [RFC8862]. 146 One area of connected identity that is not explored in this document 147 is the implications for conferencing, especially meshed conferencing 148 systems. This scope of this mechanism is solely two-party 149 communications; any work towards multiparty sharing of connected 150 identity is left for future work. 152 2. Terminology 154 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 155 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 156 "OPTIONAL" in this document are to be interpreted as described in BCP 157 14 [RFC2119] [RFC8174] when, and only when, they appear in all 158 capitals, as shown here. 160 3. Connected Identity Problem Statement for STIR 162 The STIR problem statement [RFC7340] enumerates robocalling, 163 voicemail hacking, vishing, and swatting as problems with the modern 164 telephone network that are enabled, or abetted, by impersonation: by 165 the ability of a calling party to arbitrarily set the telephone 166 number that will be rendered to end users to identify the caller. 168 Today, sophisticated adversaries can redirect calls on the PSTN to 169 destinations other than the intended called party. For some call 170 centers, like those associated with financial institutions, 171 healthcare, and emergency services, an attacker could hope to gain 172 valuable information about people or to prevent some classes of 173 important services. Moreover, on the Internet, the lack of any 174 centralized or even federated routing system for telephone numbers 175 has resulted in deployments where the routing of calls is arbitrary: 176 calls to telephone numbers might be unceremoniously dumped on a PSTN 177 gateway, they might be sent to a default intermediary that makes 178 forwarding decisions based on a local flat file, various mechanisms 179 like private ENUM [RFC6116] might be consulted, or routing might be 180 determined in some other, domain-specific way. In short, there are 181 numerous attack surfaces that an adversary could explore to attempt 182 to redirect calls to a particular number to someplace other than the 183 intended destination. 185 Another motivating use case for connected identity is mid-dialog 186 requests, including BYE. The potential for an intermediary to 187 generate a forged BYE in the backwards direction has always been 188 built in to the stateful dialog management of SIP. For example, 189 there is a class of mobile fraud attacks ("short-stopping") that rely 190 on intermediary networks making it appear as if a call has terminated 191 to one side, while maintaining that the call is still active to the 192 other, in order to create a billing discrepancy that could be 193 pocketed by the intermediary. If BYE requests in both directions of 194 a SIP dialog could be authenticated with STIR, just like dialog- 195 forming requests, then another impersonation vector leading to fraud 196 in the telephone network could be shut down. 198 There are however practical limits to what securing the signaling can 199 achieve. [RFC4916] rightly observed that once a SIP call has been 200 answered, the called party can be replaced by a different party (with 201 a different identity) due to call transfer, call park and retrieval, 202 and so on. In some cases, due to the presence of a back-to-back user 203 agent, it can be effectively impossible for the calling party to know 204 that this has happened. The problem statement considered for STIR 205 focuses solely on signaling, not whether media from the connected 206 party should be rendered to the caller when a dialog has been 207 established. This specification does not consider further any 208 threats that arise from a substitution of media. 210 4. Connected Identity in Provisional Dialogs 212 [RFC4916] identified a means of sending Identity header field values 213 in the backwards direction before a final response to a dialog has 214 been received by the UAC. It relied on the use of the UPDATE method 215 to send the connected identity in the backwards direction after the 216 UAS had received and responded to a PRACK [RFC3262] from the UAC, 217 which would in turn have been triggered by a provisional 1xx response 218 sent earlier by the UAC. [RFC4916] permits the From header field of 219 the UPDATE to change the address of record of the recipient: if the 220 original INVITE had been sent with a To header field value of 221 "sip:bob@example.com", the UAS in its UPDATE could set the From 222 header field value to "sip:carol@example.com." For STIR, this is a 223 very important property, as Carol might not even possess a credential 224 that can legitimately sign for Bob. 226 In order to use connected identity with STIR, UAC's that require 227 connected identity MUST thus send a Require header field with the 228 option tag 100rel in INVITEs (per [RFC3262]) in addition to an 229 Identity header field value containing a PASSporT. UAS's that 230 support this mechanism will first send a Require header field with 231 the option tag 100rel in 1xx class responses to INVITEs that they 232 receive, along with the necessary RSeq header field. The UAC will 233 send a PRACK when it receives the reliable 1xx response from the UAS; 234 the UAS, upon receiving a PRACK, responds with a 200 OK. At this 235 point, the terminating UA is free to send an UPDATE [RFC3311] request 236 in the backwards direction to the originating UA. This update will 237 contain an Identity header, with a PASSporT that signs for the 238 connected identity in its "orig" claim, which typically corresponds 239 to the From header field value of the UPDATE request. If the 240 PASSporT is valid, the originating UA will respond with an OK, and 241 may perform any behaviors associated with the updated identity (see 242 Section 7). Even if connected identity is not required by the 243 originator of an INVITE request, it can still be solicited if 244 available by sending the 100rel option tag in a Supported header 245 field when sending an INVITE with an Identity header, which will 246 trigger the preceding flow if the UAS supports connected identity. 248 Usually, the updated Identity reflects a change to the From header 249 field value. But in many operating environments, the From header 250 field value does not contain the identity of the caller that has been 251 asserted by the network, which is instead conveyed by the 252 P-Asserted-Identity header field [RFC3325]. The contents of PAID are 253 not used for dialog matching, and so in environments where PAID is 254 used, it can be altered more dynamically. However, in order for the 255 connected identity and a PASSporT to be conveyed in the backwards 256 direction, a provisional dialog still needs to be established, and an 257 UPDATE sent: in this case, it will be the UDPATE that contains the 258 connected identity in its P-Asserted-Identity header field value, and 259 that value will be signed by the PASSporT in its "orig" claim. 261 5. Connected Identity in Mid-Dialog and Dialog-Terminating Requests 263 The use of the connected identity mechanism here specified is not 264 limited to provisional dialog requests. Once a dialog has been 265 established with connected identity, any re-INVITEs from either the 266 originating and terminating side, as well as any BYE requests, MUST 267 contain Identity headers with valid PASSporTs based on the current 268 To/From header field values for the dialog. This prevents third- 269 parties from spoofing any mid-dialog requests in order to redirect 270 media or similarly interfere with communications, as well as 271 preventing denial of service teardowns by attackers. 273 Theoretically, any SIP requests in a dialog could be signed in this 274 fashion, though it is unclear how valuable it would be for some (e.g. 275 OPTIONS). Requests with specialized payloads such as INFO or 276 MESSAGE, however, would require additional specification for how 277 integrity protection for their bodies could be implemented. Some 278 work has been done toward that for MESSAGE (see 279 [I-D.peterson-stir-messaging]. This specification thus does not 280 mandate PASSporTs for any requests sent in a dialog other than 281 INVITE, UPDATE, and BYE. [TBD: recommend signing PRACK?] 283 It might seem tempting to require that, if an INVITE has been sent 284 with an Identity header containing a PASSporT, any CANCEL request 285 received for the dialog initiated by that INVITE must also contain an 286 Identity header with a PASSporT. However, CANCEL requests can also 287 sent be sent by stateful proxy servers engaged in parallel forking; 288 for example, when branches need to be canceled because a final 289 response has been received from a UAS. It is however REQUIRED by 290 this specification that if a UAC sends a CANCEL for its own PASSporT- 291 protected INVITE request, that it include an Identity header with a 292 valid PASSporT in the CANCEL. UAS policy will have to determine the 293 instances where it will accept unsigned CANCEL requests for a dialog 294 initiated with a signed INVITE. 296 6. Interaction with Divert PASSporTs 298 Many of the use cases that motivate connected identity involve 299 retargeting: when a call acquires a new target (in its Request-URI) 300 during transit, the terminating side needs a way to express to the 301 originating side which destination the INVITE reached. In STIR, the 302 "div PASSporT type [RFC8946] was created to securely record when a 303 call was retargeted from one destination to another. Those "div" 304 PASSporTs can be consumed on the terminating side by verification 305 services to determine that a call has reached its eventual 306 destination for the right reasons. 308 As specified in [RFC8946], the only way those diversion PASSporTs 309 will be seen by the calling party is if redirection is used (SIP 3XX 310 responses) instead of retargeting; as some network policies aim to 311 conceal service logic from the originating party, sending 312 redirections in the backwards direction is the only current defined 313 way for secure indications of redirection to be revealed to the 314 calling party. That in turn would allow the calling user agent to 315 have a strong assurance that legitimate entities in the call path 316 caused the request to reach a party that the caller did not 317 anticipate. 319 This specification introduces another alternative. When per 320 Section 4 the terminating side sends an UPDATE with an Identity 321 header containing a PASSporT for its current From (or PAID) header 322 field value, it MAY include in Identity header field values any "div" 323 PASSporTs it received in the INVITE that initiated this provisional 324 dialog. These "div" PASSporTs will enable the originating side to 325 receive a secure assurance that the call is being fielded by the 326 proper recipient per the routing of the call. Note however that 327 "div" is not universally supported, and thus calls may be retargeted 328 with generating a "div" PASSporT, so sending those PASSporTs in the 329 backwards direction cannot be mandated. Also note that this will 330 potentially reveal service logic to the called party. As presumably 331 this service logic is enacted on behalf of the called party, the 332 called party can make a policy determination about reflecting those 333 "div" PASSporTs back to the caller. 335 7. Authorization Policy for Callers 337 In a traditional telephone call, the called party receives an 338 alerting signal and can make a decision about whether or not to pick 339 up a phone. They may have access to displayed information, like 340 "Caller ID", to help them arrive at an authorization decision. The 341 situation is more complicated for callers, however: callers typically 342 expect to be connected to the proper destination and are often 343 holding telephones in a position that would not enable them to see 344 displayed information, if any were available for them to review--and 345 moreover, their most direct response to a security breach would be to 346 hang up the call they were in the middle of placing. 348 While this specification does not prescribe any user experience 349 associated with placing a call, it assumes that callers might have 350 some way to a set an authorization posture that will result in the 351 right thing happening when the connected identity is not expected. 352 This is analogous to a situation where SRTP negotiation fails because 353 the keys exchanges at the media layer do not match fingerprints 354 exchanged at the signaling layer: when a user requests 355 confidentiality services, and they are unavailable, media should not 356 be exchanged. Thus we assume that users have a way in their 357 interface to require this criticality, on a per-call basis, or 358 perhaps on a per-destination basis, that would cause their user agent 359 to send the INVITE with a Require for 100rel. Similarly, users will 360 not always place calls where the connected identity is crucial, but 361 when they do, they should have a way to tell their devices that the 362 call should not be completed if it arrives at an unexpected party. 364 Ultimately, authorization policy for called parties is difficult to 365 set, as calls can end up at unexpected places for legitimate reasons. 366 Some work has been done to make sure that secure diversion works with 367 STIR, as described in Section 6. 369 8. Creating Pre-Association with Destinations 371 Any connected identity mechanism will work best if the user knows 372 before initiating a call that connected identity is supported by the 373 destination side. Not every institution that a user wants to connect 374 to securely will support STIR and connected identity out of the gate. 375 Some sort of directory service might exist advertising support for 376 connected identity which institutions could use to inform potential 377 callers that, if connected identity is supported when reaching them 378 with SIP, there is a potential security problem. Similarly, user 379 devices might keep some sort of log recording that a destination 380 previously supported connected identity, so that if support is 381 unavailable later, calling users could be alerted to a potential 382 security problem. 384 8.1. Media-less Dialogs for Connected Identity 386 The user interface of modern smartphones support an address book from 387 which users select telephone numbers to dial. Even when dialing a 388 number manually, the interface frequently checks the address book and 389 will display to users any provisioned name for the target of the call 390 if one exists. Similarly, when clicking on a telephone number viewed 391 on a web page, or similar service, smartphones often prompt users 392 approve the access to the outbound dialer. These sorts of decision 393 points, when the user is still interacting with the user interface 394 before a call is placed, provide an opportunity to probe what 395 identity would be reached as a destination, and potentially even to 396 exchange STIR PASSporTs in order to validate whether or not the 397 expected destination can be reached securely. Again, this is 398 probably most meaningful for contacting financial, government, or 399 emergency services, for cases where reaching an unintended 400 destination may have serious consequences. 402 The establishment of media-less dialogs has long been specified as a 403 component of third-party call control in SIP [RFC3375], in which an 404 INVITE is sent with no SDP. Similar media-less dialogs have been 405 proposed for certain automata per [RFC5552]. In the STIR context, a 406 media-less dialog is established by sending an INVITE with an 407 Identity header but no SDP. STIR-aware UAS's that support this 408 specification, upon receiving an INVITE with no SDP, carrying a 409 PASSporT with a 100rel in the Require header field value, SHOULD 410 follow the mechanism described in Section 4 to send a provisional 411 response and then an UPDATE carrying a PASSporT in the backwards 412 direction. The PASSporT received in the backwards direction could be 413 rendered to the originating user to help them decide if they want to 414 place the call. 416 [More TBD. In some environments, that may require the use of 417 mechanisms defined by [RFC8816].] 419 9. Examples 421 9.1. Connected Identity During Normal Call Setup 423 The following example shows the basic call flow of connected identity 424 as sent during call setup. For the purposes of this example, assume 425 the authentication service acts on behalf of both Alice and Bob; more 426 likely, they will each of their own authentication service. Note 427 that responses (183 and 200) are shown here going past the 428 authentication service; since they are not requests, they cannot be 429 signed. 431 Alice's UA Bob's UA 432 Authentication 433 Service 435 INVITE INVITE 436 ----------------> ----------------> 438 183 439 <----------------------------------- 441 PRACK PRACK 442 ----------------> ----------------> 444 200 200 445 <----------------------------------- 447 UPDATE UPDATE 448 <---------------- <---------------- 450 200 451 ------------------------------------> 453 [Message details TBD.] 454 Once the UPDATE has been received at Alice's UA, Alice responds with 455 a 200 OK acknowledging receipt of the connected identity from Bob. As 456 in this case, reaching Bob was the intended desintation, Alice can 457 proceed with the call. 459 9.2. Connected Identity During Retargeted Call Setup 461 The following example shows the basic call flow of connected identity 462 as sent during call setup when retargeting has occurred. For the 463 purposes of this example, assume that Alice intended to reach Bob, 464 but the call has been forwarded to Carol. Also assume the 465 authentication service acts on behalf of both Alice and Carol; more 466 likely, they will each of their own authentication service. Note 467 that responses (183 and 200) are shown here going past the 468 authentication service; since they are not requests, they cannot be 469 signed. 471 Alice's UA Carol's UA 472 Authentication 473 Service 475 INVITE INVITE 476 ----------------> ----------------> 478 183 479 <----------------------------------- 481 PRACK PRACK 482 ----------------> ----------------> 484 200 485 <----------------------------------- 487 UPDATE UPDATE 488 <---------------- <---------------- 490 200 491 ------------------------------------> 493 [Message details TBD.] 495 Once the UPDATE has been received at Alice's UA, Alice responds with 496 a 200 OK acknowledging receipt of the connected identity from Carol. 497 Alice can then make any necessary policy decision about treating this 498 call based on the fact that it arrived at Carol rather than Bob. 500 10. Updates to RFC4916 502 [TBD - ways that UPDATEs in the backwards direction can carry 503 additional information in support of the above] 505 In general, the guidance of RFC4916 remains valid for RFC8224. 507 The deprecation of the Identity-Info header has a number of 508 implications for RFC4916; all of the protocol examples need to be 509 updated to reflect that. 511 11. Acknowledgments 513 We would like to thank YOU for your contributions to this 514 specification. 516 12. IANA Considerations 518 This memo includes no request to IANA. 520 13. Security Considerations 522 TBD. 524 14. References 526 14.1. Informative References 528 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 529 Requirement Levels", BCP 14, RFC 2119, 530 DOI 10.17487/RFC2119, March 1997, 531 . 533 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 534 A., Peterson, J., Sparks, R., Handley, M., and E. 535 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 536 DOI 10.17487/RFC3261, June 2002, 537 . 539 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 540 Provisional Responses in Session Initiation Protocol 541 (SIP)", RFC 3262, DOI 10.17487/RFC3262, June 2002, 542 . 544 [RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP) 545 UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October 546 2002, . 548 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 549 Extensions to the Session Initiation Protocol (SIP) for 550 Asserted Identity within Trusted Networks", RFC 3325, 551 DOI 10.17487/RFC3325, November 2002, 552 . 554 [RFC3375] Hollenbeck, S., "Generic Registry-Registrar Protocol 555 Requirements", RFC 3375, DOI 10.17487/RFC3375, September 556 2002, . 558 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 559 Authenticated Identity Management in the Session 560 Initiation Protocol (SIP)", RFC 4474, 561 DOI 10.17487/RFC4474, August 2006, 562 . 564 [RFC4916] Elwell, J., "Connected Identity in the Session Initiation 565 Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June 566 2007, . 568 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 569 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 570 2014, . 572 [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure 573 Telephone Identity Problem Statement and Requirements", 574 RFC 7340, DOI 10.17487/RFC7340, September 2014, 575 . 577 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 578 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 579 May 2017, . 581 [RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt, 582 "Authenticated Identity Management in the Session 583 Initiation Protocol (SIP)", RFC 8224, 584 DOI 10.17487/RFC8224, February 2018, 585 . 587 [RFC8396] Peterson, J. and T. McGarry, "Managing, Ordering, 588 Distributing, Exposing, and Registering Telephone Numbers 589 (MODERN): Problem Statement, Use Cases, and Framework", 590 RFC 8396, DOI 10.17487/RFC8396, July 2018, 591 . 593 [RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity 594 Revisited (STIR) Out-of-Band Architecture and Use Cases", 595 RFC 8816, DOI 10.17487/RFC8816, February 2021, 596 . 598 [RFC8862] Peterson, J., Barnes, R., and R. Housley, "Best Practices 599 for Securing RTP Media Signaled with SIP", BCP 228, 600 RFC 8862, DOI 10.17487/RFC8862, January 2021, 601 . 603 [RFC8946] Peterson, J., "Personal Assertion Token (PASSporT) 604 Extension for Diverted Calls", RFC 8946, 605 DOI 10.17487/RFC8946, February 2021, 606 . 608 14.2. Informative References 610 [I-D.peterson-stir-messaging] 611 Peterson, J. and C. Wendt, "Messaging Use Cases and 612 Extensions for STIR", Work in Progress, Internet-Draft, 613 draft-peterson-stir-messaging-01, 22 February 2021, 614 . 617 [RFC5552] Burke, D. and M. Scott, "SIP Interface to VoiceXML Media 618 Services", RFC 5552, DOI 10.17487/RFC5552, May 2009, 619 . 621 [RFC6116] Bradner, S., Conroy, L., and K. Fujiwara, "The E.164 to 622 Uniform Resource Identifiers (URI) Dynamic Delegation 623 Discovery System (DDDS) Application (ENUM)", RFC 6116, 624 DOI 10.17487/RFC6116, March 2011, 625 . 627 Authors' Addresses 629 Jon Peterson 630 Neustar, Inc. 631 Email: jon.peterson@team.neustar 633 Chris Wendt 634 Somos 635 Email: chris-ietf@chriswendt.net