RFC 3323

A Privacy Mechanism for the Session Initiation Protocol (SIP)

📅 published December 2002, from ietf

RFC 3323: A Privacy Mechanism for the Session Initiation Protocol (SIP) 🎀

  • Series: Network Working Group 🧚
  • Number: RFC 3323
  • Author: J. Peterson, of Neustar 💅
  • Category: Standards Track 👑
  • Date: November 2002 🌸
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates ✨

Status of This Memo 📜

okay so this doc is an Internet standards track protocol spec for the Internet community 🫶 it's literally asking people to talk about it and send in suggestions for making it better. if you want to know where it stands officially, check the current edition of "Internet Official Protocol Standards" (that's STD 1) 🔍. and the good news is that distribution of this memo is unlimited, so share it with everyone 💖

Copyright (C) The Internet Society (2002). All Rights Reserved. 💜

Abstract ✨

this doc is all about new privacy mechanisms for the Session Initiation Protocol (SIP) 🦋 it gives guidelines for building messages that don't spill personal identity info everywhere 🙈 it also defines a new "privacy service" logical role for intermediaries, because there are some privacy needs that user agents just can't handle on their own 💅 and finally it lays out how a user can ask a privacy service for specific functions 🔥

Table of Contents 🍓

1.      Introduction . . . . . . . . . . . . . . . . . . . . . . .  2
2.      Terminology  . . . . . . . . . . . . . . . . . . . . . . .  3
3.      Varieties of Privacy . . . . . . . . . . . . . . . . . . .  4
3.1     When is Privacy Necessary? . . . . . . . . . . . . . . . .  5
3.2     User-Provided Privacy  . . . . . . . . . . . . . . . . . .  6
3.3     Network-Provided Privacy . . . . . . . . . . . . . . . . .  7
4.      User Agent Behavior  . . . . . . . . . . . . . . . . . . .  7
4.1     Constructing Private Messages  . . . . . . . . . . . . . .  8
4.1.1   URIs, Display-Names and Privacy  . . . . . . . . . . . . .  8
4.1.1.1 Display-Names  . . . . . . . . . . . . . . . . . . . . . .  9
4.1.1.2 URI Usernames  . . . . . . . . . . . . . . . . . . . . . .  9
4.1.1.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . .  9
4.2     Expressing Privacy Preferences . . . . . . . . . . . . . . 11
4.3     Routing Requests to Privacy Services . . . . . . . . . . . 12
4.4     Routing Responses to Privacy Services  . . . . . . . . . . 13
5.      Privacy Service Behavior . . . . . . . . . . . . . . . . . 14
5.1     Header Privacy . . . . . . . . . . . . . . . . . . . . . . 16
5.2     Session Privacy  . . . . . . . . . . . . . . . . . . . . . 17
5.3     Applying User-Level Privacy Functions. . . . . . . . . . . 18
6.      Security Considerations  . . . . . . . . . . . . . . . . . 19
7.      IANA Considerations  . . . . . . . . . . . . . . . . . . . 19
        Normative References . . . . . . . . . . . . . . . . . . . 20
        Informative References . . . . . . . . . . . . . . . . . . 20
        Author's Address . . . . . . . . . . . . . . . . . . . . . 21
        Acknowledgments  . . . . . . . . . . . . . . . . . . . . . 21
        Full Copyright Statement . . . . . . . . . . . . . . . . . 22

1. Introduction 🦋

this doc is all about privacy requirements and mechanisms for SIP 💖

so privacy, as this doc defines it, is keeping a person's identity (plus related personal info) hidden from one or more parties in a communication exchange, specifically a SIP dialog 🫣. those parties can include the intended destination(s) of messages and/or any intermediaries handling them 🧚. and here's the thing: as identity is defined in this doc, hiding a user's identity will, among other things, leave the other parties in the dialog unable to send new SIP requests to that user outside the context of the current dialog 😭

in SIP, identity usually shows up as a SIP URI plus an optional display-name 💅 a SIP address-of-record looks kinda like an email address with a SIP URI scheme (for example, sip:alice@atlanta.com) ✨ and a display-name is a string with a name for the identified user (for example, "Alice") 🌈. these identities usually show up in the To and From header fields of SIP requests and responses 🍓. and a user can have a bunch of identities they use in different contexts, which is giving multi-personality energy 👑

