aviralyash27@gmail.com

Applications and Real-Time Secure Telephone Identity Revisited STIR PASSporT SIP connected identity This document updates RFC 9970. RFC 9970 recommends STIR PASSporTs on re-INVITE and BYE requests after connected identity has been established in a SIP dialog, and states that this prevents spoofed mid-dialog or dialog-terminating events. The baseline PASSporT construction used by RFC 8224 does not bind the SIP request method, CSeq number, Call-ID, or dialog tags. Consequently, a valid PASSporT can remain valid when a fresh signed in-dialog request is transformed into a different SIP request whose authenticated identity fields are unchanged. This document defines the "sipctx" PASSporT type. It binds the SIP request method and dialog/sequence context to the PASSporT. Implementations relying on PASSporT validation for mid-dialog request authenticity use this context binding as specified in this document.

Introduction recommends valid PASSporTs on re-INVITE and BYE requests after connected identity has been established and states that doing so prevents spoofed mid-dialog requests and denial-of-service teardowns. That construction uses the SIP Identity mechanism of and the PASSporT format of . The baseline construction does not bind several SIP fields that select the operation and dialog context of a request. In particular, the SIP method, CSeq number, Call-ID, From tag, and To tag are not baseline PASSporT claims. This creates a semantic substitution gap when a PASSporT is used as evidence that a specific mid-dialog operation was authorized by its signer. This omission is historically significant. The predecessor SIP Identity mechanism in signed CSeq and specifically identified transformation of an INVITE into a BYE as the attack prevented by doing so. intentionally reduced the protected SIP fields when it replaced RFC 4474. That reduction is compatible with the narrower origin-identity properties of RFC 8224, but it is insufficient for the request-semantic property later assigned to PASSporTs by RFC 9970. This document does not change baseline STIR origin-identity semantics. It defines an additional mandatory PASSporT type for applications that rely on cryptographic authentication of an in-dialog SIP request as a particular operation in a particular dialog.

Conventions and Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Request-Method Substitution Counterexample Consider an established two-party SIP dialog in which the remote sequence number last accepted by the terminating UA is 80. The originating UA creates a legitimate in-dialog re-INVITE using CSeq 81, adds a fresh RFC 8224 Identity field, and sends the request. A downstream on-path intermediary suppresses that request before it reaches the terminating UA. The intermediary changes only the method token in the Request-Line and the method token in CSeq from INVITE to BYE. The numeric CSeq value, From and To fields, Date, Call-ID, dialog tags, and Identity field are unchanged. The resulting request therefore has the same baseline PASSporT inputs as the signed re-INVITE while carrying BYE semantics. changes only to BYE sip:bank@192.0.2.20:5060 SIP/2.0 ... Call-ID: DlgA-9f2@alice.example CSeq: 81 BYE Date: Sun, 16 Aug 2026 11:00:00 GMT Identity: ]]> The original re-INVITE can also retain its Contact field unchanged. RFC 3261 classifies Contact as not applicable to BYE, but requires a UAS to ignore a not-applicable header field if one is present by mistake. The transformation therefore need not delete Contact or alter any other header field. The CSeq method still matches the Request-Line method as required by , and the numeric CSeq is the exact next value in the dialog. Because the authentic re-INVITE was suppressed, a replay cache at the receiver has not previously observed its Identity value. Neither full-form nor compact baseline PASSporT verification reconstructs a request method or dialog identifier, so baseline identity verification cannot distinguish these two requests.

The "sipctx" PASSporT Type This document defines a PASSporT type whose "ppt" value is "sipctx". The type makes five SIP request-context claims mandatory as a set: "sip_method", "sip_cseq_num", "sip_callid", "sip_from_tag", and "sip_to_tag". The "sip_callid", "sip_cseq_num", and "sip_from_tag" claim names are already registered by . This document reuses those claim names with the same SIP-field meanings. It defines two additional JWT claim names, "sip_method" and "sip_to_tag". The serialization procedure in Section 5.5 of is specific to reconstruction of the RFC 8055 received-realm detached JWS and MUST NOT be applied to a "sipctx" PASSporT. In particular, a Call-ID value MUST NOT be case-normalized. Construction and reconstruction of "sipctx" claims are instead specified by and use PASSporT deterministic JSON serialization from .

Claim Construction An authentication service constructing a "sipctx" PASSporT for an in-dialog SIP request MUST populate the five mandatory claims as follows:

sip_method

A JSON string containing the method token from the SIP Request-Line. SIP method names are case-sensitive as specified by ; no case normalization is performed.

sip_cseq_num

A JSON string containing the CSeq sequence number in canonical unsigned base-10 form. The canonical form contains no leading zeroes except that zero itself is encoded as "0". Signers and verifiers compare the underlying CSeq value numerically before producing this representation.

sip_callid

A JSON string containing the Call-ID value of the request. Call-ID is case-sensitive and is compared byte-for-byte as specified by .

sip_from_tag

A JSON string containing the parsed From "tag" parameter value, converted to lowercase ASCII for deterministic representation. The "tag" parameter is a SIP token parameter and follows the SIP parameter-value comparison rules of .

sip_to_tag

A JSON string containing the parsed To "tag" parameter value, converted to lowercase ASCII for deterministic representation.

The value of "sip_method" MUST equal the method token in CSeq. A signer MUST NOT generate a "sipctx" PASSporT for a request for which those method tokens differ.

