< draft-ietf-stir-servprovider-oob-01.txt		draft-ietf-stir-servprovider-oob-02.txt >
	Network Working Group J. Peterson		Network Working Group J. Peterson
	Internet-Draft Neustar		Internet-Draft Neustar
	Intended status: Informational February 22, 2021		Intended status: Informational 21 April 2022
	Expires: August 26, 2021		Expires: 23 October 2022
	Out-of-Band STIR for Service Providers		Out-of-Band STIR for Service Providers
	draft-ietf-stir-servprovider-oob-01		draft-ietf-stir-servprovider-oob-02
	Abstract		Abstract
	The Secure Telephone Identity Revisited (STIR) framework defines		The Secure Telephone Identity Revisited (STIR) framework defines
	means of carrying its Persona Assertion Tokens (PASSporTs) either in-		means of carrying its Persona Assertion Tokens (PASSporTs) either in-
	band, within the headers of a SIP request, or out-of-band, through a		band, within the headers of a SIP request, or out-of-band, through a
	service that stores PASSporTs for retrieval by relying parties. This		service that stores PASSporTs for retrieval by relying parties. This
	specification defines a way that the out-of-band conveyance of		specification defines a way that the out-of-band conveyance of
	PASSporTs can be used to support large service providers, for cases		PASSporTs can be used to support large service providers, for cases
	in which in-band STIR conveyance is not universally available.		in which in-band STIR conveyance is not universally available.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at https://datatracker.ietf.org/drafts/current/.		Drafts is at https://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 26, 2021.		This Internet-Draft will expire on 23 October 2022.
	Copyright Notice		Copyright Notice
	Copyright (c) 2021 IETF Trust and the persons identified as the		Copyright (c) 2022 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents (https://trustee.ietf.org/
	(https://trustee.ietf.org/license-info) in effect on the date of		license-info) in effect on the date of publication of this document.
	publication of this document. Please review these documents		Please review these documents carefully, as they describe your rights
	carefully, as they describe your rights and restrictions with respect		and restrictions with respect to this document. Code Components
	to this document. Code Components extracted from this document must		extracted from this document must include Revised BSD License text as
	include Simplified BSD License text as described in Section 4.e of		described in Section 4.e of the Trust Legal Provisions and are
	the Trust Legal Provisions and are provided without warranty as		provided without warranty as described in the Revised BSD License.
	described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Service Provider Deployment Architecture for Out-of-Band STIR 3		3. Service Provider Deployment Architecture for Out-of-Band
	4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 3		STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 3
			4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 4
	5. Submitting a PASSporT . . . . . . . . . . . . . . . . . . . . 5		5. Submitting a PASSporT . . . . . . . . . . . . . . . . . . . . 5
	6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 6		6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 6
	7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 7		7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
	10. Security Considerations . . . . . . . . . . . . . . . . . . . 7		10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
	11. Informative References . . . . . . . . . . . . . . . . . . . 7		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9		11.1. Normative References . . . . . . . . . . . . . . . . . . 8
			11.2. Informative References . . . . . . . . . . . . . . . . . 9
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	STIR [RFC8224] provides a cryptographic assurance of the identity of		STIR [RFC8224] provides a cryptographic assurance of the identity of
	calling parties in order to prevent impersonation, which is a key		calling parties in order to prevent impersonation, which is a key
	enabler of unwanted robocalls, swatting, vishing, voicemail hacking,		enabler of unwanted robocalls, swatting, vishing, voicemail hacking,
	and similar attacks (see [RFC7340]). The STIR out-of-band		and similar attacks (see [RFC7340]). The STIR out-of-band [RFC8816]
	[I-D.ietf-stir-oob] framework enables the delivery of PASSporT		framework enables the delivery of PASSporT [RFC8225] objects through
	[RFC8225] objects through a Call Placement Service (CPS), rather than		a Call Placement Service (CPS), rather than carrying them within a
	carrying them within a signaling protocol such as SIP. Out-of-band		signaling protocol such as SIP. Out-of-band conveyance is valuable
	conveyance is valuable when end-to-end SIP delivery of calls is		when end-to-end SIP delivery of calls is partly or entirely
	partly or entirely unavailable due to network border policies, calls		unavailable due to network border policies, calls routinely
	routinely transitting a gateway to the PSTN, or similar		transitting a gateway to the PSTN, or similar circumstances.
	circumstances.
	While out-of-band STIR can be implemented as an open Internet		While out-of-band STIR can be implemented as an open Internet
	service, it then requires complex security measures to enable the CPS		service, it then requires complex security measures to enable the CPS
	function without allowing the CPS to collect data about the parties		function without allowing the CPS to collect data about the parties
	placing calls. This specification describes CPS implementations that		placing calls. This specification describes CPS implementations that
	act specifically on behalf of service providers who will be		act specifically on behalf of service providers who will be
	processing the calls that STIR secures, and who thus will learn about		processing the calls that STIR secures, and who thus will learn about
	the parties to communication independently, so an alternative		the parties to communication independently, so an alternative
	security architecture becomes possible. These functions may be		security architecture becomes possible. These functions may be
	crucial to the adoption of STIR in some environments, like mobile		crucial to the adoption of STIR in some environments, like mobile
	skipping to change at page 3, line 33 ¶		skipping to change at page 3, line 50 ¶
	third party could operate the CPS on the destination's behalf. This		third party could operate the CPS on the destination's behalf. This
	model does not assume a monolithic CPS that acts on behalf of all		model does not assume a monolithic CPS that acts on behalf of all
	service providers, but nor does it prohibit multiple service		service providers, but nor does it prohibit multiple service
	providers from sharing a CPS provider. Moreover, a particular CPS		providers from sharing a CPS provider. Moreover, a particular CPS
	can be a logically distributed entity compromised of several		can be a logically distributed entity compromised of several
	geographically distant entities that flood PASSporTs among themselves		geographically distant entities that flood PASSporTs among themselves
	to support an anycast-like service.		to support an anycast-like service.
	The process of locating a destination CPS and submitting a PASSporT		The process of locating a destination CPS and submitting a PASSporT
	naturally requires Internet connectivity to the CPS. If the CPS is		naturally requires Internet connectivity to the CPS. If the CPS is
	deployed in the terminating service provider network, that network		deployed in the terminating service provider network, any such
	connectivity could be leveraged by a caller to initiate a SIP		network connectivity could instead be leveraged by a caller to
	session, during which in-band STIR could be used normally. The		initiate a SIP session, during which in-band STIR could be used
	applicability of this architecture is therefore to those cases where,		normally. The applicability of this architecture is therefore to
	for whatever reason, SIP requests cannot reliably convey PASSporTs		those cases where, for whatever reason, SIP requests cannot reliably
	end-to-end, but an HTTP transaction can reliably be sent to the		convey PASSporTs end-to-end, but an HTTP transaction can reliably be
	destination network from the out-of-band authentication service (OOB-		sent to the CPS from the out-of-band authentication service (OOB-AS).
	AS). It is hoped that as IP connectivity between telephone providers		It is hoped that as IP connectivity between telephone providers
	increases, there will be less need for an out-of-band mechanism, but		increases, there will be less need for an out-of-band mechanism, but
	it can serve as a fallback mechanism in cases where service providers		it can serve as a fallback mechanism in cases where service providers
	cannot predict whether end-to-end delivery of SIP calls will occur.		cannot predict whether end-to-end delivery of SIP calls will occur.
	4. Advertising a CPS		4. Advertising a CPS
	If more than one CPS exists for a given deployment, there will need		If more than one CPS exists for a given deployment, there will need
	to be some means of discovering CPSs, either administratively or		to be some means of discovering CPSs, either administratively or
	programmatically. Many services providers have bilateral agreements		programmatically. Many services providers have bilateral agreements
	to peer with one another, and in those environments, identifying		to peer with one another, and in those environments, identifying
	skipping to change at page 5, line 8 ¶		skipping to change at page 5, line 25 ¶
	these certificates are themselves signed by a CA, and contain their		these certificates are themselves signed by a CA, and contain their
	own TNAuthList, the URI would be bound securely to the proper		own TNAuthList, the URI would be bound securely to the proper
	telephone network identifiers. As STIR assumes a community of		telephone network identifiers. As STIR assumes a community of
	relying parties who trust these credentials, this method perhaps best		relying parties who trust these credentials, this method perhaps best
	mirrors the trust model required to allow a CPS to authorize PASSporT		mirrors the trust model required to allow a CPS to authorize PASSporT
	submission and retrieval.		submission and retrieval.
	5. Submitting a PASSporT		5. Submitting a PASSporT
	Submitting a PASSporT to a CPS as specified in the STIR out-of-band		Submitting a PASSporT to a CPS as specified in the STIR out-of-band
	framework [I-D.ietf-stir-oob] requires security measures which are		framework [RFC8816] requires security measures which are intended to
	intended to prevent the CPS from learning the identity of the caller		prevent the CPS from learning the identity of the caller (or callee),
	(or callee), to the degree possible. In this service provider case,		to the degree possible. In this service provider case, however, the
	however, the CPS is operated by the service provider of the callee		CPS is operated by the service provider of the callee (or an entity
	(or an entity operating on their behalf), and as such the information		operating on their behalf), and as such the information that appears
	that appears in the PASSporT is redundant with call signaling that		in the PASSporT is redundant with call signaling that the terminating
	the terminating party will receive anyway. Therefore, the service		party will receive anyway. Therefore, the service provider out-of-
	provider out-of-band framework does not attempt to conceal the		band framework does not attempt to conceal the identity of the
	identity of the originating or terminating party from the CPS.		originating or terminating party from the CPS.
	An out-of-band authentication service (OOB-AS) forms a secure		An out-of-band authentication service (OOB-AS) forms a secure
	connection with the target CPS. This may happen at the time a call		connection with the target CPS. This may happen at the time a call
	is being placed, or it may be a persistent connection, if there is a		is being placed, or it may be a persistent connection, if there is a
	significant volume of traffic sent over this interface. The OOB-AS		significant volume of traffic sent over this interface. The OOB-AS
	SHOULD authenticate itself to the CPS via mutual TLS using its STIR		SHOULD authenticate itself to the CPS via mutual TLS using its STIR
	credential [RFC8226], the same one it would use to sign calls; this		credential [RFC8226], the same one it would use to sign calls; this
	helps mitigate the risk of flooding that more open OOB		helps mitigate the risk of flooding that more open OOB
	implementations may face. Furthermore, use of mutual TLS prevents		implementations may face. Furthermore, use of mutual TLS prevents
	attackers from replaying captured PASSporTs to the CPS. A CPS makes		attackers from replaying captured PASSporTs to the CPS. A CPS makes
	skipping to change at page 5, line 43 ¶		skipping to change at page 6, line 13 ¶
	See Section 7 below for more on their behavior.		See Section 7 below for more on their behavior.
	Service provider out-of-band PASSporTs do not need to be encrypted		Service provider out-of-band PASSporTs do not need to be encrypted
	for storage at the CPS, although use of transport-layer security to		for storage at the CPS, although use of transport-layer security to
	prevent eavesdropping on the connection between the CPS and OOB-ASs		prevent eavesdropping on the connection between the CPS and OOB-ASs
	is REQUIRED. PASSporTs will typically be submitted to the CPS at the		is REQUIRED. PASSporTs will typically be submitted to the CPS at the
	time they are created by an AS; if the PASSporT is also being used		time they are created by an AS; if the PASSporT is also being used
	for in-band transit within a SIP request, the PASSporT can be		for in-band transit within a SIP request, the PASSporT can be
	submitted to the CPS before or after the SIP request is sent, at the		submitted to the CPS before or after the SIP request is sent, at the
	discretion of the originating domain. An OOB-AS will use a REST		discretion of the originating domain. An OOB-AS will use a REST
	interface to submit PASSporTs to the CPS as described in		interface to submit PASSporTs to the CPS as described in [RFC8816]
	[I-D.ietf-stir-oob] Section 9 [more TBD]. PASSporTs persist at the		Section 9. PASSporTs persist at the CPS for as long as is required
	CPS for as long as is required for them to be retrieved (see the next		for them to be retrieved (see the next section), but in any event for
	section), but in any event for no longer than the freshness interval		no longer than the freshness interval of the PASSporT itself (a
	of the PASSporT itself (a maximum of sixty seconds).		maximum of sixty seconds).
	6. PASSporT Retrieval		6. PASSporT Retrieval
	The STIR out-of-band framework [I-D.ietf-stir-oob] proposes two means		The STIR out-of-band framework [RFC8816] proposes two means that
	that called parties can acquire PASSporTs out-of-band: through a		called parties can acquire PASSporTs out-of-band: through a retrieval
	retrieval interface, or through a subscription interface. In the		interface, or through a subscription interface. In the service
	service provider context, where many calls to or from the same number		provider context, where many calls to or from the same number may
	may pass through a CPS simultaneous, an out-of-band capable		pass through a CPS simultaneously, an out-of-band capable
	verification service may therefore operate in one of two modes: it		verification service (OOB-VS) may therefore operate in one of two
	can either pull PASSporTs from the CPS after calls arrive, or receive		modes: it can either pull PASSporTs from the CPS after calls arrive,
	push notifications from the CPS for incoming calls.		or receive push notifications from the CPS for incoming calls.
	If a CPS serves only one service provider, then all PASSporTs
	submitted to the CPS are made available to the OOB-VS of that
	provider; indeed, the CPS and OOB-VS may be colocated or effectively
	operated as a consolidated system. In a multi-provider environment,
	the STIR credential of the terminating domain can be used by the CPS
	to determine the range of TNAuthLists for which an OOB-VS is entitled
	to receive PASSporTs; this may be through a mechanism like mutual
	TLS, or through using the STIR credential to sign a token that is
	submitted to the CPS by the retrieving OOB-VS. Note that a multi-
	provider CPS will need to inspect the "dest" element of a PASSporT to
	determine which OOB-VS should receive the PASSporT.
	[TBD: Which sub/not protocol to use for the case where the CPS and
	OOB-VS are not composed in a single function?]
	Pulling of PASSporTs from the CPS will follow the basic REST flow		Pulling of PASSporTs from the CPS will follow the basic REST flow
	described in [I-D.ietf-stir-oob] Section 9. Exactly how a CPS		described in [RFC8816] Section 9. In the pull model, a terminating
	determines which PASSporTs an OOB-VS is eligible to receive is a		service provider polls the CPS via its OOB-VS after having received a
	matter of implementation. An OOB-VS could for example subscribe to a		call for those cases in which the call signaling does not itself
	range of telephone numbers, which will be directed to that OOB-VS by		carry a PASSporT. Exactly how a CPS determines which PASSporTs an
	the CPS (provided the OOB-VS is authorized to receive them by the		OOB-VS is eligible to receive over this interface is a matter of
	CPS). In the pull model, a terminating service provider polls the		local policy. If a CPS serves only one service provider, then all
	CPS via its OOB-VS after having received a call, in those cases where		PASSporTs submitted to the CPS are made available to the OOB-VS of
	the call signaling does not itself carry a PASSporT. In the push		that provider; indeed, the CPS and OOB-VS may be colocated or
	model, a PASSporT might be sent to the OOB-VS either before or after		effectively operated as a consolidated system. In a multi-provider
	unsigned call signaling has been received by the terminating domain.		environment, the STIR credential of the terminating domain can be
	Domains using the push model may therefore need to adopt a model		used by the CPS to determine the range of TNAuthLists for which an
	where the display of call verification for alerting is held		OOB-VS is entitled to receive PASSporTs; this may be through a
	momentarily in order to await the potential arrival of a PASSporT at		mechanism like mutual TLS, or through using the STIR credential to
	the OOB-VS. The exact timing of this, and its interaction with the		sign a token that is submitted to the CPS by the retrieving OOB-VS.
	substitution attack described in [I-D.ietf-stir-oob] Section 7.4,		Note that a multi-provider CPS will need to inspect the "dest"
	will be the covered by future versions of this specification.		element of a PASSporT to determine which OOB-VS should receive the
			PASSporT.
			In a push model, an OOB-VS could for example subscribe to a range of
			telephone numbers, which will be directed to that OOB-VS by the CPS
			(provided the OOB-VS is authorized to receive them by the CPS).
			PASSporT might be sent to the OOB-VS either before or after unsigned
			call signaling has been received by the terminating domain. In
			either model, the terminating side may need to delay rendering a call
			verification indicator when alerting, in order to await the potential
			arrival of a PASSporT at the OOB-VS. The exact timing of this, and
			its interaction with the substitution attack described in [RFC8816]
			Section 7.4, is left for future work.
	7. Gateways		7. Gateways
	In some deployment architectures, gateways might perform a function		In some deployment architectures, gateways might perform a function
	that interfaces with a CPS for the retrieval or storage of PASSporTs,		that interfaces with a CPS for the retrieval or storage of PASSporTs,
	especially in cases when in-band STIR service providers need to		especially in cases when in-band STIR service providers need to
	exchange secure calls with providers that can only be reached by STIR		exchange secure calls with providers that can only be reached by STIR
	out-of-band. For example, a closed network of in-band STIR providers		out-of-band. For example, a closed network of in-band STIR providers
	may send SIP INVITEs to a gateway in front of a traditional PSTN		may send SIP INVITEs to a gateway in front of a traditional PSTN
	tandem that services a set of legacy service providers. In that		tandem that services a set of legacy service providers. In that
	skipping to change at page 7, line 28 ¶		skipping to change at page 7, line 34 ¶
	functions.		functions.
	The simplest way to interface a gateway performing this sort of		The simplest way to interface a gateway performing this sort of
	function for a service provider CPS system is to issue credentials to		function for a service provider CPS system is to issue credentials to
	the gateway that allow it to act on behalf of the legacy service		the gateway that allow it to act on behalf of the legacy service
	providers it supports: this would allow it to both add PASSporTs to		providers it supports: this would allow it to both add PASSporTs to
	the CPS acting on behalf of the legacy providers, and also to create		the CPS acting on behalf of the legacy providers, and also to create
	PASSporTs for in-band STIR conveyance from the legacy-providers to		PASSporTs for in-band STIR conveyance from the legacy-providers to
	terminating service providers in the closed STIR network. For		terminating service providers in the closed STIR network. For
	example, a service provider could issue a delegate certificate		example, a service provider could issue a delegate certificate
	[I-D.ietf-stir-cert-delegation] for this purpose.		[RFC9060] for this purpose.
	8. Acknowledgments		8. Acknowledgments
	We would like to thank Alex Fenichel for contributions to this		We would like to thank Alex Fenichel for contributions to this
	specification.		specification.
	9. IANA Considerations		9. IANA Considerations
	This memo includes no request to IANA.		This memo includes no request to IANA.
	10. Security Considerations		10. Security Considerations
	It is the aim of this mechanism to provide		The Security Considerations of [RFC8816] apply to those document as
			well, including concerns about potential denial-of-service vectors
	11. Informative References		and traffic analysis. However, that specification's model focused a
			great deal on the privacy implications of uploading PASSporTs to a
			third-party web service. This draft mitigates those concerns by
			making the CPS one of the two parties to call setup (or an entity
			contractual acting on their behalf). That said, any architecture in
			which PASSporTs are shared with a federated or centralized CPS raises
			potential concerns about data collection [RFC7258].
	[I-D.ietf-stir-cert-delegation]		Unlike [RFC8816], this document proposes the use of STIR certificates
	Peterson, J., "STIR Certificate Delegation", draft-ietf-		to authenticate transactions with a CPS as well as signatures for CPS
	stir-cert-delegation-03 (work in progress), July 2020.		advertisements. This presumes an environment where STIR certificates
			are issued by known trust anchors which are known to the CPS,
			potentially including gateways and similar services. Common STIR
			deployments use Service Provider Codes (SPCs) instead of telephone
			numbers ranges to identify service providers today; determining
			whether a given SPC entitles a service provider to access PASSporTs
			for a given telephone number is not trivial, but is a necessary
			component of this CPS architecture. If anyone with a STIR
			certificate is able to publish or access PASSporTs for any telephone
			number, the potential data collection implications are significant.
			As
	[I-D.ietf-stir-oob]		11. References
	Rescorla, E. and J. Peterson, "STIR Out-of-Band
	Architecture and Use Cases", draft-ietf-stir-oob-07 (work
	in progress), March 2020.
	[I-D.ietf-stir-passport-divert]		11.1. Normative References
	Peterson, J., "PASSporT Extension for Diverted Calls",
	draft-ietf-stir-passport-divert-09 (work in progress),
	July 2020.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119,		Requirement Levels", BCP 14, RFC 2119,
	DOI 10.17487/RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<https://www.rfc-editor.org/info/rfc2119>.		<https://www.rfc-editor.org/info/rfc2119>.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	DOI 10.17487/RFC3261, June 2002,		DOI 10.17487/RFC3261, June 2002,
	<https://www.rfc-editor.org/info/rfc3261>.		<https://www.rfc-editor.org/info/rfc3261>.
	[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
	UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
	2002, <https://www.rfc-editor.org/info/rfc3311>.
	[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
	Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
	2007, <https://www.rfc-editor.org/info/rfc4916>.
	[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data		[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
	Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March		Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March
	2014, <https://www.rfc-editor.org/info/rfc7159>.		2014, <https://www.rfc-editor.org/info/rfc7159>.
	[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
	Telephone Identity Problem Statement and Requirements",
	RFC 7340, DOI 10.17487/RFC7340, September 2014,
	<https://www.rfc-editor.org/info/rfc7340>.
	[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC		[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
	2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,		2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
	May 2017, <https://www.rfc-editor.org/info/rfc8174>.		May 2017, <https://www.rfc-editor.org/info/rfc8174>.
	[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,		[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
	"Authenticated Identity Management in the Session		"Authenticated Identity Management in the Session
	Initiation Protocol (SIP)", RFC 8224,		Initiation Protocol (SIP)", RFC 8224,
	DOI 10.17487/RFC8224, February 2018,		DOI 10.17487/RFC8224, February 2018,
	<https://www.rfc-editor.org/info/rfc8224>.		<https://www.rfc-editor.org/info/rfc8224>.
	[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion		[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
	Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,		Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
	<https://www.rfc-editor.org/info/rfc8225>.		<https://www.rfc-editor.org/info/rfc8225>.
	[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity		[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
	Credentials: Certificates", RFC 8226,		Credentials: Certificates", RFC 8226,
	DOI 10.17487/RFC8226, February 2018,		DOI 10.17487/RFC8226, February 2018,
	<https://www.rfc-editor.org/info/rfc8226>.		<https://www.rfc-editor.org/info/rfc8226>.
			[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
			Revisited (STIR) Out-of-Band Architecture and Use Cases",
			RFC 8816, DOI 10.17487/RFC8816, February 2021,
			<https://www.rfc-editor.org/info/rfc8816>.
			11.2. Informative References
			[RFC3311] Rosenberg, J., "The Session Initiation Protocol (SIP)
			UPDATE Method", RFC 3311, DOI 10.17487/RFC3311, October
			2002, <https://www.rfc-editor.org/info/rfc3311>.
			[RFC4916] Elwell, J., "Connected Identity in the Session Initiation
			Protocol (SIP)", RFC 4916, DOI 10.17487/RFC4916, June
			2007, <https://www.rfc-editor.org/info/rfc4916>.
			[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
			Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
			2014, <https://www.rfc-editor.org/info/rfc7258>.
			[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
			Telephone Identity Problem Statement and Requirements",
			RFC 7340, DOI 10.17487/RFC7340, September 2014,
			<https://www.rfc-editor.org/info/rfc7340>.
			[RFC8946] Peterson, J., "Personal Assertion Token (PASSporT)
			Extension for Diverted Calls", RFC 8946,
			DOI 10.17487/RFC8946, February 2021,
			<https://www.rfc-editor.org/info/rfc8946>.
			[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
			Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
			September 2021, <https://www.rfc-editor.org/info/rfc9060>.
	Author's Address		Author's Address
	Jon Peterson		Jon Peterson
	Neustar, Inc.		Neustar, Inc.
			Email: jon.peterson@team.neustar
	Email: jon.peterson@neustar.biz
End of changes. 22 change blocks.
	115 lines changed or deleted		143 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/