TransUnion

jon.peterson@transunion.com

Somos

chris@appliedbits.com

ART stir SIP The Session Initiation Protocol (SIP) Identity header field conveys cryptographic identity information about the originators of SIP requests. However, the Secure Telephone Identity Revisited (STIR) framework provides no means for determining the identity of the called party in a conventional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem to reflect the changes to SIP identity that accompanied STIR. It also considers a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destination and preventing the spoofing of mid-dialog or dialog-terminating events by intermediaries or third parties.

Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .

Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents () in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

Table of Contents

• .  Introduction
• .  Terminology
• .  Connected Identity Problem Statement for STIR
• .  Connected Identity without Diversion
• .  Connected Identity with Diversion
• .  Connected Identity in Mid-Dialog and Dialog-Terminating Requests
• .  Authorization Policy for Callers
• .  Creating Pre-Association with Destinations
• .  The "rsp" PASSporT Type
• . UPDATE Procedures for Provisional Dialogs
• . IANA Considerations
• . Privacy Considerations
• . Security Considerations
• . References
  • .  Normative References
  • .  Informative References
• Acknowledgments
• Authors' Addresses

Introduction The Session Initiation Protocol (SIP) initiates sessions, and as a step in establishing sessions, it exchanges information about the parties at both ends. Called users review information about the calling party, for example, to determine whether to accept communications initiated by SIP), in the same way that users of the telephone network assess "Caller ID" information before picking up calls. This information may sometimes be consumed by automated systems to make authorization decisions. STIR provides a cryptographic assurance of the identity of calling parties in order to prevent impersonation, which is a key enabler of unwanted robocalls, swatting, vishing, voicemail hacking, and similar attacks (see ). A related problem also exists: The identity of the party who answers a call can differ from that of the initial called party for various innocuous reasons such as call forwarding. In certain network environments, however, it is possible for attackers to hijack the route of a called number and direct it to a resource controlled by the attacker. It can potentially be difficult to determine why a call reached a target other than the one originally intended and whether the party ultimately reached by the call is one that the caller should trust. Moreover, the lack of mutual authentication of parties makes it possible for outside attackers to inject forged messages (e.g., BYE) into a SIP session. The property of providing the identity of the called party to the calling party is called "connected identity". Previous work on connected identity focused on fixing the core semantics of SIP. allows a mid-dialog request, such as an UPDATE , to convey identity in either direction within the context of an existing INVITE-initiated dialog. also allows that UPDATE to alter the From header field value for requests in the backwards direction; this is an update to the behavior described in , which requires that the From header field values sent in requests in the backwards direction reflect the To header field value of the dialog-forming request. Under the original rules in , if Alice sent a dialog-forming request to Bob, then even if Bob's SIP service forwarded that dialog-forming request to Carol, Carol would still be required to put Bob's identity in the From header field value in any mid-dialog requests in the backwards direction. One of the original motivating use cases for was the use of connected identity with the SIP Identity header field . While a mid-dialog request in the backwards direction (e.g., UPDATE) can be signed with identity like any other SIP request, forwarded requests would not be properly signed without the ability to change the mid-dialog From header field value. Thus, Carol would not be able to furnish a key to sign for Bob's identity if Carol wanted to sign requests in the backwards direction. Carol would, however, be able to sign for her own identity in the From header field value if mid-dialog requests in the backwards direction were permitted to vary from the original To header field value. With the obsolescence of by , this specification adapts the connected identity concepts of to STIR, reflecting the changes to the SIP Identity header field and the revised problem space that STIR introduces. It also explores some new features that would be enabled by connected identity for STIR, including the use of connected identity to prevent route hijacking and to notify callers when an expected called party has successfully been reached. This document also addresses concerns about applying connected identity to STIR discussed in the SIPBRANDY framework . One area of connected identity that is not explored in this document is the implications for conferencing, especially meshed conferencing systems. The scope of this mechanism is solely two-party communications; multiparty sharing of connected identity is left for future work.

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document assumes familiarity with common messages, response codes, and header fields used in SIP and the elements present in the Personal Assertion Token (PASSporT) format.

