The Session Initiation Protocol (SIP) Referred-By Mechanism
updated by
- rfc-8217 — Clarifications for When to Use the name-addr Production in SIP Messages
Extracted elements (26)
S/MIME protection of the Referred-By token is optional because some systems either do not need trust validation of this information or can establish trust through other means. Implementations not using S/MIME must provide their own defenses against falsification, eavesdropping, and replay attacks.
The 428 error response (from RFC 3261's authenticated identity management) is explicitly noted as NOT appropriate for use by a refer target requesting a Referred-By token — 428 is needed to request an authentication token from the referee, while 429 is defined specifically for this purpose.
The sip-clean-msg-id grammar is defined as the intersection of SIP gen-value and RFC 2822 msg-id expansions, with double-quotes replaced by angle brackets to derive the MIME Content-ID. This ensures the cid parameter is valid both as a SIP header parameter and as a MIME Content-ID reference.
In nested REFER scenarios (e.g., A refers B to send a REFER to C which sends an INVITE to D), the original Referred-By token from A passes through all intermediaries unchanged. B does not provide its own Referred-By token to C; A's token is forwarded by B and C all the way to D.
A REFER request containing a Referred-By token MUST contain a Referred-By header field value with a cid parameter value equal to the Content-ID of the body part containing the token.
A REFER request MUST NOT contain more than one Referred-By header field value.
A refer target MUST treat a Referred-By token with an invalid signature as an invalid token and MUST reject an otherwise well-formed request with an invalid Referred-By token with a 429 error response.
A refer target SHOULD verify that the request it receives matches the Refer-To header field in the token, including at least the request method and any end-to-end header field values. The URI in Refer-To may differ from request URI due to re-targeting.
A referee accepting a REFER to a SIP URI (sip: or sips:) MUST copy any Referred-By header field value and token into the referenced request without modification.
A referee SHOULD NOT reject a REFER request that contains a Referred-By token encrypted to a key it does not possess simply because it cannot decrypt the token, as per RFC 3893 the referee should still be able to verify the signature.
If a refer target provides Referred-By header information to its user without a valid token present, it MUST notify the user that the information is suspect.
Proxies MUST NOT remove or modify Referred-By header field values; they do not need to be able to read them.
The Referred-By token body part MUST be identified with a MIME Content-ID field, and the sipfrag inside it MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request.
The sip and sips URI schemes MUST be treated as equivalent when comparing token To header field URIs against subjectAltNames from the referee's certificate.
The subjectAltName of the certificate used for S/MIME operations on the token SHOULD exactly match the identity claimed in the referrer-uri in the Referred-By header field in the token.
The token SHOULD NOT contain the Call-ID header field from the REFER request (not useful to refer target and may be an information leak), and SHOULD NOT contain the From header field since identity is represented in the Referred-By header.
When including the To header field in the token (which identifies the referee), the referrer MUST have cryptographically identified the referee first, e.g., via TLS certificate inspection or S/MIME encryption of the Refer-To header.
Including the To header field in the Referred-By token reveals the referee's identity. If the referrer encrypts the token to the refer target, the referee (Carol) may not even be aware that her identity is included, defeating her desire for anonymity. Carol must reject REFER requests with tokens she cannot inspect to protect herself.
The 429 'Provide Referrer Identity' client error response is used by a refer target to indicate that a valid Referred-By token must be provided. The referee forwards this to the referrer via a NOTIFY containing a message/sipfrag body with 'SIP/2.0 429 Provide Referrer Identity'.
The Referred-By header field carries a SIP URI representing the identity of the referrer and optionally the Content-ID (cid parameter) of a body part containing the Referred-By token. It can appear in any SIP request but is meaningless for ACK and CANCEL.
The Referred-By token is an Authenticated Identity Body (AIB) as defined in RFC 3893, carried as a MIME body part identified by a Content-ID. It MUST contain copies of the Refer-To, Referred-By, and Date header fields from the REFER request, S/MIME signed and optionally encrypted.
This document registers the 'Referred-By' SIP header field (compact form 'b') in the IANA SIP Parameters header field registry, and registers the 429 'Provide Referrer Identity' response code in the Request Failure 4xx section of the SIP response code registry.
A cut-and-paste attack is possible with minimal tokens: if Mallory sees Alice refer Carol to a target using a token without a To field, he can copy that token into his own request and falsely appear to have been referred by Alice. Mitigation requires protecting the REFER with TLS or S/MIME, or including the To header field in the token.
The referee is necessarily an eavesdropper of the Referred-By information and is positioned to launch man-in-the-middle attacks. Unlike proxies managed by service providers, a referee endpoint's behavior is entirely under a single user's control, making malicious behavior more feasible.
The S/MIME mechanism protects against falsified referred-by information injection, replay of stale assertions (timestamp covered by signature), and use in unrelated requests (Refer-To header covered by signature). However, it cannot prevent the referee from deleting all referred-by information, which transforms the request into an ordinary SIP request.
The Referred-By header field grammar: 'Referred-By = ("Referred-By" / "b") HCOLON referrer-uri *( SEMI (referredby-id-param / generic-param) )' where referredby-id-param = "cid" EQUAL sip-clean-msg-id and sip-clean-msg-id = LDQUOT dot-atom "@" (dot-atom / host) RDQUOT. The compact form is 'b'.