there are also loads of other spots in SIP messages where identity-related info can leak 👀 for example, the Contact header field has a SIP URI, and that one is often just as revealing as the address-of-record in the From 😳. some headers can be hidden by the originating user agent as a matter of local policy without messing with how SIP works 🙌. BUT certain headers get used to route later messages in a dialog, so they have to be filled with functional data 😤 no hiding those ones!

and it gets even messier because of proxy servers (also called "intermediaries" or "the network" in this doc) 🌐 they add their own headers, like Record-Route and Via 🧁. that info could accidentally reveal something about who sent the message 🙈. like, a Via header might show the service provider a user sends requests through, and that could totally hint at the user's identity to some recipients 💀. so intermediaries are also crucial to making privacy work in SIP 🫶

two complementary principles guided the design of this privacy mechanism ✨. first, users get to hide their identity and related personal info when they send requests 🙌. second, intermediaries and designated recipients of requests are allowed to reject requests whose originator can't be identified 🔒. both matter, bestie!

the privacy properties of only the specific headers listed in the core SIP specification ([1]) are discussed in this doc, not headers from any existing or planned extension 📚. BUT the privacy mechanisms here can be extended to support extensions 🌸

there are other parts of the general SIP privacy problem this doc doesn't cover 🙅‍♀️. most importantly, the mechanisms for managing the confidentiality of SIP headers and bodies, and the security of session traffic, aren't reconsidered here 😌. those problems are already handled well enough by the baseline SIP spec and related docs, so no new mechanisms are needed for them 💅

this doc starts with a section giving a general framework and architecture for privacy in SIP (Section 3) 🗺️, then covers user agent behavior (Section 4) and privacy service behavior (Section 5) 🎀

2. Terminology 📖

in this doc, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be read as described in BCP 14, RFC 2119 [2] 🧠. they show the requirement levels for compliant SIP implementations, so they matter a LOT 🔥

3. Varieties of Privacy 🌈

a user can have many identities used in different contexts 🦋. generally, identities are addresses-of-record that are bound to particular registrars (run by the administrators of a domain) where SIP user agents register 📍. the operators of these domains could be employers, service providers, or unaffiliated users themselves 🧑‍💻

when a user voluntarily asserts an identity in a request, they're claiming they can receive requests sent to that identity in that domain 🫡. strictly speaking, privacy means restricting the distribution of a specific identity and related personal info from some particular party or parties who could be recipients of the message 🙈. specifically, there are scenarios where someone who wants anonymity might:

  • send a message and withhold an identity from the final destination(s) while still giving an identity to one or more intermediaries 🧚
  • send a message and withhold their identity from some or all intermediaries, but still give an identity end-to-end to the final destination(s) 🎀
  • withhold identity from both intermediaries and final destination(s) 🫥

withholding an identity means the other parties would be unable to, for example, try to start a new dialog with the anonymous party later on 🚫. BUT the anonymous party still has to be able to receive responses and new requests during the dialog they're already in 💖

it can also be important to restrict identity info in both requests and responses 🪄. at first, it might seem weird to say a response has privacy concerns, since presumably the originator of the request already knows who they tried to contact, so the respondent's identity can hardly be confidential 🤔. but some personal info in responses (like the contact address where the respondent is currently registered) is subject to privacy concerns, and these mechanisms can handle that too 🔐 ✨

3.1 When is Privacy Necessary? 🤔

okay so, when would you even need privacy? 🙈 users might have totally valid reasons to keep their identity on the down-low from someone, like:

  • wanting to reach a certain party while keeping their name out of it, especially if the info they're sharing is something they'd rather not be linked to 🫣
  • being scared that their identity or personal info getting out to certain networks or destinations could make them a magnet for spam ads, legal trouble, or other yikes situations 😬
  • not wanting session participants to see the identity that network intermediaries know them by for billing and accounting 💸

when a user agent sends a request through a proxy server, the originator might not be able to predict where the message actually ends up 🌀 so users are advised not to judge their privacy needs by where they think a message is going. for example, someone might send a request to telephone number and figure it'll land at a station in the public switched telephone network (PSTN) that can't read stuff like SIP Contact headers, so it's fine to leave those in the clear. but that request could totally get retargeted by the network to a native SIP endpoint where Contact headers are super readable 👀 main character plot twist.