Connected Identity Problem Statement for STIR The STIR problem statement enumerates robocalling, voicemail hacking, vishing, and swatting as problems with the modern telephone network that are enabled, or abetted, by impersonation, i.e., the ability of a calling party to arbitrarily set the telephone number that will be rendered to end users to identify the caller. Today, sophisticated adversaries can redirect calls on the Public Switched Telephone Network (PSTN) to destinations other than the intended called party. For some call centers, like those associated with financial institutions, healthcare, and emergency services, an attacker could hope to gain valuable information about people or to prevent some classes of important services. Moreover, on the Internet, the lack of any centralized or even federated routing system for telephone numbers has resulted in deployments where the routing of calls is arbitrary: Calls to telephone numbers might be dumped on a PSTN gateway, they might be sent to a default intermediary that makes forwarding decisions based on a local configuration file, potentially using various mechanisms such as consulting a private ENUM , or routing might be determined in some other, domain-specific way. In short, there are numerous attack surfaces that an adversary could explore to attempt to redirect calls for a particular number to someplace other than the intended destination. Another motivating use case for connected identity is mid-dialog requests, including BYE. The potential for an intermediary to generate a forged BYE in the backwards direction has always been built in to the stateful dialog management of SIP. For example, there is a class of mobile fraud attacks ("call stretching") that rely on intermediary networks making it appear to one side as if a call has terminated, while maintaining that the call is still active to the other side, in order to create a billing discrepancy that could be pocketed by the intermediary. If BYE requests in both directions of a SIP dialog could be authenticated with STIR, in the same way as dialog-forming requests, then another impersonation vector leading to fraud in the telephone network could be shut down. Finally, telephone numbers are widely used today for two-factor authentication (TFA) prior to accessing web resources, which typically rely on sharing some sort of one-time password or similar unique link to validate control of a telephone number. These systems are often capable of using either telephone calls or messages for TFA. Connected identity is very valuable for these use cases because it gives a strong assurance to the calling party that they have in fact reached the telephone for the called telephone number. However, there are practical limits to what securing the signaling can achieve. rightly observes that once a SIP call has been answered, the called party can be replaced by a different party (with a different identity) due to call transfer, call park and retrieval, and so on. In some cases, due to the presence of a back-to-back user agent, it can be effectively impossible for the calling party to know that this has happened. The problem statement considered for STIR focuses solely on signaling, not whether media from the connected party should be rendered to the caller when a dialog has been established. This specification does not consider further any threats that arise from a substitution of media, though contains related guidance.

Connected Identity without Diversion In straightforward call setup, the address-of-record (AoR) of the party reached by an INVITE corresponds to the "dest" field of the PASSporT in the INVITE's Identity header field value. The calling party will, however, have no secure assurance that they have reached the proper party if an Identity header field cannot be sent to them in the backwards direction. Provided that the terminating side of the dialog is STIR-capable, they should have the capacity to sign a PASSporT for the AoR of the called party. This specification therefore adds provisional and final SIP responses, including the 100, 180, 183, and 200 responses, to the set of messages that may contain an Identity header field. PASSporTs that appear in SIP responses SHOULD use a "ppt" of "rsp", which is defined in (although "div" may additionally appear in responses, per ). PASSporTs of the "rsp" type will be referred to throughout this specification as "rsp" PASSporTs. At a high level, an "rsp" PASSporT is signed similarly to the "div" PASSporT , insofar as the certificate that signs an "rsp" PASSporT is signing the "dest" field rather than the "orig" field. If the terminating side does not possess an appropriate credential to sign for the value of the "dest" element value in the PASSporT, it MUST NOT sign and send an "rsp" PASSporT in the backwards direction. While it might seem attractive to provide identity for SIP failure response codes (4XX, 5XX, 6XX), those explicitly do not form dialogs or connections and are thus outside the scope of this specification. The same applies to SIP redirect (3XX) response codes, though see for guidance on authentication redirection. It is worth noting that at the time was written, the identity mechanism was far stricter about what counted as retargeting than is described in , which has canonicalization processes that eliminate minor changes to the URIs, especially when telephone numbers are the identifiers used by the caller and callee. For basic use cases, a PASSporT in a 183 or 200 OK should be sufficient to secure media keys for the purposes of SIPBRANDY . The handling of an "rsp" PASSporT differs from the handling of a PASSporT received in a SIP request. Most importantly, note that SIP responses cannot be rejected, unlike SIP requests -- there is no way for the recipient of a response to report errors to the sender. The only protocol action that the calling party could take upon receiving a response carrying a problem PASSporT is to issue a CANCEL (for provisional dialogs) or BYE request in order to tear down the dialog (see ). Moreover, provisional responses are not reliably delivered without using 100rel and Provisional Response Acknowledgement (PRACK) , and provisional responses may be consumed (without forwarding) by intermediaries under a variety of conditions. In short, their delivery is not guaranteed.

