RFC 8946 — PASSporT Extension for Diverted Calls — library

RFC 8946 (Peterson, February 2021) extends PASSporT so that a call can be forwarded without its signature turning into evidence against it. Proposed Standard; it updates RFC 8224.

A baseline PASSporT signs the called number as the authentication service saw it. That is deliberate: RFC 8224 §12.1 uses the signed dest to stop cut-and-paste attacks, where Bob lifts the Identity header from Alice’s call to him and replays it on a call to Carol. Carol sees a PASSporT addressed to Bob and can treat the call as suspect. Call forwarding produces the same picture legitimately. History-Info and the Diversion header record a retargeting but carry no cryptographic assurance, and both log syntactic changes to URIs that are not real changes of target.

What it specifies

The div PASSporT type and claim. A retargeting entity that receives a signed call and changes its destination may act as an authentication service and add a new PASSporT. The original destination becomes the div claim; the new target becomes dest; orig is copied unchanged, and iat is kept unless the retargeting entity changed the date in the signaling. No other claims carry over. A div PASSporT is only created when the canonical form of dest changes, and it must use full form.

Signed by the diverting party. A div PASSporT is signed with a credential that has authority over the number in the div claim, not the one in orig. The party vouching for the forward is the holder of the number the call was forwarded from, which in ordinary operation is the entity already holding keys for that number.

Carried alongside the original. In SIP the div PASSporT travels in its own Identity header field with ppt="div", and the authentication service must not remove the original. It must not add a div to an INVITE that carries no Identity header field at all.

Chain validation. The verification service extracts every PASSporT in the request and links each div to an earlier PASSporT whose dest matches its div value, repeating until it reaches the original. It then checks that the outermost dest matches the call’s target, validates the outermost signature against the authority for its div value, and requires every PASSporT in the chain to carry the same orig; a changed orig invalidates the whole chain. Freshness is checked on the outermost PASSporT, and checking the innermost iat is recommended so a stale original cannot be replayed inside a fresh div. If no complete chain can be built, the non-div PASSporTs can still be verified normally. What a relying party does with the result is local policy.

div-o for out-of-band and gatewayed use. Where separate Identity header fields cannot be carried, as in out-of-band STIR, the div-o type embeds the original PASSporT in an opt claim instead of sending it alongside.

Redirection. A 3xx redirect needs nothing from STIR, because the caller places a new call and signs the new target. A redirecting entity that wants to prove the redirect was legitimate may return div PASSporTs in the 3xx, and RFC 8946 updates RFC 8224 to permit Identity header fields in 300-class responses. Using them is optional for the caller.

History-Info correlation. An optional hi element in the div claim carries the History-Info index the PASSporT corresponds to.

Privacy and security

A div chain reveals how calls are routed, including forwarding relationships between numbers. The RFC notes that this normally goes to the called party, who usually set up the forwarding. Creating a div PASSporT is at the retargeting entity’s discretion; one that needs to keep an intermediate number confidential creates none, and the downstream verifier then cannot tie the call to its original PASSporT. Anonymizing forwarding services may not be able to produce a chain at all. Larger requests are a potential SIP amplification vector, and the RFC points to redirection instead of retargeting as the mitigation under load.

Where it is used

ATIS-1000085 profiles div for SHAKEN (IP-NNI). RFC 9970 depends on it: when a retargeted call returns connected identity, the rsp PASSporT must be accompanied by the div PASSporTs that explain why the answering number differs from the one called, and without them rsp is not used. div is not universally supported, so a forwarded call often arrives with no chain to validate.

Status

RFC 8946 (February 2021, Proposed Standard), from draft-ietf-stir-passport-divert. Updates RFC 8224. IANA has registered the div and opt claims and the div and div-o PASSporT types.