this document describes three levels of privacy: one level of user-provided privacy, and two levels of network-provided privacy (header privacy and session privacy) ✨ so how much privacy does a user need for a session? honestly, if you're seeking privacy, you're gonna want as much as you can get 💅 but if a user doesn't know of any privacy service, they've gotta be happy with user-provided privacy alone. same vibe if someone finds an anonymization service that can give session privacy but can't lock down the session traffic, so the anonymizer could still eavesdrop. they might decide losing session privacy is the lesser evil 😤 the user might also know about special conditions in the architecture where their user agent lives that could make one or more privacy concerns not a thing anymore 🧚

ngl a user isn't always the best judge of when privacy is needed, even in ideal conditions. so in some architectures, intermediaries might apply privacy without the user explicitly asking for it on each message. by sending a request through intermediaries that can play a privacy role, the user is kinda tacitly okaying privacy functions being used whenever they're needed 🫶

it's also super important that users get that intermediaries might not be able to deliver the privacy functions they ask for 🙃 requests for privacy might not get honored because of legal constraints, features that aren't implemented or are misconfigured, or other exceptional conditions. no cap, that stuff happens.

also, just like it's a user's prerogative to hide their identity, proxy servers and other users get to refuse requests from people they can't identify 🔒 so users shouldn't automatically withhold their identity from every request and response. if nobody can figure out who sent a request, that's frequently grounds for rejection. privacy should only be requested when the user actually needs it 💖

and one more thing: hiding some info in signaling might not be necessary for every user agent to be private 🌸 for example, user agents might get their IP addresses and hostnames dynamically, and those dynamic addresses might not reveal anything about the user at all. in those cases, restricting access to hostnames (as described in Section 4.1.1.3) is unnecessary.

3.2 User-Provided Privacy

a user agent can actually provide a certain amount of privacy all by itself 💅 for example, the baseline SIP specification lets a user agent fill the From header field of a request with an anonymous value. users can take similar steps to avoid revealing any other unnecessary identity info in related SIP headers (more on this in Section 4.1.1).

a user might have different privacy needs for a message that goes through intermediaries versus one that goes directly end-to-end 🦋 they might want to hide stuff from intermediaries that the final destination can still see, or the other way around. for example, using baseline SIP mechanisms, a user agent can encrypt SIP bodies end-to-end so intermediaries can't read them. if a SIP message won't pass through any intermediaries, though, that step might not be necessary (lower-layer security, without adding security for SIP bodies, could be enough) ✨

also, if a dialog goes directly end-to-end between participants, it won't be possible to hide the participants' network addresses 🙈 so keep that in mind!

3.3 Network-Provided Privacy

if a user is sending a request through intermediaries, their user agent can only hide its identity to a limited extent without the intermediaries' help 🥺 and some info can only be hidden from destination endpoints if an intermediary is trusted to strip it out.

because of all that, a user needs a way to ask intermediaries for privacy 🎀 this lets them signal which privacy services they want and make sure their call gets routed to an intermediary that can actually provide them. a user might already know a specific third-party anonymizing host they have a relationship with, or they might ask their local administrative domain to handle privacy services for them 🧚

intermediaries can also be empowered to apply privacy to a message with zero explicit signaling from the originating user 👑 that's because user agents aren't always aware of, or able to request, privacy when it's needed.

4. User Agent Behavior ✨

there are three different ways a user agent can help make a request private 💜 it can fill headers with values that match its privacy requirements, ask the network for extra privacy services, or use cryptographic confidentiality to protect headers and bodies. heads up: that last one is outside the scope of this document 🙈

the mechanisms in this section assume the user agent is configurable enough that the user can pick header values and set up privacy preferences (ideally on a per-call basis) 💅 if that's not the case, the user might be able to route their call through a privacy service that's set up to groom signaling from that user agent, so it can provide some of the functions described below (see Section 5).

4.1 Constructing Private Messages

privacy starts with the user agent 🌈 most of the steps needed to hide private info about a message's sender are, appropriately enough, the sender's job.

the following SIP headers, when a user agent generates them, can directly or indirectly reveal identity info about the message's originator: From, Contact, Reply-To, Via, Call-Info, User-Agent, Organization, Server, Subject, Call-ID, In-Reply-To and Warning 👀 also, using an authentication system (like the SIP Digest authentication method described in [1]) usually means revealing identity to one or more parties. see Section 6 for more on that.

step one, and the most obvious one: user agents SHOULD not include any optional headers that might spill personal info 🙅‍♀️ there's zero reason for a user seeking privacy to include a Call-Info. step two: the user SHOULD fill in URIs throughout the message following the guidelines in Section 4.1.1. for example, users SHOULD create an anonymous From header field for the request. step three: users MAY also need to request certain privacy functions from the network, as described in Section 4.2 ✨