Connected Identity with Diversion Use cases involving authorized retargeting motivate connected identity. When a call acquires a new target (in its Request-URI) during transit, then the destination will no longer correspond to the target, the "dest" specified by the PASSporT in the dialog-forming request. If a PASSporT in a response came signed by a different destination than the caller intended, why should the caller trust it? In STIR, the "div" PASSporT type was created to securely record when a call was retargeted from one destination to another. Those "div" PASSporTs can be consumed on the terminating side by verification services to determine that a call has reached its eventual destination for the right reasons. As explains the situation, the only way those diversion PASSporTs will be seen by the calling party is if redirection is used (SIP 3XX responses) instead of retargeting. Because some network policies aim to conceal service logic from the originating party, sending redirections in the backwards direction is the only currently defined way for secure indications of redirection to be revealed to the calling party. That in turn would allow the calling user agent to have a strong assurance that legitimate entities in the call path caused the request to reach a party that the caller did not anticipate. This specification introduces another alternative. When sending an "rsp" PASSporT type in a SIP response, a User Agent Server (UAS) MAY also include (in Identity header field values) any "div" PASSporTs it received in the INVITE that initiated this dialog. Thus, PASSporTs of type "div" MAY also appear in SIP responses. These "div" PASSporTs can enable the originating side to receive a secure assurance that the call is being fielded by the proper recipient per the routing of the call. In this case, the "dest" signed in the "rsp" PASSporT MUST be the address-of-record of the party who was reached rather than the "dest" of the PASSporT received in the dialog-initiating INVITE. An "rsp" PASSporT that signs a different "dest" than the one that appeared in the PASSporT of the dialog-forming request MUST send at least one "div" PASSporT with it. If no "div" PASSporTs were received in a dialog-forming request with a different "dest" value than the original PASSporT claimed, then "rsp" PASSporTs MUST NOT be used in responses. "div" is not universally supported, so calls MAY be retargeted without generating a "div" PASSporT, in which case the use of "rsp" PASSporTs will not be possible. Note that the decision to trust any "div" or "rsp" PASSporT is, as always in STIR, a matter of local policy of the relying parties: Some stricter systems may not want to trust any "rsp" that differs from the "dest" in the PASSporT of the original request. Note that sending "div" PASSporTs in the backwards direction will potentially reveal service logic to the called party. As presumably this service logic is enacted on behalf of the called party, the called party can make a policy determination about reflecting those "div" PASSporTs back to the caller; connected identity may not be compatible with some operator policies. This mechanism does not require altering the value of the From header field value in requests or responses in the backwards direction. While this was a major concern of , in many operating environments, the From header field value does not even contain the identity of the caller that has been asserted by the network, which is instead conveyed by the P-Asserted-Identity (PAID) header field . The contents of PAID were never used for dialog matching, and so in environments where PAID is used, it can be altered more dynamically than the From header field (moreover, by introducing tag parameters to the To and From header field values, eliminates the need for stability in From values for dialog identification some time ago). For retargeting that utilizes the "from-change" option tag in , see . STIR is, in general, more flexible in constructing the "dest" than the Identity header field managed addresses-of-record at the time was written.

