STIR/SHAKEN — caller authentication and the trust framework

This is the most developed section in the library because STIR/SHAKEN is where I’ve done the most foundational work. I’m a co-author of several of the core RFCs (8224, 8225, 8226, 8588, plus 9795 for the RCD PASSporT extension and 9796 for the SIP Call-Info delivery of RCD to end devices) and I’ve served as principal architect on the framework’s deployment across North American networks. The notebook will frequently link back to specific topics here.

The topic name “STIR/SHAKEN” elides a distinction worth holding clearly: STIR and SHAKEN are not the same thing. STIR is the cryptographic protocol — defined at the IETF, applicable in principle to any deployment of caller authentication anywhere in the world. SHAKEN is the operational profile of STIR specified by ATIS for North American carriers, including the governance arrangement that decides who issues certificates and what trust anchors verifiers should honor. The two are paired in deployment because the framework needs both — protocol and profile — to actually work, but their evolution and their constituencies are different. STIR covers the protocol layer; SHAKEN covers the profile and governance.

        ┌──────────────────────────────────────────────┐
        │              REGULATORY                      │
        │ FCC rulemakings, robocall mitigation,        │
        │ blocking authority, RMD                      │
        └─────────────────────┬────────────────────────┘
                              │ delegates technical
                              │ implementation to
                              ▼
        ┌──────────────────────────────────────────────┐
        │                SHAKEN                        │
        │ Operational profile, governance, attestation │
        │ ATIS-1000xxx specifications                  │
        │ STI-GA / STI-PA / STI-CA hierarchy           │
        └─────────────────────┬────────────────────────┘
                              │ built on
                              │ protocol layer
                              ▼
        ┌──────────────────────────────────────────────┐
        │                 STIR                         │
        │ RFC 8224 (Identity in SIP)                   │
        │ RFC 8225 (PASSporT)                          │
        │ RFC 8226 (Certificate model)                 │
        │ + extensions for OOB, RCD, delegation, ACME  │
        └──────────────────────────────────────────────┘

How we got here

The problem STIR addresses — caller-ID spoofing — has been around as long as caller-ID has. The SS7 era’s calling-party number was trivially settable by any switch with sufficient privilege, and the trust model was institutional: a small number of carriers, all known to each other, all bound by interconnection agreements that discouraged abuse. The honor system worked, more or less, because the population of entities able to inject calls was small enough to police socially.

The transition to SIP-signaled networks broke that arrangement. SIP made it cheap to originate calls — a VoIP provider could stand up a softswitch in an afternoon — and the population of originators expanded by orders of magnitude. Spoofing the calling-party number, which had been technically straightforward all along, became economically viable. By the early 2010s, a caller-ID display was unreliable enough as a trust signal that the public was beginning to ignore it entirely, and robocall volumes were starting their multi-year climb.

The IETF response was the STIR working group, chartered in 2013 to specify a cryptographic protocol that would let an originating provider sign an assertion about a calling identity in a way that downstream verifiers could check. The problem statement and threat model came out in late 2014 (RFC 7340 and RFC 7375); the core protocol trilogy — RFC 8224 for SIP-side identity, RFC 8225 for the PASSporT token format, RFC 8226 for the certificate model — was published in February 2018. Those three documents specify the cryptographic machinery; for the per- document treatment of each, see the IETF catalog.

The North American operational profile came together in parallel. ATIS — the Alliance for Telecommunications Industry Solutions — chartered the IP-NNI Task Force (Internet Protocol Network-to-Network Interface) to specify how STIR would actually be deployed between US and Canadian carriers. Three foundational documents emerged. ATIS-1000074, the SHAKEN base specification, established the use of the core STIR protocols and defined the operational profile carriers would deploy — attestation levels, signing semantics, and the on-the-wire structure of the SHAKEN PASSporT. ATIS-1000080 and ATIS-1000084 together define the certificate governance model — critical for SHAKEN management, STIR PKI governance, administration of certificate policies, and the eco-system participation rules that determine who can issue certificates and who can validate them. The governance arrangement (the STI-GA, STI-PA, STI-CA roles) was operational by 2019.

The third leg of the framework was regulatory: the United States TRACED Act of December 2019 directed the FCC to require carrier-level caller authentication, and the FCC’s March 2020 Report and Order mandated SHAKEN deployment for IP-based voice service by June 2021 for major carriers, with extensions for smaller carriers. The TRACED Act and the FCC order are what turned SHAKEN from a voluntary industry effort into compliance-driven deployment, and they’re the reason the framework is now live across essentially all major US and Canadian carriers.

Where the framework stands now

As of the mid-2020s, SHAKEN is operationally deployed across the North American carrier ecosystem. The vast majority of legitimate inter-carrier calls carry an authentication assertion; analytics engines and call-blocking products consume those assertions; the FCC continues to evolve the regulatory requirements through ongoing rulemakings.

The framework is not finished. The active work spans several fronts:

• Enterprise origination at scale — getting calls signed with attestation A from enterprise customers (rather than B from their carrier) requires the delegation model in RFC 9060 plus operational arrangements between carriers and customers that are still maturing. See delegate certificates.
• Non-IP call paths — SHAKEN’s in-band model assumes SIP signaling end to end, which TDM and SS7 segments break. Out-of- band SHAKEN, specified in RFC 8816, addresses this; deployment is slower than in-band SHAKEN. See out-of-band.
• Display-layer trust — caller-ID is necessary but not sufficient as a trust signal; rich call data (RFC 9795) and branded calling work add an authenticated display layer on top of the calling-number assertion. See rich call data.
• Cross-border arrangements — SHAKEN’s governance is North American; international interconnection requires trust arrangements with foreign carriers whose certificate hierarchies don’t share trust anchors. The ITU-T work on cross-border trust frameworks intersects here; see trust governance.
• Domain-bound identity — the current framework anchors trust in telephone-number authority, but many calling parties have stronger identity in their internet domain (a bank, a retailer, an airline). VESPER extends the framework to bind both. This is active draft work I’m authoring.

How this section is organized

STIR covers the IETF protocol layer — the identity-in-SIP mechanism (RFC 8224), the PASSporT token format (RFC 8225), the certificate model (RFC 8226), and how the pieces compose at runtime. STIR extensions catalogs the body of work that extends STIR — PASSporT extensions for SHAKEN, diversion, RCD, resource priority, and messaging; auxiliary mechanisms for delegation, out-of-band, error handling, and ACME-based certificate issuance; and the active drafts. The per-document pages live in the IETF catalog; the STIR and extensions pages provide the framing.

SHAKEN covers the operational profile and governance — the ATIS-1000xxx specifications, the STI- GA / STI-PA / STI-CA trust triangle, the attestation model, and the regulatory framework. Per-spec pages for the core ATIS documents live as sub-pages within this topic.

The remaining sub-pages are concept pages that synthesize across the protocol and the profile: attestation levels, out-of-band, delegate certificates, and rich call data. A glossary collects the terminology that gets used across all of these.