A Privacy Mechanism for the Session Initiation Protocol (SIP)
Extracted elements (30)
The 'none' priv-value allows users to explicitly opt out of pre-provisioned privacy profiles when routing through a privacy service that would otherwise apply privacy functions by default. This gives users positive control over privacy application.
The 'user' privacy level is typically set only by intermediaries to communicate that user-level privacy functions must be provided by the network because the user agent is unable to provide them itself (e.g., legacy clients). User agents MAY set it for REGISTER requests but SHOULD NOT set it for other requests.
Two complementary principles guided the design: users are empowered to hide their identity and related personal information when issuing requests, but intermediaries and designated recipients are entitled to reject requests whose originator cannot be identified. This prevents anonymous privacy from being an unconditional right.
Using an IP address rather than a hostname in Contact/Via URIs is not recommended for privacy: reverse-resolving such addresses is generally trivial, and substituting an IP address could introduce complications for NAT/firewall traversal and DNS-dependent services.
Some legacy SIP clients might consider it an error condition if the URI value in the From header is altered between a request and its response, even though current SIP dialog matching uses only the tags rather than whole header field values. Privacy services performing user-level privacy SHOULD act as a B2BUA to account for this.
For header privacy, a privacy service SHOULD remove all Via headers added prior to the request's arrival (Via stripping) and add a single Via header representing itself. It SHOULD replace the Contact header value with a URI that dereferences to the privacy service, and that replacement URI MUST dereference to the privacy service.
For user-level privacy, the privacy service MUST remove non-essential informational headers added by the user agent, including Subject, Call-Info, Organization, User-Agent, Reply-To, and In-Reply-To.
If a user agent believes it is sending a request directly to a privacy service, it SHOULD include a Proxy-Require header containing the option-tag 'privacy', especially when the 'critical' priv-value is present in the Privacy header.
It is highly RECOMMENDED that user agents use network or transport layer security such as TLS when contacting a privacy service. Users SHOULD establish a direct (single pre-loaded Route header) connection to a privacy service to allow certificate inspection and reduce exposure of private information.
It is RECOMMENDED that user agents seeking anonymity use a display-name of "Anonymous" in the From header field.
Privacy services MUST implement support for the 'none' and 'critical' privacy tokens. If the 'critical' privacy level is present and the privacy service cannot fulfill all requested privacy levels, it MUST fail the request with a 500 (Server Error) response.
Privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header if the Privacy header value of 'none' is specified in a message.
Requesting session-level privacy without end-to-end security for session traffic (e.g., SRTP for RTP media) is NOT RECOMMENDED, because the anonymizer itself becomes party to the communications.
The host portion of URIs used in routing subsequent requests (e.g., Contact header) SHOULD NOT be altered by the user agent for privacy reasons. If these headers require anonymization, the user should request that service from a privacy service intermediary.
The hostname value 'anonymous.invalid' SHOULD be used for anonymous URIs. The full recommended form of the anonymous From header is: From: "Anonymous" <sip:[email protected]>;tag=1928301774, and this From header MUST contain a valid and unique 'tag=' parameter.
User agents SHOULD include a Privacy header when network-provided privacy is required. Intermediaries SHOULD only add Privacy headers if operating at a user's behest. An intermediary MUST NOT modify the Privacy header in any way if the 'none' priv-value is already specified.
User agents SHOULD not include optional headers that might divulge personal information (e.g., Call-Info). Users SHOULD populate URIs in accordance with anonymization guidelines and SHOULD create an anonymous From header field for requests seeking privacy.
User agents SHOULD substitute the IP address or hostname frequently appended to Call-ID values with a suitably long random value, as the Call-ID header is frequently constructed in a manner that reveals the originating client's IP address or hostname.
When a Privacy header is constructed, it MUST consist of either the value 'none', or one or more of the values 'user', 'header', and 'session' (each appearing at most once), which MAY in turn be followed by the 'critical' indicator. User agents MUST NOT populate any other priv-values in a Privacy header that contains a value of 'none'.
When a privacy service performs a function corresponding to a privacy level, it SHOULD remove that priv-value from the Privacy header. When the last priv-value (not counting 'critical') is removed, the entire Privacy header MUST be removed from the message.
When further requests or responses associated with a dialog reach the privacy service, it MUST restore values for the Via, Record-Route/Route, or Contact headers that it previously removed for privacy purposes.
When session privacy is requested, user agents MUST NOT encrypt SDP bodies in messages, because the privacy service acting as a B2BUA needs to access and modify the SDP to anonymize session traffic.
When the privacy service removes the entire Privacy header from a request, it MUST also remove any 'privacy' option-tag from the Proxy-Require header field of the request.
When user-level privacy functions require modification of dialog-matching headers, the privacy service SHOULD act as a transparent back-to-back user agent and MUST persist the former values of dialog-matching headers, restoring them in messages sent to the originating user agent.
Authentication mechanisms such as SIP Digest authentication are outside the scope of the privacy considerations in this document. Users that do not wish to reveal their identity to servers issuing authentication challenges MAY elect not to respond to such challenges.
The Privacy header field is defined to allow user agents to request specific privacy handling for SIP requests and responses. Its syntax is: Privacy-hdr = 'Privacy' HCOLON priv-value *(";" priv-value), where priv-value = "header" / "session" / "user" / "none" / "critical" / token.
This document creates an IANA registry for Privacy header priv-value tokens, indexed by token name with a short semantic description. Initial values are: user, header, session, none, and critical. New values require IETF Consensus including RFC publication per RFC 2434.
This document registers a new SIP header field 'Privacy' (no compact form defined) in the IANA SIP parameters header sub-registry, and defines a new SIP option-tag 'privacy' representing support for the extensions defined in this document.
Messages requesting privacy require both confidentiality and integrity. Without integrity, privacy functions could be downgraded or eliminated; without confidentiality, eavesdroppers could see the personal information the user asked the privacy service to obscure. Users should only trust privacy services that are accountable to them.
Operators of privacy services should be aware that in the eyes of downstream entities, a privacy service will be the only source to which anonymous messages can be traced, placing legal and operational accountability on the privacy service operator.