wdiff rfc9888.original rfc9888.txt

Network Working Group

Internet Engineering Task Force (IETF) J. Peterson
Internet-Draft
Request for Comments: 9888 TransUnion
Intended status:
Category: Standards Track 7 July October 2025
Expires: 8 January 2026
ISSN: 2070-1721

Out-of-Band STIR Secure Telephone Identity Revisited (STIR) for Service
Providers
draft-ietf-stir-servprovider-oob-08

Abstract

The Secure Telephone Identity Revisited (STIR) framework defines
means of carrying its Personal Assertion Tokens (PASSporTs) either
in-band, within the headers of a Session Initiation Protocol (SIP)
request, or out-of-band, through a service that stores PASSporTs for
retrieval by relying parties. This specification defines a way that
the out-of-band conveyance of PASSporTs can be used to support large
service providers, providers for cases in which in-band STIR conveyance is not
universally available.

Status of This Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force
(IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list It represents the consensus of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid the IETF community. It has
received public review and has been approved for a maximum publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.

Information about the current status of six months this document, any errata,
and how to provide feedback on it may be updated, replaced, or obsoleted by other documents obtained at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

This Internet-Draft will expire on 8 January 2026.
https://www.rfc-editor.org/info/rfc9888.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info)
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Revised BSD License text as described in Section 4.e of the
Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Service Provider Deployment Architecture for Out-of-Band STIR . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. Advertising a CPS . . . . . . . . . . . . . . . . . . . . . . 4
5. Submitting a PASSporT . . . . . . . . . . . . . . . . . . . . 5
6. PASSporT Retrieval . . . . . . . . . . . . . . . . . . . . . 6
7. Gateways . . . . . . . . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
10.
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8
11.
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8
12.
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
12.1.
11.1. Normative References . . . . . . . . . . . . . . . . . . 9
12.2.
11.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgments
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10

1. Introduction

The Secure Telephone Identity Revisited (STIR) [RFC8224] framework
provides a cryptographic assurance of the identity of calling parties
in order to prevent impersonation, which is a key enabler of unwanted
robocalls, swatting, vishing, voicemail hacking, and similar attacks
(see [RFC7340]). The STIR out-of-band [RFC8816] framework enables
the delivery of PASSporT [RFC8225] objects through a Call Placement
Service (CPS), rather than carrying them within a signaling protocol
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
border policies, calls routinely transiting a gateway to the Public
Switched Telephone Network (PSTN), or similar circumstances.

While out-of-band STIR can be implemented as an open Internet
service, it then requires complex security and privacy measures to enable
the CPS function without allowing the CPS to collect data about the
parties placing calls. This specification describes CPS
implementations that act specifically on behalf of service providers
who will be processing the calls that STIR secures, and thus secures and, thus, who
will necessarily know the parties communicating, so an alternative
security architecture becomes possible. These functions may be
crucial to the adoption of STIR in some environments, like legacy
non-IP telephone networks, where in-band transmission of PASSporTs
may not be feasible.

Environments that might support this flavor of STIR out-of-band
include carriers, large enterprises, call centers, or any Internet
service that aggregates on behalf of a large number of telephone
endpoints. That last case may include PSTN gateway or interexchange
or international transit providers.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.

3. Service Provider Deployment Architecture for Out-of-Band STIR

The architecture in this specification assumes that every
participating service provider is associated with one or more
designated CPS instances. A service provider's CPS serves as a place
where callers, or callers or, in some cases gateways, cases, gateways can deposit a PASSporT when
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
done at the same time as an in-band STIR call is placed. The
terminating service provider could operate the CPS themselves, or a
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
service providers, nor does it prohibit multiple service providers
from sharing a CPS provider. Moreover, a particular CPS can be a
logically distributed entity compromised of several geographically
distant entities that flood PASSporTs among themselves to support an
anycast-like service.

The process of locating a destination CPS and submitting a PASSporT
naturally requires Internet connectivity to the CPS. If the CPS is
deployed in the terminating service provider network, any such
network connectivity could instead be leveraged by a caller to
initiate a SIP session, during which in-band STIR could be used
normally. The Therefore, the applicability of this architecture is therefore to
those cases where, for whatever reason, SIP requests cannot reliably
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).
It is hoped that as IP connectivity between telephone providers
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
cannot predict whether end-to-end delivery of SIP calls will occur.

4. Advertising a CPS

If more than one CPS exists for a given deployment, there will need
to be some means of discovering CPSs, either administratively or
programmatically. Many service providers have bilateral agreements
to peer with one another, and another; in those environments, identifying their
respective CPS's CPSs 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 mechanism is needed to discover the CPS associated with the
target of a call.

In order to allow the CPS chosen by a service provider to be
discovered securely, this specification defines a CPS advertisement.
Effectively, a CPS advertisement is a document which that contains the URL
of a CPS, CPS as well as any information needed to determine 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 [RFC8226] credential, credential or another credential that is
trusted by the participants in a given STIR environment. The
advantage to signing with STIR certificates is that they contain a
"TNAuthList" value indicating the telephone network resources that a
service provider controls. This information can be matched with a
TNAuthList value in the CPS advertisement to determine whether the
signer has the authority to advertise a particular CPS as the proper
destination for PASSporTs.