Connected Identity in Mid-Dialog and Dialog-Terminating Requests The use of the connected identity mechanism specified in this document is not limited to provisional dialog requests. Once a dialog has been established with connected identity, any re-INVITEs from either the originating and terminating side, as well as any BYE requests, SHOULD contain Identity header fields with valid PASSporTs. If only the terminating side supports connected identity, obviously the originator cannot be expected to know that it needs to send PASSporTs for subsequent requests like BYE. Doing so prevents third parties from spoofing any mid-dialog requests in order to redirect media or similarly interfere with communications, and it also prevents denial-of-service teardowns by attackers. Theoretically, any SIP requests in a dialog could be signed in this fashion, though it is unclear how valuable it would be for some (e.g., OPTIONS). Requests with specialized payloads such as INFO or MESSAGE, however, would require additional specification for how integrity protection for their bodies could be implemented. Some work has been done toward that for MESSAGE (see ). This specification thus does not recommend PASSporTs for any requests sent in a dialog other than INVITE, UPDATE, and BYE. It might seem tempting to require that, if an INVITE has been sent with an Identity header field containing a PASSporT, any CANCEL request received for the dialog initiated by that INVITE must also contain an Identity header field with a PASSporT. However, CANCEL requests can also be sent by stateful proxy servers engaged in parallel forking, for example, when branches need to be canceled because a final response has been received from a UAS. This specification does not forbid a User Agent Client (UAC) from sending a CANCEL for its own PASSporT-protected INVITE requests, as there may be limited use cases where it would be useful to relying parties, but recipients of a CANCEL should not expect PASSporTs to be present in connected identity cases. Mid-dialog requests also require special handling in diversion cases. Relying parties who intended to trust an "rsp" PASSporT MUST validate any "div" chain back to the "rsp" PASSporT on any Identity header field values received in responses (per ). The dialog initiator can then treat the certificate that signed that "rsp" PASSporT as the appropriate certificate to sign any further mid-dialog or dialog-terminating requests received in the backwards direction. Furthermore, the "dest" element value in any requests or responses sent in the backwards direction during this dialog MUST be the same as the "dest" element value in the first response to the dialog-forming request that contains a PASSporT -- unless the "from-change" extension is used, per .

Authorization Policy for Callers In a conventional telephone call, the called party receives an alerting signal and can make a decision about whether or not to pick up a phone. They may have access to displayed information, like "Caller ID", to help them arrive at an authorization decision. However, the situation is more complicated for callers because they typically expect to be connected to the proper destination and are often holding telephones in a position that would not enable them to see displayed information if any were available for them to review. Moreover, their most direct response to a security breach would be to hang up the call they were in the middle of placing. While this specification does not prescribe any user experience associated with placing a call, it assumes that callers might have some way to a set an authorization posture that will result in the right thing happening when the connected identity is not as expected. This is analogous to a situation where Secure Real-time Transport Protocol (SRTP) negotiation fails because the keys exchanged at the media layer do not match the fingerprints exchanged at the signaling layer: When a user requests confidentiality services and they are unavailable, media should not be exchanged. Thus, we assume that users have a way in their interface to require this criticality, on a per-call basis or perhaps on a per-destination basis. Users will not always place calls where the connected identity is crucial, but when they do, they should have a way to tell their devices that the call should not be completed if it arrives at an unexpected or unauthenticated party.

