SIP Request Context Binding for STIR Connected Identity

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 2 February 2027.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

[RFC9970] 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 [RFC8224] and the PASSporT format of [RFC8225].¶

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 [RFC4474] signed CSeq and specifically identified transformation of an INVITE into a BYE as the attack prevented by doing so. [RFC8224] 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.¶

2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

3. 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.¶

INVITE sip:bank@192.0.2.20:5060 SIP/2.0
...
Call-ID: DlgA-9f2@alice.example
CSeq: 81 INVITE
Date: Sun, 16 Aug 2026 11:00:00 GMT
Identity: <unchanged PASSporT>

                 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: <unchanged PASSporT>

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 [RFC3261], 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.¶

4. 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 [RFC8055]. 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 [RFC8055] 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 Section 4.1 and use PASSporT deterministic JSON serialization from [RFC8225].¶

{
  "dest":{"tn":["12125550100"]},
  "iat":1786878000,
  "orig":{"tn":"12125550101"},
  "sip_callid":"DlgA-9f2@alice.example",
  "sip_cseq_num":"81",
  "sip_from_tag":"a1b2c3",
  "sip_method":"INVITE",
  "sip_to_tag":"b4c5d6"
}

5. 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 Section 4.1 before validating the PASSporT signature. This reconstruction requirement makes the extension suitable for compact PASSporT use under [RFC8225].¶

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 Section 4.1. Any mismatch causes that "sipctx" Identity field to be invalid for request-semantic authentication.¶

6. Update to RFC 9970

This section updates the processing guidance in Section 6 of [RFC9970].¶

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.¶

7. Compatibility and Downgrade Handling

[RFC8224] 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.¶

8. Back-to-Back User Agents and Dialog Legs

A Back-to-Back User Agent (B2BUA), as described by [RFC3261], 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.¶

9. 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.¶

10. Related Work

The individual Internet-Draft [I-D.hardman-verifiable-voice-protocol] 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.¶

11. IANA Considerations

12. Security Considerations

The security considerations of [RFC8224], [RFC8225], and [RFC9970] 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.¶

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.¶

Author's Address