RFC 9888 — Out-of-Band STIR for Service Providers

RFC 9888 (Peterson — June 2026) defines a service-provider deployment model for STIR out-of-band PASSporT delivery. Authored by Jon Peterson, it was published from the working-group draft draft-ietf-stir-servprovider-oob. Proposed Standard.

RFC 9888 extends RFC 8816 (which establishes the general STIR OOB framework) with operational specifics for large service providers, addressing deployment scenarios where in-band STIR conveyance via the SIP Identity header isn’t universally available. The conceptual framing for OOB more broadly — what out-of-band delivery is for, how it relates to the broader trust framework — lives on the out-of-band topic page.

What it specifies

Authentication and verification service roles. The draft introduces an Out-of-Band Authentication Service (OOB-AS) and Out-of-Band Verification Service (OOB-VS) as the operational endpoints. The OOB-AS is operated by the originating service provider and submits PASSporTs to a Call Placement Service (CPS); the OOB-VS is operated by the terminating service provider and retrieves PASSporTs from CPSes when needed. In a single-provider deployment, the CPS and OOB-VS may be co-located or operated as a consolidated system.

Mutual TLS authentication using STIR credentials. OOB-AS authentication to the CPS uses mutual TLS (RFC 9325) with the service provider’s STIR credential (RFC 8226) — the same credential used to sign calls. This serves several purposes: prevents replay of captured PASSporTs to the CPS, anchors the CPS’s authorization decisions in the existing STIR trust hierarchy, and provides an existing identity for service providers without requiring a parallel credential system. Entities without STIR credentials (gateway or transit providers) need alternative submission mechanisms — out of scope for this draft.

Multi-provider CPS authorization. When a CPS serves multiple service providers, the terminating provider’s STIR credential identifies the TNAuthLists for which its OOB-VS is entitled to receive PASSporTs. The draft describes both mutual-TLS-based authorization and an alternative using a STIR-credential-signed token submitted to the CPS by the retrieving OOB-VS. The CPS inspects the dest element of the PASSporT to route to the appropriate OOB-VS.

Push and pull retrieval models. The pull model has the terminating OOB-VS contacting the CPS after receiving an unsigned call signal, retrieving the matching PASSporT. The push model has the CPS pushing PASSporTs to subscribed OOB-VSes (subscribed to specific TN ranges or SPCs); the OOB-VS may need to delay verification rendering during alerting to await arrival. Push timing and the substitution-attack interaction mentioned in RFC 8816 §7.4 are flagged for future work.

CPS advertisement. The draft discusses several methods for advertising CPS endpoints — distributed databases, DNS lookup during call routing, multilateral peering arrangements, and notably the option of embedding a CPS URI directly in STIR certificates. The certificate-embedded-URI approach is operationally appealing because the URI inherits the CA’s signature on the certificate. The draft-sliwa-stir-cert-cps-ext draft formalizes that mechanism and is referenced from this draft’s §4.

Gateway scenarios. The draft addresses the case where gateways perform OOB functions on behalf of providers that otherwise can only be reached through STIR out-of-band — for example, when in-band-STIR providers need to exchange secure calls with TDM-only providers reached via gateway-mediated OOB.

Relationship to VESPER OOB

This draft and the individual draft-wendt-stir-vesper-oob are different approaches to OOB STIR. RFC 9888 (this document, formerly draft-ietf-stir-servprovider-oob) targets deployment by large service providers using existing STIR credentials, with mutual-TLS-based CPS authorization. The VESPER OOB draft is an individual draft positioned as the substrate for a more general PASSporT-delivery model, with transparent CPS discovery via certificate-transparency log monitoring and Connected Identity integration.

Both can coexist; deployments may choose between them based on operational fit, and the OOB topic page covers the broader landscape including how the two approaches relate.

Status

Published as RFC 9888 (June 2026, Proposed Standard), from draft-ietf-stir-servprovider-oob-08. It is the IETF specification for service-provider OOB STIR deployment, complementing RFC 8816 (general STIR OOB framework).