Personal Assertion Token (PASSporT) Extension for Diverted Calls
updates
- rfc-8224 — Authenticated Identity Management in the Session Initiation Protocol (SIP)
Extracted elements (30)
History-Info and the SIP Diversion header field were found insufficient because neither provides cryptographic assurance of secure redirection and both record entries for minor syntactic URI changes that do not reflect actual target changes. This motivated the new "div" PASSporT extension with cryptographic signing.
The "div-o" type nests the original PASSporT in an "opt" field rather than carrying it in a parallel Identity header, making it suitable for out-of-band STIR and non-SIP environments where multiple Identity header fields cannot be conveyed. Verification of "div-o" is simpler because chains are self-contained rather than requiring correlation of separate header fields.
The "div" signer must have authority over the "div" claim (the previous destination) rather than the "orig" field. This is because the "div" value is the URI that caused the call to be routed to the retargeting entity, so the retargeting entity would already hold appropriate private keying material for that identity in ordinary operations.
Because PASSporT operates on canonicalized telephone numbers and normalized URIs, many minor syntactic changes to identifiers that might be captured by History-Info or Diversion headers will not require a new "div" PASSporT; a "div" PASSporT is only needed when the canonical form of the "dest" identifier actually changes.
This document updates RFC 8224 to permit carrying Identity header fields in SIP 300-class (redirect) responses. Originating user agents receiving a 3xx MAY copy those Identity header fields into new requests; use is OPTIONAL.
When a request arrives at a retargeting entity carrying multiple non-"div" PASSporTs with different "orig" or "dest" values, the authentication service SHOULD generate one "div" PASSporT for each such non-"div" PASSporT, creating multiple chains in a single request.
All "div" PASSporTs MUST contain a "div" claim indicating the previous destination. A new PASSporT with a "div" claim MUST NOT be produced if the canonical form of the "dest" identifier has not changed due to retargeting.
An authentication service MUST NOT add a "div" PASSporT to an INVITE that contains no existing Identity header field, and MUST NOT remove the original Identity header field value before forwarding after adding a "div" PASSporT.
"div" PASSporTs MUST use full form instead of compact form. The PASSporT header MUST include the "div" PASSporT type and an "x5u" field pointing to a credential controlled by the retargeting entity.
Each "div-o" PASSporT MUST contain an "opt" claim set element with the value of the original PASSporT from which the "div-o" was created, and the "div" claim MUST be populated with the "dest" field of that original PASSporT.
For each "div" PASSporT, the verification service MUST find an earlier PASSporT in the request whose "dest" claim is equivalent to the "div" claim; if a complete chain cannot be constructed, "div" validation cannot be completed.
PASSporTs of type "div" MUST NOT contain an "opt" element in their payload; "opt" is reserved for "div-o" PASSporTs.
The "opt" claim MUST contain a quoted full-form PASSporT as specified by RFC 8225 Appendix A; it MUST NOT contain a compact form PASSporT.
The signature on a "div" PASSporT MUST be created with a credential that has authority over the identity in the "div" claim (the previous destination), not the "orig" field. This is a significant departure from baseline STIR, where the signer has authority over "orig".
The verification service MUST check date freshness of the outermost "div" PASSporT per RFC 8224 Section 6.2 Step 4, and MUST inspect and validate the signatures on every PASSporT object in the chain from the outermost "div" PASSporT to the innermost PASSporT.
The verification service MUST validate that the "orig" field of the innermost PASSporT is equivalent to the "orig" field of the outermost "div" PASSporT and all intermediate "div" PASSporTs in the chain; if the "orig" value has changed, the entire chain MUST be treated as invalid.
When adding an Identity header field containing a "div" claim, SIP authentication services MUST also add a "ppt" parameter to the Identity header with the value "div".
Forwarding services acting as anonymizing proxies may be unable to provide a secure chain of retargeting because the originating identity is obfuscated; the interaction of STIR with anonymization services is a general risk of STIR identity mechanisms.
Tracking call routing in SIP signaling via "div" reveals call forwarding policies and may expose relationships between different identifiers belonging to the same user. This information is ordinarily revealed to the called party's user agent service rather than the caller, but implementers should understand the trade-off, particularly when service logic is shared with a caller's network via 3xx responses.
The "div-o" PASSporT type embeds the original PASSporT inside an "opt" element rather than conveying it as a separate Identity header field. It is designed for non-SIP or gatewayed SIP environments such as out-of-band STIR scenarios where separate Identity header fields cannot be carried.
The "div" PASSporT type is a new PASSporT extension carrying a "div" claim that indicates the previous destination of a call before retargeting. It is created by authentication services at retargeting entities and conveys the original called-party identifier that caused the call to be routed to the retargeting entity.
The "hi" element may appear inside the "div" claim to correlate the PASSporT with a History-Info header field index parameter value (e.g., "1.2.1"). This optional field assists relying parties in matching PASSporTs to History-Info entries when not all retargeting events produce a "div" PASSporT.
The "opt" (Original PASSporT) claim encapsulates an entire prior PASSporT in full form within a containing PASSporT. Its presence signifies that the outer PASSporT was derived by transforming the encapsulated one.
Two new JWT claims are registered in the IANA "JSON Web Token Claims" registry: "div" (Claim Description: Diverted Target of a Call) and "opt" (Claim Description: Original PASSporT (in Full Form)), both referencing RFC 8946.
Two new PASSporT types are registered in the IANA "Personal Assertion Token (PASSporT) Extensions" registry: "div" (defined in Section 3) and "div-o" (defined in Section 5).
"div" PASSporTs increase PASSporT size and create a potential amplification vector for SIP-based DDoS attacks. Using 3xx redirections instead of in-path retargeting mitigates this risk, and domains under unusual traffic loads can switch to redirection.
Including diversion information in PASSporTs reveals routing policies used by the retargeting entity. If an intermediate called number must remain confidential, no "div" PASSporT should be created for that retargeting; the only consequence is that downstream entities cannot correlate the incoming call with the original PASSporT without prior knowledge.
Chain validation for "div" PASSporTs proceeds by: (1) comparing outermost "dest" to the call target, (2) validating the outermost "div" PASSporT signature and credential authority, (3) verifying "orig" consistency across the entire chain, (4) checking date freshness, and (5) validating all signatures in every link of the chain. An invalid step at any stage invalidates the chain.
A "div-o" PASSporT claims set contains "orig", "dest", "iat", "div", and an "opt" field holding the base64url-encoded full-form PASSporT that was retargeted. The "opt" value MUST be a quoted full-form PASSporT per RFC 8225 Appendix A; compact form is prohibited.
A "div" PASSporT header MUST include "typ":"passport", "ppt":"div", "alg":"ES256", and "x5u" pointing to the retargeting entity's credential. The claims set includes "orig" (copied from the original PASSporT), "dest" (the new target), "iat", and the "div" field (the previous destination identifier).