Example Payload A full "sipctx" payload for the request in can contain the following claims in addition to any other claims required by the applicable STIR profile:

Verification Procedures A verification service that supports "sipctx" first performs the applicable RFC 8224 verification procedures, including credential, freshness, and baseline identity processing. It then validates the mandatory request-context claims defined by this document. For a compact PASSporT, the verifier MUST reconstruct all five request-context claims from the received SIP request according to before validating the PASSporT signature. This reconstruction requirement makes the extension suitable for compact PASSporT use under . For a full-form PASSporT, validating the JWS bytes alone is insufficient. After cryptographic validation, the verifier MUST independently derive the five request-context values from the received SIP request and compare them to the signed claims using the rules in . Any mismatch causes that "sipctx" Identity field to be invalid for request-semantic authentication.

Update to RFC 9970 This section updates the processing guidance in Section 6 of . An implementation that relies on PASSporT validation to obtain the RFC 9970 property that an in-dialog re-INVITE or BYE request was authorized as that specific SIP operation MUST require a valid "sipctx" PASSporT for that request. A valid baseline PASSporT without "sipctx" continues to authenticate the identity information defined by RFC 8224, but MUST NOT be treated as cryptographic authentication of the request method or dialog context. This requirement does not require every RFC 9970 deployment to reject requests that lack "sipctx". Authorization policy remains local. Rather, a relying party MUST NOT claim or depend on the anti-spoofing or anti-teardown property described above unless the request-semantic binding has been successfully verified.

Compatibility and Downgrade Handling permits multiple Identity fields in a request. During incremental deployment, an authentication service MAY therefore include both a baseline Identity field and a "sipctx" Identity field for the same request. A relying party requiring request-semantic authentication MUST NOT fall back to a baseline Identity field when the "sipctx" Identity is absent, removed, unsupported, or invalid. Such a fallback would permit an intermediary to strip the context-bound Identity while retaining a valid baseline Identity, defeating the property this document provides. A baseline Identity that remains valid after such stripping MAY still be used for the narrower identity assertions defined by RFC 8224, subject to local policy.

Back-to-Back User Agents and Dialog Legs A Back-to-Back User Agent (B2BUA), as described by , acts as a User Agent Server on one side and as a User Agent Client on the other, maintaining the dialogs it establishes. The Call-ID, tags, CSeq state, and method sequencing are therefore properties of each dialog leg. A B2BUA that provides request-semantic authentication on an outgoing leg MUST create a new "sipctx" PASSporT from the context of that outgoing request. A "sipctx" PASSporT from one dialog leg MUST NOT be copied to another leg.

Fields Deliberately Not Bound This document does not bind Via, Route, Record-Route, Max-Forwards, Contact, or the Request-URI. Routing fields can be legitimately modified by SIP intermediaries, and Contact is not required to bind a request to its method, sequence position, or dialog. None of these fields is required to close the method-substitution or same-identities cross-dialog substitution described here. This document also does not provide generic SIP message-body integrity. Existing or future PASSporT extensions can bind media keys or other application-specific bodies where required.

Related Work The individual Internet-Draft independently binds "call-id" and "cseq" when verifying callee evidence against the preceding SIP INVITE. That construction is scoped to VVP call setup and does not authenticate the method of an arbitrary RFC 9970 mid-dialog request. It is nevertheless useful design precedent for binding telephone-identity evidence to SIP transaction or dialog context rather than to identity claims alone.

IANA Considerations

PASSporT Type IANA is requested to add the following value to the "Personal Assertion Token (PASSporT) Extensions" registry:

ppt value	Reference
sipctx	This document,

JSON Web Token Claims IANA is requested to add the following values to the "JSON Web Token Claims" registry:

Claim Name	Claim Description	Change Controller	Reference
sip_method	SIP request method	IESG	This document,
sip_to_tag	SIP To tag header field parameter value	IESG	This document,

Security Considerations The security considerations of , , and continue to apply. This document adds integrity binding between a PASSporT and the SIP operation/dialog context in which it is used. This document does not revise RFC 8224's original statement that its Identity mechanism was not designed to provide generic end-to-end SIP message integrity against a man-in-the-middle. The narrower issue is that RFC 9970 later relies on the same reduced signed envelope for a request-semantic anti-spoofing and anti-teardown property. The threat addressed here is semantic substitution by an entity that can modify signaling after a legitimate authentication service has created an Identity field. The attacker does not need the signer's private key. Suppression of the original signed request before the forged request reaches the verifier also means that first-observation replay state does not detect the substitution. The mechanism does not prevent an on-path attacker from dropping SIP messages. An on-path party can always cause signaling-level denial of service by discarding traffic. The additional property provided here is that such a party cannot transform a signed request into a different authenticated SIP operation or transplant the proof into a different dialog without invalidating the "sipctx" verification. Binding only the request method is insufficient. Two simultaneous dialogs between the same authenticated identities have identical baseline "orig" and "dest" claims. Call-ID and both dialog tags bind the proof to one dialog, while CSeq binds it to the request ordering context within that dialog.

Normative References Informative References Work in Progress

Executable Model An executable model used during development exercises full-form and compact baseline PASSporTs, an origin-identity negative control, compact-form Date reconstruction and full-form signed-iat repair, a two-token INVITE-to-BYE transformation with an unchanged numeric CSeq, a method-only control, a same-identities cross-dialog transplant, comparison-rule controls, and extension-stripping behavior. The model is non-normative; the protocol requirements are the text in the body of this document.