Session Initiation Protocol (SIP) Via Header Field Parameter to Indicate Received Realm
Extracted elements (17)
An Inter Operator Identifier (IOI) cannot be used to identify adjacent networks because IOIs are not defined for enterprise networks. The 'received-realm' parameter was introduced to fill this gap, allowing both operator and enterprise adjacent networks to be identified using a locally scoped token.
The JWS Payload is detached from the serialized JWS conveyed in the header field parameter (per RFC 7515 Appendix F) because the payload information is already present in other SIP header fields. This avoids redundant encoding while still cryptographically binding the realm claim to the specific SIP message.
The 'received-realm' mechanism is scoped entirely within a single operator's network; the operator identifier value's scope is only within the network that inserts it. Cross-network use is explicitly prohibited by the requirement to discard parameters received from outside the operator network.
A SIP entity acting as a network entry point that adds the 'received-realm' parameter MUST also calculate a JWS and add the calculated JWS Header and JWS Signature as the 'jws' part of the Via header field parameter.
A SIP entity consuming the 'received-realm' value MUST first recalculate the JWS and verify it matches the received JWS. If there is a mismatch, the entity MUST discard the received parameter; it MAY also take additional actions such as rejecting the SIP request based on local policy.
For JWS serialization, all claims MUST be encoded using lowercase characters, MUST appear in the order listed in Section 5.4, all claims except 'sip_date' MUST be StringOrURI JSON string values, 'sip_date' MUST be a JSON NumericDate, and the payload MUST follow JWK thumbprint construction rules (RFC 7638, Section 3, Step 1 only).
The JWS Header MUST include the 'typ' parameter with value 'JWT' and the 'alg' parameter set to the algorithm used to calculate the JWS. Operators must agree on a set of supported algorithms and use only those with registered 'alg' parameter values.
The JWS Payload MUST include six claims: 'sip_from_tag' (From tag), 'sip_date' (Date header in NumericDate format), 'sip_callid' (Call-ID), 'sip_cseq_num' (CSeq numeric value), 'sip_via_branch' (Via branch parameter), and 'sip_via_opid' (operator identifier from the same Via field).
The mechanism defined in this specification MUST only be used by SIP entities that are able to verify from which adjacent upstream network a SIP request is received. The verification mechanism itself is outside the scope of this specification.
The operator identifier is a case-insensitive token whose scope is limited to the network that inserts the value. It represents the adjacent upstream operator and forms the first part of the 'received-realm' parameter, separated from the JWS by a colon character.
The Via 'received-realm' header field parameter combines an operator identifier (representing the adjacent network) and a serialized JSON Web Signature (JWS). The JWS Payload consists of the operator identifier and selected SIP information element values; the payload is detached from the serialized JWS and replaced by an empty string.
RFC 8055 registers six new JWT claims in the IANA 'JSON Web Token Claims' sub-registry: sip_from_tag, sip_date, sip_callid, sip_cseq_num, sip_via_branch, and sip_via_opid, all referencing RFC 8055 and RFC 3261.
RFC 8055 registers the 'received-realm' parameter in the IANA 'Header Field Parameters and Parameter Values' sub-registry (created by RFC 3968), associated with the Via header field, with no predefined values.
A SIP entity MUST NOT use the adjacent network information if there is a mismatch between the JWS Signature received in the SIP header field and the JWS Signature recalculated by the receiving entity. This prevents unauthorized injection of realm identity.
Operators MUST use a key management policy that protects against unauthorized access to JWS signing keys stored in network nodes and against cryptanalysis attacks using captured wire data. The signing key must be known only to entities that sign/add and verify/consume the 'received-realm' parameter.
The 'received-realm' parameter MUST be discarded if received from another (non-operator-internal) network, and MUST only be inserted by SIP entities that can verify the adjacent upstream network. The parameter is intended to be inserted, signed, verified, and consumed entirely within a single operator's network.
The 'received-realm' parameter is encoded as a quoted string containing an operator identifier token, a colon, and a JWS with the format 'header..signature' (base64 characters). The two adjacent dots represent the detached (empty) payload position. ABNF: received-realm = "received-realm" EQUAL LDQUOT op-id COLON jws RDQUOT.