Creating Pre-Association with Destinations Any connected identity mechanism will work best if the user knows before initiating a call that connected identity is supported by the destination side. Not every institution that a user wants to connect to securely will support STIR and connected identity out of the gate. Some sort of directory service might exist that advertises support for connected identity, which institutions then could use to inform potential callers that, if connected identity is not supported when reaching them with SIP, there is a potential security problem. Similarly, user devices might keep some sort of log recording that a destination previously supported connected identity, so that if support is unavailable later, calling users could be alerted to a potential security problem. The user interface of modern smartphones supports an address book from which users select telephone numbers to dial. Even when dialing a number manually, the interface frequently checks the address book, which will display to users any provisioned name for the target of the call if one exists. Similarly, when clicking on a telephone number viewed on a web page or similar service, smartphones often prompt users to approve the access to the outbound dialer. These sorts of decision points, when the user is still interacting with the user interface before a call is placed, provide an opportunity to probe what identity would be reached as a destination and potentially even to exchange STIR PASSporTs in order to validate whether or not the expected destination can be reached securely. Again, this is probably most meaningful for contacting financial, government, or emergency services, for cases where reaching an unintended destination may have serious consequences. The establishment of media-less dialogs has long been specified as a component of third-party call control in SIP , in which an INVITE is sent with no Session Description Protocol (SDP). Similar media-less dialogs have been proposed for certain automated systems per . In the STIR context, a media-less dialog is established by sending an INVITE with an Identity header field but no SDP. When a STIR-aware UAS that supports this specification receives an INVITE that has no SDP, carries a PASSporT, and includes a 100rel in the Require header field value, it SHOULD follow the mechanism described in to send a provisional response carrying a PASSporT in the backwards direction. The PASSporT received in the backwards direction could be rendered to the originating user to help them decide if they want to place the call.

The "rsp" PASSporT Type This specification defines an "rsp" PASSporT type that is sent only in SIP responses; it MUST NOT be sent in SIP requests. Any "rsp" PASSporTs received in requests MUST be ignored. The header of an "rsp" PASSporT shows a "ppt" of "rsp": { "typ":"passport", "ppt":"rsp", "alg":"ES256", "x5u":"https://www.example.com/cert.pem" } The payload of an "rsp" PASSporT looks entirely like a normal PASSporT -- the only difference is in semantics, as the PASSporT is signed to authenticate the "dest" claim value rather than the "orig". { "orig":{"tn":"12155551212"}, "dest":{"tn":["12155551214"]}, "iat":1443208345 } No restrictions are placed here on additional elements appearing in the payload of an "rsp" type PASSporT.

UPDATE Procedures for Provisional Dialogs identifies a means of sending Identity header field values in the backwards direction before a final response to a dialog has been received by the UAC. It relies on negotiating support for "from-change" options tags on both sides, followed by the use of the UPDATE method to send the connected identity in the backwards direction. This can only happen after the UAS has received and responded to a PRACK from the UAC, which would in turn have been triggered by a provisional 1xx response sent earlier by the UAC. However, the complexity of this mechanism makes it impractical to deploy for both the primary use case and the diversion use case described above. It may still have utility for corner cases with legacy versions of SIP (that date before the addition of the To and From header field value tags) or more complex call parking scenarios. As such, this specification does not deprecate the "from-change" behavior in , nor does it provide an update for it for STIR -- that is left for future work.

IANA Considerations This specification defines a new PASSporT type for the "Personal Assertion Token (PASSporT) Extensions" registry , which resides at :

ppt value:

rsp

Reference:

RFC 9970,

Privacy Considerations Note that sending connected identity can reveal information about the called party. If a called party does not wish to be identified, it is especially important not to share rich call data (RCD) in the backwards direction, particular in business-to-consumer calling cases. From a user experience perspective, this would likely work similarly to current systems for sharing numbers, names, and even pictures from calling parties to called parties -- users have considerable control over that experience, and similarly for connected identity, this must be an opt-in choice for users. In general, RCD is more commonly used by enterprises than by individual users.

