RFC 9970

Connected Identity for Secure Telephone Identity Revisited (STIR)

📅 published June 2026, from ietf

Connected Identity for Secure Telephone Identity Revisited (STIR) 📞✨

Okay bestie, this is RFC 9970 💖 It's an IETF Standards Track doc (ISSN 2070-1721), dated June 2026. The authors are J. Peterson from TransUnion and C. Wendt from Somos 🫶 It doesn't have a formal "Obsoletes" or "Updates" line in its header, but the abstract says it updates prior guidance on the connected identity problem to match how SIP identity changed with STIR 🔥

Abstract ✨

Okay so, the SIP Identity header field carries cryptographic identity info about whoever started a SIP request 🪪 But STIR doesn't tell you who the called party is in a normal phone call 🤔 This doc updates the old "connected identity" guidance so it matches the SIP identity changes STIR brought in. It also looks at a new problem space: spotting calls that got retargeted to someone pretending to be the intended destination, and stopping anyone (intermediaries or third parties) from spoofing mid-dialog or dialog-terminating events 🕵️‍♀️💅

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, got public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more on Internet Standards, check out Section 2 of RFC 7841 📚

For the current status, any errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc9970 🦋

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 (https://trustee.ietf.org/license-info) in effect on the publication date. Please read these carefully, because they describe your rights and restrictions for this document 📜 Code Components pulled out of this document must include Revised BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🫶

Table of Contents 🧚

1.  Introduction
2.  Terminology
3.  Connected Identity Problem Statement for STIR
4.  Connected Identity without Diversion
5.  Connected Identity with Diversion
6.  Connected Identity in Mid-Dialog and Dialog-Terminating
        Requests
7.  Authorization Policy for Callers
8.  Creating Pre-Association with Destinations
9.  The "rsp" PASSporT Type
10. UPDATE Procedures for Provisional Dialogs
11. IANA Considerations
12. Privacy Considerations
13. Security Considerations
14. References
  14.1.  Normative References
  14.2.  Informative References
Acknowledgments
Authors' Addresses

1. Introduction 🍓

Okay so the Session Initiation Protocol (SIP) [RFC3261] is what starts sessions, and as part of setting one up, it swaps info about the parties on both ends 📲 Called users check the calling party's info, for example to decide whether to accept communications initiated by SIP), kind of like how phone users look at "Caller ID" before they pick up 🙈 Sometimes automated systems use this info to make authorization decisions too 🤖 STIR [RFC8224] gives a cryptographic assurance of who the calling parties are, so impersonation gets blocked. Impersonation is a huge enabler of unwanted robocalls, swatting, vishing, voicemail hacking, and similar attacks (see [RFC7375]) 💀

There's a related problem too. The identity of whoever answers a call can be different from the original called party for totally innocent reasons, like call forwarding 🔀 But in some network setups, attackers can hijack the route of a called number and send it to a resource they control 😱 It can be hard to figure out why a call reached a target other than the one you meant, and whether the party who actually picked up is someone the caller should trust. Plus, because parties don't mutually authenticate, outside attackers can inject forged messages (for example, BYE) into a SIP session 👀

The property of giving the called party's identity to the calling party is called "connected identity" ✨ Earlier work on connected identity focused on fixing the core semantics of SIP. [RFC4916] lets a mid-dialog request, such as an UPDATE [RFC3311], carry identity in either direction inside an existing INVITE-initiated dialog 💃 [RFC4916] also lets that UPDATE change the From header field value for requests in the backwards direction. That's an update to the behavior in [RFC3261], which requires that the From header field values sent in backwards-direction requests reflect the To header field value of the dialog-forming request. Under the original [RFC3261] rules, if Alice sent a dialog-forming request to Bob, then even if Bob's SIP service forwarded it to Carol, Carol would still be required to put Bob's identity in the From header field value of any backwards-direction mid-dialog requests. Not iconic 😤

One of the original motivating use cases for [RFC4916] was connected identity together with the SIP Identity header field [RFC4474]. A backwards-direction mid-dialog request (like UPDATE) can be signed with identity like any other SIP request, but forwarded requests wouldn't be signed properly without the ability to change the mid-dialog From header field value 🥺 So Carol couldn't get a key to sign for Bob's identity if she wanted to sign backwards-direction requests. She could sign for her own identity in the From header field value, but only if backwards-direction mid-dialog requests were allowed to differ from the original To header field value 💅

With [RFC4474] made obsolete by [RFC8224], this spec adapts the connected identity ideas from [RFC4916] to STIR. That covers the changes to the SIP Identity header field and the revised problem space STIR brings 🌈 It also explores new features that connected identity for STIR could enable, like using it to prevent route hijacking and to tell callers when an expected called party has been reached successfully 🎯 This document also deals with concerns about applying connected identity [RFC4916] to STIR, which were raised in the SIPBRANDY framework [RFC8862] 🫶

One area this doc doesn't explore is what connected identity means for conferencing, especially meshed conferencing systems 🙅‍♀️ The scope here is only two-party communications. Multiparty sharing of connected identity is left for future work ⭐

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📖

This document assumes you already know the common messages, response codes, and header fields used in SIP [RFC3261], plus the elements in the Personal Assertion Token (PASSporT) [RFC8225] format 🧠

3. Connected Identity Problem Statement for STIR 🔍

The STIR problem statement [RFC7340] lists robocalling, voicemail hacking, vishing, and swatting as problems with the modern telephone network. They're enabled, or made worse, by impersonation. That's when a calling party can set whatever phone number gets shown to end users to identify the caller 🙃

Right now, sophisticated adversaries can redirect calls on the Public Switched Telephone Network (PSTN) to somewhere other than the intended called party 😬 For call centers, like the ones at financial institutions, healthcare providers, and emergency services, an attacker could try to gain valuable info about people, or block some important services 📉 And on the Internet, there's no centralized, or even federated, routing system for telephone numbers. That means call routing can be pretty arbitrary. Calls might get dumped onto a PSTN gateway, sent to a default intermediary that makes forwarding decisions from a local configuration file (possibly by consulting a private ENUM [RFC6116]), or routed in some other domain-specific way 🗺️ Basically, there are lots of attack surfaces an adversary could use to redirect calls for a particular number somewhere other than the intended destination 🚨

Another motivating use case for connected identity is mid-dialog requests, including BYE 🔁 An intermediary has always been able to generate a forged BYE in the backwards direction, because that's built into SIP's stateful dialog management. For example, there's a class of mobile fraud attacks called "call stretching" 💸 These attacks rely on intermediary networks making one side think the call ended while keeping it active for the other side. That creates a billing discrepancy the intermediary can pocket. If BYE requests in both directions of a SIP dialog could be authenticated with STIR, the same way dialog-forming requests are, then another impersonation route to telephone fraud could get shut down 🔒

Last one: telephone numbers are widely used today for two-factor authentication (TFA) before people access web resources. Those systems usually rely on sharing a one-time password or a similar unique link to prove control of a phone number 📱 They can often use either phone calls or messages for TFA. Connected identity is super valuable for these cases, because it gives the calling party strong assurance that they've actually reached the telephone for the called number 🥰

That said, there are practical limits to what securing the signaling can achieve ⚠️ [RFC4916] correctly points out that once a SIP call has been answered, the called party can be swapped for a different party (with a different identity) because of call transfer, call park and retrieval, and so on. In some cases, because of a back-to-back user agent, it can be effectively impossible for the calling party to know that happened 🫠 The STIR problem statement focuses only on signaling. It doesn't cover whether media from the connected party should be rendered to the caller once a dialog has been established. This specification doesn't look further into threats from media substitution, though [RFC8862] has related guidance 🎧

4. Connected Identity without Diversion ✨

Okay so in straightforward call setup, the address-of-record (AoR) of the party reached by an INVITE lines up with the dest field of the PASSporT in the INVITE's Identity header field value 📞. The calling party, though, has zero secure assurance that they reached the right person if no Identity header field can be sent back to them in the backwards direction 😭. As long as the terminating side is STIR-capable, they should have the capacity to sign a PASSporT for the AoR of the called party 💅.

So this spec adds provisional and final SIP responses, including the 100, 180, 183, and 200 responses, to the list of messages that may carry an Identity header field 🦋. PASSporTs in SIP responses SHOULD use a ppt of rsp, which is defined in Section 9. (div [RFC8946] may also show up in responses, per Section 5 🌸.) We'll call these rsp PASSporTs all throughout this spec. Honestly, an rsp PASSporT is signed a lot like a div PASSporT [RFC8946], because the certificate that signs an rsp PASSporT is signing the dest field instead of the orig field 🧚. If the terminating side doesn't have a credential that can sign for the dest value in the PASSporT, it MUST NOT sign and send an rsp PASSporT in the backwards direction 🚫.

Now, failure responses (4XX, 5XX, 6XX) might seem like they'd be perfect for identity, but they explicitly don't form dialogs or connections, so they're outside this spec's scope 🙈. Same deal for SIP redirect (3XX) responses. For authentication redirection guidance, check out Section 7 of [RFC8946] 💜.

It's worth knowing that when [RFC4916] was written, the identity mechanism was way stricter about what counted as retargeting than what [RFC8224] describes. Like, [RFC8224] has canonicalization processes that wipe out minor URI changes, especially when telephone numbers are the identifiers the caller and callee use 🍓. For basic use cases, a PASSporT in a 183 or 200 OK should be enough to secure media keys for SIPBRANDY [RFC8862] ✨.

Handling an rsp PASSporT is different from handling a PASSporT in a SIP request, and this is the big one: SIP responses can't be rejected, unlike SIP requests. There's literally no way for the recipient of a response to report errors back to the sender 💀. The only move the calling party can make after getting a response with a problem PASSporT is to send a CANCEL (for provisional dialogs) or a BYE request to tear down the dialog (see Section 7) 🔥. Plus, provisional responses aren't reliably delivered unless you use 100rel and Provisional Response Acknowledgement (PRACK) [RFC3262], and intermediaries can consume provisional responses without forwarding them under a bunch of different conditions 😬. Bottom line: their delivery is not guaranteed.

5. Connected Identity with Diversion 🎀

Authorized retargeting is the whole reason connected identity exists 👑. When a call picks up a new target (in its Request-URI) during transit, the destination no longer matches the target, which is the dest the PASSporT in the dialog-forming request specified. So 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 [RFC8946] was made to securely record when a call got retargeted from one destination to another 🦋. Verification services on the terminating side can use those div PASSporTs to confirm that a call reached its eventual destination for the right reasons ✨. Here's the catch: as [RFC8946] explains, the calling party only sees those diversion PASSporTs if redirection (SIP 3XX responses) is used instead of retargeting. Some network policies want to hide service logic from the originating party, so sending redirections backwards is currently the only defined way to reveal secure indications of redirection to the calling party 🙈. That would give the calling user agent strong assurance that legit entities in the call path made the request reach a party the caller didn't expect 💅.

This spec introduces another option 🌈. When a UAS sends an rsp PASSporT type in a SIP response, it MAY also include (in Identity header field values) any div PASSporTs it received in the INVITE that started this dialog. So div PASSporTs MAY also show up in SIP responses too 🫶. These div PASSporTs can give the originating side secure assurance that the call is being picked up by the proper recipient, based on how the call was routed 🧚. In this case, the dest signed in the rsp PASSporT MUST be the address-of-record of the party who was actually reached, not the dest of the PASSporT received in the dialog-initiating INVITE 🎯.

Now, an rsp PASSporT that signs a different dest than the one in the PASSporT of the dialog-forming request MUST send at least one div PASSporT with it 📮. If no div PASSporTs came 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 isn't universally supported, so calls MAY get retargeted without generating a div PASSporT, and in that case rsp PASSporTs just won't be possible 🥲. And remember, deciding whether to trust any div or rsp PASSporT is, like always in STIR, a matter of local policy for 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 🔒.

Heads up: sending div PASSporTs backwards can potentially reveal service logic to the called party 👀. Since this service logic is usually enacted on behalf of the called party, the called party gets to make a policy call on whether to reflect those div PASSporTs back to the caller. Connected identity may not be compatible with some operator policies 🙃.

This mechanism doesn't require changing the value of the From header field in backwards-direction requests or responses 🙌. That was a huge concern for [RFC4916], but in lots of operating environments, the From header field doesn't even hold the caller's identity as asserted by the network. That info goes in the P-Asserted-Identity (PAID) header field [RFC3325] instead 💖. PAID contents were never used for dialog matching, so where PAID is used, it can change more dynamically than the From header field. (Also, [RFC3261] added tag parameters to the To and From header field values, so From values don't need to be stable for dialog identification anymore. That happened a while ago 🕰️.) For retargeting that uses the from-change option tag in [RFC4916], see Section 10 🧁. And honestly, STIR is more flexible than [RFC4916] was at the time in building the dest, which was limited to the Identity header field's managed addresses-of-record 🌟.

