SIP M. Munakata Internet-Draft S. Schubert Expires: August 23, 2007 T. Ohba NTT February 23, 2007 SIP Privacy Clarified draft-munakata-sip-privacy-clarified-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 23, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document defines the privacy mechanisms for the Session Initiation Protocol (SIP). Specifically, guidelines are provided for the creation of messages that do not divulge personal identity information. A "privacy service" logical role for intermediaries is defined to answer some privacy requirements that user agents cannot satisfy themselves. Finally, means are presented by which a user can request particular functions from a privacy service. Munakata, et al. Expires August 23, 2007 [Page 1] Internet-Draft SIP Privacy Clarified Feb 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . . . 6 3.1. User-Provided Privacy . . . . . . . . . . . . . . . . . . 6 3.2. Network-Provided Privacy . . . . . . . . . . . . . . . . . 6 3.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7 3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7 4. Privacy Header Definition . . . . . . . . . . . . . . . . . . 7 4.1. Syntax of Privacy Header . . . . . . . . . . . . . . . . . 7 4.2. Semantics of priv-values . . . . . . . . . . . . . . . . . 8 5. Target for Each priv-value . . . . . . . . . . . . . . . . . . 9 5.1. Target SIP Headers for Each priv-value . . . . . . . . . . 10 5.2. Target SIP Parameters and SDP Attributes for Each priv-value . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Treatment of User Privacy Related Information . . . . . . . . 11 6.1. Display-Names and URIs . . . . . . . . . . . . . . . . . . 11 6.1.1. Display-Names . . . . . . . . . . . . . . . . . . . . 12 6.1.2. URI User Part And Host Name . . . . . . . . . . . . . 12 6.1.3. Obtaining Anonymous URI at a User Agent . . . . . . . 13 6.1.4. IP Addresses . . . . . . . . . . . . . . . . . . . . . 13 6.1.5. Obtaining Anonymous IP Address to be Used by a User Agent . . . . . . . . . . . . . . . . . . . . . . . 14 6.2. Target SIP Headers . . . . . . . . . . . . . . . . . . . . 14 6.2.1. Call-ID . . . . . . . . . . . . . . . . . . . . . . . 15 6.2.2. Call-Info . . . . . . . . . . . . . . . . . . . . . . 15 6.2.3. Contact . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.4. From . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.2.5. Geolocation . . . . . . . . . . . . . . . . . . . . . 16 6.2.6. History-Info . . . . . . . . . . . . . . . . . . . . . 17 6.2.7. Identity/Identity-Info . . . . . . . . . . . . . . . . 17 6.2.8. Organization . . . . . . . . . . . . . . . . . . . . . 18 6.2.9. P-Asserted-Identity . . . . . . . . . . . . . . . . . 18 6.2.10. Record-Route . . . . . . . . . . . . . . . . . . . . . 18 6.2.11. Referred-By . . . . . . . . . . . . . . . . . . . . . 19 6.2.12. Reply-To . . . . . . . . . . . . . . . . . . . . . . . 19 6.2.13. Server . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.14. Subject . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.15. User-Agent . . . . . . . . . . . . . . . . . . . . . . 20 6.2.16. Via . . . . . . . . . . . . . . . . . . . . . . . . . 20 6.2.17. Warning . . . . . . . . . . . . . . . . . . . . . . . 21 6.3. SIP Parameters / SDP Attributes . . . . . . . . . . . . . 21 6.3.1. c/m Lines . . . . . . . . . . . . . . . . . . . . . . 21 6.3.2. o Line . . . . . . . . . . . . . . . . . . . . . . . . 22 6.3.3. i/u/e/p Lines . . . . . . . . . . . . . . . . . . . . 22 6.4. Considerations for Non-Target SIP Headers/Parameters . . . 22 6.4.1. In-Reply-To . . . . . . . . . . . . . . . . . . . . . 22 6.4.2. Path . . . . . . . . . . . . . . . . . . . . . . . . . 23 Munakata, et al. Expires August 23, 2007 [Page 2] Internet-Draft SIP Privacy Clarified Feb 2007 6.4.3. Replaces Header/Parameter . . . . . . . . . . . . . . 23 6.4.4. Route . . . . . . . . . . . . . . . . . . . . . . . . 26 6.4.5. Service-Route . . . . . . . . . . . . . . . . . . . . 26 6.4.6. Target-Dialog . . . . . . . . . . . . . . . . . . . . 26 7. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 27 7.1. Locating Privacy Service . . . . . . . . . . . . . . . . . 27 7.2. Generating Anonymous Request . . . . . . . . . . . . . . . 28 7.2.1. Intermediary Inserted/Modified Information . . . . . . 29 7.3. Requesting Anonymization at Privacy Service . . . . . . . 29 7.4. Requesting No Privacy Treatment . . . . . . . . . . . . . 29 8. Privacy Service Behavior . . . . . . . . . . . . . . . . . . . 30 8.1. Handling Message with Privacy:nw-level . . . . . . . . . . 31 8.2. Handling Message with Privacy:all . . . . . . . . . . . . 31 8.3. Handling Message with Privacy:none . . . . . . . . . . . . 32 9. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 32 10. Guidelines on the Privacy Consideration for Future RFCs . . . 33 10.1. Future RFCs with Privacy Implications . . . . . . . . . . 33 10.2. Future RFCs Defining a New priv-values . . . . . . . . . . 33 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 13.1. Normative Reference . . . . . . . . . . . . . . . . . . . 35 13.2. Informative Reference . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 38 Munakata, et al. Expires August 23, 2007 [Page 3] Internet-Draft SIP Privacy Clarified Feb 2007 1. Introduction This document provides privacy requirements and mechanisms for the Session Initiation Protocol (SIP). The purpose of this document is to specify and clarify the privacy mechanism for SIP in order to secure the privacy of message senders. This document obsoletes RFC 3323 and redefines the privacy mechanism, if approved. It also clarifies the extensions to the SIP privacy that are defined in RFCs 3325 and 4244. Privacy is defined in this document as the withholding of the identity of a person (and related personal information) from one or more parties in an exchange of communications, specifically a SIP dialog. These parties potentially include the intended destination(s) of messages and/or any intermediaries handling these messages. In SIP, identity is most commonly carried in the form of a SIP URI and an optional display-name. A SIP address-of-record has a form similar to an email address with a SIP URI scheme (for example, sip:alice@atlanta.com). A display-name is a string containing a name for the identified user (for example, "Alice"). SIP identities of this form commonly appear in the To, From and P-Asserted-Identity header fields of SIP requests and responses. A user may have many identities that they use in different contexts. There are numerous other places in SIP messages in which identity- related information can be revealed. For example, the Contact header field contains a SIP URI, one that is commonly as revealing as the address-of-record in the From. In some headers, the originating user agent can conceal identity information as a matter of network policy without affecting the operation of the SIP protocol. However, certain headers are used in the routing of subsequent messages in a dialog, and must therefore be populated with functional data when replaced with information that would provide privacy. The privacy problem is further complicated by proxy servers (also referred to in this document as "intermediaries" or "the network") that add headers of their own or on behalf or the user, such as the Record-Route, Via, Organization and Identity headers. Information in these headers could inadvertently reveal something about the originator of a message; for example, a Via header might reveal the service provider through whom the user sends requests, which might in turn strongly hint at the user's identity to some recipients. Many of the new SIP extensions since the creation of privacy mechanism can only be added by the intermediaries and therefore the participation of intermediaries is even more crucial to providing privacy in SIP than ever before. Munakata, et al. Expires August 23, 2007 [Page 4] Internet-Draft SIP Privacy Clarified Feb 2007 Although there are cases where intermediary invokes the privacy functions on behalf of the user or to fulfill the domain/network policy (e.g. topology hiding), and this may be done with or without the privacy mechanism defined in this document. However this document focuses on the invocation of privacy functions using a SIP procedures thereby does not go into how intermediaries may conduct privacy function without the SIP procedures. This document also makes an assumption that when user requests privacy, it is based on a binary decision. The user either requests privacy for the whole message or no privacy at all. In order to cover all the use cases defined in this document, this document defines priv-values of "nw-level", "all", and "none" as the values to be set in a Privacy header. The existing priv-values of "id" defined in RFC 3325 and "history" defined in RFC 4244 will be maintained for the sake of backwards compatibility. This document clarifies the SIP headers and related parameters that need to be handled by the network entities who execute privacy function for each priv-value, and provides the recommended behaviors for user agents and privacy service on treatment of each headers/parameters. This document begins with a section that provides a general framework and architecture for the privacy mechanism in SIP (Section 3), followed by a section that describes definitions of Privacy header (Section 4), followed by a section that describe the target headers/ parameters (Section 5), followed by a section that describes the desired treatment of user privacy related information (Section 6), followed by user agent behavior (Section 7), privacy service behavior (Section 8), and proxy behavior (Section 9) and provides guidelines on writing privacy considerations for future RFCs (Section 10). 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. priv-value: Values registered with IANA to be used in Privacy header. Three priv-values, "nw-level", "all", and "none" are specified in this document. The extended priv-values of "id" and "history" are specified in RFC 3325 and 4244, respectively. privacy service: A network entity which executes privacy functions before forwarding messages to elements that are not trusted. It is sometimes abbreviated to PS in this document. Munakata, et al. Expires August 23, 2007 [Page 5] Internet-Draft SIP Privacy Clarified Feb 2007 3. Varieties of Privacy 3.1. User-Provided Privacy A user agent can execute privacy functions by itself for user inserted information. For example, the baseline SIP specification permits a user agent to populate the From header field of a request with an anonymous value. User agents can take similar steps to avoid revealing any other unnecessarily identity information in related SIP headers/parameters including SDP attributes (this is discussed further in Section 6). Furthermore by utilizing some of the SIP extensions and existing internet protocols a user agent can construct a message withholding all the user inserted information such as Contact and Via headers. The user agent executing the privacy functions for all the user inserted information is not suffice to make the message fully anonymized, this is due to the information that are added or modified by the intermediaries. Thus aid by network entity to provide privacy on intermediary inserted/modified information is necessary to provide full anonymization. 3.2. Network-Provided Privacy A privacy service can execute partial or full privacy functions on behalf of a user agent when requested. A privacy service may execute the privacy functions only for the intermediary inserted/modified information in a message when the user inserted information in the message is already anonymized by the user agent. Otherwise, a privacy service may execute the privacy functions for all the user privacy related information those inserted by the user agent as well as those inserted by the intermediaries. Even if there is no explicit privacy request by the user agent, a privacy service may obscure the user privacy related information based on network or domain policy (e.g. based on the contractual agreement). When user's privacy is requested, the privacy service either delete or modify values in headers/parameters that reveal user's identity. When the privacy services modify headers/parameters that are essential to route further messages to the originating user agent, the former value must be recoverable and restored in the further messages inside the dialog. Munakata, et al. Expires August 23, 2007 [Page 6] Internet-Draft SIP Privacy Clarified Feb 2007 3.3. Use Cases The followings are the most common use cases for invoking privacy functions. Regarding the user privacy related information, (1) privacy is required. (1)-1 A user agent anonymizes all the user inserted information by itself and the user agent or intermediary requests a privacy service to execute privacy functions for intermediary inserted/modified information. (1)-2 A user agent or intermediary requests a privacy service to execute all the privacy functions. (2) privacy is not required. The user does not want privacy at all and would like to reveal its identity. If a user agent can execute all the privacy functions for the user inserted information, then the functions SHOULD be executed at the user agent. If a user agent can provide only partial or no privacy function, the user agent SHOULD NOT execute any privacy functions and rather it SHOULD delegate the task to the privacy service. 3.4. Requirements The followings are requirements to cover the use cases in the previous section. Req 1: A user agent SHOULD be able to indicate to a privacy service that it desires obfuscation and anonymization on information that may reveal something about the user. Req 2: user agent SHOULD be able to indicate to a privacy service that it desires obfuscation and anonymization on information that are inserted and modified by intermediaries. Req 3: A user agent SHOULD be able to indicate to a privacy service that it desires no privacy and that it would like to reveal its identity to the recipient. 4. Privacy Header Definition 4.1. Syntax of Privacy Header This document defines a SIP header, Privacy, that can be used to specify privacy handling for requests and responses. The ABNF [2] syntax is as follows. Munakata, et al. Expires August 23, 2007 [Page 7] Internet-Draft SIP Privacy Clarified Feb 2007 Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) priv-value = "nw-level" / "all" / "none" / token The following table specifies extensions to Table 2 in [3]. 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 Editor's Note: How does a privacy service deal REGISTER requests with a Privacy header? Should Privacy headers not appear in REGISTER request? It needs a further study. A user agent SHOULD include a Privacy header when it requires privacy. Note that some intermediaries may also add the Privacy header to messages, including privacy services. However, such intermediaries SHOULD only do so if they are operating at a user's behest, for example if a user has an administrative arrangement with the operator of the intermediary that it will add such a Privacy header. An intermediary SHOULD NOT modify the Privacy header in any way if the "none" priv-value is already specified. When a Privacy header is constructed, it MUST consist of at least one priv-value. An example of the syntax of the Privacy header is given below: Privacy: all 4.2. Semantics of priv-values The semantics of priv-values defined in this document are described below: nw-level: Request that a privacy service removes or obscures intermediary inserted/modified information. A privacy service should remove or obscure headers/parameters that are inserted or modified by intermediaries after a user agent sends out the message (such as Record-Route, History-Info, P-Asserted-Identity, etc.) Munakata, et al. Expires August 23, 2007 [Page 8] Internet-Draft SIP Privacy Clarified Feb 2007 Editor's Note: The priv-value of "nw-level" may not be appropriate. The other candidates are "intermediary-level" and "intermediary", which may be too long. all: Request that a privacy service removes or obscures all user privacy related information, i.e. both user inserted information and intermediary inserted/modified information. A privacy service should remove or obscure all the user inserted and intermediary inserted/ modified information that may reveal sender's identity. none: A privacy service should not perform any privacy functions for the purpose of obscuring user agent's information. A privacy service should not remove or modify the Privacy header. This document doesn't obsolete priv-values of "id" and "history". For the semantics of these priv-values, refer to RFCs 3325 and 4244. With this document, "user", "session", and "critical" are NOT RECOMMENDED to be used and be kept solely for the backward compatibility reason. Note: Location of privacy service is out of scope. It depends on deployments and network policy. 5. Target for Each priv-value Tables in this section show the recommended treatment of SIP headers/ parameters per priv-value categorized by entity providing the privacy function. The SIP headers/parameters that are not shown in the tables are regarded as a nontarget of these priv-values. Some nontarget headers/parameters may carry user privacy related information, headers/parameters that may carry user privacy related information that need privacy treatment despite the lack of priv- values are described in 6.4. Note that the SIP headers/parameters that are not covered in this document are regarded as irrelevant to user privacy. The treatments listed in the tables are only recommendations. Exact treatments to obscure SIP headers/parameters listed here may depend on implementation and network policy. This specification does not prevent privacy services to manipulate other headers based on the local policy. Munakata, et al. Expires August 23, 2007 [Page 9] Internet-Draft SIP Privacy Clarified Feb 2007 Note: The scope of these tables are SIP headers and related parameters specified in RFCs or internet drafts that are likely to be RFCs in near future. There may be more to be included in these tables. Further study will be necessary. 5.1. Target SIP Headers for Each priv-value Table 1 below shows a recommended treatment of each SIP headers for each of the priv-value. The table also illustrates the desired treatment per entity involved in the privacy function. Detail description on exactly what kind of treatment is recommended per SIP headers are covered in section 6. Behaviors of UA PS PS PS PS priv-values nw-level nw-level all id history Target headers Call-ID anonymize anonymize(Note1) Call-Info not add delete delete Contact anonymize anonymize From anonymize anonymize Geolocation not add delete delete History-Info not add delete delete delete Identity anonymize Identity-Info anonymize Organization not add delete delete P-Asserted-Identity delete delete delete Record-Route anonymize anonymize Referred-By anonymize* anonymize* Reply-To not add delete Server not add delete Subject not add delete User-Agent not add delete Via anonymize anonymize anonymize Warning anonymize anonymize Table 1: Recommended PS/UA behaviors for each SIP headers Note 1: Any time a privacy service modifies a Call-ID, it SHOULD retain the former and modified values. Then it SHOULD restore the former value in a Call-ID header and other corresponding headers (such as In-Reply-To, Replaces, and Target-Dialog) in any further relevant messages that are sent to the originating user agent. It SHOULD also modify a Call-ID header and other corresponding headers/parameters (such as Target-Dialog and "replaces" parameter) in any further relevant messages that are sent by the originating user agent. Munakata, et al. Expires August 23, 2007 [Page 10] Internet-Draft SIP Privacy Clarified Feb 2007 Note 2: Asterisk indicates that involvement of a privacy service and treatment of the relevant header, depends on the circumstance. Description can be found in section describing the treatment of header marked with asterisk in Section 6. Note 3: In-Reply-To, Path, Route, Service-Route, and Target-Dialog headers are not the target of these priv-value (should not be anonymized or modified by a user agent and a privacy service based on priv-value in a Privacy header). Refer to 6.4 for details. 5.2. Target SIP Parameters and SDP Attributes for Each priv-value Table 2 below shows a recommended treatment of each SIP parameters and SDP attributes per priv-values. Behaviors of UA PS PS PS PS priv-values nw-level nw-level all id history Target parameters SDP c/m lines anonymize anonymize SDP o lines anonymize anonymize SDP i/u/e/p lines anonymize anonymize Table 2: Recommended PS/UA behaviors for each SIP parameters and SDP attributes 6. Treatment of User Privacy Related Information The following URIs, SIP headers and related parameters may be of privacy concern. This section describes what kind of user privacy related information is included in each SIP header/parameter, and how to hide such information at a user agent or a privacy service to provide anonymity. 6.1. Display-Names and URIs A certain amount of privacy can be afforded by choosing to populate SIP headers with URIs and display-names that do not reveal any identity information. In some of the header fields (for example, the Reply-To and From headers), URIs are not used in further signaling within the current dialog. In others, like the Contact header, an inaccurate URI will result in a failure to route subsequent requests within the dialog. Display-names, URIs, and IP addresses used to present/convey user Munakata, et al. Expires August 23, 2007 [Page 11] Internet-Draft SIP Privacy Clarified Feb 2007 agent's address SHOULD be obfuscated according to the following guidelines. Relevant headers that may be affected by this include From, Reply-To, Contact, and Via. 6.1.1. Display-Names It is a relatively common practice in email and other applications to use an assumed name in the display-name component of the From header field. Outside of a business context (especially in applications such as instant messaging or Internet gaming) the use of such aliases is unlikely to provide a cause for distrust. It is RECOMMENDED to use a display-name of "Anonymous" for anonymous SIP requests. 6.1.2. URI User Part and Host Name The structure of a URI itself can reveal or conceal a considerable amount of personal information such as full name and employer of the party. Today, the SIP specification recommends a URI with "anonymous" in the user portion of the From header. In some URIs, such as those that appear in Contact headers, it MAY also make sense to omit the username altogether, and provide only a hostname, like: sip:anonymous-sip.com. Sometimes, merely changing the username will not be enough to conceal a user's identity. A user's SIP service provider might decisively reveal a user's identity (if it reflected something like a small company or a personal domain). So in this case, even though the URI would not dereference to the anonymous user, humans might easily guess the user's identity and know the proper form of their address- of-record. For these reasons, the URI hostname SHOULD be anonymized as well as URI username. It is assumed that the user that requests privacy wishes to receive future requests and responses within this dialog. In order to route future requests and received future response, the URI needs to be functional even when it is anonymized for a privacy. This imposes a user agent to construct or obtain a functional anonymous URI rather than simply using sip:anonymous@anonymous.invalid. How to generate and obtain a functional anonymous URI at the user agent is described in Section 6.1.3. Munakata, et al. Expires August 23, 2007 [Page 12] Internet-Draft SIP Privacy Clarified Feb 2007 6.1.3. Obtaining Anonymous URI at a User Agent A user agent wanting to obtain functional anonymous URI SHOULD support and SHOULD utilize Global Routable User Agent URI (GRUU) [4] mechanism. By sending a REGISTER request requesting GRUU, UA can obtains an anonymous URI which can later be used for From, Contact and other headers where URI of the originator is needed. The detail process on how a user agent obtains a GRUU is described in [4]. If the Registrar supports GRUU and returns a REGISTER response, user agent SHOULD search within the REGISTER response for a "temp- gruu" uri parameter. If "temp-gruu" uri parameter with value exists within the REGISTER response, user agent SHOULD use the value of the "temp-gruu" as an anonymous URI representing the originator. This URI SHOULD be used for Contact, From etc where originator of the URI is required. The user agent setting the "temp-gruu" as a GRUU SHOULD set "Anonymous" as a display name to any header where display name of the originator is set, it indicates the anonymity of the request to intermediaries that may invocate some services based on the anonymity of the call. The temp-gruu alone is not sufficient to invocate such services because GRUU is merely a URI and does not indicate that it's an anonymous URI in any way. If there is no "temp-gruu" URI parameter in the 200 response to the REGISTER request, a user agent SHOULD NOT proceed with its anonymization process, unless something equivalent to "temp-gruu" is provided through some administrative means. Instead the user agent SHOULD send the request to the privacy service requesting the complete anonymization by setting "all" to the Privacy header, more detail on how to request complete anonymization from the privacy service is covered in section 7.3. 6.1.4. IP Addresses Is there much additional privacy in using an IP address rather than a hostname? It does prevent someone who casually inspects a message from gathering information that they might see otherwise. However, reverse-resolving such addresses is generally trivial, and substituting an IP address for a hostname could introduce some complications, for example due to NAT and firewall traversal concerns. Headers used in routing may also rely on certain DNS practices to provide services that would be lost if an IP address is used in place of a hostname. A user agents and a privacy services anonymizing SIP messages SHOULD Munakata, et al. Expires August 23, 2007 [Page 13] Internet-Draft SIP Privacy Clarified Feb 2007 utilize mechanism to obtain functional anonymous IP address. How to generate and obtain a functional anonymous IP address at the user agent is described in Section 6.1.5. As IP addresses are generally present in SDP, if the privacy function is executed at the privacy services to anonymize IP addresses, the privacy service needs to act as a back-to-back user agent (B2BUA). 6.1.5. Obtaining Anonymous IP to be Used by a User Agent If a user agent wanting to obtain an anonymous IP address and port for use in the SDP, Via header and other SIP headers requiring source IP address, a user agent SHOULD contact a Traversal Using Relay NAT (TURN) [8] server. It uses normal TURN processing to obtain an IP address on the server which route to it. Ideally, this is done with a TURN server that is specifically dedicated to anonymous services, and thus can provide a higher degree of anonymity by obtaining anonymized IP address from a separate provider than a one originator is subscribed to. The client uses the TURN-derived addresses in those fields of the message where the UA wishes to anonymize an IP address. These include IP address used in SDP, Call-ID and Via. If TURN is non-existent and user agent has no other way to obtain anonymous IP address, user agent SHOULD NOT proceed with its anonymization process. Instead the user agent SHOULD send the request to the privacy service requesting the full anonymization by setting "all" to the Privacy header. Details on how to request complete anonymization from the privacy service is covered in section 7.3. 6.2. Target SIP Headers This section describes privacy considerations and recommended treatment for each SIP header that may reveal user privacy related information. This section goes into detail of how each header affects the privacy, the desired treatment of the value by user agent and privacy service, and other instructions/additional notes necessary to provide privacy. In some headers, the originating user agent can conceal identity information as a matter of network policy without affecting the operation of the SIP protocol. However, certain headers (such as Contact) are used in the routing of subsequent messages in a dialog, and must therefore be populated with functional data. Munakata, et al. Expires August 23, 2007 [Page 14] Internet-Draft SIP Privacy Clarified Feb 2007 Any time that a privacy service needs to modify any dialog-matching headers (such as Call-ID) for privacy reasons, it SHOULD act as a transparent B2BUA, and it MUST persist the former values of the dialog-matching headers. These values MUST be restored in any messages that are sent to the originating user agent. 6.2.1. Call-ID This field frequently contains an IP address or hostname appended to the Call-ID value. A user agent constructing anonymous SIP requests SHOULD exclude host name and IP address from a Call-ID header or anonymize them by using functional anonymous URI or IP address. A privacy service SHOULD delete the host name and IP address from a Call-ID header or anonymize them by using functional anonymous URI or IP address when the request contains Privacy:all. Generally this is done by replacing the IP address or host name with that of the privacy service. Call-ID is essential to dialog matching, therefore, any time a privacy service modifies this field, it SHOULD retain the former value, then restore the value in a Call-ID header in any messages that are sent to the originating user agent inside the dialog. Privacy service SHOULD be prepared to receive a request outside of the dialog containing the value of the Call-ID set by the PS in other SIP headers (e.g. In-Reply-To/Replaces/Target-Dialog), at least while the dialog state is active for the dialog Call-ID was modified by that PS. When receiving such request, the Call-ID value contained in the relevant headers indicated above, SHOULD be replaced with one retained. Note: This is only possible if the privacy service maintains state and retains all the information it modified to provide privacy. Some PS is known to encrypt information prior to obfuscation in Via header etc. In which case the PS can't correlate the Call-ID value modified to original Call-ID. Further challenges are imposed to ensure PS always receives the message that addresses information PS modified. Refer to each section, 6.4.1 (In-Reply-To), 6.4.3 (Replaces), and 6.4.6 (Target-Dialog) for detail considerations. 6.2.2. Call-Info This field contains additional information about the user. Munakata, et al. Expires August 23, 2007 [Page 15] Internet-Draft SIP Privacy Clarified Feb 2007 A user agent constructing anonymous SIP requests SHOULD NOT add a Call-Info header. A privacy service SHOULD delete the Call-Info headers when the user privacy is requested with Privacy:nw-level or Privacy:all. 6.2.3. Contact This field contains a URI used to reach the user agent for mid-dialog requests and possibly out-of-band requests, such as REFER [9]. Since the Contact header is essential for routing further requests and response to the user agent, it must be populated with functional URI even when it is anonymized. A user agent constructing anonymous SIP requests SHOULD anonymize a Contact header using functional anonymous URI or IP address. A privacy service SHOULD anonymize a Contact header using functional anonymous URI when the user privacy is requested with Privacy:all. 6.2.4. From This field contains the identity of the user, such as display-name and URI. A user agent constructing anonymous SIP requests SHOULD anonymize a From header using anonymous display-name and functional anonymous URI. A privacy service SHOULD anonymize a From header when the user privacy is requested with Privacy:all. 6.2.5. Geolocation This field contains either a URI which may be a cid URI (Content Identification, per RFC2392 [14]) or a location-by-reference URI to be dereferenced by a location recipient to retrieve the location of the UAC. Where the Geolocation header [12] contains a cid URI, the actual location information is included in the body of the message in the form of a PIDF-LO [15]. If the URI in the Geolocation header contains a location-by-reference URI, the location information of the user agent will be retrieved from the referenced entity. A user agent constructing anonymous SIP requests SHOULD NOT add a Geolocation header, as well as PIDF-LO in the message body. Network entities such as proxy SHOULD NOT add a Geolocation header when the privacy of Privacy:nw-level or Privacy:all is requested. Munakata, et al. Expires August 23, 2007 [Page 16] Internet-Draft SIP Privacy Clarified Feb 2007 A privacy service SHOULD delete the Geolocation header and PIDF-LO if present in the message when the user privacy is requested with Privacy:nw-level or Privacy:all. 6.2.6. History Info History-Info header [11] that is set by user agent contains the user's URI. History-Info headers set by network entities may contain URIs to which the request was forwarded or retargeted. A user agent constructing anonymous SIP requests SHOULD NOT add a History-Info header. A privacy service SHOULD delete the History-Info headers when the user privacy is requested with Privacy:nw-level or Privacy:all. In addition, the History-Info header can reveal general routing information. Thus, network policy MAY also be used to determine whether to include the History-Info header at all, whether to capture a specific Request-URI in the header, or whether it be included only in the Request as it is retargeted within a specific domain. Refer to RFC 4244 [11] for detail behaviors to deal with History-Info headers. 6.2.7. Identity/Identity-Info Identity header [17] field contains a signature used for validating the identity. Identity-Info header field contains a reference to the certificate of the signer of Identity headers. Identity-Info header may reveal the information about the administrative domain of the user. The signature in an Identity header provides integrity protection over From, To, Call-ID, Cseq, Date, Contact headers and message body. The integrity protection is violated if a privacy service modifies these headers and message body for the purpose of user privacy protection. When a privacy service receives a request with an Identity header and Privacy:all, it SHOULD compute the signature using its own certificate (Assuming the privacy service has ability to access domain certificate) and replace the value of an Identity header after executing privacy functions on relevant headers that are considered user privacy related (From, Contact, etc.) and/or message body. A privacy service SHOULD replace the value of an Identity-Info header with the reference to the certificate it used to compute the signature. Munakata, et al. Expires August 23, 2007 [Page 17] Internet-Draft SIP Privacy Clarified Feb 2007 If the privacy service cannot compute the signature due to lack of its authority or lack of valid certificate, it SHOULD delete both Identity and Identity-Info headers when the user privacy is requested with Privacy:all is requested. When a privacy service receives a request with an Identity header and Privacy:nw-level, it SHOULD check the domain portion of From and domain portion of the Identity-Info value, if they match the header SHOULD be left untouched, if they mismatched the privacy service SHOULD remove Identity-Info and Identity header. 6.2.8. Organization This field contains additional information about the user. A user agent constructing anonymous SIP requests SHOULD NOT add a Organization header. A privacy service SHOULD delete the Organization headers when the user privacy is requested with Privacy:nw-level or Privacy:all. 6.2.9. P-Asserted-Identity This header contains a network verified and asserted identity of the user sending a SIP message. A privacy service SHOULD delete the P-Asserted-Identity headers before it forwards the message to an entity that is not trusted, when the user privacy is requested with Privacy:nw-level, Privacy:all, or Privacy:id. 6.2.10. Record-Route This field may reveal information about the administrative domain of the user. In order to hide Record-Route headers while keeping routability to the sender, privacy services can execute a practice referred to as "stripping". Stripping is to remove all the Record-Route headers that have been added to the request prior to its arrival at the privacy service and then add a single Record-Route header representing itself. In this case, the privacy service needs to retain the removed headers and restore them in a response. Besides, privacy services can remove the Record-Route headers, and encrypt it into a single header. In this case, the privacy service needs to decrypt the header and restore the former values in a response. Munakata, et al. Expires August 23, 2007 [Page 18] Internet-Draft SIP Privacy Clarified Feb 2007 A privacy service SHOULD strip or encrypt any Record-Route headers that have been added to a request before it reaches the privacy service when the user privacy is requested with Privacy:nw-level or Privacy:all. 6.2.11. Referred-By Referred-By header [16] carries a SIP URI representing the identity of the referrer. Referred-By header is an anonymization target when the REFER request with Referred-By header is sent by the user whose privacy is requested to be processed in the privacy service. A user agent constructing anonymous REFER requests SHOULD anonymize a Referred-By header using functional anonymous URI. A privacy service SHOULD anonymize a Referred-By header in REFER request using functional anonymous URI when the user privacy is requested with Privacy:all. On the other hand, Referred-By header is not an anonymization target when it appears in request other than REFER (e.g. INVITE) because the URI in the Referred-By header never represents the sender of the request. Example 1: Referrer request no privacy and referee request privacy Alice > REF(Referred-By:Alice) > Bob Bob > INV(Referred-By:Alice, Privacy:all) > PS > INV(Referred-By:Alice) > Carol Example 2: Referrer requested privacy and referee request privacy Alice > REF(Referred-By:Alice, Privacy:all) > PS > REF(Referred-By:X) > Bob Bob > INV(Referred-By:X, Privacy:all) > PS > INV(Referred-By:X) > Carol 6.2.12. Reply-To This field contains a URI that can be used to reach the user on subsequent call-backs. A user agent constructing anonymous SIP messages SHOULD NOT add a Reply-To header in the message. A privacy service SHOULD delete a Reply-To header when the user privacy is requested with Privacy:all. Munakata, et al. Expires August 23, 2007 [Page 19] Internet-Draft SIP Privacy Clarified Feb 2007 6.2.13. Server This field contains information about the software used by the UAS to handle the request. A user agent constructing anonymous SIP responses SHOULD NOT add a Server header in the response. A privacy service SHOULD delete a Server header when the user privacy is requested with Privacy:all. 6.2.14. Subject This field contains freeform text about the subject of the call. Which may include a text describing something about the user. A user agent constructing anonymous SIP requests SHOULD NOT add a Subject header. A privacy service SHOULD delete a Subject header when the user privacy is requested with Privacy:all. 6.2.15. User-Agent This field contains user agent's information. A user agent constructing anonymous SIP messages SHOULD NOT add a User-Agent header. A privacy service SHOULD delete User-Agent header when the user privacy is requested with Privacy:all. 6.2.16. Via A bottommost Via header added by a user agent contains an IP address and port or hostname that are used to reach the user agent for responses. Via headers added by proxies may reveal information about the administrative domain of the user. A user agent constructing anonymous SIP requests SHOULD anonymize a Via header that represents itself by using functional anonymous IP address and port. Detail on how to obtain anonymous IP address and port is covered in section 6.1.5. A privacy service SHOULD strip or encrypt any Via headers that have been added prior to reaching the privacy service when the user privacy is requested with Privacy:nw-level or Privacy:all. Refer to 6.2.10 for details of stripping and encryption. Munakata, et al. Expires August 23, 2007 [Page 20] Internet-Draft SIP Privacy Clarified Feb 2007 A privacy service SHOULD recover the original values of Via headers when handing a response in order to route the response to the originator. Even if the bottommost Via header is already anonymized before reaching a Privacy service, all Via headers including the bottommost one will be stripped or encrypted by the privacy service. No Via stripping is required when handling responses. 6.2.17. Warning This field may contain host name of the user agent. A user agent constructing anonymous SIP responses SHOULD NOT include host name in a Warning header. A privacy service SHOULD modify a Warning header by deleting host name portion from the header when the user privacy is requested with Privacy:all. 6.3. SIP Parameters / SDP Attributes This section describes privacy considerations for each SIP related parameter including SDP attributes that may reveal information about the user. When the privacy functions for user inserted information are requested to be executed at a privacy service, user agents MUST NOT encrypt SDP bodies in messages using S/MIME. 6.3.1. c/m Lines The c and m lines in the SDP body convey an IP address and port for receiving media. A user agent constructing anonymous SIP messages SHOULD anonymize the IP address and port in m and c lines using functional anonymous IP address and port. A privacy service SHOULD anonymize the IP address and port in m and c lines using functional anonymous IP address and port, when the user privacy is requested with Privacy:all. This is generally done through replacing IP address and port present in the SDP with that of a relay server. How to obtain functional anonymous IP address at a user agent is covered in section 6.1.5. Munakata, et al. Expires August 23, 2007 [Page 21] Internet-Draft SIP Privacy Clarified Feb 2007 6.3.2. o Line The username and IP address in this attribute may reveal information about the user. A user agent constructing anonymous SIP messages SHOULD anonymize the username and IP address in o lines by setting username to "-" and by setting functional anonymous IP address as IP address. A privacy service SHOULD anonymize the username and IP address in o lines by setting username to "-" and setting functional anonymous IP address as IP address, when the user privacy is requested with Privacy:all. How to obtain functional anonymous IP address at a user agent is covered in section 6.1.5. 6.3.3. i/u/e/p Lines These lines may contain information about the user. A user agent constructing anonymous SIP messages SHOULD NOT include their information in i, u, e, and p lines. A privacy service SHOULD modify i, u, e, and p lines to delete user's identity information when the user privacy is requested with Privacy: all. 6.4. Considerations for Non-Target SIP Headers/Parameters 6.4.1. In-Reply-To This field enumerates the Call-IDs that the call references or returns. The Call-ID may contains an IP address or a host name of the originator of the referenced call. The originator of the referenced call cannot be the sender of the request with In-Reply-To header. Therefore, there is no information of the sender, and this header is outside the anonymization target. As described in section 6.2.1 (Call-ID), regardless of priv-value or presence of a Privacy header, once a privacy service modifies a Call-ID in the previous request, a privacy service SHOULD restore the former value in a In-Reply-To header in the related INVITE request. Example: Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob Bob > INV(In-Reply-To:C2, Privacy:none) > PS > INV(Call-ID:C1) > Alice Munakata, et al. Expires August 23, 2007 [Page 22] Internet-Draft SIP Privacy Clarified Feb 2007 Note: This is only possible if the privacy service maintains state and retains all the information it modified to provide privacy even after the dialog is terminated, which would be an unlikely event. Call back is difficult to realize once a privacy service is involved in forming the dialog to be referenced. 6.4.2. Path This field may contain information about the administrative domain and/or the visited domain of the user agent, however, the Path header is not the target of any priv-values. Path headers [17] only appear in REGISTER requests and responses. Given that a user agent sends a REGISTER request with Privacy:nw- level or Privacy:all, Path headers inserted by intermediaries may contain information about the domain where the user is visiting, and there is no point in hiding such user location information from the registrar who receives the REGISTER request. The only reason privacy may be considered desirable is if the visited domain wants to withhold its topology from the home domain of the user. However, anonymization of network privacy related information is out of scope. Editor's Note: If the Privacy header is not allowed in REGISTER requests, Path header is automatically outside of the target. 6.4.3. Replaces Header/Parameter Replaces header [18] and "replaces" parameter contain dialog identifiers of a dialog to be replaced, which are composed of Call-ID, local tag, and remote tag. The sender of the INVITE with a Replaces header is never an originating user agent or terminating user agent of the target dialog to be replaced. And therefore the Call-ID within the Replaces header is never generated by the sender. Therefore, this header is outside the anonymization target per priv-value. The "replaces" parameter is not the target of any particular priv- values neither. The parameter appears in a Refer-To header in REFER request, and its functionality when anonymized depends on the circumstances it is used. The REFER may work and may not work depending on three criteria below. Munakata, et al. Expires August 23, 2007 [Page 23] Internet-Draft SIP Privacy Clarified Feb 2007 1. Who generated the Call-ID. 2. Where on the signaling path is the privacy service. 3. Who initiates the REFER with "replaces" parameter. As described in section 6.2.1 (Call-ID), regardless of priv-value or presence of a Privacy header, once a privacy service modifies a Call-ID in the request, a privacy service SHOULD monitor headers that may contain Call-ID and restore the portion of the value representing the modified Call-ID to original Call-ID value in a Replaces header received. Main challenge for this to function properly is that privacy service has to be on a signaling path to the originator for every dialogs. Which is generally not possible. Followings are few examples exploring when Replaces parameter works and fails. Example 1: Transfer initiated by the originator PS added for INV and REF Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:all) > PS > REF(Refer-To:Bob?Replaces=C2) > Carol Carol > INV(Replaces:C2) > Bob Example 2: Transfer initiated by the originator PS added only for INV Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob Alice > REF(Refer-To:Bob?Replaces=C1) > Carol Carol > INV(Replaces:C1) > Bob (FAIL) Note: Example 2 would succeed if the same PS (that modifies the Call-ID in the INVITE from Alice) is added for REFER too and modifies the value in "replaces" parameter from C1 to C2, even if there is no Privacy header in the REFER. Example 3: Transfer initiated by the originator PS added only for REF Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:all) > PS > REF(Refer-To:Bob?Replaces=C1) > Carol Carol > INV(Replaces:C1, Privacy:all) > PS' > INV(Replaces:C1) > Bob Munakata, et al. Expires August 23, 2007 [Page 24] Internet-Draft SIP Privacy Clarified Feb 2007 Example 4: Transfer initiated by the terminating party PS added for both INV Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob Bob > REF(Refer-To:Alice?Replaces=C2) > Carol Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice Note: Example 4 succeeds because the same PS (that modifies the Call-ID in the INVITE from Alice) checks the incoming requests and modifies the value in a Replaces header in the INVITE from Carol to the former value of Call-ID (C1). Example 5: Hold Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server Music-Server > INV(Replaces:C1) > Bob (FAIL) Note: Example 5 would succeed if the same PS (that modifies the Call-ID in the INVITE from Alice) is added for INVITE from Music-Server and modifies the value in a Replaces header from C1 to C2. As you can see from examples above, in some scenarios, information carried in Replaces header/parameter would result in failing the REFER. This would not happen if the anonymization is done at a user agent. 6.4.4. Route This field may contain information about the administrative domain of the user agent, however, the Route header is not the target of any priv-values. Route headers appear only in SIP requests to force routing through the listed set of proxies. If a privacy service anonymizes the Route header, the routing does not function. Furthermore, there is no risk to reveal the information in the Route headers to further network entities including terminating user agent, because a proxy removes the value from the Route header when it replaces the value in the Request-URI as defined in RFC 3261. 6.4.5. Service-Route Service-Route [19] headers only appear in 200 OK responses for REGISTER requests, and contains information about the registrar. The purpose of the privacy mechanism defined in this document is to secure user's privacy, and the case where a registrar sets a Privacy header is not considered here. Therefore, the Service-Route header is not the target of any priv-values. Munakata, et al. Expires August 23, 2007 [Page 25] Internet-Draft SIP Privacy Clarified Feb 2007 Furthermore, if the Service-Route is replaced with other value less sensitive (That of a SBC etc.), it is not because it was requested by the user but rather it would be likely to be at the convenience of the domain policy/network policy and use of privacy for this purpose seems illogical. Editor's Note: If the Privacy header is not allowed in responses for REGISTER requests, Service-Route header is automatically outside of the target. 6.4.6. Target-Dialog Target-Dialog header faces exactly the same issues seen in Replaces header. Please refer to section 6.4.3 for why this is not a target for any particular priv-values and how a privacy service still needs to evaluate and modify the value contained even if no privacy is requested. Munakata, et al. Expires August 23, 2007 [Page 26] Internet-Draft SIP Privacy Clarified Feb 2007 7. User Agent Behavior A user agent fully compliant to this document SHOULD anonymize its messages by following the guidelines in section 7.2, when user privacy is requested. If the ability of the user agent to obfuscate information is limited to only part of the information listed in table 1 under UA/nw-level, the user agent SHOULD NOT try to anonymize the messages but instead utilize the privacy service and delegate the anonymization as described in the section 7.3. Any attempt to anonymize the message at the user agent without its ability to obscure all of the information listed in table 1 under UA/ nw-level may result in privacy implications, revealing information about the originator to the recipient of the message. Although when privacy service is temporarily out of service, non existent or unreachable from the network where originator is connected, limited anonymization may be useful. In any case whenever the user agent is aware of the potential privacy implication due to either a lack of ability to obscure the privacy sensitive information or absence of privacy services, it is RECOMMENDED that user agent somehow communicates the possible privacy implication to the originating user. 7.1. Locating Privacy Service Even with a user-agent fully compliant to this document, providing complete anonymity is not always possible as headers modified/ inserted by intermediaries may contain information about the originator. In order for the user agent to insure message sent is fully anonymized by the time it is received by the recipient, aid from privacy services is imperative. The most obvious means for the user agent to invoke the privacy function is to direct a request through an intermediary known to act as a privacy service. Location of privacy service may be learnt through means such as configuration framework [13], manual configuration etc. If the originating user agent is aware of the URI for the privacy service it SHOULD address the privacy service by setting the URI of the privacy service in the "Route" header. If the originating user wishes to keep their local administrative domain a secret, then they must use a third-party anonymization service outside of any of the principal domains associated with the user. Such domain may exist strictly for providing anonymity. Munakata, et al. Expires August 23, 2007 [Page 27] Internet-Draft SIP Privacy Clarified Feb 2007 It is highly RECOMMENDED that user agents use network or transport layer security, such as TLS, when contacting a privacy service. Ideally, user agents SHOULD establish a direct (i.e., single pre- loaded Route header) connection to a privacy service; this will both allow the user to inspect a certificate presented by the privacy service, and it will provide confidentiality for requests that will reduce the chances that the information that the privacy service will obscure is revealed before a message arrives at the privacy service. By establishing a direct connection to a privacy service, the user also eliminates the possibility that intermediaries could remove requests for privacy. If a direct connection is impossible, users SHOULD use a mechanism like SIPS to guarantee the use of lower-layer security all the way to the privacy service. If a user agent believes that it is sending a request directly to a privacy service, it SHOULD include a Proxy-Require header containing an option-tag, "privacy", That way, in the unlikely event that the user agent sends a request to an intermediary that does not support the extensions described in this document, the request will fail, although it will not guarantee that privacy function will be executed as the user agent requested. When a user agent is aware of the fact that direct connection to privacy service isn't possible, user agent MAY display a warning to the user about the possible privacy implication(e.g. "Unable to guarantee privacy protection"). Note: Currently there is no way for a user agent to tell if a privacy function was invoked on an outgoing request/response. There is also no means to insure the invocation of privacy functions, use of the option-tag in Proxy-Require merely means that proxy understands the specification and does not necessary mean the proxy/privacy-service can provide privacy function requested. It is possible that request with certain level or privacy requested passes through proxies and privacy service, and as it happens none of the intermediaries support the level of privacy and as a consequences reaching the recipient without any privacy treatment revealing everything about the originator. 7.2. Generating Anonymous Request If user agent compliant to this document is aware of its ability that it can fully anonymize and obscure its request and response on its own, it SHOULD obscure or conceal all the information listed in table 1 under column "UA". For detail of what kind of treatment UA needs to conduct over each headers and parameters refer to section 6. The two imperative information user agent needs to obscure while Munakata, et al. Expires August 23, 2007 [Page 28] Internet-Draft SIP Privacy Clarified Feb 2007 sustaining its purpose and functionality is URI and IP address used for establishing media/signaling session. Instruction on how to obtain function anonymous URI and IP address is covered in section 6.1.3 and 6.1.5 respectively. For any other headers and information, the user agent SHOULD follow the instruction in section 6 for the headers listed in table 1 under column "UA". 7.2.1. Intermediary Inserted/modified Information Some information inserted by an intermediaries such as History-Info [11], Record-Route header, P-Asserted Identity [10], Identity-Info [6], Geolocation [12] etc. may reveal or identify the originator of the request. These information can not be modified or omitted by a user agent. A user agent therefore needs to request the privacy service to help anonymize the request even if it obscured all the information listed in table 1 and 2 under column "UA". To request a privacy service to obscure or omit information set or modified by the intermediaries, the user agent SHOULD set "nw-level" as the priv-value to the privacy header. 7.3. Requesting Anonymization at Privacy Service If a user agent compliant to this document is unaware of its ability or is aware of lack of ability to fully anonymize its request/ response, it SHOULD request anonymization from the privacy service whenever anonymization is desired. The User agent delegating the task of privacy function to the privacy service can do so by setting the value of Privacy header to "all". If direct connection to the privacy service is not available or possible, the ramification may be that request will not be anonymized. So it is highly recommended to establish a direct connection to the privacy service whenever its possible to ensure privacy function is executed or else be notified that level of privacy requested is not possible. 7.4. Requesting No Privacy Treatment If a user agent compliant to this document desires no privacy and rather desires to see no privacy functions be applied to its message and as a result reveal its identity to the recipient, the user agent SHOULD request no privacy by setting the value of Privacy header to "none". Munakata, et al. Expires August 23, 2007 [Page 29] Internet-Draft SIP Privacy Clarified Feb 2007 8. Privacy Service Behavior The privacy service role is instantiated by a network intermediary, frequently by entities that can act as SIP proxy servers. The function of a privacy service is to supply privacy functions for SIP messages that cannot be provided by user agents themselves. 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 ascertaining the preferences of the user (such as a pre-arranged user profile) and therefore they MAY perform such other privacy functions without an explicit Privacy header. Performing even a privacy function on user privacy related information in a privacy service could be useful, for example, when a user is sending messages from a legacy client that does support the Privacy header, or a user agent that does not allow the user to configure the values of headers that could reveal personal information. However, if the Privacy header value of "none" is specified in a message, privacy services SHOULD NOT perform any privacy function on the headers containing user privacy related information and SHOULD NOT remove or modify the Privacy header. If privacy is requested by an originator, it is generally assumed that privacy is desired for the duration of the dialog. In which case privacy service SHOULD Record-Route itself in the dialog-forming request to ensure its ability to provide privacy function for the duration of the dialog. When doing so, if Record-Route already present it should modify its value according to section 6.2.10. If it's not present it should Record-Route itself by adding the Record- Route header. Privacy services MUST implement support for the "none" and "id" privacy tokens, and MAY implement "nw-level", "all", "history" and any of other privacy tokens that are obsolete by this document. In some cases, the privacy service will not be capable of fulfilling the requested level of privacy. A privacy service SHOULD be prepared to receive a request outside of a dialog relating to an active dialog privacy service is providing a service to(Call-ID in Replaces, Target-Dialog etc), in which case the privacy service SHOULD do its best to recover the original value so originator can handle the request correctly (e.g. Call-ID modified by the privacy service in Replaces to Call-ID originator had sent). When a privacy service performs one of the functions corresponding to a privacy level listed in the Privacy header, it SHOULD remove the Munakata, et al. Expires August 23, 2007 [Page 30] Internet-Draft SIP Privacy Clarified Feb 2007 corresponding priv-value from the Privacy header - otherwise, any other privacy service involved with routing this message might unnecessarily apply the same function, which in many cases would be undesirable. When the priv-value has been removed from the Privacy header, the entire Privacy header MUST be removed from a 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. When the privacy service receives a request with a level of privacy it does not support, the privacy service MUST decline the request with 4xx response unless it can forward the request to a privacy service that can provide the level of privacy requested. Note: Do we need a new response code to notify the user agent about lack of support for requested level of privacy? 8.1. Handling Message with Privacy:nw-level If a privacy level of "nw-level" is requested, then the requestor has asked the privacy service to help to obscure information that may reveal information about the requestor that were added by the intermediaries. However, the values that have been so obscured must be recoverable when further messages in the dialog need to be routed to the originating user agent. In order to provide these functions the privacy service must frequently act as a transparent B2BUA. Firstly, a request with privacy level of "nw-level" entails that the intermediaries SHOULD NOT add any headers to the message that reveal any identity or any other user privacy related information which may impose privacy implication. The relevant information which privacy service SHOULD omit or obscure when this level of privacy is requested are listed in table 1 under "nw-level/PS". Detail treatment of listed headers are described in section 6. Note that when a privacy service is handling a request and providing 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. 8.2. Handling Message with Privacy:all If a privacy level of "all" is requested, then the requestor has asked the privacy service to help to obscure every possible information that may reveal information about the requestor, Munakata, et al. Expires August 23, 2007 [Page 31] Internet-Draft SIP Privacy Clarified Feb 2007 including all the listed in section 6. However, the values that have been so obscured must be recoverable when further messages in the dialog need to be routed to the originating user agent. In order to provide these functions the privacy service must frequently act as a transparent B2BUA. Firstly, a request with privacy level of "all" entails that the privacy server SHOULD NOT add any headers to the message that reveal any identity or any other user-level information which may impose privacy implication. The relevant information which privacy service SHOULD omit or obscure when this level of privacy is requested are listed in table 1 under "all". Detail treatment of listed headers are described in section 6. Note that when a privacy service is handling a request and providing 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. 8.3. Handling Message with Privacy:none If a privacy level of "none" is requested, then the originator has asked the privacy service to apply no privacy functions to the relevant message. The privacy services SHOULD NOT remove or alter headers to obscure. Intermediaries SHOULD NOT remove or alter a Privacy header whose priv- value is "none". 9. Proxy Server Behavior If a proxy server receives a request containing a Privacy header with values "all" or "nw-level", the proxy server should route the call to a privacy service if it is aware of the location of the privacy service and if no pre-configured route set exists in the request. When proxy server receives a request containing a Privacy header with values "all" or "nw-level", the proxy server SHOULD not add any information that may reveal something about the originator that is irrelevant to routing. Munakata, et al. Expires August 23, 2007 [Page 32] Internet-Draft SIP Privacy Clarified Feb 2007 10. Guidelines on the privacy consideration for future RFCs This section gives the guidelines on providing a privacy considerations for future documents defining new SIP headers, parameters and/or new priv-values that may impact privacy in someway. 10.1. Future RFCs with Privacy Implications Whenever a new SIP header or a SIP parameter is defined, consideration MUST be made whether the new header/parameter is a target of the privacy mechanism. In other words, if the header/ parameter carries privacy sensitive information, the privacy considerations SHOULD be part of the document that defines the new header/parameter. The privacy considerations SHOULD specify the treatment desired for each priv-values on the header/parameter, the document defines. This may include but not limited to clarifying the priv-value that imposes manipulation/obfuscation and the desired treatment of relevant header/parameter by the privacy function. Understating the privacy consideration when defined extension carries privacy sensitive information may have the ramification undesired. 10.2. Future RFCs defining a new priv-values When defining a new priv-value, the target headers/parameters MUST be specified. If the specified priv-value requires different treatment from what's specified in this document, that needs to be clarified as well. Note: It is RECOMMENDED to use existing priv-values and avoid defining a new priv-value to keep the privacy mechanism simple. 11. Security Considerations Messages that request privacy require confidentiality and integrity. Without integrity, the requested privacy functions could be downgraded or eliminated, potentially exposing identity information. Without confidentiality, eavesdroppers on the network (or any intermediaries between the user and the privacy service) could see the very personal information that the user has asked the privacy service to obscure. All of the network-provided privacy functions in this document entail a good deal of trust for the privacy service. Users should only trust privacy services that are somehow accountable to them. Munakata, et al. Expires August 23, 2007 [Page 33] Internet-Draft SIP Privacy Clarified Feb 2007 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. Note that 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 result in the compromise of any private information. Obviously, users that do not wish to reveal their identity to servers that issue authentication challenges MAY elect not to respond to such challenges. Some recommendations are provided to secure the messages when privacy services are in use. o It is recommended that user agent uses SIPS or TLS for transport protocol to secure the message from malicious entity eavesdropping on the call. o If the privacy service's URI is known It is also recommended to use S/MIME to protect the message for both confidentiality and integrity. 12. IANA Considerations This document adds values to the IANA registry for priv-value tokens. If more values are to be added they should be indexed by priv-value tokens and should contain a short semantic description of the new value. The values to be added with this draft are as follows: o nw-level: Request that a privacy service removes or obscures intermediary inserted/modified information. o all: Request that a privacy service removes or obscures all user privacy related information. 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 the participants in sessions are advised against extending the "Privacy" header - rather, it is preferable to create new identity mechanisms whose privacy can be managed by the user agent without the agency of intermediaries. Munakata, et al. Expires August 23, 2007 [Page 34] Internet-Draft SIP Privacy Clarified Feb 2007 13. References 13.1. Normative Reference [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005. [3] 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. [4] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft draft-ietf-sip-gruu-10, November 2006. [5] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [6] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [7] Rosenberg, J., "Traversal Using Relay NAT (TURN)", Draft draft-rosenberg-midcom-turn-08, September 2005. [8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. 13.2. Informative Reference [9] Sparks, R., "The Session Initiation Protocol (SIP) Refer Method", RFC 3315, April 2003. [10] Jennings, C., Peterson, J., and M. Watson, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks", RFC 3325, November 2002. [11] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [12] Polk, J. and B. Rosen, "Session Initiation Protocol (SIP) Location Conveyance", Draft draft-ietf-sip-location-conveyance-07.txt, Feb 2007. Munakata, et al. Expires August 23, 2007 [Page 35] Internet-Draft SIP Privacy Clarified Feb 2007 [13] Petrie, D. and S. Channabasappa, "A Framework for Session Initiation Protocol User Agent Profile Delivery", Draft draft-ietf-sipping-config-framework-10, March 2007. [14] Levington, E., "Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998. [15] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005. [16] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC 3892, September 2004. [17] Willis, D. and H. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts", RFC 3327, December 2002. [18] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation Protocol (SIP) "Replaces" Header", RFC 3891, September 2004. [19] Willis, D. and H. Hoeneisen, "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration", RFC 3608, October 2003. [20] Rosenberg, J., "Request Authorization through Dialog Identification in the Session Initiation Protocol (SIP)", RFC 4538, June 2006. Munakata, et al. Expires August 23, 2007 [Page 36] Internet-Draft SIP Privacy Clarified Feb 2007 Authors' Addresses Mayumi Munakata NTT Corporation Phone: +81 422 36 7565 Email: munakata.mayumi at lab.ntt.co.jp Shida Schubert NTT Corporation Phone: +1 604 762 5606 Email: shida at ntt-at.com Takumi Ohba NTT Corporation 9-11, Midori-cho 3-Chome Musashino-shi, Tokyo 180-8585 Japan Phone: +81 422 59 7748 Email: ohba.takumi at lab.ntt.co.jp URI: http://www.ntt.co.jp Munakata, et al. Expires August 23, 2007 [Page 37] Internet-Draft SIP Privacy Clarified Feb 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Munakata, et al. Expires August 23, 2007 [Page 38]