appliedbits
LIBRARY  ·  IETF LIBRARY ENTRY
Last updated 2026-05-03 drafted

RFC 8224 — Authenticated Identity Management in the Session Initiation Protocol

RFC 8224 (Peterson, Jennings, Rescorla, Wendt — February 2018) is the SIP-level specification for how cryptographically authenticated identity travels in a call. It defines the Identity header field, the verification procedures, and the relationship between the signature carried in that header and the SIP request the signature is asserting identity over. I am a co-author. The document is the cornerstone of the STIR protocol layer; the other core RFCs (8225 for the token format, 8226 for the certificate model) plug into the architecture this one establishes.

What it specifies

The protocol mechanism is straightforward in its essentials:

  • The originating SIP entity computes a PASSporT (the JWT-shaped token defined by RFC 8225) that asserts a calling identity, signs it with a private key whose certificate authorizes assertion over the calling number, and carries the token in a SIP Identity header alongside the invite.
  • Intermediate SIP elements forward the Identity header unchanged; modifications to the canonicalized fields invalidate the signature.
  • The terminating SIP entity (or any element with verification responsibility) retrieves the certificate via the info URL in the PASSporT header, validates the certificate against the trust anchors managed by governance, and confirms the signature over the canonicalized fields.

The verification procedure produces one of three outcomes: verification succeeded, verification failed, or no Identity header was present. What the terminating side does with that outcome — admission, rejection, branding, scoring, downstream analytics — is policy, not protocol. RFC 8224 specifies the mechanism; it does not mandate what verifiers do with the result.

Design choices worth knowing

The single most important design decision in RFC 8224 is the canonicalization rule — which SIP fields the signature covers and how they are normalized before signing.

The canonical form covers the calling number (typically the From URI’s user portion), the called number (the To URI’s user portion), the timestamp from the PASSporT’s iat claim, and a small set of additional metadata. It deliberately does not cover the SIP message body, route headers, or the long list of SIP fields that intermediate elements legitimately rewrite — session border controllers, route adaptors, and proxy elements all touch SIP signaling in transit, and a signature that breaks every time a proxy adjusts a Via header would be unverifiable in practice.

The choice to canonicalize over a tightly scoped set of fields is also the source of most of the implementation subtlety in real deployments. Edge cases — what canonical form does a tel URI take versus a sip URI, how are E.164 numbers normalized, what happens when a proxy rewrites the From header for privacy — all map to specific paragraphs of this RFC. Most STIR/SHAKEN production bugs trace back to a canonicalization decision somewhere on the signing or verifying side.

The second design point worth understanding: the certificate retrieval URL. PASSporT carries an x5u claim that points at a URL where the verifier can fetch the certificate chain. The choice to use a URL rather than embed the chain in the PASSporT itself was deliberate (PASSporTs travel in SIP, where header size matters; URLs are short, certificate chains aren’t), but it introduces a dependency: the verifier must be able to retrieve the certificate in time. Caching, prefetching, and CDN distribution of the certificate URLs are all operational concerns the protocol pushes to the deployment.

The third: the relationship to existing SIP identity mechanisms. Before RFC 8224 there was RFC 4474, an earlier attempt at SIP identity that didn’t survive contact with real deployment — too brittle in the face of SBC rewrites, too narrow in its threat model, no working trust hierarchy. RFC 8224 formally obsoletes 4474 and incorporates the lessons. The most visible evidence of this in the document is the explicit treatment of the connection between identity assertions and the SIP elements that legitimately rewrite signaling between origination and termination.

Where this document is referenced

RFC 8224 is the SIP-side specification; nearly everything else in the STIR ecosystem depends on it directly:

  • RFC 8225 defines the token format carried in the Identity header.
  • RFC 8226 (page forthcoming) defines the certificate model the signing key lives in.
  • RFC 8588 (page forthcoming) extends the carried PASSporT with SHAKEN-specific claims.
  • RFC 8816 (page forthcoming) defines an out-of-band variant for call paths where SIP doesn’t travel end to end.

For the operational profile that wraps these documents into the deployed framework, see SHAKEN.