rfc9888.original   rfc9888.txt 
Network Working Group J. Peterson Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft TransUnion Request for Comments: 9888 TransUnion
Intended status: Standards Track 7 July 2025 Category: Standards Track October 2025
Expires: 8 January 2026 ISSN: 2070-1721
Out-of-Band STIR for Service Providers Out-of-Band Secure Telephone Identity Revisited (STIR) for Service
draft-ietf-stir-servprovider-oob-08 Providers
Abstract Abstract
The Secure Telephone Identity Revisited (STIR) framework defines The Secure Telephone Identity Revisited (STIR) framework defines
means of carrying its Personal Assertion Tokens (PASSporTs) either means of carrying its Personal Assertion Tokens (PASSporTs) either
in-band, within the headers of a Session Initiation Protocol (SIP) in-band, within the headers of a Session Initiation Protocol (SIP)
request, or out-of-band, through a service that stores PASSporTs for request, or out-of-band, through a service that stores PASSporTs for
retrieval by relying parties. This specification defines a way that retrieval by relying parties. This specification defines a way that
the out-of-band conveyance of PASSporTs can be used to support large the out-of-band conveyance of PASSporTs can be used to support large
service providers, for cases in which in-band STIR conveyance is not service providers for cases in which in-band STIR conveyance is not
universally available. universally available.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 8 January 2026. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc9888.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology
3. Service Provider Deployment Architecture for Out-of-Band 3. Service Provider Deployment Architecture for Out-of-Band STIR
STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Advertising a CPS
4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 4 5. Submitting a PASSporT
5. Submitting a PASSporT . . . . . . . . . . . . . . . . . . . . 5 6. PASSporT Retrieval
6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 6 7. Gateways
7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 9. Privacy Considerations
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 10. Security Considerations
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 11. References
11. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.2. Informative References
12.1. Normative References . . . . . . . . . . . . . . . . . . 9 Acknowledgments
12.2. Informative References . . . . . . . . . . . . . . . . . 10 Author's Address
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
Secure Telephone Identity Revisited (STIR) [RFC8224] provides a The Secure Telephone Identity Revisited (STIR) [RFC8224] framework
cryptographic assurance of the identity of calling parties in order provides a cryptographic assurance of the identity of calling parties
to prevent impersonation, which is a key enabler of unwanted in order to prevent impersonation, which is a key enabler of unwanted
robocalls, swatting, vishing, voicemail hacking, and similar attacks robocalls, swatting, vishing, voicemail hacking, and similar attacks
(see [RFC7340]). The STIR out-of-band [RFC8816] framework enables (see [RFC7340]). The STIR out-of-band [RFC8816] framework enables
the delivery of PASSporT [RFC8225] objects through a Call Placement the delivery of PASSporT [RFC8225] objects through a Call Placement
Service (CPS), rather than carrying them within a signaling protocol Service (CPS), rather than carrying them within a signaling protocol
such as SIP. Out-of-band conveyance is valuable when end-to-end SIP such as SIP. Out-of-band conveyance is valuable when end-to-end SIP
delivery of calls is partly or entirely unavailable due to network delivery of calls is partly or entirely unavailable due to network
border policies, calls routinely transiting a gateway to the Public border policies, calls routinely transiting a gateway to the Public
Switched Telephone Network (PSTN), or similar circumstances. Switched Telephone Network (PSTN), or similar circumstances.
While out-of-band STIR can be implemented as an open Internet While out-of-band STIR can be implemented as an open Internet
service, it then requires complex security and privacy measures to service, it requires complex security and privacy measures to enable
enable the CPS function without allowing the CPS to collect data the CPS function without allowing the CPS to collect data about the
about the parties placing calls. This specification describes CPS parties placing calls. This specification describes CPS
implementations that act specifically on behalf of service providers implementations that act specifically on behalf of service providers
who will be processing the calls that STIR secures, and thus who will who will be processing the calls that STIR secures and, thus, who
necessarily know the parties communicating, so an alternative will necessarily know the parties communicating, so an alternative
security architecture becomes possible. These functions may be security architecture becomes possible. These functions may be
crucial to the adoption of STIR in some environments, like legacy crucial to the adoption of STIR in some environments, like legacy
non-IP telephone networks, where in-band transmission of PASSporTs non-IP telephone networks, where in-band transmission of PASSporTs
may not be feasible. may not be feasible.
Environments that might support this flavor of STIR out-of-band Environments that might support this flavor of STIR out-of-band
include carriers, large enterprises, call centers, or any Internet include carriers, large enterprises, call centers, or any Internet
service that aggregates on behalf of a large number of telephone service that aggregates on behalf of a large number of telephone
endpoints. That last case may include PSTN gateway or interexchange endpoints. That last case may include PSTN gateway or interexchange
or international transit providers. or international transit providers.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Service Provider Deployment Architecture for Out-of-Band STIR 3. Service Provider Deployment Architecture for Out-of-Band STIR
The architecture in this specification assumes that every The architecture in this specification assumes that every
participating service provider is associated with one or more participating service provider is associated with one or more
designated CPS instances. A service provider's CPS serves as a place designated CPS instances. A service provider's CPS serves as a place
where callers, or in some cases gateways, can deposit a PASSporT when where callers or, in some cases, gateways can deposit a PASSporT when
attempting to place a call to a subscriber of the destination service attempting to place a call to a subscriber of the destination service
provider; if the caller's domain supports in-band STIR, this can be 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 done at the same time as an in-band STIR call is placed. The
terminating service provider could operate the CPS themselves, or a terminating service provider could operate the CPS themselves, or a
third party could operate the CPS on the destination's behalf. This third party could operate the CPS on the destination's behalf. This
model does not assume a monolithic CPS that acts on behalf of all model does not assume a monolithic CPS that acts on behalf of all
service providers, nor does it prohibit multiple service providers service providers, nor does it prohibit multiple service providers
from sharing a CPS provider. Moreover, a particular CPS can be a from sharing a CPS provider. Moreover, a particular CPS can be a
logically distributed entity compromised of several geographically logically distributed entity compromised of several geographically
distant entities that flood PASSporTs among themselves to support an distant entities that flood PASSporTs among themselves to support an
anycast-like service. anycast-like service.
The process of locating a destination CPS and submitting a PASSporT The process of locating a destination CPS and submitting a PASSporT
naturally requires Internet connectivity to the CPS. If the CPS is naturally requires Internet connectivity to the CPS. If the CPS is
deployed in the terminating service provider network, any such deployed in the terminating service provider network, any such
network connectivity could instead be leveraged by a caller to network connectivity could instead be leveraged by a caller to
initiate a SIP session, during which in-band STIR could be used initiate a SIP session, during which in-band STIR could be used
normally. The applicability of this architecture is therefore to normally. Therefore, the applicability of this architecture is to
those cases where, for whatever reason, SIP requests cannot reliably those cases where, for whatever reason, SIP requests cannot reliably
convey PASSporTs end-to-end, but an HTTP transaction can reliably be convey PASSporTs end-to-end, but an HTTP transaction can reliably be
sent to the CPS from an out-of-band authentication service (OOB-AS). sent to the CPS from an out-of-band authentication service (OOB-AS).
It is hoped that as IP connectivity between telephone providers It is hoped that as IP connectivity between telephone providers
increases, there will be less need for an out-of-band mechanism, but increases, there will be less need for an out-of-band mechanism, but
it can serve as a fallback mechanism in cases where service providers it can serve as a fallback mechanism in cases where service providers
cannot predict whether end-to-end delivery of SIP calls will occur. cannot predict whether end-to-end delivery of SIP calls will occur.
4. Advertising a CPS 4. Advertising a CPS
If more than one CPS exists for a given deployment, there will need If more than one CPS exists for a given deployment, there will need
to be some means of discovering CPSs, either administratively or to be some means of discovering CPSs, either administratively or
programmatically. Many service providers have bilateral agreements programmatically. Many service providers have bilateral agreements
to peer with one another, and in those environments, identifying to peer with one another; in those environments, identifying their
their respective CPS's could be a simple matter of provisioning. A respective CPSs could be a simple matter of provisioning. A
consortium of service providers could agree to choose from a list of consortium of service providers could agree to choose from a list of
available CPS providers, say. But in more pluralist environments, available CPS providers, say. But in more pluralist environments,
some mechanism is needed to discover the CPS associated with the some mechanism is needed to discover the CPS associated with the
target of a call. target of a call.
In order to allow the CPS chosen by a service provider to be In order to allow the CPS chosen by a service provider to be
discovered securely, this specification defines a CPS advertisement. discovered securely, this specification defines a CPS advertisement.
Effectively, a CPS advertisement is a document which contains the URL Effectively, a CPS advertisement is a document that contains the URL
of a CPS, as well as any information needed to determine which of a CPS as well as any information needed to determine which
PASSporTs should be submitted to that CPS (e.g., Service Provider PASSporTs should be submitted to that CPS (e.g., Service Provider
Codes (SPCs) or telephone number ranges). An advertisement may be Codes (SPCs) or telephone number ranges). An advertisement may be
signed with a STIR [RFC8226] credential, or another credential that signed with a STIR [RFC8226] credential or another credential that is
is trusted by the participants in a given STIR environment. The trusted by the participants in a given STIR environment. The
advantage to signing with STIR certificates is that they contain a advantage to signing with STIR certificates is that they contain a
"TNAuthList" value indicating the telephone network resources that a "TNAuthList" value indicating the telephone network resources that a
service provider controls. This information can be matched with a service provider controls. This information can be matched with a
TNAuthList value in the CPS advertisement to determine whether the TNAuthList value in the CPS advertisement to determine whether the
signer has the authority to advertise a particular CPS as the proper signer has the authority to advertise a particular CPS as the proper
destination for PASSporTs. destination for PASSporTs.
The format of a service provider CPS advertisement consists of a The format of a service provider CPS advertisement consists of a
simple JSON object containing one or more pairs of TNAuthList values simple JSON object containing one or more pairs of TNAuthList values
pointing to the URIs of CPSs, e.g. { pointing to the URIs of CPSs, for example:
"0-1234":"https://cps.example.com" }. The format of this is a hyphen-
separated concatenation of each [RFC8226] TNAuthList TNEntry value { "0-1234":"https://cps.example.com" }
("0" for SPC, "1" for telephone number range, "2" for individual
telephone number) with the corresponding TNAuthList value. Note for The format of this is a hyphen-separated concatenation of each
in case "1", telephone number ranges are expressed by a starting [RFC8226] TNAuthList TNEntry value ("0" for SPC, "1" for telephone
telephone number followed by a count, and the count itself is here number range, "2" for individual telephone number) with the
also by hyphen-separated from the TN (e.g., "1-15714341000-99"). An corresponding TNAuthList value. Note for case "1", telephone number
advertisement can contain multiple such ranges by adding more pairs. ranges are expressed by a starting telephone number followed by a
CPS URIs MUST be HTTPS URIs [RFC9110] (Section 4.2.2). These CPS count, and the count itself; they are hyphen-separated from the TN
URIs SHOULD be publicly reachable, as service providers cannot (e.g., "1-15714341000-99"). An advertisement can contain multiple
usually anticipate all of the potential callers that might want to such ranges by adding more pairs. CPS URIs MUST be HTTPS URIs
connect with them, but in more constrained environments, they MAY be ([RFC9110], Section 4.2.2). These CPS URIs SHOULD be publicly
only reachable over a closed network. reachable as service providers cannot usually anticipate all of the
potential callers that might want to connect with them; however, in
more constrained environments, they MAY be only reachable over a
closed network.
Advertising an SPC may be inappropriate in environments where an Advertising an SPC may be inappropriate in environments where an
originating domain has no ready means to determine whether a given originating domain has no ready means to determine whether a given
called telephone number falls within the scope of an SPC (such as a called telephone number falls within the scope of an SPC (such as a
national routing database that maps telephone numbers to SPCs). In national routing database that maps telephone numbers to SPCs). In
such environments, TN-based advertisements could enable discovery such environments, TN-based advertisements could enable discovery
instead. Also, note that PASSporTs can be used to sign communication instead. Also, note that PASSporTs can be used to sign communication
where the "orig" and/or "dest" are not telephone numbers as such, but where the "orig" and/or "dest" are not telephone numbers as such, but
instead URI-based identifiers; these PASSporTs typically would not be instead URI-based identifiers; typically, these PASSporTs would not
signed by an [RFC8226] certificate, and future specification would be be signed by a certificate as described in [RFC8226] and any future
required to identify URI-based prefixes for CPS advertisements. specification would be required to identify URI-based prefixes for
CPS advertisements.
CPS advertisements could be made available through existing or new CPS advertisements could be made available through existing or new
databases, potentially aggregated across multiple service providers databases, potentially aggregated across multiple service providers
and distributed to call originators as necessary. They could be and distributed to call originators as necessary. They could be
discovered during the call routing process, including through a DNS discovered during the call routing process, including through a DNS
lookup. They could be shared through a distributed database among lookup. They could be shared through a distributed database among
the participants in a multilateral peering arrangement. the participants in a multilateral peering arrangement.
An alternative to CPS advertisements that may be usable in some An alternative to CPS advertisements that may be usable in some
environments is adding a field to STIR [RFC8226] certificates environments is adding a field to STIR certificates as described in
identifying the CPS URI issued to individual service providers. As [RFC8226] identifying the CPS URI issued to individual service
these certificates are themselves signed by a CA and contain their providers. As these certificates are themselves signed by a
own TNAuthList, the URI would be bound securely to the proper Certificate Authority (CA) and contain their own TNAuthList, the URI
telephone network identifiers. As STIR assumes a community of would be bound securely to the proper telephone network identifiers.
relying parties who trust these credentials, this method perhaps best As STIR assumes a community of relying parties who trust these
mirrors the trust model required to allow a CPS to authorize PASSporT credentials, this method perhaps best mirrors the trust model
submission and retrieval. required to allow a CPS to authorize PASSporT submission and
retrieval.
5. Submitting a PASSporT 5. Submitting a PASSporT
Submitting a PASSporT to a CPS as specified in the STIR out-of-band Submitting a PASSporT to a CPS as specified in the STIR out-of-band
framework [RFC8816] requires security measures that are intended to framework [RFC8816] requires security measures that are intended to
prevent the CPS from learning the identity of the caller (or callee) prevent the CPS from learning the identity of the caller (or callee)
to the degree possible. In this service provider case, however, the to the degree possible. However, in this service provider case, the
CPS is operated by the service provider of the callee (or an entity CPS is operated by the service provider of the callee (or an entity
operating on their behalf), and as such the information that appears operating on their behalf) and, as such, the information that appears
in the PASSporT is redundant with call signaling that the terminating in the PASSporT is redundant with call signaling that the terminating
party will receive anyway (see Section 11 for potential data party will receive anyway (see Section 10 for potential data
minimization concerns). Therefore, the service provider out-of-band minimization concerns). Therefore, the service provider out-of-band
framework does not attempt to conceal the identity of the originating framework does not attempt to conceal the identity of the originating
or terminating party from the CPS. or terminating party from the CPS.
An out-of-band authentication service (OOB-AS) forms a secure An out-of-band authentication service (OOB-AS) forms a secure
connection with the target CPS. This may happen at the time a call connection with the target CPS. This may happen at the time a call
is being placed, or it may be a persistent connection if there is a is being placed or it may be a persistent connection if there is a
significant volume of traffic sent over this interface. The OOB-AS significant volume of traffic sent over this interface. The OOB-AS
SHOULD authenticate itself to the CPS via mutual TLS (see [RFC9325]) SHOULD authenticate itself to the CPS via mutual TLS (see [RFC9325])
using its STIR credential [RFC8226], the same one it would use to using its STIR credential [RFC8226], the same one it would use to
sign calls; this helps mitigate the risk of flooding that more open sign calls; this helps mitigate the risk of flooding that more-open
OOB implementations may face. Furthermore, the use of mutual TLS OOB implementations may face. Furthermore, the use of mutual TLS
prevents attackers from replaying captured PASSporTs to the CPS. A prevents attackers from replaying captured PASSporTs to the CPS. A
CPS makes its own policy decision as to whether it will accept calls CPS makes its own policy decision as to whether it will accept calls
from a particular OOB-AS, and at what volumes. from a particular OOB-AS, and at what volumes.
A CPS can use this mechanism to authorize service providers who A CPS can use this mechanism to authorize service providers who
already hold STIR credentials to submit PASSporTs to a CPS, but already hold STIR credentials to submit PASSporTs to a CPS, but
alternative mechanisms would be required for any entities that do not alternative mechanisms would be required for any entities that do not
hold a STIR credential, including gateway or transit providers who hold a STIR credential, including gateway or transit providers who
want to submit PASSporTs. See Section 7 below for more on their want to submit PASSporTs. See Section 7 for more on their behavior.
behavior.
Service provider out-of-band PASSporTs do not need to be encrypted Service provider out-of-band PASSporTs do not need to be encrypted
for storage at the CPS, although the use of transport-layer security for storage at the CPS, although the use of TLS to prevent
to prevent eavesdropping on the connection between the CPS and OOB- eavesdropping on the connection between the CPS and OOB-ASs is
ASs is REQUIRED. PASSporTs will typically be submitted to the CPS at REQUIRED. PASSporTs will typically be submitted to the CPS at the
the time they are created by an AS; if the PASSporT is also being time they are created by an AS; if the PASSporT is also being used
used for in-band transit within a SIP request, the PASSporT can be for in-band transit within a SIP request, the PASSporT can be
submitted to the CPS before or after the SIP request is sent, at the submitted to the CPS before or after the SIP request is sent, at the
discretion of the originating domain. An OOB-AS MUST implement a discretion of the originating domain. An OOB-AS MUST implement a
REST interface to submit PASSporTs to the CPS as described in Representational State Transfer (REST) interface to submit PASSporTs
[RFC8816] Section 9. PASSporTs persist at the CPS for as long as is to the CPS as described in [RFC8816], Section 9. PASSporTs persist
required for them to be retrieved (see the next section), but in any at the CPS for as long as is required for them to be retrieved (see
event for no longer than the freshness interval of the PASSporT Section 6) but, in any event, for no longer than the freshness
itself (a maximum of sixty seconds). interval of the PASSporT itself (a maximum of sixty seconds).
6. PASSporT Retrieval 6. PASSporT Retrieval
The STIR out-of-band framework [RFC8816] proposes two means by which The STIR out-of-band framework [RFC8816] proposes two means by which
called parties can acquire PASSporTs out-of-band: through a retrieval called parties can acquire PASSporTs out-of-band: through a retrieval
interface, or a subscription interface. In the service provider interface or a subscription interface. In the service provider
context, where many calls to or from the same number may pass through context, where many calls to or from the same number may pass through
a CPS simultaneously, an out-of-band capable verification service a CPS simultaneously, an out-of-band-capable verification service
(OOB-VS) may therefore operate in one of two modes: it can either (OOB-VS) may therefore operate in one of two modes: it can either
pull PASSporTs from the CPS after calls arrive or receive push pull PASSporTs from the CPS after calls arrive or receive push
notifications from the CPS for incoming calls. notifications from the CPS for incoming calls.
CPS implementations MUST support pulling of the PASSpoRTs via the CPS implementations MUST support pulling of the PASSporTs via the
REST flow described in [RFC8816] Section 9. In the pull model, a REST flow described in [RFC8816], Section 9. In the pull model, a
terminating service provider polls the CPS via its OOB-VS after terminating service provider polls the CPS via its OOB-VS after
having received a call for which the call signaling does not itself having received a call for which the call signaling does not itself
carry a PASSporT. Exactly how a CPS determines which PASSporTs an carry a PASSporT. Exactly how a CPS determines which PASSporTs an
OOB-VS is eligible to receive over this interface is a matter of OOB-VS is eligible to receive over this interface is a matter of
local policy. If a CPS serves only one service provider, then all local policy. If a CPS serves only one service provider, then all
PASSporTs submitted to the CPS are made available to the OOB-VS of PASSporTs submitted to the CPS are made available to the OOB-VS of
that provider; indeed, the CPS and OOB-VS may be colocated or that provider; indeed, the CPS and OOB-VS may be colocated or
effectively operated as a consolidated system. In a multi-provider effectively operated as a consolidated system. In a multi-provider
environment, the STIR credential of the terminating domain can be environment, the STIR credential of the terminating domain can be
used by the CPS to determine the range of TNAuthLists for which an used by the CPS to determine the range of TNAuthLists for which an
OOB-VS is entitled to receive PASSporTs; this may be through a OOB-VS is entitled to receive PASSporTs; this may be through a
mechanism like mutual TLS, or through using the STIR credential to mechanism like mutual TLS or through the use of the STIR credential
sign a token that is submitted to the CPS by the retrieving OOB-VS. to sign a token that is submitted to the CPS by the retrieving OOB-
Note that a multi-provider CPS will need to inspect the "dest" 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 element of a PASSporT to determine which OOB-VS should receive the
PASSporT. PASSporT.
In a push model, an OOB-VS could for example subscribe to a range of In a push model, an OOB-VS could, for example, subscribe to a range
telephone numbers or SPCs, which will be directed to that OOB-VS by of telephone numbers or SPCs, which will be directed to that OOB-VS
the CPS (provided the OOB-VS is authorized to receive them by the 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 CPS). PASSporT might be sent to the OOB-VS either before or after
unsigned call signaling has been received by the terminating domain. unsigned call signaling has been received by the terminating domain.
In either model, the terminating side may need to delay rendering a In either model, the terminating side may need to delay rendering a
call verification indicator when alerting, in order to await the call verification indicator when alerting, in order to await the
potential arrival of a PASSporT at the OOB-VS. The exact timing of potential arrival of a PASSporT at the OOB-VS. The exact timing of
this, and its interaction with the substitution attack described in this, and its interaction with the substitution attack described in
[RFC8816] Section 7.4, is left for future work. [RFC8816], Section 7.4, is left for future work.
7. Gateways 7. Gateways
In some deployment architectures, gateways might perform a function In some deployment architectures, gateways might perform a function
that interfaces with a CPS for the retrieval or storage of PASSporTs, that interfaces with a CPS for the retrieval or storage of PASSporTs,
especially in cases when in-band STIR service providers need to especially in cases when in-band STIR service providers need to
exchange secure calls with providers that can only be reached by STIR exchange secure calls with providers that can only be reached by STIR
out-of-band. For example, a closed network of in-band STIR providers out-of-band. For example, a closed network of in-band STIR providers
may send SIP INVITEs to a gateway in front of a traditional PSTN may send SIP INVITEs to a gateway in front of a traditional PSTN
tandem that services a set of legacy service providers. In that tandem that services a set of legacy service providers. In that
environment, a gateway might extract a PASSporT from an in-band SIP environment, a gateway might extract a PASSporT from an in-band SIP
INVITE and store it in a CPS that was established to handle requests INVITE and store it in a CPS that was established to handle requests
for one or more legacy providers, who in turn consume those PASSporTs for one or more legacy providers, who, in turn, consume those
through an OOB-VS to assist in robocall mitigation and similar PASSporTs through an OOB-VS to assist in robocall mitigation and
functions. similar functions.
The simplest way to implement a gateway performing this sort of The simplest way to implement a gateway performing this sort of
function for a service provider CPS system is to issue credentials to function for a service provider CPS system is to issue credentials to
the gateway that allow it to act on behalf of the legacy service the gateway that allow it to act on behalf of the legacy service
providers it supports: this would allow it to both add PASSporTs to providers it supports: this would allow it to both add PASSporTs to
the CPS acting on behalf of the legacy providers and also to create the CPS acting on behalf of the legacy providers and also to create
PASSporTs for in-band STIR conveyance from the legacy-providers to PASSporTs for in-band STIR conveyance from the legacy-providers to
terminating service providers in the closed STIR network. For terminating service providers in the closed STIR network. For
example, a service provider could issue a delegate certificate example, a service provider could issue a delegate certificate
[RFC9060] for this purpose. [RFC9060] for this purpose.
8. Acknowledgments 8. IANA Considerations
We would like to thank Alex Fenichel for contributing to this
specification.
9. IANA Considerations
This memo includes no request to IANA. This document has no IANA actions.
10. Privacy Considerations 9. Privacy Considerations
The analysis of out-of-band STIR in the Privacy Considerations of The analysis of out-of-band STIR in the "Privacy Considerations"
[RFC8816] differs considerably from this document. Per Section 1, section of [RFC8816] differs considerably from this document. Per
this specification was motivated in part by choosing a different Section 1, this specification was motivated in part by choosing a
privacy architecture than [RFC8816], one in which the CPS is operated different privacy architecture than [RFC8816], one in which the CPS
by a service provider who is a party to the call itself, and thus is operated by a service provider who is a party to the call itself
would independently have access to the call metadata captured in a and, thus, would independently have access to the call metadata
PASSporT. captured in a PASSporT.
That said, in cases where a third-party service operates the That said, in cases where a third-party service operates the
verification service function on behalf of a carrier, that third verification service function on behalf of a carrier, that third-
party service would indeed be privy to this metadata. That said, it party service would indeed be privy to this metadata. It is a fairly
is a fairly common situation for third party services to receive this common situation for third-party services to receive this sort of
sort of metadata to perform tasks related to billing, security, metadata to perform tasks related to billing, security, number
number translation, and so on, and existing data governance translation, and so on; existing data governance agreements could be
agreements could be readily applied to the out-of-band STIR use case. readily applied to the out-of-band STIR use case.
Finally, note that PASSporTs are extensible tokens, and it is Finally, note that PASSporTs are extensible tokens, and it is
conceivable that they might contain data that is not otherwise conceivable that they might contain data that is not otherwise
carried in SIP signaling or that would ordinarily be considered a carried in SIP signaling or that would ordinarily be considered a
component of call metadata. Any such extensions might have specific component of call metadata. Any such extensions might have specific
interactions with the privacy of both in-band and out-of-band STIR interactions with the privacy of both in-band and out-of-band STIR
which their specifications would need to elaborate. that their specifications would need to elaborate.
11. Security Considerations 10. Security Considerations
The Security Considerations of [RFC8816] apply to this documen, The security considerations of [RFC8816] apply to this document,
including concerns about potential denial-of-service vectors and including concerns about potential denial-of-service vectors and
traffic analysis. However, that specification's model focused a traffic analysis. However, that specification's model focused a
great deal on the privacy implications of uploading PASSporTs to a great deal on the privacy implications of uploading PASSporTs to a
third-party web service. This draft mitigates those concerns by third-party web service. This document mitigates those concerns by
making the CPS one of the parties to call setup (or an entity making the CPS one of the parties to call setup (or an entity
contractually acting on their behalf). That said, any architecture contractually acting on their behalf). That said, any architecture
in which PASSporTs are shared with a federated or centralized CPS in which PASSporTs are shared with a federated or centralized CPS
raises potential concerns about data collection [RFC7258]. Moreover, raises potential concerns about data collection [RFC7258]. Moreover,
any additional information included in a PASSporT which is not any additional information included in a PASSporT that is not
strictly redundant with the contents of a SIP request increases data strictly redundant with the contents of a SIP request increases data
collection concerns; while baseline [RFC8225] PASSporTs only contain collection concerns; while baseline [RFC8225] PASSporTs only contain
information otherwise in the SIP request. Existing and future information otherwise in the SIP request. Existing and future
extensions (e.g. [RFC8588] "origid" field) might leak further extensions (e.g., the "origid" field described in [RFC8588]) might
information. leak further information.
Unlike [RFC8816], this document proposes the use of STIR certificates Unlike [RFC8816], this document proposes the use of STIR certificates
to authenticate transactions with a CPS as well as signatures for CPS to authenticate transactions with a CPS as well as signatures for CPS
advertisements. This presumes an environment where STIR certificates advertisements. This presumes an environment where STIR certificates
are issued by trust anchors which are already trusted by the CPS, are issued by trust anchors that are already trusted by the CPS,
potentially to gateways and similar services. Common STIR potentially to gateways and similar services. Common STIR
deployments use Service Provider Codes (SPCs) instead of telephone deployments use Service Provider Codes (SPCs) instead of telephone
number ranges to identify service providers today; determining number ranges to identify service providers today; determining
whether a given SPC entitles a service provider to access PASSporTs whether a given SPC entitles a service provider to access PASSporTs
for a given telephone number is not trivial, but is a necessary for a given telephone number is not trivial, but is a necessary
component of this CPS architecture. Otherwise, if anyone with a STIR component of this CPS architecture. Otherwise, if anyone with a STIR
certificate were able to publish or access PASSporTs for any certificate were able to publish or access PASSporTs for any
telephone number, this could lead to an undesirable environment where telephone number, this could lead to an undesirable environment where
effectively anyone with a STIR certificate could acquire PASSporTs effectively anyone with a STIR certificate could acquire PASSporTs
for calls in progress to any service provider. for calls in progress to any service provider.
12. References 11. References
12.1. Normative References 11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
skipping to change at page 10, line 21 skipping to change at line 435
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati, [RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>. 2022, <https://www.rfc-editor.org/info/rfc9325>.
12.2. Informative References 11.2. Informative References
[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>. 2014, <https://www.rfc-editor.org/info/rfc7258>.
[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure [RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements", Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014, RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>. <https://www.rfc-editor.org/info/rfc7340>.
[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token [RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token
(PaSSporT) Extension for Signature-based Handling of (PaSSporT) Extension for Signature-based Handling of
Asserted information using toKENs (SHAKEN)", RFC 8588, Asserted information using toKENs (SHAKEN)", RFC 8588,
DOI 10.17487/RFC8588, May 2019, DOI 10.17487/RFC8588, May 2019,
<https://www.rfc-editor.org/info/rfc8588>. <https://www.rfc-editor.org/info/rfc8588>.
[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR) [RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060, Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/info/rfc9060>. September 2021, <https://www.rfc-editor.org/info/rfc9060>.
Acknowledgments
Thank you to Alex Fenichel for contributing to this specification.
Author's Address Author's Address
Jon Peterson Jon Peterson
TransUnion TransUnion
Email: jon.peterson@transunion.com Email: jon.peterson@transunion.com
 End of changes. 51 change blocks. 
148 lines changed or deleted 148 lines changed or added

This html diff was produced by rfcdiff 1.48.