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 " "> | ||||
<!ENTITY zwsp "​"> | ||||
<!ENTITY nbhy "‑"> | ||||
<!ENTITY wj "⁠"> | ||||
]> | ]> | |||
<!--?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 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. |