6. Connected Identity in Mid-Dialog and Dialog-Terminating Requests 💜

Connected identity isn't just for provisional dialog requests 🙌. Once a dialog is set up with connected identity, any re-INVITEs from either the originating or terminating side, plus any BYE requests, SHOULD contain Identity header fields with valid PASSporTs ✨. If only the terminating side supports connected identity, the originator obviously can't be expected to know it needs to send PASSporTs for later requests like BYE 🤷‍♀️. Signing them stops third parties from spoofing mid-dialog requests to redirect media or otherwise mess with the call, and it also stops attackers from doing denial-of-service teardowns 🛡️.

In theory, any SIP request in a dialog could be signed this way, though it's unclear how valuable that would be for some (like OPTIONS) 🤔. Requests with specialized payloads, like INFO or MESSAGE, would need extra specification for how to protect the integrity of their bodies. Some work has been done on that for MESSAGE (see [RFC9475]) 📨. So this spec doesn't recommend PASSporTs for any dialog requests other than INVITE, UPDATE, and BYE 💅.

It might seem tempting to require that if an INVITE was sent with an Identity header field containing a PASSporT, any CANCEL request received for that INVITE's dialog must also carry an Identity header field with a PASSporT. But CANCEL requests can also come from stateful proxy servers doing parallel forking, for example when branches need canceling because a final response came in from a UAS 🌊. So this spec doesn't forbid a User Agent Client (UAC) from sending a CANCEL for its own PASSporT-protected INVITE requests, since there may be limited use cases where it's useful to relying parties. But recipients of a CANCEL shouldn't expect PASSporTs to be there in connected identity cases 🫠.