the Call-ID header is a special case 🫣 it's often built in a way that reveals the IP address or hostname of the originating client. user agents SHOULD swap out that IP address or hostname that usually gets appended to the Call-ID value for a suitably long random value (the value used as the 'tag' for the From header of the request might even get reused) 🎲

if a user wants to hide any of the headers above from intermediaries only, without keeping them from the message's final destination, users MAY also put legitimate values for those headers inside encapsulated message/sip S/MIME bodies, as described in Section 23 of [1] 🔐

4.1.1 URIs, Display-Names and Privacy

a certain amount of privacy can come from filling SIP headers with URIs and display-names that don't reveal any identity info 💖 in some header fields (like Reply-To and From), URIs aren't used for further signaling within the current dialog. in others, like Contact, a bad URI will break routing for later requests in the dialog, so be careful there!

4.1.1.1 Display-Names

it's pretty common in email and other apps to use an assumed name in the display-name part of the From header field 🎭 outside of a business context (especially in stuff like instant messaging or Internet gaming), using aliases like that probably won't make anyone distrust you.

it is RECOMMENDED that user agents seeking anonymity use a display-name of "Anonymous" 🕶️

4.1.1.2 URI Usernames

the structure of a URI can reveal or hide a LOT of personal info 😳 compare these two:

sip:jon.peterson@neustar.biz

and

sip:a0017@anonymous-sip.com

from the first one, you can easily guess the person's full name and employer 💼 from the second, you learn absolutely nothing except that the party wants to stay anonymous 🫥 in some cases, you can get enough anonymity just by picking an oblique URI. today, the SIP specification recommends using a URI with "anonymous" in the user portion of the From header 🧢

in some URIs, like the ones that show up in Contact headers, it MAY also make sense to leave out the username completely and just give a hostname, like:

sip:anonymous-sip.com

4.1.1.3 URI Hostnames and IP Addresses ✨

okay so this doc is assuming the user who wants privacy still wants to get future requests and responses inside this same dialog 🦋, but doesn't want to hand out an identity that could be used to send brand-new requests outside that dialog 🙈. So the treatment has to be different for URIs that route further requests in the dialog versus URIs that route new requests outside it. it's giving two different rules for two different jobs 💅

for headers that say how the user wants to be contacted for future sessions (like From), it's not immediately obvious why the hostname would need changing. like, if the username is 'anonymous', requests won't be routable to the anonymous user anyway 💀

sometimes though, changing only the username isn't enough 😭 a user's SIP service provider might totally reveal who they are (say it reflects a small company or a personal domain). so even though the URI in the From header wouldn't dereference to the anonymous user, humans could easily guess the identity and figure out the proper form of their address-of-record. not iconic 🙃

so for these reasons, the hostname anonymous.invalid SHOULD be used for anonymous URIs (see [3] for more info about the reserved 'invalid' DNS TLD) 🧚 the full recommended From header for anonymity looks like this (and fyi this From header, like all the others, MUST contain a valid and unique 'tag=' parameter 🎀):

From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774

now for headers that say how further requests in the current dialog should be routed (namely Contact, Via, and the session info in the SDP), there's honestly not much a user can do to disguise the existing URI 😩 because users MUST provide a value that will let them receive further requests. disguising or leaving out the username (like we just talked about) might create some privacy, but the hostname is the bigger obstacle, no cap 🧱

is there much extra privacy in using an IP address instead of a hostname? 🤔 well, it does stop someone who just casually peeks at a message from grabbing info they'd otherwise see. BUT reverse-resolving addresses is generally trivial, and swapping in an IP address could cause some complications, like NAT and firewall traversal concerns 🚧 headers used for routing might also rely on certain DNS practices to provide services that would get lost if an IP address replaced the hostname. so it's a no from me, bestie 😌

so this doc recommends that the host portion of URIs used to route subsequent requests (like the ones in the Contact header) SHOULD NOT be altered by the user agent due to privacy considerations 🌸 if those headers need anonymizing, the user asks an intermediary to handle it instead, namely a privacy service 🫶

and lowkey, a lot of what we said about Contact applies to SIP headers where a hostname (not a full URI) is used for routing, like the Via header 💜

4.2 Expressing Privacy Preferences 💖

