Implementing STIR/SHAKEN (RFC 8224/8225) Authentication and Verification in SIP Carrier Networks

Overview

Key takeaways

• STIR (RFC 8224) defines the SIP Identity header syntax and transport, while SHAKEN governs carrier implementation rules and token profiles.
• PASSporT (RFC 8225) uses JSON Web Signatures (JWS) containing origin, destination, attestation level, and origin identifier claims.
• Attestation levels (A, B, and C) reflect the originating provider's trust relationship with the calling customer and telephone number.
• Verification Services extract PASSporT tokens, fetch X.509 certificates from public repositories (STI-CR), validate signatures against trust anchors, and append verification status parameters.

Prerequisites

• In-depth understanding of SIP call routing and header manipulation
• Knowledge of Public Key Infrastructure (PKI), X.509 certificates, and asymmetric cryptography
• Familiarity with JSON Web Signature (JWS) structures (RFC 7515)

Guide

1. section #1

   Architectural Overview of STIR/SHAKEN The STIR/SHAKEN framework addresses caller ID spoofing by embedding cryptographically signed identity assertions into SIP signalling. STIR (Secure Telephone Identity Revisited) specifies the underlying protocols for creating digital signatures over telephone identities, while SHAKEN (Signature-based Handling of Asserted information using toKENs) defines the operational guidelines, governance, and profiles for service providers. The architecture comprises four primary logical components: the Authentication Service (AS), the Verification Service (VS), the Secure Telephone Identity Certification Authority (STI-CA), and the Secure Telephone Identity Certificate Repository (STI-CR). The AS signs outgoing calls on behalf of the originating network, while the VS validates incoming signatures on the terminating network using public key certificates fetched from an STI-CR.

2. section #2

   PASSporT JSON Web Token Structure (RFC 8225) A Personal Assertion Token (PASSporT) is a compact JSON Web Signature (JWS) structure transported inside the SIP Identity header. It consists of three base64url-encoded parts separated by periods: Header, Payload, and Signature. The Header specifies the algorithm (typically ES256), the token type ('passport'), the profile ('shaken'), and the URI of the public key certificate ('x5u'). The Payload contains essential claims including 'attest' (Attestation level), 'dest' (Destination telephone numbers), 'iat' (Issued At Unix timestamp), 'orig' (Originating telephone number), and 'origid' (Unique call/traceability identifier). The Signature is generated using the originating provider's private key matching the certificate referenced in 'x5u'.

   jsoncopy

   {
     "header": {
       "alg": "ES256",
       "ppt": "shaken",
       "typ": "passport",
       "x5u": "https://cert-repo.carrier.com/certs/cert123.pem"
     },
     "payload": {
       "attest": "A",
       "dest": {
         "tn": ["12125550199"]
       },
       "iat": 1672531200,
       "orig": {
         "tn": "12125550100"
       },
       "origid": "123e4567-e89b-12d3-a456-426614174000"
     }
   }

3. section #3

   Constructing the SIP Identity Header (RFC 8224) When an outbound SIP INVITE passes through an Authentication Service, the AS evaluates the calling party number, assigns an attestation level, and constructs the PASSporT JWS string. The AS then formats the result into a SIP Identity header field and attaches it to the egress INVITE message. Per RFC 8224, the Identity header contains the encoded PASSporT string followed by parameters that indicate the algorithm, profile, and certificate URL. Multiple Identity headers can be present if different identities are asserted, but typical SHAKEN implementations use a single primary Identity header representing the calling number.

   httpcopy

   INVITE sip:+12125550199@term-sbc.carrier.net SIP/2.0
   Via: SIP/2.0/UDP orig-sbc.carrier.com:5060;branch=z9hG4bK776asdhds
   From: <sip:+12125550100@carrier.com>;tag=1928301774
   To: <sip:+12125550199@term-sbc.carrier.net>
   Call-ID: a8434231e08920456281771829@carrier.com
   CSeq: 314159 INVITE
   Identity: eyJhbGciOiJFUzI1NiIsInBwdCI6InNoYWtlbiIsInR5cCI6InBhc3Nwb3J0IiwieDV1IjoiaHR0cHM6Ly9jZXJ0LXJlcG8uY2Fycmllci5jb20vY2VydHMvY2VydDEyMy5wZW0ifQ.eyJhdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6FsIjEyMTI1NTUwMTk5In19LCJpYXQiOjE2NzI1MzEyMDAsIm9yaWciOnsidG4iOiIxMjEyNTU1MDEwMCJ9LCJvcmlnaWQiOiIxMjNlNDU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2MTQxNzQwMDAifQ.sM3...sig;info=<https://cert-repo.carrier.com/certs/cert123.pem>;alg=ES256;ppt=shaken
   Content-Type: application/sdp

4. section #4

   Attestation Levels and Sign-Off Logic The SHAKEN framework categorizes caller authenticity into three standardized attestation levels based on how well the originating provider knows the subscriber and their right to use the calling number. Full Attestation (Level A) applies when the provider authenticates the customer calling and confirms they are authorized to use the specific originating telephone number. Partial Attestation (Level B) applies when the provider authenticates the customer originating the call, but cannot verify if the customer owns or is authorized to use the specific calling number (common in enterprise PBX trunking). Gateway Attestation (Level C) applies when the provider receives the call from an unauthenticated international gateway or non-SHAKEN interconnect and passes it forward without identity validation.

5. section #5

   Verification Service Operations and Result Passing When a terminating SBC receives an INVITE containing an Identity header, it passes the request to the Verification Service. The VS decodes the PASSporT token header, extracts the 'x5u' URL, and retrieves the corresponding X.509 certificate (checking local caches first). It verifies that the certificate was issued by an authorized STI-CA under the STI Governing Authority (STI-GA) trust anchor. The VS then checks signature integrity, confirms that the 'iat' timestamp falls within an acceptable staleness window (typically 60 seconds), and compares the 'orig' and 'dest' claims against the SIP From and To/Request-URI headers. Finally, the VS passes verification status to downstream softswitches by injecting a Reason header (RFC 3326) or a 'verstat' parameter into the From or P-Asserted-Identity header (e.g., verstat=TN-Validation-Passed).

   httpcopy

   P-Asserted-Identity: <sip:+12125550100@term-carrier.net>;verstat=TN-Validation-Passed
   Reason: SIP;cause=200;text="STIR-Verification-Successful"

6. section #6

   Key Management and Operational Best Practices High-availability carrier deployments require robust PKI and certificate management strategies. Certificates must be issued by STI-CAs recognized by the STI-PA (Policy Administrator). Public certificates must be hosted on high-availability HTTP repositories (STI-CR) with aggressive CDN caching to handle global verification fetches without latency spikes. On the verification side, local caching of public certificates using HTTP Cache-Control headers is essential to prevent per-call HTTP requests and unnecessary call setup delays. Private signing keys stored in the AS should be protected using Key Management Systems (KMS) or Hardware Security Modules (HSMs), and certificate revocation lists (CRLs) or OCSP stapling should be monitored continuously.

Further reading

• RFC 8224 - Authenticated Identity Management in the Session Initiation Protocol (SIP)
• RFC 8225 - PASSporT: Personal Assertion Token
• ATIS-1000074 - Signature-based Handling of Asserted information using toKENs (SHAKEN)
• RFC 7393 - Using the Secure Telephone Identity Revisited (STIR) Architecture in SIP