The format of a service provider CPS advertisement consists of a
simple JSON object containing one or more pairs of TNAuthList values
pointing to the URIs of CPSs, e.g. for example:

{ "0-1234":"https://cps.example.com" }. }

The format of this is a hyphen-
separated hyphen-separated concatenation of each
[RFC8226] TNAuthList TNEntry value ("0" for SPC, "1" for telephone
number range, "2" for individual telephone number) with the
corresponding TNAuthList value. Note for
in case "1", telephone number
ranges are expressed by a starting telephone number followed by a
count, and the count itself is here
also by itself; they are hyphen-separated from the TN
(e.g., "1-15714341000-99"). An advertisement can contain multiple
such ranges by adding more pairs. CPS URIs MUST be HTTPS URIs [RFC9110] (Section
([RFC9110], Section 4.2.2). These CPS URIs SHOULD be publicly reachable,
reachable as service providers cannot usually anticipate all of the
potential callers that might want to connect with them, but 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
originating domain has no ready means to determine whether a given
called telephone number falls within the scope of an SPC (such as a
national routing database that maps telephone numbers to SPCs). In
such environments, TN-based advertisements could enable discovery
instead. Also, note that PASSporTs can be used to sign communication
where the "orig" and/or "dest" are not telephone numbers as such, but
instead URI-based identifiers; typically, these PASSporTs typically would not
be signed by an a certificate as described in [RFC8226] certificate, and any future
specification would be required to identify URI-based prefixes for
CPS advertisements.

CPS advertisements could be made available through existing or new
databases, 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 distributed database among
the participants in a multilateral peering arrangement.

An alternative to CPS advertisements that may be usable in some
environments is adding a field to STIR [RFC8226] certificates as described in
[RFC8226] identifying the CPS URI issued to individual service
providers. As these certificates are themselves signed by a CA
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 method perhaps best mirrors the trust model
required to allow a CPS to authorize PASSporT submission and
retrieval.

5. Submitting a PASSporT

Submitting a PASSporT to a CPS as specified in the STIR out-of-band
framework [RFC8816] requires security measures that are intended to
prevent the CPS from learning the identity of the caller (or callee)
to the degree possible. In However, 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 behalf) and, as such such, the information that appears
in the PASSporT is redundant with call signaling that the terminating
party will receive anyway (see Section 11 10 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.

An out-of-band authentication service (OOB-AS) forms a secure
connection with the target CPS. This may happen at the time a call
is being placed, 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 [RFC9325])
using its STIR credential [RFC8226], the same one it would use to
sign calls; this helps mitigate the risk of flooding that more open more-open
OOB implementations may face. Furthermore, the use of mutual TLS
prevents attackers from replaying 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.

A CPS can use this mechanism to authorize service providers who
already hold STIR credentials to submit PASSporTs to a CPS, but
alternative mechanisms would be required for any entities that do not
hold a STIR credential, including gateway or transit providers who
want to submit PASSporTs. See Section 7 below for more on their behavior.

Service provider out-of-band PASSporTs do not need to be encrypted
for storage at the CPS, although the use of transport-layer security TLS to prevent
eavesdropping on the connection between the CPS and OOB-
ASs OOB-ASs is
REQUIRED. PASSporTs will typically be submitted to the CPS at the
time they are created by an AS; if the PASSporT is also being used
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
discretion of the originating domain. An OOB-AS MUST implement a
REST
Representational State Transfer (REST) interface to submit PASSporTs
to the CPS as described in
[RFC8816] [RFC8816], Section 9. PASSporTs persist
at the CPS for as long as is required for them to be retrieved (see the next section), but
Section 6) but, in any
event event, for no longer than the freshness
interval of the PASSporT itself (a maximum of sixty seconds).

6. PASSporT Retrieval

The STIR out-of-band framework [RFC8816] proposes two means by which
called parties can acquire PASSporTs out-of-band: through a retrieval
interface,
interface or a subscription interface. In the service provider
context, where many calls to or from the same number may pass through
a CPS simultaneously, an out-of-band capable 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 or receive push
notifications from the CPS for incoming calls.

CPS implementations MUST support pulling of the PASSpoRTs PASSporTs via the
REST flow described in [RFC8816] [RFC8816], Section 9. In the pull model, a
terminating 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 all
PASSporTs submitted to the CPS are made available to the OOB-VS of
that provider; indeed, the CPS and OOB-VS may be colocated or
effectively operated as a consolidated system. In a multi-provider
environment, the STIR credential of the terminating domain can be
used by the CPS to determine the range of TNAuthLists for which an
OOB-VS is entitled to receive PASSporTs; this may be through a
mechanism like mutual TLS, TLS or through using the use of the STIR credential
to sign a token that is submitted to the CPS by the retrieving OOB-VS. 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.