okay the vibe here: some headers a user agent literally can't hide itself, because they're needed for routing 🙃 but an intermediary could hide them for it, by taking over the job of sending messages to and from the anonymous user 🦋 so the user agent needs a way to ask the network for those privacy services. that's where this doc's brand-new SIP header comes in, Privacy, which says what privacy handling should happen for requests and responses 🎀

   Privacy-hdr  =  "Privacy" HCOLON priv-value *(";" priv-value)
   priv-value   =   "header" / "session" / "user" / "none" / "critical"
                    / token

user agents SHOULD include a Privacy header when network-provided privacy (see Section 3.3) is needed 🌈 some intermediaries might also add a Privacy header, including privacy services 👑 BUT they SHOULD only do that if they're working at the user's behest, like if the user has an admin arrangement with the intermediary's operator that it'll add the header. and an intermediary MUST NOT modify the Privacy header in any way if the 'none' priv-value is already there 🛑

the priv-values are restricted to the options above for now, though more can be defined as needed (see Section 7) ✨ each legit priv-value can show up zero or one times in a Privacy header. the current ones are:

  • header: the user wants a privacy service to hide the headers that can't be fully cleaned of identifying info without help from intermediaries (like Via and Contact) 🙈 also, the service shouldn't add any unnecessary headers that could reveal personal info about whoever sent the request.
  • session: the user wants a privacy service to anonymize the session(s) started by this message (like the ones described in an SDP [5] body) 🦋 this masks the IP address the session traffic would normally appear to come from. when session privacy is requested, user agents MUST NOT encrypt SDP bodies in messages.
warning bestie: asking for session privacy without any end-to-end session encryption raises some serious security concerns (see Section 5.2) 😭🚨
  • user: this level is usually only set by intermediaries 💅 it tells the user agent that user-level privacy functions (see Section 5.3) have to be provided by the network, probably because the user agent can't provide them itself. user agents MAY set this level for REGISTER requests, but SHOULD NOT set 'user' level privacy for other requests.
  • none: the user says "apply NO privacy functions to this message" 🛑 no matter what's pre-set in their profile or the service's default behavior. user agents can pick this when they're forced to route a message through a privacy service that would otherwise (if there's no Privacy header) apply privacy functions the user doesn't want for this one. intermediaries MUST NOT remove or alter a Privacy header whose priv-value is 'none'. and user agents MUST NOT put any other priv-values (including 'critical') in a Privacy header that has 'none' in it.
  • critical: the user is saying the privacy services for this message are critical 🔥 so if the network can't provide them, the request should get rejected. criticality can't be managed appropriately for responses.

when a Privacy header gets built, it MUST be either just the value 'none', or one or more of 'user', 'header' and 'session' (each of which MUST appear at most once) 🧩 which MAY then be followed by the 'critical' indicator.

the following table specifies extensions to Table 2 in [1] 🍓

   Header field          where   proxy ACK BYE CAN INV OPT REG
   ___________________________________________________________
   Privacy                        amrd  o   o   o   o   o   o

   Header field                        SUB NOT PRK IFO UPD MSG
   ___________________________________________________________
   Privacy                              o   o   o   o   o   o

4.3 Routing Requests to Privacy Services 🧚

the most obvious way for a user agent to get the privacy function is to send a request through an intermediary that's known to act as a privacy service 🦋 and traditionally that means setting up pre-loaded Route headers that point at the privacy service 🎀

it is RECOMMENDED that service providers pair the privacy service function with a local outbound proxy 💖 that way, users can send their privacy-requesting messages through their usual outbound route 🌸 but users should not assume the administrative domain at the request's destination would be willing and able to do the privacy service function for them 🙃 and if the originating user wants their local administrative domain to stay a secret, then they must use a third-party anonymization service outside of any of the principal administrative domains tied to the session 🕵️‍♀️

