A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)
updated by
- rfc-8217 — Clarifications for When to Use the name-addr Production in SIP Messages
Extracted elements (27)
A credit-based authorization mechanism is used to prevent amplification attacks: clients must generate bandwidth comparable to what the relay will generate when sending MESSAGE requests. This is enforced by restricting additions to one recipient URI per transaction (one URI per HTTP transaction for XCAP, one contact per REGISTER).
MESSAGE requests for permission SHOULD include a human-readable body part alongside the XML permission document, so that legacy user agents that do not understand permission documents can still display the request and allow the user to manually click a grant/deny URI.
REGISTER transactions are treated as a special translation type because traditionally they simultaneously set up a translation and authorize it. This creates vulnerability to third-party registration attacks where an attacker binds their AoR to a victim's contact URI, causing the victim to receive unsolicited traffic.
Return routability tests are included as an authentication method because SIP identity is not yet widely available on the public Internet. They provide a better-than-nothing security level by using cryptographically unguessable URIs delivered over SIPS, with the expectation that relays will migrate to SIP identity as it becomes available.
P-Asserted-Identity is only applicable inside an administrative domain with previously agreed-upon policies (trusted networks), as described in RFC 3325. It cannot be used across administrative domains for authenticating permission grants.
The framework is designed with backwards compatibility so legacy user agents (those not implementing RFC 5360) can act as both clients and recipients with acceptable functionality. However, full functionality requires implementing the Pending Additions event package (RFC 5362), the permission document format (RFC 5361), and the header fields defined here.
A relay executing a translation SHOULD add a Trigger-Consent header field to the outgoing request. The URI in that header field MUST have a target-uri parameter identifying the translation's target URI, enabling recipients to revoke permissions even if they have lost the original permission document URIs.
A relay that receives a request-contained URI list with a URI for which it has no permissions MUST NOT perform the translation and SHOULD return a 470 (Consent Needed) response with a Permission-Missing header field listing the unauthorized URIs.
All relays MUST implement this consent framework in order to avoid being used to perform attacks such as amplification attacks. This applies to any relay performing translations.
Entities implementing this framework MUST support the format for permission documents defined in RFC 5361 and MAY support other formats. Relays MUST support the use of SIP and SIPS URIs in permission documents and MAY support HTTP and HTTPS URIs.
If a recipient is removed from a relay's translation logic, the relay SHOULD delete the permissions related to that recipient. It is also RECOMMENDED that relays request recipients to refresh permissions periodically; if a recipient fails to refresh, the relay SHOULD delete those permissions.
Implementations of store-and-forward servers MUST provide a mechanism for delivering encrypted and integrity-protected messages to their user agents, to protect the unguessable URIs used in permission documents when SIPS cannot be used end-to-end.
MESSAGE requests sent to request permissions MUST include a permission document and SHOULD include a human-readable part in their bodies. The human-readable part contains the same information as the permission document in plain text, enabling legacy UAs to display and act on it.
Relays implementing this framework MUST NOT allow clients to add more than one recipient URI per transaction. If a client using XCAP attempts to add more than one URI in a single HTTP transaction, the XCAP server SHOULD return an HTTP 409 (Conflict) response.
Relays MUST ensure that the SIP PUBLISH or HTTP GET request received was generated by the actual recipient of the translation and not by an attacker. Four authentication methods are available: SIP identity, P-Asserted-Identity, return routability test, or SIP digest.
Relays MUST obtain permissions from potential recipients before adding them to their translation logic. Relays request permissions from potential recipients using MESSAGE requests containing a permission document.
Relays using a return routability test MUST send the MESSAGE request with the permission document to a SIPS URI. Permission documents sent by such relays MUST only contain secure URIs (SIPS and HTTPS), and a portion of those URIs MUST be cryptographically random with at least 32 bits of randomness.
When a user agent is registered by a third party and cannot use SIP Identity, P-Asserted-Identity, or SIP digest to prove ownership of the recipient URI, return routability MUST be used as the authentication mechanism.
When using SIP identity or P-Asserted-Identity, the relay MUST check that the originator of the PUBLISH request is the owner of the recipient URI in the permission document. Otherwise, the PUBLISH request SHOULD be responded with a 401 (Unauthorized) and MUST NOT be processed further.
A permission document contains: the identity of the sender, the identity of the original recipient (target URI), the identity of the final recipient (recipient URI), URIs to grant permission, and URIs to deny permission. The recipient URI MUST NOT be wildcarded, though sender identity fields may use wildcards.
A relay is any SIP server (proxy, B2BUA, or hybrid) that receives a request, translates its Request-URI (the target URI) into one or more next-hop URIs (recipient URIs), and delivers the request to those URIs. The consent problem arises specifically from this translation operation.
The 470 (Consent Needed) response code indicates that a request contained a URI list with at least one URI for which the relay had no permissions. A UAS generating this response SHOULD include a Permission-Missing header field listing the URIs lacking permissions.
IANA registered four items under the SIP Parameters registry: response code 470 (Consent Needed) in the Methods and Response Codes subregistry; header fields Trigger-Consent and Permission-Missing (no compact forms) in the Header Fields subregistry; and the 'target-uri' parameter for the Trigger-Consent header field in the Header Field Parameters subregistry.
Even with client authentication and authorization mechanisms in place (e.g., SPAM prevention per RFC 5039), authorized clients can still add recipients to a translation without those recipients' consent. This is why relays performing translations MUST implement this framework regardless of other security measures.
Permission documents can reveal sensitive information and attackers may attempt to modify them to cause clients to grant or deny unintended permissions. Relays SHOULD use strong integrity protection and confidentiality when sending permission documents; end-to-end S/MIME is RECOMMENDED, with TLS/SIPS as a fallback for hop-by-hop protection.
The Permission-Missing header field carries URIs for which a relay had no permissions. Its BNF is: Permission-Missing = 'Permission-Missing' HCOLON per-miss-spec *( COMMA per-miss-spec ); per-miss-spec = ( name-addr / addr-spec ) *( SEMI generic-param ).
The Trigger-Consent header field carries a SIP or SIPS URI with a required target-uri parameter (a quoted URI) identifying the translation's target URI. BNF: Trigger-Consent = 'Trigger-Consent' HCOLON trigger-cons-spec *( COMMA trigger-cons-spec ); trigger-cons-spec = ( SIP-URI / SIPS-URI ) *( SEMI trigger-param ).