Mid-dialog requests need special handling in diversion cases too 🦋. Relying parties who meant to trust an rsp PASSporT MUST validate any div chain back to that rsp PASSporT on any Identity header field values received in responses (per [RFC8946]) 🔍. The dialog initiator can then treat the certificate that signed the rsp PASSporT as the right certificate for signing any further mid-dialog or dialog-terminating requests received in the backwards direction 🔑. And finally, the dest element value in any requests or responses sent backwards 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 Section 10 🎀.

7. Authorization Policy for Callers ✨

Okay so bestie, in a normal phone call the person getting called gets an alerting ring 🔔 and gets to decide whether to pick up. They can even peek at displayed info like "Caller ID" 📱 to help them decide. Callers have it way harder 💀. They usually expect to land at the right place, and they're often holding the phone somewhere they couldn't see any displayed info anyway 🙈. Their most direct move if something feels sus is to hang up the call they were literally in the middle of placing. Not ideal!

This spec doesn't prescribe any user experience for placing a call 💅, but it does assume callers might have some way to set an authorization posture so the right thing happens when the connected identity isn't what they expected 🫶. It's kind of like SRTP negotiation failing because the keys exchanged at the media layer don't match the fingerprints exchanged at the signaling layer 🔐. When a user asks for confidentiality and it's unavailable, media should not be exchanged. So we assume users have a way in their interface to require this criticality, per call or maybe per destination 🎀. Not every call needs connected identity to be crucial, but when it does, people should be able to tell their devices that the call should not be completed if it arrives at an unexpected or unauthenticated party 🚫. Main character energy, honestly.