it is highly RECOMMENDED that user agents use network or transport layer security, such as TLS, when contacting a privacy service 🔐 ideally, users SHOULD set up a direct connection (that's a single pre-loaded Route header) to the privacy service 💅 this lets the user check the certificate the privacy service presents 🪪 and it gives confidentiality for requests, which cuts down the chance that the info the privacy service is supposed to obscure gets revealed before the message reaches it 🙈 a direct connection also means there's no chance intermediaries could strip out the privacy request 🛡️ and if a direct connection just isn't possible, users SHOULD use a mechanism like SIPS to guarantee lower-layer security all the way to the privacy service 🫶

if a user agent believes it's sending a request directly to a privacy service, it SHOULD include a Proxy-Require header with a new option-tag, 'privacy' 💜 especially when the 'critical' priv-value is in the Privacy header. that way, in the unlikely event the user agent sends the request to an intermediary that doesn't support this doc's extensions, the request fails instead of getting lost 🥲

one more thing, bestie: because of the special privacy service behavior (see Section 5), no later intermediaries in the request's signaling path need to support the 'privacy' option-tag 🌈 once the privacy service has done all the required privacy functions, the 'privacy' option-tag gets removed from the Proxy-Require header ✨

4.4 Routing Responses to Privacy Services

Okay so making sure responses go through a privacy service is lowkey trickier 😭 Responses take the same path the request traveled, so the responding user agent can't just force a privacy service into the response path after a request has already arrived 💅

What a responding user agent can do is make sure the path requests take to reach them goes through its privacy service ✨ In some architectures, the privacy service is run by the same server that requests for the local administrative domain get sent to, so it's automatically in the path of incoming requests 🎀 If that isn't the case, the user has to make sure requests get directed through a third-party privacy service 🫶

One way to do this is to get an 'anonymous callback' URI from the third-party service and distribute it as an address-of-record 💜 A privacy service provider might offer these anonymous callback URIs to users the same way an ordinary SIP service provider grants addresses-of-record. The user then registers their normal address-of-record as a contact address with the third-party service.

Another option: a user agent can send REGISTER requests through a privacy service with a request for 'user' level privacy 🦋 That lets the privacy service insert anonymous Contact header URIs, so requests sent to the user's regular address-of-record reach their devices without revealing any usable contact addresses.

Finally, a user might generate a CPL ([7]) script that directs requests to an anonymization service 🧚

Users are also advised to use transport or network layer security in the response path 🔐 This may involve registering a SIPS URI and/or maintaining persistent TLS connections over which their user agent receives requests.

Privacy services MAY in turn route requests through other privacy services 🌸 This may be necessary if a privacy service doesn't support a particular privacy function but knows of a peer that does. Privacy services may also cluster themselves into networks that exchange session traffic between one another to further disguise the participants in a session, although no specific architecture or method for doing so is described in this document.

5. Privacy Service Behavior ✨

This document defines a new SIP logical role called a "privacy service" 👑 The privacy service role is instantiated by a network intermediary, frequently by entities that can act as SIP proxy servers. Its job is to supply privacy functions for SIP messages that user agents can't provide on their own.

When a message arrives at a server that can act as a privacy service, the service SHOULD evaluate the level of privacy requested in a Privacy header. Usually, only the services explicitly requested should be applied. However, privacy services MAY have some means outside SIP of finding out the user's preferences (such as a pre-arranged user profile), so they MAY perform other privacy functions without an explicit Privacy header. Performing even a user-level privacy function in a privacy service could be useful, for example, when a user is sending messages from a legacy client that doesn't support the Privacy header, or from a user agent that doesn't let the user configure the values of headers that could reveal personal information 🙈 But if the Privacy header value of 'none' is specified in a message, privacy services MUST NOT perform any privacy function and MUST NOT remove or modify the Privacy header. Hard boundary, no exceptions 🚫

Privacy services MUST implement support for the 'none' and 'critical' privacy tokens, and MAY implement any of the other privacy levels described in Section 4.2, as well as any extensions that aren't detailed in this document. Sometimes the privacy service just can't deliver the level of privacy requested 😬 If the 'critical' privacy level is present in the Privacy header of a request, and the privacy service is incapable of performing all of the levels of privacy specified in that header, then it MUST fail the request with a 500 (Server Error) response code. The reason phrase of the status line of the response SHOULD contain appropriate text saying there has been a privacy failure, plus an enumeration of the priv-value(s) the privacy service didn't support (the reason phrase SHOULD also respect any Accept-Language header in the request if possible) 💀

When a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header, it SHOULD remove the corresponding priv-value from the Privacy header 🧹 Otherwise, any other privacy service involved in routing the message might unnecessarily apply the same function, which in many cases would be undesirable. When the last priv-value (not counting 'critical') has been removed from the Privacy header, the entire Privacy header MUST be removed from the message.

When the privacy service removes the entire Privacy header, if the message is a request, the privacy service MUST also remove any 'privacy' option-tag from the Proxy-Require header field of the request 🎀

5.1 Header Privacy

If a privacy level of 'header' is requested, then the originating user has asked the privacy service to help obscure headers that might otherwise reveal information about the originator of the request 🦋 The values that have been obscured must still be recoverable when further messages in the dialog need to be routed to the originating user agent. To pull this off, the privacy service frequently has to act as a transparent back-to-back user agent (B2BUA) 💅

Firstly, a request for header privacy means the server SHOULD NOT add any headers to the message that reveal identity or personal information, including Call-Info, Server, and Organization. These all provide optional information that could reveal facts about the user who requested anonymity 🙈

Privacy services operating on requests SHOULD remove all Via headers that were added to the request before it arrived at the privacy service (a practice referred to as "Via stripping"), and then SHOULD add a single Via header representing themselves ✨ Note that the bottommost Via header field value in a request contains an IP address or hostname that designates the originating client, and subsequent Via header field values may indicate hosts in the same administrative domain as the client. No Via stripping is required when handling responses.

Contact headers are added by user agents to both requests and responses 💜 A privacy service SHOULD replace the value of the Contact header in a message with a URI that does not dereference to the originator of the message (such as the anonymous URI described in Section 4.1.1.3). The URI that replaces the existing Contact header field value MUST dereference to the privacy service.

In a manner similar to Via stripping, a privacy service SHOULD also strip any Record-Route headers that were added to a request before it reached the privacy service. Note that no such headers will be present if there is only one hop between the originating user agent and the privacy service, as is recommended above. Such Record-Route headers might also reveal information about the administrative domain of the client 🌈

For the purposes of this document, it is assumed that the privacy service has locally persisted the values of any of the above headers that are removed, which means the privacy service has to keep a pretty significant amount of state on a per-dialog basis 🧠 When further requests or responses associated with the dialog reach the privacy service, it MUST restore the values for the Via, Record-Route/Route or Contact headers that it previously removed in the interests of privacy. There may be alternative ways (outside the scope of this document) to do this without keeping state in the privacy service (usually this means encrypting and persisting the values in the signaling somehow) 🔐

The following procedures are RECOMMENDED for handling the Record-Route header field of requests and responses, which poses special challenges for a privacy service 🧩

When a privacy service is processing a request on behalf of the originator and that request contains one or more Record-Route header field values, the privacy service must strip these values from the request and remember both the dialog identifiers and the ordered Record-Route header field values. As described above, it must also replace the Contact header field with a URI indicating itself. When a response with the same dialog identifiers arrives at the privacy service, the privacy service must reapply the Record-Route header field values to the response in the same order, and then it must add a URI representing itself to the Record-Route header field of the response. If the response contains Record-Route header field values of its own, these must also be included (in order) in the Record-Route header field after the URI representing the privacy service 🫶

Note that when a privacy service handles a request and provides privacy on behalf of the destination of the request, providing privacy for Record-Route headers downstream of the privacy service is significantly more complicated 😵‍💫 This document recommends no way of statefully restoring those headers if they are stripped.

5.2 Session Privacy

If a privacy level of 'session' is requested, then the user has asked the privacy service to anonymize the session traffic (for example, for SIP telephony calls, the audio media) associated with this dialog 🎧

The SIP specification dictates that intermediaries such as proxy servers cannot inspect and modify message bodies 🚧 So the privacy service logical role MUST act as a back-to-back user agent in order to provide media privacy, effectively terminating and re-originating the messages that initiate a session. (Although, in support of session privacy, the privacy service doesn't need to alter the headers characterizing the originator or destination when the request is re-originated.) To introduce an anonymizer for session traffic, the privacy service needs to control a middlebox ([8]) that can provide an apparent source and sink for session traffic. The details of implementing an anonymizer, and the modifications that must be made to the Session Description Protocol (SDP [5]) bodies in the messages that initiate a session, are outside the scope of this document 🌷

The risk, of course, of using such an anonymizer is that the anonymizer itself is party to your communications 👀 For that reason, requesting session-level privacy without some sort of end-to-end security for the session traffic (with RTP [6] media, for example, SRTP [4]) is NOT RECOMMENDED.

5.3. Applying User-Level Privacy Functions at a Privacy Service 🎀

okay so if a privacy level of 'user' gets requested, the originating user is basically saying "hey privacy services, please do the user-level privacy functions from Section 4.1" 💅 that's the whole ask.

Also, the privacy service MUST remove any non-essential informational headers that the user agent added, like Subject, Call-Info, Organization, User-Agent, Reply-To and In-Reply-To. no cap, those are the extra little details that give away way too much 🙈

Here's the spicy part 🌶️ user-level privacy could mean changing the From header from its real value to an anonymous one. Before the current SIP spec, nobody was allowed to touch the To and From headers as an intermediary, because it would mess up dialog matching on the endpoints 😭 Now dialog matching only looks at the tags in To and From, not the whole header fields. So under the new rules, the URI values in To and From can actually get altered by intermediaries. Still, some legacy clients might treat it as an error if the URI in From changes between the request and the response. bestie, that's the drama 💀

Performing user-level privacy functions MAY also mean modifying the Call-ID header, since Call-ID usually has a hostname or IP address for the originating client in it. This one is essential to dialog matching, and intermediaries can't alter it ✨

So, whenever a privacy service needs to change any dialog-matching headers for privacy reasons, it SHOULD act as a transparent back-to-back user agent, and it MUST persist the former values of those dialog-matching headers. Those values MUST be restored in any messages sent to the originating user agent. it's giving careful record-keeping 📝🦋

6. Security Considerations 🔐

okay this section is serious, so grab your snacks 🍓

Messages that request privacy require confidentiality and integrity. Without integrity, the requested privacy functions could get downgraded or removed entirely, and then identity info could leak 😱 Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the privacy service) could see the super personal stuff the user asked the privacy service to hide. not it 🙅‍♀️

All of the network-provided privacy functions in this document involve a lot of trust in the privacy service. Users should only trust privacy services that are somehow accountable to them. be picky, babe 👑

Operators of privacy services should know that, to downstream entities, the privacy service will be the only source that anonymous messages can be traced back to. so the privacy service is literally the main character in the trace 🕵️‍♀️

Also, authentication mechanisms, including the Digest authentication method described in the SIP specification, are outside the scope of the privacy considerations in this document. Revealing identity through authentication is highly selective and may not compromise any private information at all. Obviously, users who don't want to reveal their identity to servers that issue authentication challenges MAY choose not to respond to those challenges 🫶

7. IANA Considerations 🌸

okay IANA time, this part is kinda the paperwork glow-up ✨

This document defines a new SIP header field called "Privacy" that lets a user agent ask for a certain degree of privacy for a message. The behavior tied to this header is specified in Section 4.2. The header has been added to the header sub-registry under http://www.iana.org/assignments/sip-parameters.

 Header name: Privacy
Compact form: none defined

This document also creates an IANA registry for the values that fill the Privacy header. This registry should be indexed by priv-value tokens and should contain a short semantic description of each new value. The current values of the "Privacy" header are:

  • user: Request that privacy services provide a user-level privacy function
  • header: Request that privacy services modify headers that cannot be set arbitrarily by the user (Contact/Via).
  • session: Request that privacy services provide privacy for session media
  • none: Privacy services must not perform any privacy function
  • critical: Privacy service must perform the specified services or fail the request

New values for the "Privacy" header can only be defined by IETF Consensus including RFC publication (RFC 2434). IANA registration for the "Privacy" header field values is required along with the RFC publication. 📚

Authors of extensions to the SIP protocol that expose personal information about session participants are advised against extending the "Privacy" header. Instead, it's preferable to create new identity mechanisms whose privacy can be managed by the user agent without intermediaries getting involved 🦋

This document also defines a new SIP option-tag, 'privacy', that represents support for the extension defined in this document. ✨

Normative References

[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.

[2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.

[3] Eastlake, D. and A. Panitz, "Reserved Top Level DNS Names", RFC 2606, June 1999.

Informative References

[4] Baugher, M., McGrew, D., Oran, D., Blom, R., Carrara, E., Naslund, M. and K. Normann, "The Secure Real Time Transport Protocol", Work in Progress.

[5] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.

[6] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.

[7] Lennox, J. and H. Schulzrinne, "CPL: A Language for User Control of Internet Telephony Services", Work in Progress

[8] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002.

Author's Address 📮

Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA  94520 US

Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI:   http://www.neustar.biz/

Acknowledgments 🙏

The author would like to thank Allison Mankin, Rohan Mahy, Eric Rescorla, Mark Watson, Cullen Jennings, Robert Sparks, Jonathan Rosenberg, Ben Campbell, Tom Gray and John Elwell for their comments. 💜

The legal text stays exactly as written, so here it is in full:

Copyright (C) The Internet Society (2002).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💖

Funding for the RFC Editor function is currently provided by the Internet Society. ✨

📦 where this page comes from