Security Considerations The security considerations of and apply to the use of the "rsp" PASSporT. In general, a PASSporT of type "rsp" has similar security properties to a diversion ("div") PASSporT . Relying parties leverage an "rsp" PASSporT to determine the recipient of a request, and as with "div", the "dest" element of an "rsp" PASSporT is signed rather than the "orig" element. The major threat that "rsp" addresses is the impersonation of a SIP response or mid-dialog/dialog-terminating request. For the latter, this might include forging a BYE for a denial-of-service attack or, for example, forging a re-INVITE that negotiates media channels controlled by an attacker. For the former, some form of route hijacking or similar attack can be mounted by forging a dialog-forming response that appears to the caller to initiate a dialog with the intended destination. The "rsp" mechanism uses PASSporTs to provide a non-repudiable assurance of the signer of such responses and requests. The value of an "rsp" PASSporT to relying parties, as with all PASSporTs, depends on the relying party trusting the certificate that signs the PASSporT and having a reasonable assurance that the certificate in question is eligible to sign responses/requests for the number in the "dest" claim of the "rsp" PASSporT. For STIR certificates that use Service Provider Codes (SPCs), effectively the relying party knows the network operator who is vouching for that "rsp". This in turn enables traceback and similar mitigations. As mentioned in , the use of "div" along with "rsp" in responses may reveal the service logic of diversions to calling parties. However, since the called party ultimately invokes the "rsp" mechanism, any necessary policy controls can prevent the sending of "rsp" when that service logic must be protected. The use of PASSporTs within responses creates a novel potential vector for amplification attacks, as many responses may be sent in response to a single SIP request, and the presence of a PASSporT meaningfully increases the size of SIP responses. However, given that PASSporTs can only be present in responses to requests carrying a PASSporT, and thus requests with strong sender authentication, called parties have adequate means to authorize the source of requests and disregard spoofs intended to trigger amplification attacks.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. [STANDARDS-TRACK] This document specifies an extension to the Session Initiation Protocol (SIP) providing reliable provisional response messages. This extension uses the option tag 100rel and defines the Provisional Response ACKnowledgement (PRACK) method. [STANDARDS-TRACK] This specification defines the new UPDATE method for the Session Initiation Protocol (SIP). UPDATE allows a client to update parameters of a session (such as the set of media streams and their codecs) but has no impact on the state of a dialog. In that sense, it is like a re-INVITE, but can be sent before the initial INVITE has completed. This makes it very useful for updating session parameters within early dialogs. This document describes private extensions to SIP that enable a network of trusted SIP servers to assert the identity of authenticated users, and the application of existing privacy mechanisms to the identity problem. The use of these extensions is only applicable inside an administrative domain with previously agreed-upon policies for generation, transport and usage of such information. This document does NOT offer a general privacy or identity model suitable for use between different trust domains, or use in the Internet at large. Third party call control refers to the ability of one entity to create a call in which communication is actually between other parties. Third party call control is possible using the mechanisms specified within the Session Initiation Protocol (SIP). However, there are several possible approaches, each with different benefits and drawbacks. This document discusses best current practices for the usage of SIP for third party call control. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document provides a means for a Session Initiation Protocol (SIP) User Agent (UA) that receives a dialog-forming request to supply its identity to the peer UA by means of a request in the reverse direction, and for that identity to be signed by an Authentication Service. Because of retargeting of a dialog-forming request (changing the value of the Request-URI), the UA that receives it (the User Agent Server, UAS) can have a different identity from that in the To header field. The same mechanism can be used to indicate a change of identity during a dialog, e.g., because of some action in the Public Switched Telephone Network (PSTN) behind a gateway. This document normatively updates RFC 3261 (SIP). [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. The baseline security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP requests. It does so by defining a SIP header field for conveying a signature used for validating the identity and for conveying a reference to the credentials of the signer. This document obsoletes RFC 4474. This document defines a method for creating and validating a token that cryptographically verifies an originating identity or, more generally, a URI or telephone number representing the originator of personal communications. The Personal Assertion Token, PASSporT, is cryptographically signed to protect the integrity of the identity of the originator and to verify the assertion of the identity information at the destination. The cryptographic signature is defined with the intention that it can confidently verify the originating persona even when the signature is sent to the destination party over an insecure channel. PASSporT is particularly useful for many personal-communications applications over IP networks and other multi-hop interconnection scenarios where the originating and destination parties may not have a direct trusted relationship. Although the Session Initiation Protocol (SIP) includes a suite of security services that has been expanded by numerous specifications over the years, there is no single place that explains how to use SIP to establish confidential media sessions. Additionally, existing mechanisms have some feature gaps that need to be identified and resolved in order for them to address the pervasive monitoring threat model. This specification describes best practices for negotiating confidential media with SIP, including a comprehensive protection solution that binds the media layer to SIP layer identities. The Personal Assertion Token (PASSporT) is specified in RFC 8225 to convey cryptographically signed information about the people involved in personal communications. This document extends PASSporT to include an indication that a call has been diverted from its original destination to a new one. This information can greatly improve the decisions made by verification services in call forwarding scenarios. Also specified here is an encapsulation mechanism for nesting a PASSporT within another PASSporT that assists relying parties in some diversion scenarios. This document updates RFC 8224. Informative References The existing security mechanisms in the Session Initiation Protocol (SIP) are inadequate for cryptographically assuring the identity of the end users that originate SIP requests, especially in an interdomain context. This document defines a mechanism for securely identifying originators of SIP messages. It does so by defining two new SIP header fields, Identity, for conveying a signature used for validating the identity, and Identity-Info, for conveying a reference to the certificate of the signer. [STANDARDS-TRACK] This document describes a SIP interface to VoiceXML media services. Commonly, Application Servers controlling Media Servers use this protocol for pure VoiceXML processing capabilities. This protocol is an adjunct to the full MEDIACTRL protocol and packages mechanism. [STANDARDS-TRACK] This document discusses the use of the Domain Name System (DNS) for storage of data associated with E.164 numbers, and for resolving those numbers into URIs that can be used (for example) in telephony call setup. This document also describes how the DNS can be used to identify the services associated with an E.164 number. This document obsoletes RFC 3761. [STANDARDS-TRACK] Over the past decade, Voice over IP (VoIP) systems based on SIP have replaced many traditional telephony deployments. Interworking VoIP systems with the traditional telephone network has reduced the overall level of calling party number and Caller ID assurances by granting attackers new and inexpensive tools to impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. Despite previous attempts to provide a secure assurance of the origin of SIP communications, we still lack effective standards for identifying the calling party in a VoIP session. This document examines the reasons why providing identity for telephone numbers on the Internet has proven so difficult and shows how changes in the last decade may provide us with new strategies for attaching a secure identity to SIP sessions. It also gives high-level requirements for a solution in this space. As the Internet and the telephone network have become increasingly interconnected and interdependent, attackers can impersonate or obscure calling party numbers when orchestrating bulk commercial calling schemes, hacking voicemail boxes, or even circumventing multi-factor authentication systems trusted by banks. This document analyzes threats in the resulting system, enumerating actors, reviewing the capabilities available to and used by attackers, and describing scenarios in which attacks are launched. Secure Telephone Identity Revisited (STIR) provides a means of attesting the identity of a telephone caller via a signed token in order to prevent impersonation of a calling party number, which is a key enabler for illegal robocalling. Similar impersonation is sometimes leveraged by bad actors in the text and multimedia messaging space. This document explores the applicability of STIR's Personal Assertion Token (PASSporT) and certificate issuance framework to text and multimedia messaging use cases, including support for both messages carried as a payload in SIP requests and messages sent in sessions negotiated by SIP.

Acknowledgments We would like to thank , , and for their contributions to this specification.

Authors' Addresses TransUnion

jon.peterson@transunion.com

Somos

chris@appliedbits.com