In a push model, an OOB-VS could could, for example example, subscribe to a range
of telephone 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
potential arrival of a PASSporT at the OOB-VS. The exact timing of
this, and its interaction with the substitution attack described in
[RFC8816]
[RFC8816], Section 7.4, is left for future work.

7. Gateways

In some deployment architectures, gateways might perform a function
that interfaces with a CPS for the retrieval or storage of PASSporTs,
especially in cases when in-band STIR service providers need to
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
may send SIP INVITEs to a gateway in front of a traditional PSTN
tandem that services a set of legacy service providers. In that
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
for one or more legacy providers, who who, in turn turn, consume those
PASSporTs through an OOB-VS to assist in robocall mitigation and
similar functions.

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 allow 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 providers and also to create
PASSporTs for in-band STIR conveyance from the legacy-providers to
terminating service providers in the closed STIR network. For
example, a service provider could issue a delegate certificate
[RFC9060] for this purpose.

8. Acknowledgments

We would like to thank Alex Fenichel for contributing to this
specification.

9. IANA Considerations

This memo includes document has no request to IANA.

10. IANA actions.

9. Privacy Considerations

The analysis of out-of-band STIR in the Privacy Considerations "Privacy Considerations"
section of [RFC8816] differs considerably from this document. Per
Section 1, this specification was motivated in part by choosing a
different privacy architecture than [RFC8816], one in which the CPS
is operated by a service provider who is a party to the call itself, and thus itself
and, thus, would independently have access to the call metadata
captured in a PASSporT.

That said, in cases where a third-party service operates the
verification service function on behalf of a carrier, that third third-
party service would indeed be privy to this metadata. That said, it It is a fairly
common situation for third party third-party services to receive this sort of
metadata to perform tasks related to billing, security, number
translation, and so on, and on; existing data governance agreements could be
readily applied to the out-of-band STIR use case.

Finally, note that PASSporTs are extensible tokens, and it is
conceivable that they might contain data that is not otherwise
carried in SIP signaling or that would ordinarily be considered a
component of call metadata. Any such extensions might have specific
interactions with the privacy of both in-band and out-of-band STIR
which
that their specifications would need to elaborate.

11.

10. Security Considerations

The Security Considerations security considerations of [RFC8816] apply to this documen, document,
including concerns about potential denial-of-service vectors and
traffic analysis. However, that specification's model focused a
great deal on the privacy implications of uploading PASSporTs to a
third-party web service. This draft document mitigates those concerns by
making the CPS one of the parties to call setup (or an entity
contractually acting on their behalf). That said, any architecture
in which PASSporTs are shared with a federated or centralized CPS
raises potential concerns about data collection [RFC7258]. Moreover,
any additional information included in a PASSporT which that is not
strictly redundant with the contents of a SIP request increases data
collection concerns; while baseline [RFC8225] PASSporTs only contain
information otherwise in the SIP request. Existing and future
extensions (e.g. [RFC8588] (e.g., the "origid" field) field described in [RFC8588]) might
leak further information.

Unlike [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 issued by trust anchors which that are already trusted by the CPS,
potentially to gateways and similar services. Common STIR
deployments use Service Provider Codes (SPCs) instead of telephone
number ranges to identify service providers today; determining
whether a given SPC entitles a service provider to access PASSporTs
for a given telephone number is not trivial, but is a necessary
component of this CPS architecture. 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 PASSporTs
for calls in progress to any service provider.

12.

11. References

12.1.

11.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.

[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.

[RFC8226] Peterson, J. and S. Turner, "Secure Telephone Identity
Credentials: Certificates", RFC 8226,
DOI 10.17487/RFC8226, February 2018,
<https://www.rfc-editor.org/info/rfc8226>.

[RFC8816] Rescorla, E. and J. Peterson, "Secure Telephone Identity
Revisited (STIR) Out-of-Band Architecture and Use Cases",
RFC 8816, DOI 10.17487/RFC8816, February 2021,
<https://www.rfc-editor.org/info/rfc8816>.

[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.

[RFC9325] Sheffer, Y., Saint-Andre, P., and T. Fossati,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
2022, <https://www.rfc-editor.org/info/rfc9325>.

12.2.

11.2. Informative References

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.

[RFC7340] Peterson, J., Schulzrinne, H., and H. Tschofenig, "Secure
Telephone Identity Problem Statement and Requirements",
RFC 7340, DOI 10.17487/RFC7340, September 2014,
<https://www.rfc-editor.org/info/rfc7340>.

[RFC8588] Wendt, C. and M. Barnes, "Personal Assertion Token
(PaSSporT) Extension for Signature-based Handling of
Asserted information using toKENs (SHAKEN)", RFC 8588,
DOI 10.17487/RFC8588, May 2019,
<https://www.rfc-editor.org/info/rfc8588>.

[RFC9060] Peterson, J., "Secure Telephone Identity Revisited (STIR)
Certificate Delegation", RFC 9060, DOI 10.17487/RFC9060,
September 2021, <https://www.rfc-editor.org/info/rfc9060>.

Acknowledgments

Thank you to Alex Fenichel for contributing to this specification.

Author's Address

Jon Peterson
TransUnion
Email: jon.peterson@transunion.com