8. Creating Pre-Association with Destinations 📇

Any connected identity mechanism works best if the user knows before starting a call that the destination side supports connected identity 🧠. Not every institution people want to reach securely will support STIR and connected identity right out of the gate 😬. A directory service might exist that advertises support for connected identity, and institutions could use it to tell potential callers that if connected identity isn't supported when reaching them with SIP, there's a potential security problem 🚨. Similarly, user devices might keep a log recording that a destination previously supported connected identity, so if support disappears later, calling users can get alerted 👀.

The user interface of modern smartphones supports an address book where users pick numbers to dial 📲. Even when dialing manually, the interface often checks the address book, which will show any provisioned name for the call target if one exists. And when someone clicks a phone number on a web page or similar service, smartphones often prompt them to approve access to the outbound dialer. These decision points happen while the user is still in the interface before a call is placed 🪄, so they're a chance to check what identity would be reached and maybe even exchange STIR PASSporTs to confirm the expected destination can be reached securely 🔎. This is probably most meaningful for financial, government, or emergency services, where reaching an unintended destination could have seriously bad consequences 😰.

The establishment of media-less dialogs has long been specified as part of third-party call control in SIP [RFC3725], where an INVITE is sent with no Session Description Protocol (SDP). Similar media-less dialogs have been proposed for certain automated systems per [RFC5552]. 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 100rel in the Require header field value, it SHOULD follow the mechanism described in Section 4 to send a provisional response carrying a PASSporT in the backwards direction 💜. The PASSporT received backwards could be rendered to the originating user to help them decide if they want to place the call ✨.

