SIP Request Context Binding for STIR Connected Identity
draft-srivastava-stir-sip-request-context-00
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Aviral Srivastava | ||
| Last updated | 2026-08-16 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-srivastava-stir-sip-request-context-00
Secure Telephone Identity Revisited A. Srivastava
Internet-Draft August 2026
Updates: 9970 (if approved)
Intended status: Standards Track
Expires: 17 February 2027
SIP Request Context Binding for STIR Connected Identity
draft-srivastava-stir-sip-request-context-00
Abstract
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.
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.
Srivastava Expires 17 February 2027 [Page 1]
Internet-Draft STIR SIP Request Context August 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Requirements Language . . . . . . . . . . . . 3
3. Request-Method Substitution Counterexample . . . . . . . . . 3
4. The "sipctx" PASSporT Type . . . . . . . . . . . . . . . . . 4
4.1. Claim Construction . . . . . . . . . . . . . . . . . . . 5
4.2. Example Payload . . . . . . . . . . . . . . . . . . . . . 5
5. Verification Procedures . . . . . . . . . . . . . . . . . . . 6
6. Update to RFC 9970 . . . . . . . . . . . . . . . . . . . . . 6
7. Compatibility and Downgrade Handling . . . . . . . . . . . . 7
8. Back-to-Back User Agents and Dialog Legs . . . . . . . . . . 7
9. Fields Deliberately Not Bound . . . . . . . . . . . . . . . . 7
10. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 8
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
11.1. PASSporT Type . . . . . . . . . . . . . . . . . . . . . 8
11.2. JSON Web Token Claims . . . . . . . . . . . . . . . . . 8
12. Security Considerations . . . . . . . . . . . . . . . . . . . 8
13. Normative References . . . . . . . . . . . . . . . . . . . . 9
14. Informative References . . . . . . . . . . . . . . . . . . . 10
Executable Model . . . . . . . . . . . . . . . . . . . . . . . . 10
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
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
Srivastava Expires 17 February 2027 [Page 2]
Internet-Draft STIR SIP Request Context August 2026
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.
Srivastava Expires 17 February 2027 [Page 3]
Internet-Draft STIR SIP Request Context August 2026
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].
Srivastava Expires 17 February 2027 [Page 4]
Internet-Draft STIR SIP Request Context August 2026
4.1. 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
[RFC4485]; 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
[RFC3261].
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 [RFC3261].
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.
4.2. Example Payload
A full "sipctx" payload for the request in Section 3 can contain the
following claims in addition to any other claims required by the
applicable STIR profile:
Srivastava Expires 17 February 2027 [Page 5]
Internet-Draft STIR SIP Request Context August 2026
{
"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.
Srivastava Expires 17 February 2027 [Page 6]
Internet-Draft STIR SIP Request Context August 2026
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.
Srivastava Expires 17 February 2027 [Page 7]
Internet-Draft STIR SIP Request Context August 2026
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
11.1. PASSporT Type
IANA is requested to add the following value to the "Personal
Assertion Token (PASSporT) Extensions" registry:
+===========+==========================+
| ppt value | Reference |
+===========+==========================+
| sipctx | This document, Section 4 |
+-----------+--------------------------+
Table 1
11.2. JSON Web Token Claims
IANA is requested to add the following values to the "JSON Web Token
Claims" registry:
+============+=======================+============+================+
| Claim Name | Claim Description | Change | Reference |
| | | Controller | |
+============+=======================+============+================+
| sip_method | SIP request method | IESG | This document, |
| | | | Section 4.1 |
+------------+-----------------------+------------+----------------+
| sip_to_tag | SIP To tag header | IESG | This document, |
| | field parameter value | | Section 4.1 |
+------------+-----------------------+------------+----------------+
Table 2
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.
Srivastava Expires 17 February 2027 [Page 8]
Internet-Draft STIR SIP Request Context August 2026
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.
13. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
DOI 10.17487/RFC3261, July 2002,
<https://www.rfc-editor.org/info/rfc3261>.
[RFC4485] Rosenberg, J. and H. Schulzrinne, "Guidelines for Authors
of Extensions to the Session Initiation Protocol (SIP)",
RFC 4485, DOI 10.17487/RFC4485, May 2006,
<https://www.rfc-editor.org/info/rfc4485>.
[RFC8055] Holmberg, C. and Y. Jiang, "Session Initiation Protocol
(SIP) Via Header Field Parameter to Indicate Received
Realm", RFC 8055, DOI 10.17487/RFC8055, January 2017,
<https://www.rfc-editor.org/info/rfc8055>.
Srivastava Expires 17 February 2027 [Page 9]
Internet-Draft STIR SIP Request Context August 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8224] Peterson, J., Jennings, C., Rescorla, E., and C. Wendt,
"Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 8224,
DOI 10.17487/RFC8224, February 2018,
<https://www.rfc-editor.org/info/rfc8224>.
[RFC8225] Wendt, C. and J. Peterson, "PASSporT: Personal Assertion
Token", RFC 8225, DOI 10.17487/RFC8225, February 2018,
<https://www.rfc-editor.org/info/rfc8225>.
[RFC9970] Peterson, J. and C. Wendt, "Connected Identity for Secure
Telephone Identity Revisited (STIR)", RFC 9970,
DOI 10.17487/RFC9970, June 2026,
<https://www.rfc-editor.org/info/rfc9970>.
14. Informative References
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474,
DOI 10.17487/RFC4474, August 2006,
<https://www.rfc-editor.org/info/rfc4474>.
[I-D.hardman-verifiable-voice-protocol]
Hardman, D., "Verifiable Voice Protocol", Work in
Progress, Internet-Draft, draft-hardman-verifiable-voice-
protocol-07, 19 March 2026,
<https://datatracker.ietf.org/doc/draft-hardman-
verifiable-voice-protocol/>.
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
Aviral Srivastava
Srivastava Expires 17 February 2027 [Page 10]
Internet-Draft STIR SIP Request Context August 2026
Email: aviralyash27@gmail.com
Srivastava Expires 17 February 2027 [Page 11]