rfc9970v1.txt		rfc9970.txt
	skipping to change at line 18 ¶		skipping to change at line 18 ¶
	Connected Identity for Secure Telephone Identity Revisited (STIR)		Connected Identity for Secure Telephone Identity Revisited (STIR)
	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. However, the Secure Telephone Identity Revisited (STIR)		requests. However, the Secure Telephone Identity Revisited (STIR)
	framework provides no means for determining the identity of the		framework provides no means for determining the identity of the
	called party in a traditional telephone-calling scenario. This		called party in a traditional telephone-calling scenario. This
	document updates prior guidance on the "connected identity" problem		document updates prior guidance on the "connected identity" problem
	to reflect the changes to SIP Identity that accompanied STIR. It		to reflect the changes to SIP identity that accompanied STIR. It
	also considers a revised problem space for connected identity as a		also considers a revised problem space for connected identity as a
	means of detecting calls that have been retargeted to a party		means of detecting calls that have been retargeted to a party
	impersonating the intended destination, as well as the spoofing of		impersonating the intended destination and preventing the spoofing of
	mid-dialog or dialog-terminating events by intermediaries or third		mid-dialog or dialog-terminating events by intermediaries or third
	parties.		parties.
	Status of This Memo		Status of This Memo
	This is an Internet Standards Track document.		This is an Internet Standards Track document.
	This document is a product of the Internet Engineering Task Force		This document is a product of the Internet Engineering Task Force
	(IETF). It represents the consensus of the IETF community. It has		(IETF). It represents the consensus of the IETF community. It has
	received public review and has been approved for publication by the		received public review and has been approved for publication by the
	skipping to change at line 122 ¶		skipping to change at line 122 ¶
	the backwards direction reflect the To header field value of the		the backwards direction reflect the To header field value of the
	dialog-forming request. Under the original rules in [RFC3261], if		dialog-forming request. Under the original rules in [RFC3261], if
	Alice sent a dialog-forming request to Bob, then even if Bob's SIP		Alice sent a dialog-forming request to Bob, then even if Bob's SIP
	service forwarded that dialog-forming request to Carol, Carol would		service forwarded that dialog-forming request to Carol, Carol would
	still be required to put Bob's identity in the From header field		still be required to put Bob's identity in the From header field
	value in any mid-dialog requests in the backwards direction.		value in any mid-dialog requests in the backwards 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 header field [RFC4474].		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. Thus, Carol would not be		the mid-dialog From header field value. Thus, Carol would not be
	able to furnish a key to sign for Bob's identity if Carol wanted to		able to furnish a key to sign for Bob's identity if Carol wanted to
	sign requests in the backwards direction. Carol would, however, be		sign requests in the backwards direction. Carol would, however, be
	able to sign for her own identity in the From header field value if		able to sign for her own identity in the From header field value if
	mid-dialog requests in the backwards direction were permitted to vary		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
	skipping to change at line 239 ¶		skipping to change at line 239 ¶
	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"
	PASSporT [RFC8946], insofar as the certificate that signs a "rsp"		PASSporT [RFC8946], insofar as the certificate that signs an "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 an "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
	Section 7 of [RFC8946] for guidance on authentication redirection.		Section 7 of [RFC8946] for guidance on authentication redirection.
	It is worth noting that at the time [RFC4916] was written, the		It is worth noting that at the time [RFC4916] was written, the
	Identity mechanism was far stricter about what counted as retargeting		identity mechanism was far stricter about what counted as retargeting
	than is described in [RFC8224], which has canonicalization processes		than is described in [RFC8224], which has canonicalization processes
	that 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
	skipping to change at line 296 ¶		skipping to change at line 296 ¶
	the situation, the only way those diversion PASSporTs will be seen by		the situation, the only way those diversion PASSporTs will be seen by
	the calling party is if redirection is used (SIP 3XX responses)		the calling party is if redirection is used (SIP 3XX responses)
	instead of retargeting. Because some network policies aim to conceal		instead of retargeting. Because some network policies aim to conceal
	service logic from the originating party, sending redirections in the		service logic from the originating party, sending redirections in the
	backwards direction is the only currently defined way for secure		backwards direction is the only currently defined way for secure
	indications of redirection to be revealed to the calling party. That		indications of redirection to be revealed to the calling party. That
	in turn would allow the calling user agent to have a strong assurance		in turn would allow the calling user agent to have a strong assurance
	that legitimate entities in the call path caused the request to reach		that legitimate entities in the call path caused the request to reach
	a party that the caller did not anticipate.		a party that the caller did not anticipate.
	This specification introduces another alternative. When sending a		This specification introduces another alternative. When sending an
	"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.
	skipping to change at line 456 ¶		skipping to change at line 456 ¶
	user interface before a call is placed, provide an opportunity to		user interface before a call is placed, provide an opportunity to
	probe what identity would be reached as a destination and potentially		probe what identity would be reached as a destination and potentially
	even to exchange STIR PASSporTs in order to validate whether or not		even to exchange STIR PASSporTs in order to validate whether or not
	the 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 Session Description Protocol (SDP). Similar
	proposed for certain automated systems per [RFC5552]. In the STIR		media-less dialogs have been proposed for certain automated systems
	context, a media-less dialog is established by sending an INVITE with		per [RFC5552]. In the STIR context, a media-less dialog is
	an Identity header field but no SDP. STIR-aware UASes that support		established by sending an INVITE with an Identity header field but no
	this specification, upon receiving an INVITE with no SDP, carrying a		SDP. When a STIR-aware UAS that supports this specification receives
	PASSporT, with a 100rel in the Require header field value, SHOULD		an INVITE that has no SDP, carries a PASSporT, and includes a 100rel
	follow the mechanism described in Section 4 to send a provisional		in the Require header field value, it SHOULD follow the mechanism
	response carrying a PASSporT in the backwards direction. The		described in Section 4 to send a provisional response carrying a
	PASSporT received in the backwards direction could be rendered to the		PASSporT in the backwards direction. The PASSporT received in the
	originating user to help them decide if they want to place the call.		backwards direction could be rendered to the 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 an "rsp" PASSporT type that is sent only
	SIP responses; it MUST NOT be sent in SIP requests. Any "rsp"		in 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 an "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.pem" }		"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 PASSporT is		PASSporT -- the only difference is in semantics, as the PASSporT is
	signed to authenticate the "dest" claim value rather than the "orig".		signed to authenticate the "dest" claim value rather than the "orig".
	skipping to change at line 540 ¶		skipping to change at line 541 ¶
	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 diversion ("div") PASSporT		similar security properties to a diversion ("div") PASSporT
	[RFC8946]. Relying parties leverage a "rsp" PASSporT to determine		[RFC8946]. Relying parties leverage an "rsp" PASSporT to determine
	the recipient of a request, and as with "div", the "dest" element of		the recipient of a request, and as with "div", the "dest" element of
	an "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 an "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" claim 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 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
End of changes. 12 change blocks.
	22 lines changed or deleted		23 lines changed or added
This html diff was produced by rfcdiff 1.48.