rfc9888xml2.original.xml		rfc9888.xml
	<?xml version="1.0" encoding="US-ASCII"?>		<?xml version='1.0' encoding='UTF-8'?>
	<!--
	vim:et:ts=2:sw=2:spell:spelllang=en:tw=80
	<!-- This template is for creating an Internet Draft using xml2rfc,
	which is available here: http://xml.resource.org. -->
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.2119.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	<!ENTITY RFC7340 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7340.xml">
	<!ENTITY RFC8224 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8224.xml">
	<!ENTITY RFC8225 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8225.xml">
	<!ENTITY RFC8226 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8226.xml">
	<!ENTITY RFC8816 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8816.xml">
	<!ENTITY RFC8816 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8816.xml">
	<!ENTITY RFC9060 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.9060.xml">
	<!ENTITY RFC7258 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7258.xml">
	<!ENTITY RFC8588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8588.xml">
	<!ENTITY RFC9325 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.9325.xml">
	<!ENTITY RFC9110 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.9110.xml">
			<!DOCTYPE rfc [
			<!ENTITY nbsp "&#160;">
			<!ENTITY zwsp "&#8203;">
			<!ENTITY nbhy "&#8209;">
			<!ENTITY wj "&#8288;">
	]>		]>
	<!--?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?-->
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<!--?rfc strict="yes" ?-->
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="no" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="no" ?>
	<!-- keep one blank line between list items -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc category="std" docName="draft-ietf-stir-servprovider-oob-08"
	ipr="trust200902">
	<!-- 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-servprovider-oob-08" number="9888" consensus="true" ipr="trust200902" ob soletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocD epth="4" symRefs="true" sortRefs="true" version="3">
	<front>		<front>
	<!-- The abbreviated title is used in the page header - it is only necessary		<title abbrev="Service Provider OOB">Out-of-Band Secure Telephone Identity R
	if the		evisited (STIR) for Service Providers</title>
	full title is longer than 39 characters -->
	<title abbrev="Service Provider OOB">Out-of-Band STIR for Service Providers<		<!-- [rfced] We had the following questions/comments about the
	/title>		document title:
	<author initials="J." surname="Peterson" fullname="Jon Peterson">		a) Please note that the title of the document has been updated as
	<organization abbrev="TransUnion">TransUnion</organization>		follows:
	<address>
	<email>jon.peterson@transunion.com</email>
	</address>
	</author>
	<date year="2025" />		Abbreviations have been expanded per Section 3.6 of RFC 7322 ("RFC
			Style Guide"). Please review.
	<!-- <area>		Original:
	ART		Out-of-Band STIR for Service Providers
	</area>-->
			Current:
			Out-of-Band Secure Telephone Identity Revisited (STIR) for Service
			Providers
			b) Should "Framework" or something be added after (STIR) (once
			expanded, it doesn't seem like a noun anymore...). See also our
			change to the first sentence of the Introduction.
			Perhaps:
			Out-of-Band Secure Telephone Identity Revisited (STIR) Framework for
			Service Providers
			-->
			<seriesInfo name="RFC" value="9888"/>
			<author initials="J." surname="Peterson" fullname="Jon Peterson">
			<organization abbrev="TransUnion">TransUnion</organization>
			<address>
			<email>jon.peterson@transunion.com</email>
			</address>
			</author>
			<date year="2025" month="October"/>
			<area>ART</area>
			<workgroup>stir</workgroup>
	<keyword>SIP</keyword>		<keyword>SIP</keyword>
	<abstract>		<abstract>
	<t>		<t>
	The Secure Telephone Identity Revisited (STIR) framework defines means of carryi		The Secure Telephone Identity Revisited (STIR) framework defines means of carryi
	ng its Personal Assertion Tokens (PASSporTs) either in-band, within the headers		ng its Personal Assertion Tokens (PASSporTs) either in-band, within the headers
	of a Session Initiation Protocol (SIP) request, or out-of-band, through a servic		of a Session Initiation Protocol (SIP) request, or out-of-band, through a servic
	e that stores PASSporTs for retrieval by relying parties. This specification def		e that stores PASSporTs for retrieval by relying parties. This specification def
	ines a way that the out-of-band conveyance of PASSporTs can be used to support l		ines a way that the out-of-band conveyance of PASSporTs can be used to support l
	arge service providers, for cases in which in-band STIR conveyance is not univer		arge service providers for cases in which in-band STIR conveyance is not univers
	sally available.		ally available.
	</t>		</t>
	</abstract>		</abstract>
	</front>		</front>
	<middle>		<middle>
	<section anchor="intro" title="Introduction">		<section anchor="intro" numbered="true" toc="default">
	<t>		<name>Introduction</name>
	<xref target="RFC8224">Secure Telephone Identity Revisited (STIR)</xref> prov		<t>
	ides a cryptographic assurance of the identity of calling parties in order to pr		The Secure Telephone Identity Revisited (STIR) <xref target="RFC8224" format=
	event impersonation,		"default"></xref> framework provides a cryptographic assurance of the identity o
	which is a key enabler of unwanted robocalls, swatting, vishing, voicemail ha		f calling parties in order to prevent impersonation,
	cking, and similar attacks (see <xref target="RFC7340"/>). The STIR <xref target		which is a key enabler of unwanted robocalls, swatting, vishing, voicemail ha
	="RFC8816">out-of-band</xref> framework enables the delivery of <xref target="RF		cking, and similar attacks (see <xref target="RFC7340" format="default"/>). The
	C8225">PASSporT</xref> objects through a Call Placement Service (CPS), rather th		STIR out-of-band <xref target="RFC8816" format="default"></xref> framework enabl
	an carrying them within a signaling protocol such as SIP. Out-of-band conveyance		es the delivery of PASSporT <xref target="RFC8225" format="default"></xref> obje
	is valuable when end-to-end SIP delivery of calls is partly or entirely unavail		cts through a Call Placement Service (CPS), rather than carrying them within a s
	able due to network border policies, calls routinely transiting a gateway to the		ignaling protocol such as SIP. Out-of-band conveyance is valuable when end-to-en
	Public Switched Telephone Network (PSTN), or similar circumstances.		d SIP delivery of calls is partly or entirely unavailable due to network border
	</t><t>		policies, calls routinely transiting a gateway to the Public Switched Telephone
	While out-of-band STIR can be implemented as an open Internet service, it the		Network (PSTN), or similar circumstances.
	n requires complex security and privacy measures to enable the CPS function with		</t>
	out allowing the CPS to collect data about the parties placing calls. This speci		<t>
	fication describes CPS implementations that act specifically on behalf of servic		While out-of-band STIR can be implemented as an open Internet service, it req
	e providers who will be processing the calls that STIR secures, and thus who wil		uires complex security and privacy measures to enable the CPS function without a
	l necessarily know the parties communicating, so an alternative security archite		llowing the CPS to collect data about the parties placing calls. This specificat
	cture becomes possible. These functions may be crucial to the adoption of STIR i		ion describes CPS implementations that act specifically on behalf of service pro
	n some environments, like legacy non-IP telephone networks, where in-band transm		viders who will be processing the calls that STIR secures and, thus, who will ne
	ission of PASSporTs may not be feasible.		cessarily know the parties communicating, so an alternative security architectur
	</t><t>		e becomes possible. These functions may be crucial to the adoption of STIR in so
			me environments, like legacy non-IP telephone networks, where in-band transmissi
			on of PASSporTs may not be feasible.
			</t>
			<t>
	Environments that might support this flavor of STIR out-of-band include carri ers, large enterprises, call centers, or any Internet service that aggregates on behalf of a large number of telephone endpoints. That last case may include PST N gateway or interexchange or international transit providers.		Environments that might support this flavor of STIR out-of-band include carri ers, large enterprises, call centers, or any Internet service that aggregates on behalf of a large number of telephone endpoints. That last case may include PST N gateway or interexchange or international transit providers.
	</t>		</t>
			</section>
			<section numbered="true" toc="default">
			<name>Terminology</name>
			<t>
			The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
			IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
			NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>
			RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
			"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
			be interpreted as
			described in BCP&nbsp;14 <xref target="RFC2119"/> <xref target="RFC8174"/>
			when, and only when, they appear in all capitals, as shown here.
			</t>
	</section>		</section>
			<section anchor="arch" numbered="true" toc="default">
			<name>Service Provider Deployment Architecture for Out-of-Band STIR</name>
			<t>
			The architecture in this specification assumes that every participating s
			ervice provider is associated with one or more designated CPS instances. A servi
			ce provider's CPS serves as a place where callers or, in some cases, gateways ca
			n deposit a PASSporT when attempting to place a call to a subscriber of the dest
			ination service provider; if the caller's domain supports in-band STIR, this can
			be done at the same time as an in-band STIR call is placed. The terminating ser
			vice provider could operate the CPS themselves, or a third party could operate t
			he CPS on the destination's behalf. This model does not assume a monolithic CPS
			that acts on behalf of all service providers, nor does it prohibit multiple ser
			vice providers from sharing a CPS provider. Moreover, a particular CPS can be a
			logically distributed entity compromised of several geographically distant entit
			ies that flood PASSporTs among themselves to support an anycast-like service.
			</t>
			<t>
			The process of locating a destination CPS and submitting a PASSporT natur
			ally requires Internet connectivity to the CPS. If the CPS is deployed in the te
			rminating service provider network, any such network connectivity could instead
			be leveraged by a caller to initiate a SIP session, during which in-band STIR co
			uld be used normally. Therefore, the applicability of this architecture is to th
			ose cases where, for whatever reason, SIP requests cannot reliably convey PASSpo
			rTs end-to-end, but an HTTP transaction can reliably be sent to the CPS from an
			out-of-band authentication service (OOB-AS). It is hoped that as IP connectivity
			between telephone providers increases, there will be less need for an out-of-ba
			nd mechanism, but it can serve as a fallback mechanism in cases where service pr
			oviders cannot predict whether end-to-end delivery of SIP calls will occur.
			</t>
			</section>
			<section anchor="adv" numbered="true" toc="default">
			<name>Advertising a CPS</name>
			<t>
			If more than one CPS exists for a given deployment, there will need to be
			some means of discovering CPSs, either administratively or programmatically. Ma
			ny service providers have bilateral agreements to peer with one another; in thos
			e environments, identifying their respective CPSs could be a simple matter of pr
			ovisioning. A consortium of service providers could agree to choose from a list
			of available CPS providers, say. But in more pluralist environments, some mechan
			ism is needed to discover the CPS associated with the target of a call.
			</t>
			<t>
			In order to allow the CPS chosen by a service provider to be discovered secu
			rely, this specification defines a CPS advertisement. Effectively, a CPS adverti
			sement is a document
			that contains the URL of a CPS as well as any information needed to dete
			rmine which PASSporTs should be submitted to that CPS (e.g., Service Provider Co
			des (SPCs) or telephone number ranges). An advertisement may be signed with a ST
			IR <xref target="RFC8226" format="default"/> credential or another credential th
			at is trusted by the participants in a given STIR environment. The advantage to
			signing with STIR certificates is that they contain a "TNAuthList" value indicat
			ing the telephone network resources that a service provider controls. This infor
			mation can be matched with a TNAuthList value in the CPS advertisement to determ
			ine whether the signer has the authority to advertise a particular CPS as the pr
			oper destination for PASSporTs.
			</t>
			<t>
			The format of a service provider CPS advertisement consists of a simple JS
			ON object containing one or more pairs of TNAuthList values pointing to the URIs
			of CPSs, for example:</t>
			<t>{ "0-1234":"https://cps.example.com" }</t>
			<t>The format of this is a hyphen-separated concatenation of each <xref ta
			rget="RFC8226" format="default"/> TNAuthList TNEntry value ("0" for SPC, "1" for
			telephone number range, "2" for individual telephone number) with the correspon
			ding TNAuthList value. Note for case "1", telephone number ranges are expressed
			by a starting telephone number followed by a count, and the count itself; they a
			re hyphen-separated from the TN (e.g., "1-15714341000-99"). An advertisement can
			contain multiple such ranges by adding more pairs. CPS URIs <bcp14>MUST</bcp14>
			be HTTPS URIs (<xref target="RFC9110" sectionFormat="comma" section="4.2.2"/>).
			These CPS URIs <bcp14>SHOULD</bcp14> be
			publicly reachable as service providers cannot usually anticipate all of
			the potential callers that might want to connect with them; however, in more con
			strained environments, they <bcp14>MAY</bcp14> be only reachable over a closed n
			etwork.
			</t>
			<t>
			Advertising an SPC may be inappropriate in environments where an originat
			ing domain has no ready means to determine whether a given called telephone numb
			er falls within the scope of an SPC (such as a national routing database that ma
			ps telephone numbers to SPCs). In such environments, TN-based advertisements cou
			ld enable discovery instead. Also, note that PASSporTs can be used to sign commu
			nication where the "orig" and/or "dest" are not telephone numbers as such, but i
			nstead URI-based identifiers; typically, these PASSporTs would not be signed by
			a certificate as described in <xref target="RFC8226" format="default"/> and any
			future specification would be required to identify URI-based prefixes for CPS ad
			vertisements.
			</t>
			<t>
			CPS advertisements could be made available through existing or new databa
			ses, potentially aggregated across multiple service providers and distributed to
			call originators as necessary. They could be discovered during the call routing
			process, including through a DNS lookup. They could be shared through a distrib
			uted database among the participants in a multilateral peering arrangement.
			</t>
			<t>
			An alternative to CPS advertisements that may be usable in some environme
			nts is adding a field to STIR certificates as described in <xref target="RFC8226
			" format="default"/> identifying the CPS URI issued to individual service provid
			ers. As these certificates are themselves
			signed by a Certificate Authority (CA) and contain their own TNAuthList,
			the URI would be bound securely to the proper telephone network identifiers. As
			STIR assumes a community of relying parties who trust these credentials, this me
			thod perhaps best mirrors the trust model required to allow a CPS to authorize P
			ASSporT submission and retrieval.
			</t>
			</section>
			<section anchor="store" numbered="true" toc="default">
			<name>Submitting a PASSporT</name>
			<t>
			Submitting a PASSporT to a CPS as specified in the STIR <xref target="RFC881
			6" format="default">out-of-band framework</xref> requires security measures that
			are intended to prevent the CPS from learning the identity of the caller (or ca
			llee) to the degree possible. However, in this service provider case, the CPS is
			operated by the service provider of the callee (or an entity operating on their
			behalf) and, as such, the information that appears in the PASSporT is redundant
			with call signaling that the terminating party will receive anyway (see <xref t
			arget="Security" format="default"/> for potential data minimization concerns). T
			herefore, the service provider out-of-band framework does not attempt to conceal
			the identity of the originating or terminating party from the CPS.
			</t>
			<t>
			An out-of-band authentication service (OOB-AS) forms a secure connection wit
			h the target CPS. This may happen at the time a call is being placed or it may b
			e a persistent connection if there is a significant volume of traffic sent over
			this interface. The OOB-AS <bcp14>SHOULD</bcp14> authenticate itself to the CPS
			via mutual TLS (see <xref target="RFC9325" format="default"/>) using its STIR cr
			edential <xref target="RFC8226" format="default"/>, the same one it would use to
			sign calls; this helps mitigate the risk of flooding that more-open OOB impleme
			ntations may face. Furthermore, the use of mutual TLS prevents attackers from re
			playing captured PASSporTs to the CPS. A CPS makes its own policy decision as to
			whether it will accept calls from a particular OOB-AS, and at what volumes.
			</t>
			<t>
			A CPS can use this mechanism to authorize service providers who already h
			old STIR credentials to submit PASSporTs to a CPS, but alternative mechanisms wo
			uld be required for any entities that do not hold a STIR credential, including g
			ateway or transit providers who want to submit PASSporTs. See <xref target="gate
			waying" format="default"/> for more on their behavior.
			</t>
			<t>
			Service provider out-of-band PASSporTs do not need to be encrypted for st
			orage at the CPS, although the use of TLS to prevent eavesdropping on the connec
			tion between the CPS and OOB-ASs is <bcp14>REQUIRED</bcp14>. PASSporTs will typi
			cally be submitted to the CPS at the time they are created by an AS; if the PASS
			porT is also being used for in-band transit within a SIP request, the PASSporT c
			an be submitted to the CPS before or after the SIP request is sent, at the discr
			etion of the originating domain. An OOB-AS <bcp14>MUST</bcp14> implement a Repre
			sentational State Transfer (REST) interface to submit PASSporTs to the CPS as de
			scribed in <xref target="RFC8816" sectionFormat="comma" section="9"/>. PASSporTs
			persist at the CPS for as long as is required for them to be retrieved (see <xr
			ef target="retrieval"/>) but, in any event, for no longer than the freshness int
			erval of the PASSporT itself (a maximum of sixty seconds).
			</t>
			</section>
			<section anchor="retrieval" numbered="true" toc="default">
			<name>PASSporT Retrieval</name>
	<section title="Terminology">		<t>
			The STIR out-of-band framework <xref target="RFC8816" format="default"></
			xref> proposes two means by which called parties can acquire PASSporTs out-of-ba
			nd: through a retrieval interface or a subscription interface. In the service pr
			ovider context, where many calls to or from the same number may pass through a C
			PS simultaneously, an out-of-band-capable verification service (OOB-VS) may ther
			efore operate in one of two modes: it can either pull PASSporTs from the CPS aft
			er calls arrive or receive push notifications from the CPS for incoming calls.
			</t>
			<t>
			CPS implementations <bcp14>MUST</bcp14> support pulling of the PASSporTs
			via the REST flow described in <xref target="RFC8816" sectionFormat="comma" sect
			ion="9"/>. In the pull model, a terminating service provider polls the CPS via i
			ts OOB-VS after having received a call for which the call signaling does not its
			elf carry a PASSporT. Exactly how a CPS determines which PASSporTs an OOB-VS is
			eligible to receive over this interface is a matter of local policy. If a CPS se
			rves 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 col
			ocated or effectively operated as a consolidated system. In a multi-provider env
			ironment, the STIR credential of the terminating domain can be used by the CPS t
			o 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 the use of
			the STIR credential to sign a token that is submitted to the CPS by the retriev
			ing OOB-VS. Note that a multi-provider CPS will need to inspect the "dest" eleme
			nt of a PASSporT to determine which OOB-VS should receive the PASSporT.
			</t>
			<t>
			In a push model, an OOB-VS could, for example, subscribe to a range of telep
			hone numbers or SPCs, 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 pot
			ential arrival of a PASSporT at the OOB-VS. The exact timing of this, and its in
			teraction with the substitution attack described in <xref target="RFC8816" secti
			onFormat="comma" section="7.4"/>, is left for future work.
			</t>
			</section>
			<section anchor="gatewaying" numbered="true" toc="default">
			<name>Gateways</name>
			<t>
			In some deployment architectures, gateways might perform a function that
			interfaces with a CPS for the retrieval or storage of PASSporTs, especially in c
			ases when in-band STIR service providers need to exchange secure calls with prov
			iders that can only be reached by STIR out-of-band. For example, a closed networ
			k of in-band STIR providers may send SIP INVITEs to a gateway in front of a trad
			itional PSTN tandem that services a set of legacy service providers. In that env
			ironment, a gateway might extract a PASSporT from an in-band SIP INVITE and stor
			e it in a CPS that was established to handle requests for one or more legacy pro
			viders, who, in turn, consume those PASSporTs through an OOB-VS to assist in rob
			ocall mitigation and similar functions.
			</t>
			<t>
			The simplest way to implement a gateway performing this sort of function
			for a service provider CPS system is to issue credentials to the gateway that al
			low it to act on behalf of the legacy service providers it supports: this would
			allow it to both add PASSporTs to the CPS acting on behalf of the legacy provide
			rs and also to create PASSporTs for in-band STIR conveyance from the legacy-prov
			iders to terminating service providers in the closed STIR network. For example,
			a service provider could issue a delegate certificate <xref target="RFC9060" for
			mat="default"/> for this purpose.
			</t>
			</section>
			<section anchor="IANA" numbered="true" toc="default">
			<name>IANA Considerations</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD",		<t>This document has no IANA actions.</t>
	"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this d
	ocument
	are to be interpreted as described in BCP 14 <xref target="RFC2119"/> <xref targ
	et="RFC8174"/> when, and only when, they appear in all capitals, as shown here.<
	/t>
	</section>		</section>
			<section anchor="privacy" numbered="true" toc="default">
			<name>Privacy Considerations</name>
			<t>
			The analysis of out-of-band STIR in the "Privacy Considerations" section of <xre
			f target="RFC8816" format="default"/> differs considerably from this document. P
			er <xref target="intro" format="default"/>, this specification was motivated in
			part by choosing a different privacy architecture than <xref target="RFC8816" fo
			rmat="default"/>, one in which the CPS is operated by a service provider who is
			a party to the call itself and, thus, would independently have access to the cal
			l metadata captured in a PASSporT.
			</t>
			<t>
			That said, in cases where a third-party service operates the verification servic
			e function on behalf of a carrier, that third-party service would indeed be priv
			y to this metadata. It is a fairly common situation for third-party services to
			receive this sort of metadata to perform tasks related to billing, security, num
			ber translation, and so on; existing data governance agreements could be readily
			applied to the out-of-band STIR use case.
			</t>
			<t>
			Finally, note that PASSporTs are extensible tokens, and it is conceivable that t
			hey might contain data that is not otherwise carried in SIP signaling or that wo
			uld ordinarily be considered a component of call metadata. Any such extensions m
			ight have specific interactions with the privacy of both in-band and out-of-band
			STIR that their specifications would need to elaborate.
			</t>
			</section>
			<section anchor="Security" numbered="true" toc="default">
			<name>Security Considerations</name>
	<section anchor="arch" title="Service Provider Deployment Architecture fo		<!--[rfced] We had a few questions about the following sentence:
	r Out-of-Band STIR">
	<t>
	The architecture in this specification assumes that every participating s
	ervice provider is associated with one or more designated CPS instances. A servi
	ce provider's CPS serves as a place where callers, or in some cases gateways, ca
	n deposit a PASSporT when attempting to place a call to a subscriber of the dest
	ination service provider; if the caller's domain supports in-band STIR, this can
	be done at the same time as an in-band STIR call is placed. The terminating ser
	vice provider could operate the CPS themselves, or a third party could operate t
	he CPS on the destination's behalf. This model does not assume a monolithic CPS
	that acts on behalf of all service providers, nor does it prohibit multiple ser
	vice providers from sharing a CPS provider. Moreover, a particular CPS can be a
	logically distributed entity compromised of several geographically distant entit
	ies that flood PASSporTs among themselves to support an anycast-like service.
	</t><t>
	The process of locating a destination CPS and submitting a PASSporT natur
	ally requires Internet connectivity to the CPS. If the CPS is deployed in the te
	rminating service provider network, any such network connectivity could instead
	be leveraged by a caller to initiate a SIP session, during which in-band STIR co
	uld be used normally. The applicability of this architecture is therefore to tho
	se cases where, for whatever reason, SIP requests cannot reliably convey PASSpor
	Ts end-to-end, but an HTTP transaction can reliably be sent to the CPS from an o
	ut-of-band authentication service (OOB-AS). It is hoped that as IP connectivity
	between telephone providers increases, there will be less need for an out-of-ban
	d mechanism, but it can serve as a fallback mechanism in cases where service pro
	viders cannot predict whether end-to-end delivery of SIP calls will occur.
	</t>
	</section>
	<section anchor="adv" title="Advertising a CPS">		Original:
	<t>		Moreover, any additional information included in a PASSporT which is
	If more than one CPS exists for a given deployment, there will need to be		not strictly redundant with the contents of a SIP request increases
	some means of discovering CPSs, either administratively or programmatically. Ma		data collection concerns; while baseline [RFC8225] PASSporTs only
	ny service providers have bilateral agreements to peer with one another, and in		contain information otherwise in the SIP request.
	those environments, identifying their respective CPS's could be a simple matter
	of provisioning. A consortium of service providers could agree to choose from a
	list of available CPS providers, say. But in more pluralist environments, some m
	echanism is needed to discover the CPS associated with the target of a call.
	</t><t>
	In order to allow the CPS chosen by a service provider to be discovered secu
	rely, this specification defines a CPS advertisement. Effectively, a CPS adverti
	sement is a document
	which contains the URL of a CPS, as well as any information needed to de
	termine which PASSporTs should be submitted to that CPS (e.g., Service Provider
	Codes (SPCs) or telephone number ranges). An advertisement may be signed with a
	STIR <xref target="RFC8226"/> credential, or another credential that is trusted
	by the participants in a given STIR environment. The advantage to signing with S
	TIR certificates is that they contain a "TNAuthList" value indicating the teleph
	one network resources that a service provider controls. This information can be
	matched with a TNAuthList value in the CPS advertisement to determine whether th
	e signer has the authority to advertise a particular CPS as the proper destinati
	on for PASSporTs.
	</t><t>
	The format of a service provider CPS advertisement consists of a simple J
	SON object containing one or more pairs of TNAuthList values pointing to the URI
	s of CPSs, e.g. { "0-1234":"https://cps.example.com" }. The format of this is a
	hyphen-separated concatenation of each <xref target="RFC8226"/> TNAuthList TNEnt
	ry value ("0" for SPC, "1" for telephone number range, "2" for individual teleph
	one number) with the corresponding TNAuthList value. Note for in case "1", telep
	hone number ranges are expressed by a starting telephone number followed by a co
	unt, and the count itself is here also by hyphen-separated from the TN (e.g., "1
	-15714341000-99"). An advertisement can contain multiple such ranges by adding m
	ore pairs. CPS URIs MUST be HTTPS URIs <xref target="RFC9110"/> (Section 4.2.2).
	These CPS URIs SHOULD be
	publicly reachable, as service providers cannot usually anticipate all of
	the potential callers that might want to connect with them, but in more constra
	ined environments, they MAY be only reachable over a closed network.
	</t><t>
	Advertising an SPC may be inappropriate in environments where an originat
	ing domain has no ready means to determine whether a given called telephone numb
	er falls within the scope of an SPC (such as a national routing database that ma
	ps telephone numbers to SPCs). In such environments, TN-based advertisements cou
	ld enable discovery instead. Also, note that PASSporTs can be used to sign commu
	nication where the "orig" and/or "dest" are not telephone numbers as such, but i
	nstead URI-based identifiers; these PASSporTs typically would not be signed by a
	n <xref target="RFC8226"/> certificate, and future specification would be requir
	ed to identify URI-based prefixes for CPS advertisements.
	</t><t>
	CPS advertisements could be made available through existing or new databa
	ses, potentially aggregated across multiple service providers and distributed to
	call originators as necessary. They could be discovered during the call routing
	process, including through a DNS lookup. They could be shared through a distrib
	uted database among the participants in a multilateral peering arrangement.
	</t><t>
	An alternative to CPS advertisements that may be usable in some environme
	nts is adding a field to STIR <xref target="RFC8226"/> certificates identifying
	the CPS URI issued to individual service providers. As these certificates are th
	emselves
	signed by a CA and contain their own TNAuthList, the URI would be bound s
	ecurely to the proper telephone network identifiers. As STIR assumes a community
	of relying parties who trust these credentials, this method perhaps best mirror
	s the trust model required to allow a CPS to authorize PASSporT submission and r
	etrieval.
	</t>
	</section>
	<section anchor="store" title="Submitting a PASSporT">		a) Please help us clarify the subject of "which". Is it "information"
	<t>		or is it "PASSporT"?
	Submitting a PASSporT to a CPS as specified in the STIR <xref target="RFC881
	6">out-of-band framework</xref> requires security measures that are intended to
	prevent the CPS from learning the identity of the caller (or callee) to the degr
	ee possible. In this service provider case, however, the CPS is operated by the
	service provider of the callee (or an entity operating on their behalf), and as
	such the information that appears in the PASSporT is redundant with call signali
	ng that the terminating party will receive anyway (see <xref target="Security"/>
	for potential data minimization concerns). Therefore, the service provider out-
	of-band framework does not attempt to conceal the identity of the originating or
	terminating party from the CPS.
	</t><t>
	An out-of-band authentication service (OOB-AS) forms a secure connection wit
	h 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 significant volume of traffic sent over
	this interface. The OOB-AS SHOULD authenticate itself to the CPS via mutual TLS
	(see <xref target="RFC9325"/>) using its STIR credential <xref target="RFC8226"
	/>, the same one it would use to sign calls; this helps mitigate the risk of flo
	oding that more open OOB implementations may face. Furthermore, the use of mutua
	l TLS prevents attackers from replaying captured PASSporTs to the CPS. A CPS mak
	es its own policy decision as to whether it will accept calls from a particular
	OOB-AS, and at what volumes.
	</t><t>
	A CPS can use this mechanism to authorize service providers who already h
	old STIR credentials to submit PASSporTs to a CPS, but alternative mechanisms wo
	uld be required for any entities that do not hold a STIR credential, including g
	ateway or transit providers who want to submit PASSporTs. See <xref target="gate
	waying"/> below for more on their behavior.
	</t><t>
	Service provider out-of-band PASSporTs do not need to be encrypted for st
	orage at the CPS, although the use of transport-layer security to prevent eavesd
	ropping on the connection between the CPS and OOB-ASs is REQUIRED. PASSporTs wil
	l typically be submitted to the CPS at the time they are created by an AS; if th
	e PASSporT is also being used for in-band transit within a SIP request, the PASS
	porT can be submitted to the CPS before or after the SIP request is sent, at the
	discretion of the originating domain. An OOB-AS MUST implement a REST interface
	to submit PASSporTs to the CPS as described in <xref target="RFC8816"/> Section
	9. PASSporTs persist at the CPS for as long as is required for them to be retri
	eved (see the next section), but in any event for no longer than the freshness i
	nterval of the PASSporT itself (a maximum of sixty seconds).
	</t>
	</section>
	<section anchor="retrieval" title="PASSporT Retrieval">		b) Could the "while" be removed? This seems to be further
	<t>		information, not contrasting information?
	The STIR <xref target="RFC8816">out-of-band framework</xref> proposes two
	means by which called parties can acquire PASSporTs out-of-band: through a retr
	ieval interface, or a subscription interface. In the service provider context, w
	here many calls to or from the same number may pass through a CPS simultaneously
	, an out-of-band capable verification service (OOB-VS) may therefore operate in
	one of two modes: it can either pull PASSporTs from the CPS after calls arrive o
	r receive push notifications from the CPS for incoming calls.
	</t><t>
	CPS implementations MUST support pulling of the PASSpoRTs via the REST fl
	ow described in <xref target="RFC8816"/> Section 9. In the pull model, a termina
	ting service provider polls the CPS via its OOB-VS after having received a call
	for which the call signaling does not itself carry a PASSporT. Exactly how a CPS
	determines which PASSporTs an OOB-VS is eligible to receive over this interface
	is a matter of local policy. If a CPS serves only one service provider, then al
	l PASSporTs submitted to the CPS are made available to the OOB-VS of that provid
	er; indeed, the CPS and OOB-VS may be colocated or effectively operated as a con
	solidated system. In a multi-provider environment, the STIR credential of the te
	rminating domain can be used by the CPS to determine the range of TNAuthLists fo
	r which an OOB-VS is entitled to receive PASSporTs; this may be through a mechan
	ism like mutual TLS, or through using the STIR credential to sign a token that i
	s 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.
	</t><t>
	In a push model, an OOB-VS could for example subscribe to a range of telepho
	ne numbers or SPCs, which will be directed to that OOB-VS by the CPS (provided t
	he OOB-VS is authorized to receive them by the CPS). PASSporT might be sent to t
	he OOB-VS either before or after unsigned call signaling has been received by th
	e terminating domain. In either model, the terminating side may need to delay re
	ndering a call verification indicator when alerting, in order to await the poten
	tial arrival of a PASSporT at the OOB-VS. The exact timing of this, and its inte
	raction with the substitution attack described in <xref target="RFC8816"/> Secti
	on 7.4, is left for future work.
	</t>
	</section>
	<section anchor="gatewaying" title="Gateways">		c) Please clarify "only contain information otherwise in the SIP
	<t>		request". Does this mean only redundant information?
	In some deployment architectures, gateways might perform a function that
	interfaces with a CPS for the retrieval or storage of PASSporTs, especially in c
	ases when in-band STIR service providers need to exchange secure calls with prov
	iders that can only be reached by STIR out-of-band. For example, a closed networ
	k of in-band STIR providers may send SIP INVITEs to a gateway in front of a trad
	itional PSTN tandem that services a set of legacy service providers. In that env
	ironment, a gateway might extract a PASSporT from an in-band SIP INVITE and stor
	e it in a CPS that was established to handle requests for one or more legacy pro
	viders, who in turn consume those PASSporTs through an OOB-VS to assist in roboc
	all mitigation and similar functions.
	</t><t>
	The simplest way to implement a gateway performing this sort of function
	for a service provider CPS system is to issue credentials to the gateway that al
	low it to act on behalf of the legacy service providers it supports: this would
	allow it to both add PASSporTs to the CPS acting on behalf of the legacy provide
	rs and also to create PASSporTs for in-band STIR conveyance from the legacy-prov
	iders to terminating service providers in the closed STIR network. For example,
	a service provider could issue a delegate certificate <xref target="RFC9060"/> f
	or this purpose.
	</t>
	</section>
	<section anchor="Acknowledgments" title="Acknowledgments">		Perhaps:
	<t>We would like to thank Alex Fenichel for contributing to this specifica		Moreover, in a PASSporT, any additional information that is not
	tion.</t>		strictly redundant with the contents of a SIP request increases data
	</section>		collection concerns; baseline [RFC8225] PASSporTs only contain
			information redundant with the SIP request.
	<section anchor="IANA" title="IANA Considerations">		-->
	<t>This memo includes no request to IANA.</t>
	</section>
	<section anchor="privacy" title="Privacy Considerations">
	<t>		<t>
	The analysis of out-of-band STIR in the Privacy Considerations of <xref target="		The security considerations of <xref target="RFC8816" format="default"/
	RFC8816"/> differs considerably from this document. Per <xref target="intro"/>,		> apply to this document, including concerns about potential denial-of-service v
	this specification was motivated in part by choosing a different privacy archite		ectors and traffic analysis. However, that specification's model focused a great
	cture than <xref target="RFC8816"/>, one in which the CPS is operated by a servi		deal on the privacy implications of uploading PASSporTs to a third-party web se
	ce provider who is a party to the call itself, and thus would independently have		rvice. This document mitigates those concerns by making the CPS one of the parti
	access to the call metadata captured in a PASSporT.		es to call setup (or an entity contractually acting on their behalf). That said,
	</t><t>		any architecture in which PASSporTs are shared with a federated or centralized
	That said, in cases where a third-party service operates the verification servic		CPS raises potential concerns about data collection <xref target="RFC7258" forma
	e function on behalf of a carrier, that third party service would indeed be priv		t="default"/>. Moreover, any additional information included in a PASSporT that
	y to this metadata. That said, it is a fairly common situation for third party s		is not strictly redundant with the contents of a SIP request increases data coll
	ervices to receive this sort of metadata to perform tasks related to billing, se		ection concerns; while baseline <xref target="RFC8225" format="default"/> PASSpo
	curity, number translation, and so on, and existing data governance agreements c		rTs only contain information otherwise in the SIP request. Existing and future e
	ould be readily applied to the out-of-band STIR use case.		xtensions (e.g., the "origid" field described in <xref target="RFC8588" format="
	</t><t>		default"/>) might leak further information.
	Finally, note that PASSporTs are extensible tokens, and it is conceivable that t		</t>
	hey might contain data that is not otherwise carried in SIP signaling or that wo
	uld ordinarily be considered a component of call metadata. Any such extensions m
	ight have specific interactions with the privacy of both in-band and out-of-band
	STIR which their specifications would need to elaborate.
	</t>
	</section>
	<section anchor="Security" title="Security Considerations">
	<t>		<t>
	The Security Considerations of <xref target="RFC8816"/> apply to this d		Unlike <xref target="RFC8816" format="default"/>, this document propose
	ocumen, including concerns about potential denial-of-service vectors and traffic		s the use of STIR certificates to authenticate transactions with a CPS as well a
	analysis. However, that specification's model focused a great deal on the priva		s signatures for CPS advertisements. This presumes an environment where STIR cer
	cy implications of uploading PASSporTs to a third-party web service. This draft		tificates are issued by trust anchors that are already trusted by the CPS, poten
	mitigates those concerns by making the CPS one of the parties to call setup (or		tially to gateways and similar services. Common STIR deployments use Service Pro
	an entity contractually acting on their behalf). That said, any architecture in		vider Codes (SPCs) instead of telephone number ranges to identify service provid
	which PASSporTs are shared with a federated or centralized CPS raises potential		ers today; determining whether a given SPC entitles a service provider to access
	concerns about data collection <xref target="RFC7258"/>. Moreover, any additiona		PASSporTs for a given telephone number is not trivial, but is a necessary compo
	l information included in a PASSporT which is not strictly redundant with the co		nent of this CPS architecture. Otherwise, if anyone with a STIR certificate were
	ntents of a SIP request increases data collection concerns; while baseline <xref		able to publish or access PASSporTs for any telephone number, this could lead t
	target="RFC8225"/> PASSporTs only contain information otherwise in the SIP requ		o an undesirable environment where effectively anyone with a STIR certificate co
	est. Existing and future extensions (e.g. <xref target="RFC8588"/> "origid" fiel		uld acquire PASSporTs for calls in progress to any service provider.
	d) might leak further information.		</t>
	</t><t>
	Unlike <xref target="RFC8816"/>, this document proposes the use of STIR
	certificates to authenticate transactions with a CPS as well as signatures for
	CPS advertisements. This presumes an environment where STIR certificates are iss
	ued by trust anchors which are already trusted by the CPS, potentially to gatewa
	ys and similar services. Common STIR deployments use Service Provider Codes (SPC
	s) instead of telephone number ranges to identify service providers today; deter
	mining 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. Otherwise, if anyone with a STIR certificate were able to publish
	or access PASSporTs for any telephone number, this could lead to an undesirable
	environment where effectively anyone with a STIR certificate could acquire PASS
	porTs for calls in progress to any service provider.
	</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		<references>
	s:		<name>References</name>
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (		<references>
	as shown)		<name>Normative References</name>
	2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
	"?> here		119.xml"/>
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.x		<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
	ml")		174.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
			226.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			816.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			325.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			110.xml"/>
			</references>
			<references>
			<name>Informative References</name>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			340.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
			060.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
			258.xml"/>
			<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
			588.xml"/>
			</references>
			</references>
	Both are cited textually in the same manner: by using xref elements.		<section anchor="Acknowledgments" numbered="false" toc="default">
	If you use the PI option, xml2rfc will, by default, try to find included fil		<name>Acknowledgments</name>
	es in the same		<t>Thank you to <contact fullname="Alex Fenichel"/> for contributing to th
	directory as the including file. You can also define the XML_LIBRARY environ		is specification.</t>
	ment variable		</section>
	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 title="Normative References">		<!-- [rfced] Please review the "Inclusive Language" portion of the
	&RFC2119;		online Style Guide
	&RFC8174;		<https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
	&RFC8224;		and let us know if any changes are needed. Updates of this
	&RFC8225;		nature typically result in more precise language, which is
	&RFC8226;		helpful for readers.
	&RFC8816;
	&RFC9325;
	&RFC9110;
	</references>
	<references title="Informative References">
	&RFC7340;
	&RFC9060;
	&RFC7258;
	&RFC8588;
	</references>		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 "tradition" should be updated for
			clarity. While the NIST website
			<https://web.archive.org/web/20250214092458/https://www.nist.gov/nist-research-l
			ibrary/nist-technical-series-publications-author-instructions#table1>
			indicates that this term is potentially biased, it is also ambiguous.
			"Tradition" is a subjective term, as it is not the same for everyone.
			Original:
			..may send SIP INVITEs to a gateway in front of a traditional PSTN...
			-->
			<!-- [rfced] We had the following questions/comments about
			abbreviation use throughout the document:
			a) FYI - We have added expansions for abbreviations upon first use per
			Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review each
			expansion in the document carefully to ensure correctness.
			b) FYI - We will update to use the abbreviation only after the first
			use for the following abbreviations in accordance with
			https://www.rfc-editor.org/styleguide/part2/#exp_abbrev:
			OOB-AS
			SPC
			-->
			<!--[rfced] Please review the use of citation tags throughout the
			document: some are read as part of the sentence while others are
			not syntactically relevant.
			Please see https://www.rfc-editor.org/styleguide/part2/#citation_usage
			for further information/guidance.-->
			<!--[rfced] We see the following similar terminology used throughout
			the document. Please let us know if/how we may make these
			consistent.
			STIR credential vs. STIR certificate vs. STIR [RFC8816] certificate
			out-of-band STIR vs. STIR out-of-band vs. STIR out-of-band framework [RFC8816]
			-->
	</back>		</back>
	</rfc>		</rfc>
End of changes. 33 change blocks.
	415 lines changed or deleted		478 lines changed or added
This html diff was produced by rfcdiff 1.48.