rfc9970.original   rfc9970.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft TransUnion Request for Comments: 9970 TransUnion
Intended status: Standards Track C. Wendt Category: Standards Track C. Wendt
Expires: 8 January 2026 Somos ISSN: 2070-1721 Somos
7 July 2025 May 2026
Connected Identity for STIR Connected Identity for Secure Telephone Identity Revisited (STIR)
draft-ietf-stir-rfc4916-update-07
Abstract Abstract
The Session Initiation Protocol (SIP) Identity header field conveys The Session Initiation Protocol (SIP) Identity header field conveys
cryptographic identity information about the originators of SIP cryptographic identity information about the originators of SIP
requests. The Secure Telephone Identity Revisited (STIR) framework, requests. However, the Secure Telephone Identity Revisited (STIR)
however, provides no means for determining the identity of the called framework provides no means for determining the identity of the
party in a traditional telephone-calling scenario. This document called party in a traditional telephone-calling scenario. This
updates prior guidance on the "connected identity" problem to reflect document updates prior guidance on the "connected identity" problem
the changes to SIP Identity that accompanied STIR, and considers a to reflect the changes to SIP Identity that accompanied STIR. It
revised problem space for connected identity as a means of detecting also considers a revised problem space for connected identity as a
calls that have been retargeted to a party impersonating the intended means of detecting calls that have been retargeted to a party
destination, as well as the spoofing of mid-dialog or dialog- impersonating the intended destination, as well as the spoofing of
terminating events by intermediaries or third parties. mid-dialog or dialog-terminating events by intermediaries or third
parties.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 8 January 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9970.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology
3. Connected Identity Problem Statement for STIR . . . . . . . . 4 3. Connected Identity Problem Statement for STIR
4. Connected Identity without Diversion . . . . . . . . . . . . 5 4. Connected Identity without Diversion
5. Connected Identity with Diversion . . . . . . . . . . . . . . 7 5. Connected Identity with Diversion
6. Connected Identity in Mid-Dialog and Dialog-Terminating 6. Connected Identity in Mid-Dialog and Dialog-Terminating
Requests . . . . . . . . . . . . . . . . . . . . . . . . 8 Requests
7. Authorization Policy for Callers . . . . . . . . . . . . . . 9 7. Authorization Policy for Callers
8. Creating Pre-Association with Destinations . . . . . . . . . 10 8. Creating Pre-Association with Destinations
9. The 'rsp' PASSporT Type . . . . . . . . . . . . . . . . . . . 11 9. The "rsp" PASSporT Type
10. UPDATE Procedures for Provisional Dialogs . . . . . . . . . . 11 10. UPDATE Procedures for Provisional Dialogs
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 11. IANA Considerations
12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 12 12. Privacy Considerations
13. Security Considerations . . . . . . . . . . . . . . . . . . . 12 13. Security Considerations
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14. References
14.1. Normative References . . . . . . . . . . . . . . . . . . 13 14.1. Normative References
14.2. Informative References . . . . . . . . . . . . . . . . . 15 14.2. Informative References
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Acknowledgments
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] initiates sessions, The Session Initiation Protocol (SIP) [RFC3261] initiates sessions,
and as a step in establishing sessions, it exchanges information and as a step in establishing sessions, it exchanges information
about the parties at both ends. Called users review information about the parties at both ends. Called users review information
about the calling party, for example, to determine whether to accept about the calling party, for example, to determine whether to accept
communications initiated by SIP, in the same way that users of the communications initiated by SIP), in the same way that users of the
telephone network assess "Caller ID" information before picking up telephone network assess "Caller ID" information before picking up
calls. This information may sometimes be consumed by automated calls. This information may sometimes be consumed by automated
systems to make authorization decisions. STIR [RFC8224] provides a systems to make authorization decisions. STIR [RFC8224] provides a
cryptographic assurance of the identity of calling parties in order cryptographic assurance of the identity of calling parties in order
to prevent impersonation, which is a key enabler of unwanted to prevent impersonation, which is a key enabler of unwanted
robocalls, swatting, vishing, voicemail hacking, and similar attacks robocalls, swatting, vishing, voicemail hacking, and similar attacks
(see [RFC7375]). (see [RFC7375]).
There also exists a related problem: the identity of the party who A related problem also exists: The identity of the party who answers
answers a call can differ from that of the initial called party for a call can differ from that of the initial called party for various
various innocuous reasons such as call forwarding. In certain innocuous reasons such as call forwarding. In certain network
network environments, however, it is possible for attackers to hijack environments, however, it is possible for attackers to hijack the
the route of a called number and direct it to a resource controlled route of a called number and direct it to a resource controlled by
by the attacker. It can potentially be difficult to determine why a the attacker. It can potentially be difficult to determine why a
call reached a target other than the one originally intended, and call reached a target other than the one originally intended and
whether the party ultimately reached by the call is one that the whether the party ultimately reached by the call is one that the
caller should trust. The lack of mutual authentication of parties caller should trust. Moreover, the lack of mutual authentication of
moreover makes it possible for outside attackers to inject forged parties makes it possible for outside attackers to inject forged
messages (e.g., BYE) into a SIP session. messages (e.g., BYE) into a SIP session.
The property of providing the identity of the called party to the The property of providing the identity of the called party to the
calling party is called "connected identity". Previous work on calling party is called "connected identity". Previous work on
connected identity focused on fixing the core semantics of SIP. connected identity focused on fixing the core semantics of SIP.
[RFC4916] allowed a mid-dialog request, such as an UPDATE [RFC3311], [RFC4916] allows a mid-dialog request, such as an UPDATE [RFC3311],
to convey identity in either direction within the context of an to convey identity in either direction within the context of an
existing INVITE-initiated dialog. In an update to the original existing INVITE-initiated dialog. [RFC4916] also allows that UPDATE
[RFC3261] behavior, [RFC4916] allowed that UPDATE to alter the From to alter the From header field value for requests in the backwards
header field value for requests in the backwards direction: direction; this is an update to the behavior described in [RFC3261],
previously [RFC3261] required that the From header field values sent which requires that the From header field values sent in requests in
in requests in the backwards direction reflect the To header field the backwards direction reflect the To header field value of the
value of the dialog-forming request. Under the original [RFC3261] dialog-forming request. Under the original rules in [RFC3261], if
rules, if Alice sent a dialog-forming request to Bob, then even if Alice sent a dialog-forming request to Bob, then even if Bob's SIP
Bob's SIP service forwarded that dialog-forming request to Carol, service forwarded that dialog-forming request to Carol, Carol would
Carol would still be required to put Bob's identity in the From still be required to put Bob's identity in the From header field
header field value in any mid-dialog requests in the backwards value in any mid-dialog requests in the backwards direction.
direction.
One of the original motivating use cases for [RFC4916] was the use of One of the original motivating use cases for [RFC4916] was the use of
connected identity with the SIP Identity [RFC4474] header field. connected identity with the SIP Identity header field [RFC4474].
While a mid-dialog request in the backwards direction (e.g., UPDATE) While a mid-dialog request in the backwards direction (e.g., UPDATE)
can be signed with Identity like any other SIP request, forwarded can be signed with Identity like any other SIP request, forwarded
requests would not be properly signed without the ability to change requests would not be properly signed without the ability to change
the mid-dialog From header field value: Carol, say, would not be able the mid-dialog From header field value. Thus, Carol would not be
to furnish a key to sign for Bob's identity if Carol wanted to sign able to furnish a key to sign for Bob's identity if Carol wanted to
requests in the backwards direction. Carol would, however, be able sign requests in the backwards direction. Carol would, however, be
to sign for her own identity in the From header field value if mid- able to sign for her own identity in the From header field value if
dialog requests in the backwards direction were permitted to vary mid-dialog requests in the backwards direction were permitted to vary
from the original To header field value. from the original To header field value.
With the obsolescence of [RFC4474] by [RFC8224], this specification With the obsolescence of [RFC4474] by [RFC8224], this specification
supersedes the guidance of [RFC4916] to reflect the changes to the supersedes the guidance of [RFC4916] to reflect the changes to the
SIP Identity header field and the revised problem space of STIR. It SIP Identity header field and the revised problem space of STIR. It
also explores some new features that would be enabled by connected also explores some new features that would be enabled by connected
identity for STIR, including the use of connected identity to prevent identity for STIR, including the use of connected identity to prevent
route hijacking and to notify callers when an expected called party route hijacking and to notify callers when an expected called party
has successfully been reached. This document also addresses concerns has successfully been reached. This document also addresses concerns
about applying [RFC4916] connected identity to STIR discussed in the about applying connected identity [RFC4916] to STIR discussed in the
SIPBRANDY framework [RFC8862]. SIPBRANDY framework [RFC8862].
One area of connected identity that is not explored in this document One area of connected identity that is not explored in this document
is the implications for conferencing, especially meshed conferencing is the implications for conferencing, especially meshed conferencing
systems. The scope of this mechanism is solely two-party systems. The scope of this mechanism is solely two-party
communications; multiparty sharing of connected identity is left for communications; multiparty sharing of connected identity is left for
future work. future work.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. This document assumes familiarity with capitals, as shown here.
common messages, response codes, and header fields used in SIP
[RFC3261], and the elements present in the PASSporT [RFC8225] token This document assumes familiarity with common messages, response
format. codes, and header fields used in SIP [RFC3261] and the elements
present in the Personal Assertion Token (PASSporT) [RFC8225] format.
3. Connected Identity Problem Statement for STIR 3. Connected Identity Problem Statement for STIR
The STIR problem statement [RFC7340] enumerates robocalling, The STIR problem statement [RFC7340] enumerates robocalling,
voicemail hacking, vishing, and swatting as problems with the modern voicemail hacking, vishing, and swatting as problems with the modern
telephone network that are enabled, or abetted, by impersonation: by telephone network that are enabled, or abetted, by impersonation,
the ability of a calling party to arbitrarily set the telephone 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. number that will be rendered to end users to identify the caller.
Today, sophisticated adversaries can redirect calls on the Public Today, sophisticated adversaries can redirect calls on the Public
Switched Telephone Network (PSTN) to destinations other than the Switched Telephone Network (PSTN) to destinations other than the
intended called party. For some call centers, like those associated intended called party. For some call centers, like those associated
with financial institutions, healthcare, and emergency services, an with financial institutions, healthcare, and emergency services, an
attacker could hope to gain valuable information about people or to attacker could hope to gain valuable information about people or to
prevent some classes of important services. Moreover, on the prevent some classes of important services. Moreover, on the
Internet, the lack of any centralized or even federated routing Internet, the lack of any centralized or even federated routing
system for telephone numbers has resulted in deployments where the system for telephone numbers has resulted in deployments where the
routing of calls is arbitrary: calls to telephone numbers might be routing of calls is arbitrary: Calls to telephone numbers might be
dumped on a PSTN gateway, they might be sent to a default dumped on a PSTN gateway, they might be sent to a default
intermediary that makes forwarding decisions based on a local intermediary that makes forwarding decisions based on a local
configuration file, potentially using various mechanisms such as configuration file, potentially using various mechanisms such as
consulting a private ENUM [RFC6116], or routing might be determined consulting a private ENUM [RFC6116], or routing might be determined
in some other, domain-specific way. In short, there are numerous in some other, domain-specific way. In short, there are numerous
attack surfaces that an adversary could explore to attempt to attack surfaces that an adversary could explore to attempt to
redirect calls for a particular number to someplace other than the redirect calls for a particular number to someplace other than the
intended destination. intended destination.
Another motivating use case for connected identity is mid-dialog Another motivating use case for connected identity is mid-dialog
skipping to change at page 5, line 31 skipping to change at line 207
Finally, telephone numbers are widely used today for two-factor Finally, telephone numbers are widely used today for two-factor
authentication (TFA) prior to accessing web resources, which authentication (TFA) prior to accessing web resources, which
typically rely on sharing some sort of one-time password or similar typically rely on sharing some sort of one-time password or similar
unique link to validate control of a telephone number. These systems unique link to validate control of a telephone number. These systems
are often capable of using either telephone calls or messages for are often capable of using either telephone calls or messages for
TFA. Connected identity is very valuable for these use cases because TFA. Connected identity is very valuable for these use cases because
it gives a strong assurance to the calling party that they have in it gives a strong assurance to the calling party that they have in
fact reached the telephone for the called telephone number. fact reached the telephone for the called telephone number.
There are however practical limits to what securing the signaling can However, there are practical limits to what securing the signaling
achieve. [RFC4916] rightly observed that once a SIP call has been can achieve. [RFC4916] rightly observes that once a SIP call has
answered, the called party can be replaced by a different party (with been answered, the called party can be replaced by a different party
a different identity) due to call transfer, call park and retrieval, (with a different identity) due to call transfer, call park and
and so on. In some cases, due to the presence of a back-to-back user retrieval, and so on. In some cases, due to the presence of a back-
agent, it can be effectively impossible for the calling party to know to-back user agent, it can be effectively impossible for the calling
that this has happened. The problem statement considered for STIR party to know that this has happened. The problem statement
focuses solely on signaling, not whether media from the connected considered for STIR focuses solely on signaling, not whether media
party should be rendered to the caller when a dialog has been from the connected party should be rendered to the caller when a
established. This specification does not consider further any dialog has been established. This specification does not consider
threats that arise from a substitution of media, though [RFC8862] further any threats that arise from a substitution of media, though
contains related guidance. [RFC8862] contains related guidance.
4. Connected Identity without Diversion 4. Connected Identity without Diversion
In straightforward call setup, the address-of-record (AoR) of the In straightforward call setup, the address-of-record (AoR) of the
party reached by an INVITE corresponds to the "dest" field 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 PASSporT in the INVITE's Identity header field value. The calling
party will, however, have no secure assurance that they have reached party will, however, have no secure assurance that they have reached
the proper party if an Identity header field cannot be sent to them the proper party if an Identity header field cannot be sent to them
in the backwards direction. Provided that the terminating side of in the backwards direction. Provided that the terminating side of
the dialog is STIR-capable, they should have the capacity to sign a the dialog is STIR-capable, they should have the capacity to sign a
PASSporT for the AoR of the called party. PASSporT for the AoR of the called party.
This specification therefore adds provisional and final SIP This specification therefore adds provisional and final SIP
responses, including the 100, 180, 183, and 200 responses, to the set responses, including the 100, 180, 183, and 200 responses, to the set
of messages that may contain an Identity header field. PASSporTs of messages that may contain an Identity header field. PASSporTs
that appear in SIP responses SHOULD use a "ppt" of "rsp", which is that appear in SIP responses SHOULD use a "ppt" of "rsp", which is
defined in Section 9 (although "div" [RFC8946] may additionally defined in Section 9 (although "div" [RFC8946] may additionally
appear in responses, per Section 5). PASSporTs of the "rsp" type appear in responses, per Section 5). PASSporTs of the "rsp" type
will be referred to throughout this specification as "rsp" PASSporTs. will be referred to throughout this specification as "rsp" PASSporTs.
At a high level, an "rsp" PASSporT is signed similarly to the "div" At a high level, an "rsp" PASSporT is signed similarly to the "div"
[RFC8946] PASSporT, in so far as the certificate that signs a "rsp" PASSporT [RFC8946], insofar as the certificate that signs a "rsp"
PASSporT is signing the "dest" field, rather than the "orig" field. PASSporT is signing the "dest" field rather than the "orig" field.
If the terminating side does not possess an appropriate credential to If the terminating side does not possess an appropriate credential to
sign for the value of the "dest" element value in the PASSporT, it sign for the value of the "dest" element value in the PASSporT, it
MUST NOT sign and send a "rsp" PASSporT in the backwards direction. MUST NOT sign and send a "rsp" PASSporT in the backwards direction.
While it might seem attractive to provide identity for SIP failure While it might seem attractive to provide identity for SIP failure
response codes (4XX, 5XX, 6XX), those explicitly do not form dialogs response codes (4XX, 5XX, 6XX), those explicitly do not form dialogs
or connections, and are thus outside the scope of this specification. or connections and are thus outside the scope of this specification.
The same applies to SIP redirect (3XX) response codes, though see The same applies to SIP redirect (3XX) response codes, though see
[RFC8946], Section 7 for guidance on authentication redirection. Section 7 of [RFC8946] for guidance on authentication redirection.
It is worth noting as well that at the time [RFC4916] was written, It is worth noting that at the time [RFC4916] was written, the
the Identity mechanism was far stricter about what counted as Identity mechanism was far stricter about what counted as retargeting
retargeting than [RFC8224], which has canonicalization processes that than is described in [RFC8224], which has canonicalization processes
eliminate minor changes to the URIs, especially when telephone that eliminate minor changes to the URIs, especially when telephone
numbers are the identifiers used by the caller and callee. For basic 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 use cases, a PASSporT in a 183 or 200 OK should be sufficient to
secure media keys for the purposes of SIPBRANDY [RFC8862]. secure media keys for the purposes of SIPBRANDY [RFC8862].
The handling of an "rsp" PASSporT differs from the handling of a The handling of an "rsp" PASSporT differs from the handling of a
PASSporT received in a SIP request. Most importantly, note that SIP PASSporT received in a SIP request. Most importantly, note that SIP
responses cannot be rejected, unlike SIP requests -- there is no way responses cannot be rejected, unlike SIP requests -- there is no way
for the recipient of a response to report errors to the sender. The for the recipient of a response to report errors to the sender. The
only protocol action that the calling party could take upon receiving only protocol action that the calling party could take upon receiving
a response carrying a problem PASSporT is to issue a CANCEL (for a response carrying a problem PASSporT is to issue a CANCEL (for
provisional dialogs) or BYE request in order to tear down the dialog provisional dialogs) or BYE request in order to tear down the dialog
(see Section 7). Moreover, provisional responses are not reliably (see Section 7). Moreover, provisional responses are not reliably
delivered without using 100rel and PRACK [RFC3262], and provisional delivered without using 100rel and Provisional Response
responses may be consumed (without forwarding) by intermediaries Acknowledgement (PRACK) [RFC3262], and provisional responses may be
under a variety of conditions. In short, their delivery is not consumed (without forwarding) by intermediaries under a variety of
guaranteed. conditions. In short, their delivery is not guaranteed.
5. Connected Identity with Diversion 5. Connected Identity with Diversion
Use cases involving authorized retargeting motivate connected Use cases involving authorized retargeting motivate connected
identity: when a call acquires a new target (in its Request-URI) identity. When a call acquires a new target (in its Request-URI)
during transit, then the destination will no longer correspond to the during transit, then the destination will no longer correspond to the
target, the "dest" specified by the PASSporT in the dialog-forming target, the "dest" specified by the PASSporT in the dialog-forming
request. If a PASSporT in a response came signed by a different request. If a PASSporT in a response came signed by a different
destination than the caller intended, why should the caller trust it? destination than the caller intended, why should the caller trust it?
In STIR, the "div" PASSporT type [RFC8946] was created to securely In STIR, the "div" PASSporT type [RFC8946] was created to securely
record when a call was retargeted from one destination to another. record when a call was retargeted from one destination to another.
Those "div" PASSporTs can be consumed on the terminating side by Those "div" PASSporTs can be consumed on the terminating side by
verification services to determine that a call has reached its verification services to determine that a call has reached its
eventual destination for the right reasons. As [RFC8946] explains eventual destination for the right reasons. As [RFC8946] explains
skipping to change at page 7, line 38 skipping to change at line 305
This specification introduces another alternative. When sending a This specification introduces another alternative. When sending a
"rsp" PASSporT type in a SIP response, a User Agent Server (UAS) MAY "rsp" PASSporT type in a SIP response, a User Agent Server (UAS) MAY
also include (in Identity header field values) any "div" PASSporTs it also include (in Identity header field values) any "div" PASSporTs it
received in the INVITE that initiated this dialog. Thus, PASSporTs received in the INVITE that initiated this dialog. Thus, PASSporTs
of type "div" MAY also appear in SIP responses. These "div" of type "div" MAY also appear in SIP responses. These "div"
PASSporTs can enable the originating side to receive a secure PASSporTs can enable the originating side to receive a secure
assurance that the call is being fielded by the proper recipient per 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 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 "rsp" PASSporT MUST be the address-of-record of the party who was
reached, rather than the "dest" of the PASSporT received in the reached rather than the "dest" of the PASSporT received in the
dialog-initiating INVITE. dialog-initiating INVITE.
An "rsp" PASSporT that signs a different "dest" than the one that An "rsp" PASSporT that signs a different "dest" than the one that
appeared in the PASSporT of the dialog-forming request MUST send at appeared in the PASSporT of the dialog-forming request MUST send at
least one "div" PASSporT with it. If no "div" PASSporTs were least one "div" PASSporT with it. If no "div" PASSporTs were
received in a dialog-forming request with a different "dest" value received in a dialog-forming request with a different "dest" value
than the original PASSporT claimed, then "rsp" PASSporTs MUST NOT be than the original PASSporT claimed, then "rsp" PASSporTs MUST NOT be
used in responses. "div" is not universally supported, so calls MAY used in responses. "div" is not universally supported, so calls MAY
be retargeted without generating a "div" PASSporT, in which case the be retargeted without generating a "div" PASSporT, in which case the
use of "rsp" PASSporTs will not be possible. Note that the decision 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 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 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 want to trust any "rsp" that differs from the "dest" in the PASSporT
of the original request. of the original request.
Note that sending "div" PASSporTs in the backwards direction will Note that sending "div" PASSporTs in the backwards direction will
potentially reveal service logic to the called party. As presumably potentially reveal service logic to the called party. As presumably
this service logic is enacted on behalf of the called party, the this service logic is enacted on behalf of the called party, the
called party can make a policy determination about reflecting those called party can make a policy determination about reflecting those
"div" PASSporTs back to the caller: connected identity may not be "div" PASSporTs back to the caller; connected identity may not be
compatible with some operator policies. compatible with some operator policies.
This mechanism does not require altering the value of the From header This mechanism does not require altering the value of the From header
field value in requests or responses in the backwards direction. field value in requests or responses in the backwards direction.
While this was a major concern of [RFC4916], in many operating While this was a major concern of [RFC4916], in many operating
environments, the From header field value does not even contain the environments, the From header field value does not even contain the
identity of the caller that has been asserted by the network, which identity of the caller that has been asserted by the network, which
is instead conveyed by the P-Asserted-Identity (PAID) header field is instead conveyed by the P-Asserted-Identity (PAID) header field
[RFC3325]. The contents of PAID were never used for dialog matching, [RFC3325]. The contents of PAID were never used for dialog matching,
and so in environments where PAID is used, it can be altered more and so in environments where PAID is used, it can be altered more
dynamically than the From (moreover, [RFC3261], by introducing tag dynamically than the From header field (moreover, by introducing tag
parameters to the To and From header field values, eliminated the parameters to the To and From header field values, [RFC3261]
need for stability in From values for dialog identification some time eliminates the need for stability in From values for dialog
ago). For retargeting that utilizes the [RFC4916] "from-change" identification some time ago). For retargeting that utilizes the
option tag, see Section 10. STIR is, in general, more flexible in "from-change" option tag in [RFC4916], see Section 10. STIR is, in
constructing the "dest" than the Identity header field managed general, more flexible in constructing the "dest" than the Identity
addresses-of-record at the time [RFC4916] was written. header field managed addresses-of-record at the time [RFC4916] was
written.
6. Connected Identity in Mid-Dialog and Dialog-Terminating Requests 6. Connected Identity in Mid-Dialog and Dialog-Terminating Requests
The use of the connected identity mechanism here specified is not The use of the connected identity mechanism specified in this
limited to provisional dialog requests. Once a dialog has been document is not limited to provisional dialog requests. Once a
established with connected identity, any re-INVITEs from either the dialog has been established with connected identity, any re-INVITEs
originating and terminating side, as well as any BYE requests, SHOULD from either the originating and terminating side, as well as any BYE
contain Identity header fields with valid PASSporTs. If only the requests, SHOULD contain Identity header fields with valid PASSporTs.
terminating side supports connected identity, obviously the If only the terminating side supports connected identity, obviously
originator cannot be expected to know that it needs to send PASSporTs the originator cannot be expected to know that it needs to send
for subsequent requests like BYE. Doing so prevents third parties PASSporTs for subsequent requests like BYE. Doing so prevents third
from spoofing any mid-dialog requests in order to redirect media or parties from spoofing any mid-dialog requests in order to redirect
similarly interfere with communications, as well as preventing denial media or similarly interfere with communications, and it also
of service teardowns by attackers. prevents denial-of-service teardowns by attackers.
Theoretically, any SIP requests in a dialog could be signed in this Theoretically, any SIP requests in a dialog could be signed in this
fashion, though it is unclear how valuable it would be for some fashion, though it is unclear how valuable it would be for some
(e.g., OPTIONS). Requests with specialized payloads such as INFO or (e.g., OPTIONS). Requests with specialized payloads such as INFO or
MESSAGE, however, would require additional specification for how MESSAGE, however, would require additional specification for how
integrity protection for their bodies could be implemented. Some integrity protection for their bodies could be implemented. Some
work has been done toward that for MESSAGE (see [RFC9475]). This work has been done toward that for MESSAGE (see [RFC9475]). This
specification thus does not recommend PASSporTs for any requests sent specification thus does not recommend PASSporTs for any requests sent
in a dialog other than INVITE, UPDATE, and BYE. in a dialog other than INVITE, UPDATE, and BYE.
It might seem tempting to require that, if an INVITE has been sent It might seem tempting to require that, if an INVITE has been sent
with an Identity header field containing a PASSporT, any CANCEL with an Identity header field containing a PASSporT, any CANCEL
request received for the dialog initiated by that INVITE must also request received for the dialog initiated by that INVITE must also
contain an Identity header field with a PASSporT. However, CANCEL contain an Identity header field with a PASSporT. However, CANCEL
requests can also be sent by stateful proxy servers engaged in requests can also be sent by stateful proxy servers engaged in
parallel forking; for example, when branches need to be canceled parallel forking, for example, when branches need to be canceled
because a final response has been received from a UAS. This because a final response has been received from a UAS. This
specification does not forbid a User Agent Client (UAC) from sending specification does not forbid a User Agent Client (UAC) from sending
a CANCEL for its own PASSporT-protected INVITE requests, as there may 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 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 recipients of a CANCEL should not expect PASSporTs to be present in
connected identity cases. connected identity cases.
Mid-dialog requests also require special handling in diversion cases. Mid-dialog requests also require special handling in diversion cases.
Relying parties who intended to trust an "rsp" PASSporT MUST validate Relying parties who intended to trust an "rsp" PASSporT MUST validate
any "div" chain back to the "rsp" PASSporT on any Identity header any "div" chain back to the "rsp" PASSporT on any Identity header
skipping to change at page 9, line 36 skipping to change at line 399
responses sent in the backwards direction during this dialog MUST be responses sent in the backwards direction during this dialog MUST be
the same as the "dest" element value in the first response to the the same as the "dest" element value in the first response to the
dialog-forming request that contains a PASSporT -- unless the "from- dialog-forming request that contains a PASSporT -- unless the "from-
change" extension is used, per Section 10. change" extension is used, per Section 10.
7. Authorization Policy for Callers 7. Authorization Policy for Callers
In a traditional telephone call, the called party receives an In a traditional telephone call, the called party receives an
alerting signal and can make a decision about whether or not to pick alerting signal and can make a decision about whether or not to pick
up a phone. They may have access to displayed information, like up a phone. They may have access to displayed information, like
"Caller ID", to help them arrive at an authorization decision. The "Caller ID", to help them arrive at an authorization decision.
situation is more complicated for callers, however: callers typically However, the situation is more complicated for callers because they
expect to be connected to the proper destination and are often typically expect to be connected to the proper destination and are
holding telephones in a position that would not enable them to see often holding telephones in a position that would not enable them to
displayed information if any were available for them to review -- see displayed information if any were available for them to review.
moreover, their most direct response to a security breach would be to Moreover, their most direct response to a security breach would be to
hang up the call they were in the middle of placing. hang up the call they were in the middle of placing.
While this specification does not prescribe any user experience While this specification does not prescribe any user experience
associated with placing a call, it assumes that callers might have associated with placing a call, it assumes that callers might have
some way to a set an authorization posture that will result in the some way to a set an authorization posture that will result in the
right thing happening when the connected identity is not as expected. right thing happening when the connected identity is not as expected.
This is analogous to a situation where Secure Real-time Protocol This is analogous to a situation where Secure Real-time Transport
(SRTP) negotiation fails because the keys exchanged at the media Protocol (SRTP) negotiation fails because the keys exchanged at the
layer do not match the fingerprints exchanged at the signaling layer: media layer do not match the fingerprints exchanged at the signaling
when a user requests confidentiality services, and they are layer: When a user requests confidentiality services and they are
unavailable, media should not be exchanged. Thus we assume that unavailable, media should not be exchanged. Thus, we assume that
users have a way in their interface to require this criticality, on a 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 per-call basis or perhaps on a per-destination basis. Users will not
not always place calls where the connected identity is crucial, but always place calls where the connected identity is crucial, but when
when they do, they should have a way to tell their devices that the they do, they should have a way to tell their devices that the call
call should not be completed if it arrives at an unexpected or should not be completed if it arrives at an unexpected or
unauthenticated party. unauthenticated party.
8. Creating Pre-Association with Destinations 8. Creating Pre-Association with Destinations
Any connected identity mechanism will work best if the user knows Any connected identity mechanism will work best if the user knows
before initiating a call that connected identity is supported by the before initiating a call that connected identity is supported by the
destination side. Not every institution that a user wants to connect destination side. Not every institution that a user wants to connect
to securely will support STIR and connected identity out of the gate. to securely will support STIR and connected identity out of the gate.
Some sort of directory service might exist that advertises support Some sort of directory service might exist that advertises support
for connected identity, which institutions then could use to inform for connected identity, which institutions then could use to inform
potential callers that, if connected identity is not supported when potential callers that, if connected identity is not supported when
reaching them with SIP, there is a potential security problem. reaching them with SIP, there is a potential security problem.
Similarly, user devices might keep some sort of log recording that a Similarly, user devices might keep some sort of log recording that a
destination previously supported connected identity, so that if destination previously supported connected identity, so that if
support is unavailable later, calling users could be alerted to a support is unavailable later, calling users could be alerted to a
potential security problem. potential security problem.
The user interface of modern smartphones support an address book from The user interface of modern smartphones supports an address book
which users select telephone numbers to dial. Even when dialing a from which users select telephone numbers to dial. Even when dialing
number manually, the interface frequently checks the address book, a number manually, the interface frequently checks the address book,
which will display to users any provisioned name for the target of which will display to users any provisioned name for the target of
the call if one exists. Similarly, when clicking on a telephone the call if one exists. Similarly, when clicking on a telephone
number viewed on a web page, or similar service, smartphones often number viewed on a web page or similar service, smartphones often
prompt users approve the access to the outbound dialer. These sorts prompt users to approve the access to the outbound dialer. These
of decision points, when the user is still interacting with the user sorts of decision points, when the user is still interacting with the
interface before a call is placed, provide an opportunity to probe user interface before a call is placed, provide an opportunity to
what identity would be reached as a destination, and potentially even probe what identity would be reached as a destination and potentially
to exchange STIR PASSporTs in order to validate whether or not the even to exchange STIR PASSporTs in order to validate whether or not
expected destination can be reached securely. Again, this is the expected destination can be reached securely. Again, this is
probably most meaningful for contacting financial, government, or probably most meaningful for contacting financial, government, or
emergency services, for cases where reaching an unintended emergency services, for cases where reaching an unintended
destination may have serious consequences. destination may have serious consequences.
The establishment of media-less dialogs has long been specified as a The establishment of media-less dialogs has long been specified as a
component of third-party call control in SIP [RFC3725], in which an component of third-party call control in SIP [RFC3725], in which an
INVITE is sent with no SDP. Similar media-less dialogs have been INVITE is sent with no SDP. Similar media-less dialogs have been
proposed for certain automated systems per [RFC5552]. In the STIR proposed for certain automated systems per [RFC5552]. In the STIR
context, a media-less dialog is established by sending an INVITE with context, a media-less dialog is established by sending an INVITE with
an Identity header field but no SDP. STIR-aware UASes that support an Identity header field but no SDP. STIR-aware UASes that support
this specification, upon receiving an INVITE with no SDP, carrying a this specification, upon receiving an INVITE with no SDP, carrying a
PASSporT, with a 100rel in the Require header field value, SHOULD PASSporT, with a 100rel in the Require header field value, SHOULD
follow the mechanism described in Section 4 to send a provisional follow the mechanism described in Section 4 to send a provisional
response carrying a PASSporT in the backwards direction. The response carrying a PASSporT in the backwards direction. The
PASSporT received in the backwards direction could be rendered to 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. originating user to help them decide if they want to place the call.
9. The 'rsp' PASSporT Type 9. The "rsp" PASSporT Type
This specification defines a "rsp" PASSporT type that is sent only in This specification defines a "rsp" PASSporT type that is sent only in
SIP responses; it MUST NOT be sent in SIP requests. Any "rsp" SIP responses; it MUST NOT be sent in SIP requests. Any "rsp"
PASSporTs received in requests MUST be ignored. PASSporTs received in requests MUST be ignored.
The header of a "rsp" PASSporT shows a "ppt" of "rsp": The header of a "rsp" PASSporT shows a "ppt" of "rsp":
{ "typ":"passport", { "typ":"passport",
"ppt":"rsp", "ppt":"rsp",
"alg":"ES256", "alg":"ES256",
"x5u":"https://www.example.com/cert.cer" } "x5u":"https://www.example.com/cert.pem" }
The payload of an "rsp" PASSporT looks entirely like a normal The payload of an "rsp" PASSporT looks entirely like a normal
PASSporT -- the only difference is in semantics, as the certificate PASSporT -- the only difference is in semantics, as the PASSporT is
signs for the "dest" header field rather than the "orig". signed to authenticate the "dest" claim value rather than the "orig".
{ "orig":{"tn":"12155551212"}, { "orig":{"tn":"12155551212"},
"dest":{"tn":["12155551214"]}, "dest":{"tn":["12155551214"]},
"iat":1443208345 } "iat":1443208345 }
No restrictions are placed here on additional elements appearing in No restrictions are placed here on additional elements appearing in
the payload of an "rsp" type PASSporT. the payload of an "rsp" type PASSporT.
10. UPDATE Procedures for Provisional Dialogs 10. UPDATE Procedures for Provisional Dialogs
[RFC4916] identified a means of sending Identity header field values [RFC4916] identifies a means of sending Identity header field values
in the backwards direction before a final response to a dialog has in the backwards direction before a final response to a dialog has
been received by the UAC. It relied on negotiating support for been received by the UAC. It relies on negotiating support for
"from-change" options tags on both sides, followed by the use of the "from-change" options tags on both sides, followed by the use of the
UPDATE method to send the connected identity in the backwards UPDATE method to send the connected identity in the backwards
direction. This can only happen after the UAS has received and direction. This can only happen after the UAS has received and
responded to a PRACK [RFC3262] from the UAC, which would in turn have 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. been triggered by a provisional 1xx response sent earlier by the UAC.
However, the complexity of this mechanism makes it impractical to However, the complexity of this mechanism makes it impractical to
deploy for both the primary use case and the diversion use case deploy for both the primary use case and the diversion use case
described above. It may still have utility for corner cases with described above. It may still have utility for corner cases with
legacy versions of SIP (that date before the addition of the To and legacy versions of SIP (that date before the addition of the To and
From header field value tags) or more complex call parking scenarios. From header field value tags) or more complex call parking scenarios.
As such, this specification does not deprecate [RFC4916] "from- As such, this specification does not deprecate the "from-change"
change" behavior, nor does it provide an update for it for STIR -- behavior in [RFC4916], nor does it provide an update for it for STIR
that is left for future work. -- that is left for future work.
11. IANA Considerations 11. IANA Considerations
This specification defines a new PASSporT type for the "Personal This specification defines a new PASSporT type for the "Personal
Assertion Token (PASSporT) Extensions" registry defined in [RFC8225], Assertion Token (PASSporT) Extensions" registry [RFC8225], which
which resides at https://www.iana.org/assignments/passport/: resides at <https://www.iana.org/assignments/passport/>:
ppt value "rsp" ppt value: rsp
Reference [RFCThis], Section 9 Reference: RFC 9970, Section 9
12. Privacy Considerations 12. Privacy Considerations
Note that sending connected identity can reveal information about the Note that sending connected identity can reveal information about the
called party. If a called party does not wish to be identified, it 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 is especially important not to share rich call data (RCD) in the
backwards direction, particular in business-to-consumer calling backwards direction, particular in business-to-consumer calling
cases. From a user experience perspective, this would likely work cases. From a user experience perspective, this would likely work
similarly to current systems for sharing numbers, names, and even similarly to current systems for sharing numbers, names, and even
pictures from calling parties to called parties -- users have pictures from calling parties to called parties -- users have
considerable control over that experience, and similarly for considerable control over that experience, and similarly for
connected identity, this must be an opt-in choice for users. In connected identity, this must be an opt-in choice for users. In
general, RCD is more commonly used by enterprises than by individual general, RCD is more commonly used by enterprises than by individual
users. users.
13. Security Considerations 13. Security Considerations
The security considerations of [RFC8224] and [RFC8225] apply to the The security considerations of [RFC8224] and [RFC8225] apply to the
use of the "rsp" PASSporT. In general, a PASSporT of type "rsp" has use of the "rsp" PASSporT. In general, a PASSporT of type "rsp" has
similar security properties to a [RFC8946] diversion ("div") similar security properties to a diversion ("div") PASSporT
PASSporT. Relying parties leverage a "rsp" PASSporT to determine the [RFC8946]. Relying parties leverage a "rsp" PASSporT to determine
recipient of a request, and as with "div," the "dest" element of an the recipient of a request, and as with "div", the "dest" element of
"rsp" PASSporT is signed, rather than the "orig" element. an "rsp" PASSporT is signed rather than the "orig" element.
The major threat that "rsp" addresses is the impersonation of a SIP The major threat that "rsp" addresses is the impersonation of a SIP
response or mid-dialog/dialog-terminating request. For the latter, response or mid-dialog/dialog-terminating request. For the latter,
this might include forging a BYE for a denial-of-service attack, or, this might include forging a BYE for a denial-of-service attack or,
for example, forging a re-INVITE that negotiates media channels for example, forging a re-INVITE that negotiates media channels
controlled by an attacker. For the former, some form of route controlled by an attacker. For the former, some form of route
hijacking or similar attack can be mounted by forging a dialog- hijacking or similar attack can be mounted by forging a dialog-
forming response that appears to the caller to initiate a dialog with forming response that appears to the caller to initiate a dialog with
the intended destination. The "rsp" mechanism uses PASSporTs to the intended destination. The "rsp" mechanism uses PASSporTs to
provide a non-repudiable assurance of the signer of such responses provide a non-repudiable assurance of the signer of such responses
and requests. and requests.
The value of a "rsp" PASSporT to relying parties, as with all The value of a "rsp" PASSporT to relying parties, as with all
PASSporTs, depends on the relying party trusting the certificate that PASSporTs, depends on the relying party trusting the certificate that
signs the PASSporT, and having a reasonable assurance that the signs the PASSporT and having a reasonable assurance that the
certificate in question is eligible to sign responses/requests for certificate in question is eligible to sign responses/requests for
the number in the "dest" field of the "rsp" PASSporT. For STIR the number in the "dest" claim of the "rsp" PASSporT. For STIR
certificates that use Service Provider Codes (SPCs), effectively the certificates that use Service Provider Codes (SPCs), effectively the
relying party knows the network operator who is vouching for that relying party knows the network operator who is vouching for that
"rsp". This in turn enables traceback and similar mitigations. "rsp". This in turn enables traceback and similar mitigations.
As was mentioned in Section 5, the use of "div" along with "rsp" in As mentioned in Section 5, the use of "div" along with "rsp" in
responses may reveal the service logic of diversions to calling responses may reveal the service logic of diversions to calling
parties. However, since the called party ultimately invokes the parties. However, since the called party ultimately invokes the
"rsp" mechanism, any necessary policy controls can prevent the "rsp" mechanism, any necessary policy controls can prevent the
sending of "rsp" when that service logic must be protected. sending of "rsp" when that service logic must be protected.
The use of PASSporTs within responses creates a novel potential The use of PASSporTs within responses creates a novel potential
vector for amplification attacks, as many responses may be sent in vector for amplification attacks, as many responses may be sent in
response to a single SIP request, and the presence of a PASSporT response to a single SIP request, and the presence of a PASSporT
meaningfully increases the size of SIP responses. However, given meaningfully increases the size of SIP responses. However, given
that PASSporTs can only be present in responses to requests carrying that PASSporTs can only be present in responses to requests carrying
skipping to change at page 15, line 50 skipping to change at line 689
Steele for their contributions to this specification. Steele for their contributions to this specification.
Authors' Addresses Authors' Addresses
Jon Peterson Jon Peterson
TransUnion TransUnion
Email: jon.peterson@transunion.com Email: jon.peterson@transunion.com
Chris Wendt Chris Wendt
Somos Somos
Email: chris-ietf@chriswendt.net Email: chris@appliedbits.com
 End of changes. 54 change blocks. 
185 lines changed or deleted 184 lines changed or added

This html diff was produced by rfcdiff 1.48.