rfc9970.original.xml		rfc9970.xml
	<?xml version='1.0' encoding='utf-8'?>		<?xml version='1.0' encoding='utf-8'?>
	<!DOCTYPE rfc [		<!DOCTYPE rfc [
	<!ENTITY nbsp "&#160;">		<!ENTITY nbsp "&#160;">
	<!ENTITY zwsp "&#8203;">		<!ENTITY zwsp "&#8203;">
	<!ENTITY nbhy "&#8209;">		<!ENTITY nbhy "&#8209;">
	<!ENTITY wj "&#8288;">		<!ENTITY wj "&#8288;">
	]>		]>
	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
	tf-stir-rfc4916-update-07" ipr="trust200902" obsoletes="" updates="" submissionT
	ype="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs=
	"true" version="3">
	<!-- xml2rfc v2v3 conversion 3.22.0 -->
	<!-- category values: std, bcp, info, exp, and historic
	ipr values: trust200902, noModificationTrust200902, noDerivativesTrust200902
	,
	or pre5378Trust200902
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->
	<!-- ***** FRONT MATTER ***** -->		<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie tf-stir-rfc4916-update-07" number="9970" consensus="true" ipr="trust200902" obso letes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDep th="4" symRefs="true" sortRefs="true" version="3">
	<front>		<!-- [rfced] We made the following changes per Chris's reply to the document int
	<!-- The abbreviated title is used in the page header - it is only necessary		ake form. Chris indicated that he would like for Jon to confirm that he agrees w
	if the		ith the changes in b) and c) below; please review and confirm.
	full title is longer than 39 characters -->
	<title abbrev="Connected Identity">Connected Identity for STIR</title>		a) Email address for Chris
	<seriesInfo name="Internet-Draft" value="draft-ietf-stir-rfc4916-update-07"/
	>		OLD:
			chris-ietf@chriswendt.net
			NEW:
			chris@appliedbits.com
			b) Changes to text. Please also review to let us know if any other similar chang
			es should be made; we see other instances of '"dest" header field' and '"dest" f
			ield' in the document.
			OLD:
			... the only difference is in semantics, as the certificate
			signs for the "dest" header field rather than the "orig".
			NEW:
			... the only difference is in semantics, as the PASSporT is
			signed to authenticate the "dest" claim value rather than the "orig".
			OLD:
			... is eligible to sign responses/requests for
			the number in the "dest" field of the "rsp" PASSporT.
			NEW:
			... is eligible to sign responses/requests for
			the number in the "dest" claim of the "rsp" PASSporT.
			c) Change to sourcecode in Section 9
			OLD:
			"x5u":"https://www.example.com/cert.cer"
			NEW:
			"x5u":"https://www.example.com/cert.pem"
			-->
			<!-- [rfced] The document header does not indicate that this document updates RF
			C 4916. However, some text in the document (see below) seems to indicate a possi
			ble Updates relationship with RFC 4916. Please review and let us know if any cha
			nges are needed.
			Original:
			This document
			updates prior guidance on the "connected identity" problem to reflect
			the changes to SIP Identity that accompanied STIR, ...
			...
			With the obsolescence of [RFC4474] by [RFC8224], this specification
			supersedes the guidance of [RFC4916] to reflect the changes to the
			SIP Identity header field and the revised problem space of STIR.
			-->
			<!-- [rfced] Document title
			a) Please note that the title of the document has been updated as follows. Abbre
			viations have been expanded per Section 3.6 of RFC 7322 ("RFC Style Guide"). Ple
			ase review.
			Original:
			Connected Identity for STIR
			Updated:
			Connected Identity for Secure Telephone Identity Revisited (STIR)
			b) We have also updated the abbreviated title as shown below to more closely ali
			gn with the document title.
			Original:
			Connected Identity
			Updated:
			Connected Identity for STIR
			-->
			<front>
			<title abbrev="Connected Identity for STIR">Connected Identity for Secure Te
			lephone Identity Revisited (STIR)</title>
			<seriesInfo name="RFC" value="9970"/>
	<author initials="J." surname="Peterson" fullname="Jon Peterson">		<author initials="J." surname="Peterson" fullname="Jon Peterson">
	<organization abbrev="TransUnion">TransUnion</organization>		<organization abbrev="TransUnion">TransUnion</organization>
	<address>		<address>
	<email>jon.peterson@transunion.com</email>		<email>jon.peterson@transunion.com</email>
	</address>		</address>
	</author>		</author>
	<author fullname="Chris Wendt" initials="C." surname="Wendt">		<author fullname="Chris Wendt" initials="C." surname="Wendt">
	<organization>Somos</organization>		<organization>Somos</organization>
	<address>		<address>
	<email>chris-ietf@chriswendt.net</email>		<email>chris@appliedbits.com</email>
	</address>		</address>
	</author>		</author>
	<date year="2025"/>		<date year="2026" month="May"/>
	<!-- <area>
	ART		<area>ART</area>
	</area>-->		<workgroup>stir</workgroup>
	<keyword>SIP</keyword>		<keyword>SIP</keyword>
			<!-- [rfced] How may we revise this sentence to clarify how the text starting wi
			th "as well as ..." connects to the rest of the sentence?
			Original:
			This document
			updates prior guidance on the "connected identity" problem to reflect
			the changes to SIP Identity that accompanied STIR, and 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, as well as the spoofing of mid-dialog or dialog-
			terminating events by intermediaries or third parties.
			Perhaps 1 ("detecting both calls ... and the spoofing"):
			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
			both calls that have been retargeted to a party impersonating the intended
			destination and the spoofing of mid-dialog or dialog-
			terminating events by intermediaries or third parties.
			Perhaps 2 ("detecting calls ... and preventing the spoofing"):
			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.
			-->
	<abstract>		<abstract>
	<t>The Session Initiation Protocol (SIP) Identity header field conveys cry ptographic identity information about the originators of SIP requests. The Secur e Telephone Identity Revisited (STIR) framework, however,		<t>The Session Initiation Protocol (SIP) Identity header field conveys crypt ographic identity information about the originators of SIP requests. However, th e Secure Telephone Identity Revisited (STIR) framework
	provides no means for determining the identity of the called party in a traditional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem		provides no means for determining the identity of the called party in a traditional telephone-calling scenario. This document updates prior guidance on the "connected identity" problem
	to reflect the changes to SIP Identity that accompanied STIR, and consi ders a revised problem space for connected identity as a means of detecting call s that have been retargeted to a party impersonating the intended destination, a s well as the spoofing of mid-dialog or dialog-terminating events by intermediar ies or third parties.		to reflect the changes to SIP Identity that accompanied STIR. It also c onsiders a revised problem space for connected identity as a means of detecting calls that have been retargeted to a party impersonating the intended destinatio n, as well as the spoofing of mid-dialog or dialog-terminating events by interme diaries or third parties.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Introduction</name>		<name>Introduction</name>
	<t>		<t>
	The <xref target="RFC3261" format="default">Session Initiation Protocol (SIP) </xref> initiates		The Session Initiation Protocol (SIP) <xref target="RFC3261" format="default" /> initiates
	sessions, and as a step in establishing sessions, it exchanges information ab out the		sessions, and as a step in establishing sessions, it exchanges information ab out the
	parties at both ends. Called users review information about the calling party , for example,		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 w ay that users of		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		the telephone network assess "Caller ID" information before picking up calls. This information may sometimes
	be consumed by automated systems to make authorization decisions. <xref tar get="RFC8224" format="default">STIR</xref> provides a cryptographic assurance of the identity of calling parties in order to prevent impersonation,		be consumed by automated systems to make authorization decisions. STIR <xre f target="RFC8224" format="default"/> 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 ha cking, and similar attacks (see <xref target="RFC7375" format="default"/>).		which is a key enabler of unwanted robocalls, swatting, vishing, voicemail ha cking, and similar attacks (see <xref target="RFC7375" format="default"/>).
	</t>		</t>
	<t>		<t>
	There also exists a related problem: the identity of the party who answers a call can differ from that of		A related problem also exists: The identity of the party who answers a call c an differ from that of
	the initial called party for various innocuous reasons such as call forwardin g. In certain network environments, however, it is possible for attackers to hij ack the route of a called number and direct it to a resource controlled by the a ttacker. It can potentially be difficult to determine why a call reached a		the initial called party for various innocuous reasons such as call forwardin g. In certain network environments, however, it is possible for attackers to hij ack the route of a called number and direct it to a resource controlled by the a ttacker. It can potentially be difficult to determine why a call reached a
	target other than the one originally intended, and whether the party ultimate		target other than the one originally intended and whether the party ultimatel
	ly reached by the call is one that		y reached by the call is one that
	the caller should trust. The lack of mutual authentication of parties moreove		the caller should trust. Moreover, the lack of mutual authentication of parti
	r makes it possible for outside attackers to inject forged messages (e.g., BYE)		es makes it possible for outside attackers to inject forged messages (e.g., BYE)
	into a SIP session.		into a SIP session.
	</t>		</t>
	<t>		<t>
	The property of providing the identity of the called party to the callin g party is called "connected identity". Previous work on connected identity focu sed on fixing the core semantics of SIP. <xref target="RFC4916" format="default" /> allowed a mid-dialog request, such as an <xref target="RFC3311" format="defau lt">UPDATE</xref>,		The property of providing the identity of the called party to the callin g party is called "connected identity". Previous work on connected identity focu sed on fixing the core semantics of SIP. <xref target="RFC4916" format="default" /> allows a mid-dialog request, such as an UPDATE <xref target="RFC3311" format= "default"/>,
	to convey identity in either direction within the		to convey identity in either direction within the
	context of an existing INVITE-initiated dialog.		context of an existing INVITE-initiated dialog.
	In an update to the original <xref target="RFC3261" format="default"/> behavi		<xref target="RFC4916" format="default"/> also allows that UPDATE to alter th
	or,		e From header field value for
	<xref target="RFC4916" format="default"/> allowed that UPDATE to alter the Fr		requests in the backwards direction; this is an update to the behavior descri
	om header field value for		bed in <xref target="RFC3261" format="default"/>, which requires that the From h
	requests in the backwards direction: previously <xref target="RFC3261" format		eader field values sent in
	="default"/> required that the From header field values sent in
	requests in the backwards direction reflect the		requests in the backwards direction reflect the
	To header field value of the dialog-forming request. Under the original <xref		To header field value of the dialog-forming request. Under the original rules
	target="RFC3261" format="default"/>		in <xref target="RFC3261" format="default"/>, if Alice sent a dialog-forming re
	rules, if Alice sent a dialog-forming request to Bob, then even if Bob's SIP		quest to Bob, then even if Bob's SIP service forwarded that dialog-forming reque
	service forwarded that dialog-forming request to Carol, Carol would still be req		st to Carol, Carol would still be required to put Bob's identity in the From hea
	uired to put Bob's identity in the From header field value in any mid-dialog req		der field value in any mid-dialog requests
	uests
	in the backwards direction.		in the backwards direction.
	</t>		</t>
	<t>		<t>
	One of the original motivating use cases for <xref target="RFC4916" format="d		One of the original motivating use cases for <xref target="RFC4916" format="d
	efault"/> was the use of connected identity with the SIP <xref target="RFC4474"		efault"/> was the use of connected identity with the SIP Identity header field <
	format="default">Identity</xref> header field. While a mid-dialog request in the		xref target="RFC4474" format="default"/>. While a mid-dialog request in the back
	backwards direction (e.g., UPDATE) can be signed with Identity like		wards direction (e.g., UPDATE) can be signed with Identity like
	any other SIP request, forwarded requests would not be properly signed withou		any other SIP request, forwarded requests would not be properly signed withou
	t the ability to change the mid-dialog From header field value: Carol, say, woul		t the ability to change the mid-dialog From header field value. Thus, Carol woul
	d not be able to furnish a key to sign for Bob's identity if Carol wanted to sig		d not be able to furnish a key to sign for Bob's identity if Carol wanted to sig
	n requests in the backwards direction. Carol would, however, be able to sign for		n 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 b		her own identity in the From header field value if mid-dialog requests in the b
	ackwards direction were permitted to vary from the original To header field valu		ackwards direction were permitted to vary from the original To header field valu
	e.		e.
	</t>		</t>
	<t>		<t>
	With the obsolescence of <xref target="RFC4474" format="default"/> by <xr ef target="RFC8224" format="default"/>, this specification supersedes the guidan ce of <xref target="RFC4916" format="default"/> to reflect the changes to the SI P Identity header field and the revised problem space of STIR. It also explores some new features that would be enabled by connected identity for STIR, includin g 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 <xref target="RFC4916" format="default"/> con nected identity to STIR discussed in the SIPBRANDY framework <xref target="RFC88 62" format="default"/>.		With the obsolescence of <xref target="RFC4474" format="default"/> by <xr ef target="RFC8224" format="default"/>, this specification supersedes the guidan ce of <xref target="RFC4916" format="default"/> to reflect the changes to the SI P Identity header field and the revised problem space of STIR. It also explores some new features that would be enabled by connected identity for STIR, includin g 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 <xref target="RFC4916" for mat="default"/> to STIR discussed in the SIPBRANDY framework <xref target="RFC88 62" format="default"/>.
	</t>		</t>
	<t>		<t>
	One area of connected identity that is not explored in this document is t he implications for conferencing, especially meshed conferencing systems. The sc ope of this mechanism is solely two-party communications; multiparty sharing of connected identity is left for future work.		One area of connected identity that is not explored in this document is t he implications for conferencing, especially meshed conferencing systems. The sc ope of this mechanism is solely two-party communications; multiparty sharing of connected identity is left for future work.
	</t>		</t>
	</section>		</section>
	<section numbered="true" toc="default">		<section numbered="true" toc="default">
	<name>Terminology</name>		<name>Terminology</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SH		<t>
	OULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in		The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
	this document		IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	are to be interpreted as described in BCP 14 <xref target="RFC2119" format="defa		NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
	ult"/> <xref target="RFC8174" format="default"/> when, and only when, they appea		RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	r in all capitals, as shown here. This document assumes familiarity with common		"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
	messages, response codes, and header fields used in <xref target="RFC3261">SIP</		be interpreted as
	xref>, and the elements present in the <xref target="RFC8225">PASSporT</xref> to		described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	ken format.</t>		when, and only when, they appear in all capitals, as shown here.
			</t>
			<t>This document assumes familiarity with common messages, response codes,
			and header fields used in SIP <xref target="RFC3261"/> and the elements present
			in the Personal Assertion Token (PASSporT) <xref target="RFC8225"/> format.</t>
	</section>		</section>
	<section anchor="problem" numbered="true" toc="default">		<section anchor="problem" numbered="true" toc="default">
	<name>Connected Identity Problem Statement for STIR</name>		<name>Connected Identity Problem Statement for STIR</name>
	<t>		<t>
	The <xref target="RFC7340" format="default">STIR problem statement</xre f> enumerates robocalling, voicemail hacking, vishing, and swatting as problems with the modern telephone network that are enabled, or abetted, by impersonation : by the ability of a calling party to arbitrarily set the telephone number that will be rendered to end users to identify the caller.		The STIR problem statement <xref target="RFC7340" format="default"/> en umerates 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 w ill be rendered to end users to identify the caller.
	</t>		</t>
	<t>		<t>
	Today, sophisticated adversaries can redirect calls on the Public Switc hed Telephone Network (PSTN) to destinations other than the intended called part y. For some call centers, like those associated with financial institutions, hea lthcare, and emergency services, an attacker could hope to gain valuable informa tion about people or to prevent some classes of important services.		Today, sophisticated adversaries can redirect calls on the Public Switc hed Telephone Network (PSTN) to destinations other than the intended called part y. For some call centers, like those associated with financial institutions, hea lthcare, and emergency services, an attacker could hope to gain valuable informa tion about people or to prevent some classes of important services.
	Moreover, on the Internet, the lack of any centralized or even federate d routing system for telephone numbers has resulted in deployments where the rou ting of calls is arbitrary: calls to		Moreover, on the Internet, the lack of any centralized or even federate d routing system for telephone numbers has resulted in deployments where the rou ting 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 conf iguration file, potentially using various mechanisms		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 conf iguration file, potentially using various mechanisms
	such as consulting a private ENUM <xref target="RFC6116" format="defaul t"/>, or routing might be determined in some other, domain-specific way. In shor t, there are numerous attack surfaces that an adversary could explore to attempt to redirect calls for a particular number to someplace		such as consulting a private ENUM <xref target="RFC6116" format="defaul t"/>, or routing might be determined in some other, domain-specific way. In shor t, 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.		other than the intended destination.
	</t>		</t>
	<t>		<t>
	Another motivating use case for connected identity is mid-dialog reques ts, 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 managem ent of SIP. For example, there is a class of mobile fraud attacks ("call stretch ing") that rely on intermediary networks making it appear to one side as if a ca ll 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 int ermediary. If BYE requests in both directions of a SIP dialog could be authentic ated with STIR, in the same way as dialog-forming requests, then another imperso nation vector leading to fraud in the telephone network could be shut down.		Another motivating use case for connected identity is mid-dialog reques ts, 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 managem ent of SIP. For example, there is a class of mobile fraud attacks ("call stretch ing") that rely on intermediary networks making it appear to one side as if a ca ll 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 int ermediary. If BYE requests in both directions of a SIP dialog could be authentic ated with STIR, in the same way as dialog-forming requests, then another imperso nation vector leading to fraud in the telephone network could be shut down.
	</t>		</t>
	<t>		<t>
	Finally, telephone numbers are widely used today for two-factor authent ication (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 t elephone number. These systems are often capable of using either telephone calls or messages for TFA. Connected identity is very valuable for these use cases be cause it gives a strong assurance to the calling party that they have in fact re ached the telephone for the called telephone number.		Finally, telephone numbers are widely used today for two-factor authent ication (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 t elephone number. These systems are often capable of using either telephone calls or messages for TFA. Connected identity is very valuable for these use cases be cause it gives a strong assurance to the calling party that they have in fact re ached the telephone for the called telephone number.
	</t>		</t>
	<t>		<t>
	There are however practical limits to what securing the signaling can achiev		However, there are practical limits to what securing the signaling can achie
	e.		ve.
	<xref target="RFC4916" format="default"/> rightly observed that once a SI		<xref target="RFC4916" format="default"/> rightly observes that once a SI
	P call has		P call has
	been answered, the called party can be replaced by a different party (with a		been answered, the called party can be replaced by a different party (with a
	different identity) due to call transfer, call park and		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 u ser agent,		retrieval, and so on. In some cases, due to the presence of a back-to-back u ser agent,
	it can be effectively impossible for the calling party to know that this has happened.		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 w hether media		The problem statement considered for STIR focuses solely on signaling, not w hether media
	from the connected party should be rendered to the caller when a dialog has been established. This specification		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 medi a, though <xref target="RFC8862" format="default"/> contains related guidance.		does not consider further any threats that arise from a substitution of medi a, though <xref target="RFC8862" format="default"/> contains related guidance.
	</t>		</t>
	</section>		</section>
	<section anchor="sunny" numbered="true" toc="default">		<section anchor="sunny" numbered="true" toc="default">
	<name>Connected Identity without Diversion</name>		<name>Connected Identity without Diversion</name>
	<t>		<t>
	In straightforward call setup, the address-of-record (AoR) of the party r eached by an INVITE corresponds to the "dest" field of the PASSporT in the INVIT E'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 c annot 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 PASS porT for the AoR of the called party.		In straightforward call setup, the address-of-record (AoR) of the party r eached by an INVITE corresponds to the "dest" field of the PASSporT in the INVIT E'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 c annot 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 PASS porT for the AoR of the called party.
	</t>		</t>
	<t>		<t>
	This specification therefore adds provisional and final SIP responses, in		This specification therefore adds provisional and final SIP responses, in
	cluding the 100, 180, 183, and 200 responses, to the set of messages that may co		cluding the 100, 180, 183, and 200 responses, to the set of messages that may co
	ntain an Identity header field. PASSporTs that appear in SIP responses SHOULD us		ntain an Identity header field. PASSporTs that appear in SIP responses <bcp14>SH
	e a "ppt" of "rsp", which is defined in <xref target="rsp" format="default"/> (a		OULD</bcp14> use a "ppt" of "rsp", which is defined in <xref target="rsp" format
	lthough <xref target="RFC8946" format="default">"div"</xref> may additionally ap		="default"/> (although "div" <xref target="RFC8946" format="default"/> may addit
	pear in responses, per <xref target="div" format="default"/>). PASSporTs of the		ionally appear in responses, per <xref target="div" format="default"/>). PASSpor
	"rsp" type will be referred to throughout this specification as "rsp" PASSporTs.		Ts of the "rsp" type will be referred to throughout this specification as "rsp"
	At a high level, an "rsp" PASSporT is signed similarly to the <xref target="RFC		PASSporTs. At a high level, an "rsp" PASSporT is signed similarly to the "div" P
	8946" format="default">"div"</xref> PASSporT, in so far as the certificate that		ASSporT <xref target="RFC8946" format="default"/>, insofar as the certificate th
	signs a "rsp" PASSporT is signing the "dest" field, rather than the "orig" field		at signs a "rsp" PASSporT is signing the "dest" field rather than the "orig" fie
	.		ld.
	If the terminating side does not possess an appropriate credential to sig		If the terminating side does not possess an appropriate credential to sig
	n for the value of the "dest" element value in the PASSporT, it MUST NOT sign an		n for the value of the "dest" element value in the PASSporT, it <bcp14>MUST NOT<
	d send a "rsp" PASSporT in the backwards direction.		/bcp14> sign and send a "rsp" PASSporT in the backwards direction.
	</t>		</t>
	<t>		<t>
	While it might seem attractive to provide identity for SIP failure respon se codes (4XX, 5XX, 6XX), those explicitly do not form dialogs or connections, a nd are thus outside the scope of this specification. The same applies to SIP red irect (3XX) response codes, though see <xref target="RFC8946" sectionFormat="com ma" section="7"/> for guidance on authentication redirection.		While it might seem attractive to provide identity for SIP failure respon se codes (4XX, 5XX, 6XX), those explicitly do not form dialogs or connections an d are thus outside the scope of this specification. The same applies to SIP redi rect (3XX) response codes, though see <xref target="RFC8946" sectionFormat="of" section="7"/> for guidance on authentication redirection.
	</t>		</t>
	<t>		<t>
	It is worth noting as well that at the time <xref target="RFC4916" format ="default"/> was written, the Identity mechanism was far stricter about what cou nted as retargeting than <xref target="RFC8224" format="default"/>, which has ca nonicalization processes that eliminate minor changes to the URIs, especially wh en telephone numbers are the identifiers used by the caller and callee. For basi c use cases, a PASSporT in a 183 or 200 OK should be sufficient to secure media keys for the purposes of SIPBRANDY <xref target="RFC8862" format="default"/>.		It is worth noting that at the time <xref target="RFC4916" format="defaul t"/> was written, the Identity mechanism was far stricter about what counted as retargeting than is described in <xref target="RFC8224" format="default"/>, whic h has canonicalization processes that eliminate minor changes to the URIs, espec ially 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 secur e media keys for the purposes of SIPBRANDY <xref target="RFC8862" format="defaul t"/>.
	</t>		</t>
	<t>		<t>
	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 <xref target="authz" format="default"/>). Moreover, provisional responses are not reliably delivered without using 100rel and PRACK <xref target="RFC3262" />, and provisional responses may be consumed (without forwarding) by intermedia ries under a variety of conditions. In short, their delivery is not guaranteed.		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 <xref target="authz" format="default"/>). Moreover, provisional responses are not reliably delivered without using 100rel and Provisional Response Acknowl edgement (PRACK) <xref target="RFC3262"/>, and provisional responses may be cons umed (without forwarding) by intermediaries under a variety of conditions. In sh ort, their delivery is not guaranteed.
	</t>		</t>
	</section>		</section>
	<section anchor="div" numbered="true" toc="default">		<section anchor="div" numbered="true" toc="default">
	<name>Connected Identity with Diversion</name>		<name>Connected Identity with Diversion</name>
	<t>		<t>
	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 trus t it?		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 trus t it?
	</t>		</t>
	<t>		<t>
	In STIR, the "div" PASSporT type <xref target="RFC8946" format="default"/ > 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 ve rification services to determine that a call has reached its eventual destinatio n for the right reasons.		In STIR, the "div" PASSporT type <xref target="RFC8946" format="default"/ > 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 ve rification services to determine that a call has reached its eventual destinatio n for the right reasons.
	As <xref target="RFC8946" format="default"/> explains the situation, the only way those diversion PASSporTs will be seen by the calling party is if redir ection is used (SIP 3XX responses) instead of retargeting. Because some network policies aim to conceal service logic from the originating party, sending redire ctions in the backwards direction is the only currently defined way for secure i ndications of redirection to be revealed to the calling party. That in turn woul d allow the calling user agent to have a strong assurance that legitimate entiti es in the call path caused the request to reach a party that the caller did not anticipate.		As <xref target="RFC8946" format="default"/> explains the situation, the only way those diversion PASSporTs will be seen by the calling party is if redir ection is used (SIP 3XX responses) instead of retargeting. Because some network policies aim to conceal service logic from the originating party, sending redire ctions in the backwards direction is the only currently defined way for secure i ndications of redirection to be revealed to the calling party. That in turn woul d allow the calling user agent to have a strong assurance that legitimate entiti es in the call path caused the request to reach a party that the caller did not anticipate.
	</t>		</t>
	<t>		<t>
	This specification introduces another alternative. When sending a "rsp" P ASSporT type in a SIP response, a User Agent Server (UAS) MAY also include (in I dentity 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 resp onses. 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 routin g 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 P ASSporT received in the dialog-initiating INVITE.		This specification introduces another alternative. When sending a "rsp" P ASSporT type in a SIP response, a User Agent Server (UAS) <bcp14>MAY</bcp14> als o include (in Identity header field values) any "div" PASSporTs it received in t he INVITE that initiated this dialog. Thus, PASSporTs of type "div" <bcp14>MAY</ bcp14> also appear in SIP responses. These "div" PASSporTs can enable the origin ating side to receive a secure assurance that the call is being fielded by the p roper recipient per the routing of the call. In this case, the "dest" signed in the "rsp" PASSporT <bcp14>MUST</bcp14> be the address-of-record of the party who was reached rather than the "dest" of the PASSporT received in the dialog-initi ating INVITE.
	</t>		</t>
	<t>		<t>
	An "rsp" PASSporT that signs a different "dest" than the one that appeare d in the PASSporT of the dialog-forming request MUST send at least one "div" PAS SporT with it. If no "div" PASSporTs were received in a dialog-forming request w ith a different "dest" value than the original PASSporT claimed, then "rsp" PASS porTs MUST NOT be used in responses. "div" is not universally supported, so call s MAY be retargeted without generating a "div" PASSporT, in which case the use o f "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 relyi ng parties: some stricter systems may not want to trust any "rsp" that differs f rom the "dest" in the PASSporT of the original request.		An "rsp" PASSporT that signs a different "dest" than the one that appeare d in the PASSporT of the dialog-forming request <bcp14>MUST</bcp14> send at leas t one "div" PASSporT with it. If no "div" PASSporTs were received in a dialog-fo rming request with a different "dest" value than the original PASSporT claimed, then "rsp" PASSporTs <bcp14>MUST NOT</bcp14> be used in responses. "div" is not universally supported, so calls <bcp14>MAY</bcp14> be retargeted without generat ing a "div" PASSporT, in which case the use of "rsp" PASSporTs will not be possi ble. Note that the decision to trust any "div" or "rsp" PASSporT is, as always i n STIR, a matter of local policy of the relying parties: Some stricter systems m ay not want to trust any "rsp" that differs from the "dest" in the PASSporT of t he original request.
	</t>		</t>
	<t>		<t>
	Note that sending "div" PASSporTs in the backwards direction will potenti ally 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 det ermination about reflecting those "div" PASSporTs back to the caller: connected identity may not be compatible with some operator policies.		Note that sending "div" PASSporTs in the backwards direction will potenti ally 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 det ermination about reflecting those "div" PASSporTs back to the caller; connected identity may not be compatible with some operator policies.
	</t>		</t>
	<t>		<t>
	This mechanism does not require altering the value of the From header fie ld value in requests or responses in the backwards direction. While this was a m ajor concern of <xref target="RFC4916" format="default"/>, in many operating env ironments, 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 <xref target="RFC3325" format="default">P-Asserted-Identity (PAID) header field< /xref>. The contents of PAID were never used for dialog matching, and so in envi ronments where PAID is used, it can be altered more dynamically than the From (m oreover, <xref target="RFC3261" format="default"/>, by introducing tag parameter s to the To and From header field values, eliminated the need for stability in F rom values for dialog identification some time ago). For retargeting that utiliz es the <xref target="RFC4916" format="default"/> "from-change" option tag, see < xref target="provis" format="default"/>. STIR is, in general, more flexible in c onstructing the "dest" than the Identity header field managed addresses-of-recor d at the time <xref target="RFC4916" format="default"/> was written.		This mechanism does not require altering the value of the From header fie ld value in requests or responses in the backwards direction. While this was a m ajor concern of <xref target="RFC4916" format="default"/>, in many operating env ironments, 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 <xref target="RFC3325" format="default"/ >. The contents of PAID were never used for dialog matching, and so in environme nts 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 v alues, <xref target="RFC3261" format="default"/> eliminates the need for stabili ty in From values for dialog identification some time ago). For retargeting that utilizes the "from-change" option tag in <xref target="RFC4916" format="default "/>, see <xref target="provis" format="default"/>. STIR is, in general, more fle xible in constructing the "dest" than the Identity header field managed addresse s-of-record at the time <xref target="RFC4916" format="default"/> was written.
	</t>		</t>
	</section>		</section>
	<section anchor="mid" numbered="true" toc="default">		<section anchor="mid" numbered="true" toc="default">
	<name>Connected Identity in Mid-Dialog and Dialog-Terminating Requests</na me>		<name>Connected Identity in Mid-Dialog and Dialog-Terminating Requests</na me>
	<t>		<t>
	The use of the connected identity mechanism here specified is not limited to provisional dialog requests. Once a dialog has been established with connect ed identity, any re-INVITEs from either the originating and terminating side, as well as any BYE requests, SHOULD contain Identity header fields with valid PASS porTs. If only the terminating side supports connected identity, obviously the o riginator cannot be expected to know that it needs to send PASSporTs for subsequ ent requests like BYE. Doing so prevents third parties from spoofing any mid-dia log requests in order to redirect media or similarly interfere with communicatio ns, as well as preventing denial of service teardowns by attackers.		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 terminat ing side, as well as any BYE requests, <bcp14>SHOULD</bcp14> contain Identity he ader fields with valid PASSporTs. If only the terminating side supports connecte d identity, obviously the originator cannot be expected to know that it needs to send PASSporTs for subsequent requests like BYE. Doing so prevents third partie s 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.
	</t>		</t>
	<t>		<t>
	Theoretically, any SIP requests in a dialog could be signed in this fashi on, though it is unclear how valuable it would be for some (e.g., OPTIONS). Requ ests with specialized payloads such as INFO or MESSAGE, however, would require a dditional specification for how integrity protection for their bodies could be i mplemented. Some work has been done toward that for MESSAGE (see <xref target="R FC9475" format="default"/>). This specification thus does not recommend PASSporT s for any requests sent in a dialog other than INVITE, UPDATE, and BYE.		Theoretically, any SIP requests in a dialog could be signed in this fashi on, though it is unclear how valuable it would be for some (e.g., OPTIONS). Requ ests with specialized payloads such as INFO or MESSAGE, however, would require a dditional specification for how integrity protection for their bodies could be i mplemented. Some work has been done toward that for MESSAGE (see <xref target="R FC9475" format="default"/>). This specification thus does not recommend PASSporT s for any requests sent in a dialog other than INVITE, UPDATE, and BYE.
	</t>		</t>
	<t>		<t>
	It might seem tempting to require that, if an INVITE has been sent with a n Identity header field containing a PASSporT, any CANCEL request received for t he dialog initiated by that INVITE must also contain an Identity header field wi th a PASSporT. However, CANCEL requests can also be sent by stateful proxy serve rs engaged in parallel forking; for example, when branches need to be canceled b ecause a final response has been received from a UAS. This specification does no t forbid a User Agent Client (UAC) from sending a CANCEL for its own PASSporT-pr otected INVITE requests, as there may be limited use cases where it would be use ful to relying parties, but recipients of a CANCEL should not expect PASSporTs t o be present in connected identity cases.		It might seem tempting to require that, if an INVITE has been sent with a n Identity header field containing a PASSporT, any CANCEL request received for t he dialog initiated by that INVITE must also contain an Identity header field wi th a PASSporT. However, CANCEL requests can also be sent by stateful proxy serve rs engaged in parallel forking, for example, when branches need to be canceled b ecause a final response has been received from a UAS. This specification does no t forbid a User Agent Client (UAC) from sending a CANCEL for its own PASSporT-pr otected INVITE requests, as there may be limited use cases where it would be use ful to relying parties, but recipients of a CANCEL should not expect PASSporTs t o be present in connected identity cases.
	</t>		</t>
	<t>		<t>
	Mid-dialog requests also require special handling in diversion cases. Re lying parties who intended to trust an "rsp" PASSporT MUST validate any "div" ch ain back to the "rsp" PASSporT on any Identity header field values received in r esponses (per <xref target="RFC8946"/>). The dialog initiator can then treat the certificate that signed that "rsp" PASSporT as the appropriate certificate to s ign any further mid-dialog or dialog-terminating requests received in the backwa rds direction. Furthermore, the "dest" element value in any requests or response s sent in the backwards direction during this dialog MUST be the same as the "de st" element value in the first response to the dialog-forming request that conta ins a PASSporT -- unless the "from-change" extension is used, per <xref target=" provis" format="default"/>.		Mid-dialog requests also require special handling in diversion cases. Re lying parties who intended to trust an "rsp" PASSporT <bcp14>MUST</bcp14> valida te any "div" chain back to the "rsp" PASSporT on any Identity header field value s received in responses (per <xref target="RFC8946"/>). The dialog initiator can then treat the certificate that signed that "rsp" PASSporT as the appropriate c ertificate to sign any further mid-dialog or dialog-terminating requests receive d in the backwards direction. Furthermore, the "dest" element value in any reque sts or responses sent in the backwards direction during this dialog <bcp14>MUST< /bcp14> be the same as the "dest" element value in the first response to the dia log-forming request that contains a PASSporT -- unless the "from-change" extensi on is used, per <xref target="provis" format="default"/>.
	</t>		</t>
	</section>		</section>
	<section anchor="authz" numbered="true" toc="default">		<section anchor="authz" numbered="true" toc="default">
	<name>Authorization Policy for Callers</name>		<name>Authorization Policy for Callers</name>
	<t>		<t>
	In a traditional 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. The situation is more complicated for callers, howeve r: callers typically expect to be connected to the proper destination and are of ten 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 di rect response to a security breach would be to hang up the call they were in the middle of placing.		In a traditional 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 caller s because they typically expect to be connected to the proper destination and ar e often holding telephones in a position that would not enable them to see displ ayed 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 t he middle of placing.
	</t>		</t>
	<t>		<t>
	While this specification does not prescribe any user experience associa ted 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 co nnected identity is not as expected. This is analogous to a situation where Secu re Real-time Protocol (SRTP) negotiation fails because the keys exchanged at the media layer do not match the fingerprints exchanged at the signaling layer: whe n a user requests confidentiality services, and they are unavailable, media shou ld 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 b asis. 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 sh ould not be completed if it arrives at an unexpected or unauthenticated party.		While this specification does not prescribe any user experience associa ted 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 co nnected identity is not as expected. This is analogous to a situation where Secu re Real-time Transport Protocol (SRTP) negotiation fails because the keys exchan ged at the media layer do not match the fingerprints exchanged at the signaling layer: When a user requests confidentiality services and they are unavailable, m edia should not be exchanged. Thus, we assume that users have a way in their int erface to require this criticality, on a per-call basis or perhaps on a per-dest ination 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 th e call should not be completed if it arrives at an unexpected or unauthenticated party.
	</t>		</t>
	</section>		</section>
	<section anchor="pre" numbered="true" toc="default">		<section anchor="pre" numbered="true" toc="default">
	<name>Creating Pre-Association with Destinations</name>		<name>Creating Pre-Association with Destinations</name>
	<t>		<t>
	Any connected identity mechanism will work best if the user knows befor e 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 ST IR and connected identity out of the gate. Some sort of directory service might exist that advertises support for connected identity, which institutions then co uld 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.		Any connected identity mechanism will work best if the user knows befor e 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 ST IR and connected identity out of the gate. Some sort of directory service might exist that advertises support for connected identity, which institutions then co uld 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.
	</t>		</t>
	<t>		<t>
	The user interface of modern smartphones support an address book from w		The user interface of modern smartphones supports an address book from
	hich users select telephone numbers to dial. Even when dialing a number manually		which users select telephone numbers to dial. Even when dialing a number manuall
	, the interface frequently checks		y, the interface frequently checks
	the address book, which will display to users any provisioned name for		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 nu		the target of the call if one exists. Similarly, when clicking on a telephone nu
	mber viewed on a web page, or similar service, smartphones often prompt users ap		mber viewed on a web page or similar service, smartphones often prompt users to
	prove the access to the outbound dialer. These sorts of decision points, when th		approve the access to the outbound dialer. These sorts of decision points, when
	e user is still interacting with the user interface before a call is placed, pro		the user is still interacting with the user interface before a call is placed, p
	vide an opportunity to probe what identity would be reached as a destination, an		rovide an opportunity to probe what identity would be reached as a destination a
	d potentially even to exchange STIR PASSporTs in order to validate whether or no		nd potentially even to exchange STIR PASSporTs in order to validate whether or n
	t the expected destination can be reached securely. Again, this is probably most		ot the expected destination can be reached securely. Again, this is probably mos
	meaningful for contacting financial, government, or emergency services, for cas		t meaningful for contacting financial, government, or emergency services, for ca
	es where reaching an unintended destination may have serious consequences.		ses where reaching an unintended destination may have serious consequences.
	</t>		</t>
			<!-- [rfced] The following phrase in this sentence is difficult to follow: "upon
			receiving an INVITE with no SDP, carrying a PASSporT, with a 100rel in the Requ
			ire header field value". How may we update for clarity?
			Original:
			STIR-aware UASes that support
			this specification, upon receiving an INVITE with no SDP, carrying a
			PASSporT, with a 100rel in the Require header field value, SHOULD
			follow the mechanism described in Section 4 to send a provisional
			response carrying a PASSporT in the backwards direction.
			Perhaps:
			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, it SHOULD follow the mechanism described in
			Section 4 to send a provisional response carrying a PASSporT in the
			backwards direction.
			-->
	<t>		<t>
	The establishment of media-less dialogs has long been specified as a co mponent of third-party call control in SIP <xref target="RFC3725" format="defaul t"/>, in which an INVITE is sent with no SDP. Similar media-less dialogs have be en proposed for certain automated systems per <xref target="RFC5552" format="def ault"/>. In the STIR context, a media-less dialog is established by sending an I NVITE with an Identity header field but no SDP. STIR-aware UASes that support th is specification, upon receiving an INVITE with no SDP, carrying a PASSporT, wit h a 100rel in the Require header field value, SHOULD follow the mechanism descri bed in <xref target="sunny" format="default"/> to send a provisional response ca rrying a PASSporT in the backwards direction. The PASSporT received in the backw ards direction could be rendered to the originating user to help them decide if they want to place the call.		The establishment of media-less dialogs has long been specified as a co mponent of third-party call control in SIP <xref target="RFC3725" format="defaul t"/>, in which an INVITE is sent with no SDP. Similar media-less dialogs have be en proposed for certain automated systems per <xref target="RFC5552" format="def ault"/>. In the STIR context, a media-less dialog is established by sending an I NVITE with an Identity header field but no SDP. STIR-aware UASes that support th is specification, upon receiving an INVITE with no SDP, carrying a PASSporT, wit h a 100rel in the Require header field value, <bcp14>SHOULD</bcp14> follow the m echanism described in <xref target="sunny" format="default"/> to send a provisio nal response carrying a PASSporT in the backwards direction. The PASSporT receiv ed in the backwards direction could be rendered to the originating user to help them decide if they want to place the call.
	</t>		</t>
	</section>		</section>
	<section anchor="rsp" numbered="true" toc="default">		<section anchor="rsp" numbered="true" toc="default">
	<name>The 'rsp' PASSporT Type</name>		<name>The "rsp" PASSporT Type</name>
	<t>		<t>
	This specification defines a "rsp" PASSporT type that is sent only in S IP responses; it MUST NOT be sent in SIP requests. Any "rsp" PASSporTs received in requests MUST be ignored.		This specification defines a "rsp" PASSporT type that is sent only in S IP responses; it <bcp14>MUST NOT</bcp14> be sent in SIP requests. Any "rsp" PASS porTs received in requests <bcp14>MUST</bcp14> be ignored.
	</t>		</t>
	<t>		<t>
	The header of a "rsp" PASSporT shows a "ppt" of "rsp":		The header of a "rsp" PASSporT shows a "ppt" of "rsp":
	</t>		</t>
	<sourcecode type="json"><![CDATA[		<sourcecode type="json"><![CDATA[
	{ "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" }]]></sourcecode>
	]]></sourcecode>
	<t>		<t>
	The payload of an "rsp" PASSporT looks entirely like a normal PASSporT -- the only difference is in semantics, as the certificate signs for the "dest" he ader field rather than the "orig".</t>		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".</t>
	<sourcecode type="json"><![CDATA[		<sourcecode type="json"><![CDATA[
	{ "orig":{"tn":"12155551212"},		{ "orig":{"tn":"12155551212"},
	"dest":{"tn":["12155551214"]},		"dest":{"tn":["12155551214"]},
	"iat":1443208345 }		"iat":1443208345 }]]></sourcecode>
	]]></sourcecode>
	<t>		<t>
	No restrictions are placed here on additional elements appearing in the p ayload of an "rsp" type PASSporT.		No restrictions are placed here on additional elements appearing in the p ayload of an "rsp" type PASSporT.
	</t>		</t>
	</section>		</section>
	<section anchor="provis" numbered="true" toc="default">		<section anchor="provis" numbered="true" toc="default">
	<name>UPDATE Procedures for Provisional Dialogs</name>		<name>UPDATE Procedures for Provisional Dialogs</name>
	<t>		<t>
	<xref target="RFC4916" format="default"/> identified a means of s ending Identity header field values in the backwards direction before a final re sponse to a dialog has been received by the UAC. It relied on negotiating suppor t for "from-change" options tags on both sides, followed by the use of the UPDAT E method to send the connected identity in the backwards direction. This can onl y happen after the UAS has received and responded to a <xref target="RFC3262" fo rmat="default">PRACK</xref> from the UAC, which would in turn have been triggere d by a provisional 1xx response sent earlier by the UAC.		<xref target="RFC4916" format="default"/> identifies a means of s ending Identity header field values in the backwards direction before a final re sponse to a dialog has been received by the UAC. It relies on negotiating suppor t for "from-change" options tags on both sides, followed by the use of the UPDAT E method to send the connected identity in the backwards direction. This can onl y happen after the UAS has received and responded to a PRACK <xref target="RFC32 62" format="default"/> from the UAC, which would in turn have been triggered by a provisional 1xx response sent earlier by the UAC.
	</t>		</t>
	<t>		<t>
	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 d ate before the addition of the To and From header field value tags) or more comp lex call parking scenarios. As such, this specification does not deprecate <xref target="RFC4916" format="default"/> "from-change" behavior, nor does it provide an update for it for STIR -- that is left for future work.		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 d ate before the addition of the To and From header field value tags) or more comp lex call parking scenarios. As such, this specification does not deprecate the " from-change" behavior in <xref target="RFC4916" format="default"/>, nor does it provide an update for it for STIR -- that is left for future work.
	</t>		</t>
	</section>		</section>
	<section anchor="IANA" numbered="true" toc="default">		<section anchor="IANA" numbered="true" toc="default">
	<name>IANA Considerations</name>		<name>IANA Considerations</name>
	<t>This specification defines a new PASSporT type for the "Personal Assert ion Token (PASSporT) Extensions" registry defined in <xref target="RFC8225" form at="default"/>, which resides at <eref target="https://www.iana.org/assignments/ passport/"/>:</t>		<t>This specification defines a new PASSporT type for the "Personal Assert ion Token (PASSporT) Extensions" registry <xref target="RFC8225" format="default "/>, which resides at <eref brackets="angle" target="https://www.iana.org/assign ments/passport/"/>:</t>
	<dl>		<dl>
	<dt>ppt value</dt>		<dt>ppt value:</dt>
	<dd>"rsp"</dd>		<dd>rsp</dd>
	<dt>Reference</dt>		<dt>Reference:</dt>
	<dd>[RFCThis], <xref target="rsp" format="default"/></dd>		<dd>RFC 9970, <xref target="rsp" format="default"/></dd>
	</dl>		</dl>
	</section>		</section>
	<section anchor="priv" numbered="true" toc="default">		<section anchor="priv" numbered="true" toc="default">
	<name>Privacy Considerations</name>		<name>Privacy Considerations</name>
	<t>		<t>
	Note that sending connected identity can reveal information about the c alled 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, particul ar in business-to-consumer calling cases. From a user experience perspective, th is would likely work similarly to current systems for sharing numbers, names, an d even pictures from calling parties to called parties -- users have considerabl e 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 enterpri ses than by individual users.		Note that sending connected identity can reveal information about the c alled 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, particul ar in business-to-consumer calling cases. From a user experience perspective, th is would likely work similarly to current systems for sharing numbers, names, an d even pictures from calling parties to called parties -- users have considerabl e 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 enterpri ses than by individual users.
	</t>		</t>
	</section>		</section>
	<section anchor="Security" numbered="true" toc="default">		<section anchor="Security" numbered="true" toc="default">
	<name>Security Considerations</name>		<name>Security Considerations</name>
	<t>		<t>
	The security considerations of <xref target="RFC8224" format="default"/ > and <xref target="RFC8225" format="default"/> apply to the use of the "rsp" PA SSporT. In general, a PASSporT of type "rsp" has similar security properties to a <xref target="RFC8946" format="default"/> diversion ("div") PASSporT. Relying parties leverage a "rsp" PASSporT to determine the recipient of a request, and a s with "div," the "dest" element of an "rsp" PASSporT is signed, rather than the "orig" element.		The security considerations of <xref target="RFC8224" format="default"/ > and <xref target="RFC8225" format="default"/> apply to the use of the "rsp" PA SSporT. In general, a PASSporT of type "rsp" has similar security properties to a diversion ("div") PASSporT <xref target="RFC8946" format="default"/>. Relying parties leverage a "rsp" PASSporT to determine the recipient of a request, and a s with "div", the "dest" element of an "rsp" PASSporT is signed rather than the "orig" element.
	</t>		</t>
	<t>		<t>
	The major threat that "rsp" addresses is the impersonation of a SIP res ponse or mid-dialog/dialog-terminating request. For the latter, this might inclu de forging a BYE for a denial-of-service attack, or, for example, forging a re-I NVITE 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 dialo g-forming response that appears to the caller to initiate a dialog with the inte nded destination. The "rsp" mechanism uses PASSporTs to provide a non-repudiable assurance of the signer of such responses and requests.		The major threat that "rsp" addresses is the impersonation of a SIP res ponse or mid-dialog/dialog-terminating request. For the latter, this might inclu de forging a BYE for a denial-of-service attack or, for example, forging a re-IN VITE that negotiates media channels controlled by an attacker. For the former, s ome 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 inten ded destination. The "rsp" mechanism uses PASSporTs to provide a non-repudiable assurance of the signer of such responses and requests.
	</t>		</t>
	<t>		<t>
	The value of a "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" field of the "rsp" PASSp orT. For STIR certificates that use Service Provider Codes (SPCs), effectively t he relying party knows the network operator who is vouching for that "rsp". This in turn enables traceback and similar mitigations.		The value of a "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 t o sign responses/requests for the number in the "dest" claim of the "rsp" PASSpo rT. For STIR certificates that use Service Provider Codes (SPCs), effectively th e relying party knows the network operator who is vouching for that "rsp". This in turn enables traceback and similar mitigations.
	</t>		</t>
	<t>		<t>
	As was mentioned in <xref target="div" format="default"/>, 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" m echanism, any necessary policy controls can prevent the sending of "rsp" when th at service logic must be protected.		As mentioned in <xref target="div" format="default"/>, the use of "div" along with "rsp" in responses may reveal the service logic of diversions to cal ling parties. However, since the called party ultimately invokes the "rsp" mecha nism, any necessary policy controls can prevent the sending of "rsp" when that s ervice logic must be protected.
	</t>		</t>
	<t>		<t>
	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 authenticati on, called parties have adequate means to authorize the source of requests and d isregard spoofs intended to trigger amplification attacks.		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 authenticati on, called parties have adequate means to authorize the source of requests and d isregard spoofs intended to trigger amplification attacks.
	</t>		</t>
	</section>		</section>
	</middle>		</middle>
	<!-- *****BACK MATTER ***** -->
	<back>		<back>
	<!-- References split into informative and normative -->
	<!-- There are 2 ways to insert reference entries from the citation librarie
	s:
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (
	as shown)
	2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml
	"?> here
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x
	ml")
	Both are cited textually in the same manner: by using xref elements.
	If you use the PI option, xml2rfc will, by default, try to find included fil
	es in the same
	If you use the PI option, xml2rfc will, by default, try to find included fil
	es in the same
	directory as the including file. You can also define the XML_LIBRARY environ
	ment variable
	with a value containing a set of directories to search. These can be either
	in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).-->
	<references>		<references>
	<name>References</name>		<name>References</name>
	<references>		<references>
	<name>Normative References</name>		<name>Normative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2 119.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 174.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 261.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 261.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 262.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 262.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 224.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 224.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 225.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 225.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 916.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 916.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 311.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 311.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 946.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 946.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 862.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8 862.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 725.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3 725.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.3325.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.33 25.xml"/>
	</references>		</references>
	<references>		<references>
	<name>Informative References</name>		<name>Informative References</name>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 475.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9 475.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 116.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6 116.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 552.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5 552.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 474.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4 474.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 375.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7 375.xml"/>
	<xi:include href="https://bib.ietf.org/public/rfc/bibxml/referenc e.RFC.7340.xml"/>		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.73 40.xml"/>
	</references>		</references>
	</references>		</references>
	<section anchor="Acknowledgments" numbered="false" toc="default">		<section anchor="Acknowledgments" numbered="false" toc="default">
	<name>Acknowledgments</name>		<name>Acknowledgments</name>
	<t>We would like to thank Russ Housley, Jonathan Rosenberg, and Orie Steel e for their contributions to this specification.</t>		<t>We would like to thank <contact fullname="Russ Housley"/>, <contact ful lname="Jonathan Rosenberg"/>, and <contact fullname="Orie Steele"/> for their co ntributions to this specification.</t>
	</section>		</section>
	</back>		</back>
			<!-- [rfced] Abbreviations
			a) How should SDP be expanded in this document? As "Session Description Protocol
			" or "Service Demarcation Point"?
			b) We have added expansions for the following abbreviation(s) per Section 3.6 of
			RFC 7322 ("RFC Style Guide"). Please review each expansion in the document care
			fully to ensure correctness.
			Provisional Response Acknowledgement (PRACK)
			Personal Assertion Token (PASSporT)
			-->
			<!-- [rfced] Terminology
			a) How is "rsp" pronounced? We ask in order to choose the appropriate indefinite
			article for it to follow (i.e., "a" or "an"). We see both of the following form
			s in the document:
			a "rsp"
			an "rsp"
			b) We see both "identity" (lowercase) and "Identity" (capitalized) used in this
			document. The lowercase form is used consistently in the context of "connected i
			dentity", and the capitalized form is used consistently in the context of "Ident
			ity header field".
			However, we see the following inconsistency. May we update to use the lowercase
			form?
			Identity mechanism - 1 instance
			identity mechanism - 2 instances
			Also, the capitalized form is used in the following sentences. Is this correct,
			or should the lowercase form be used here?
			Original:
			This document updates prior guidance on the "connected identity" problem
			to reflect the changes to SIP Identity that accompanied STIR ...
			...
			While a mid-dialog request in the backwards direction (e.g., UPDATE)
			can be signed with Identity like any other SIP request, ...
			-->
			<!-- [rfced] Please review the "Inclusive Language" portion of the online
			Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
			and let us know if any changes are needed. Updates of this nature typically
			result in more precise language, which is helpful for readers.
			Note that our script did not flag any words in particular, but this should
			still be reviewed as a best practice.
			In addition, please consider whether "traditional" should be updated for clarity
			.
			While the NIST website <https://web.archive.org/web/20250214092458/https://www.n
			ist.gov/nist-research-library/nist-technical-series-publications-author-instruct
			ions#table1>
			indicates that "tradition" is potentially biased, it is also ambiguous.
			"Traditional" is a subjective term, as it is not the same for everyone.
			Original:
			The Secure Telephone Identity Revisited (STIR) framework,
			however, provides no means for determining the identity of the called
			party in a traditional telephone-calling scenario.
			...
			In a traditional telephone call, the called party receives an
			alerting signal and can make a decision about whether or not to pick
			up a phone.
			-->
	</rfc>		</rfc>
End of changes. 60 change blocks.
	160 lines changed or deleted		320 lines changed or added
This html diff was produced by rfcdiff 1.48.