9. 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, since 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 🌈.

10. UPDATE Procedures for Provisional Dialogs 🔁

[RFC4916] 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 using the UPDATE method to send the connected identity backwards. This can only happen after the UAS has received and responded to a PRACK [RFC3262] 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 [RFC4916], nor does it provide an update for it for STIR. That's left for future work 🛠️.

11. IANA Considerations 🗂️

This specification defines a new PASSporT type for the "Personal Assertion Token (PASSporT) Extensions" registry [RFC8225], which resides at https://www.iana.org/assignments/passport/:

ppt value:  rsp

Reference:  RFC 9970, Section 9

12. Privacy Considerations 🫣

Heads up, 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, particularly 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 🏢.

13. Security Considerations 🚨🔐

The security considerations of [RFC8224] and [RFC8225] apply to the use of the "rsp" PASSporT. In general, a PASSporT of type "rsp" has similar security properties to a diversion ("div") PASSporT [RFC8946] 🪞. Relying parties leverage an "rsp" PASSporT to determine the recipient of a request, and just like 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, just like 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 Section 5, using "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, since 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 🫶🔥.

14. References 📚

14.1. Normative References 📚

Okay bestie, these are the docs this spec leans on the hardest, so they're the ones to pull up first 🫶

14.2. Informative References 🌸

These ones are the extra reading for the curious, the background and context that make everything click 🧚

Acknowledgments 💖

Huge shoutout to Russ Housley, Jonathan Rosenberg, and Orie Steele 🫶 They all contributed to this spec, and we literally couldn't have done it without them ✨

Authors' Addresses 💌

Jon Peterson TransUnion Email: jon.peterson@transunion.com

Chris Wendt Somos Email: chris@appliedbits.com

📦 where this page comes from