SIPPING M. Munakata Internet-Draft S. Schubert Intended status: Informational T. Ohba Expires: April 15, 2007 NTT October 15, 2006 Clarification of Privacy Mechanism for SIP draft-munakata-sipping-privacy-clarified-00 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 April 15, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract This document is an informational RFC to clarify the use of privacy mechanism for Session Initiation Protocol (SIP) that is specified in RFC 3323 and extended in subsequent RFCs, such as RFC 3325. It is intended to clarify the semantics of each privacy header value (priv-value) and the handling of the relevant target SIP headers for each of the priv-value. It also provides some guidelines on providing privacy considerations for future specifications that define SIP headers which may be influenced by the privacy mechanism. Munakata, et al. Expires April 15, 2007 [Page 1] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 Table of Contents 1. Introduction ....................................................2 2. Terminology .....................................................3 3. Clarification of the existing privacy mechanism .................3 3.1. Clarification of the existing priv-values ..................4 3.2. Target for each priv-value .................................5 4. Guidelines on the privacy considerations for future RFCs ........6 4.1. Guidelines on considering the impact of the existing privacy mechanism to future SIP headers ...........6 4.2. Guidelines on specifying new priv-values ...................6 5. Security Considerations .........................................7 6. IANA Considerations .............................................7 7. Normative References ............................................7 1. Introduction This document clarifies the privacy mechanism for Session Initiation Protocol (SIP) [2] defined in RFC 3323 [3] and extended in RFCs 3325 [4] and 4244 [5]. It describes the practical manner of operations of the privacy mechanism as BCP (Best Current Practice) and has no intention to change the existing definitions of the privacy mechanism. In RFC 3323, the semantics of basic set of priv-values (header, session, user, none, and critical) is defined, but it has some ambiguities. Moreover, the target headers to be obscured per priv- value are not explicitly specified. These ambiguities may result in different interpretations of header handling per priv-value at an entity who sets a Privacy header and at an entity who processes the Privacy header, which could lead to an adverse impact on interoperability. Additional priv-values, "id" and "history", are defined in RFCs 3325 and 4244 respectively. In RFC 4244 that defines History-Info header, the priv-value of "history" is defined in order to request privacy on History-Info headers, and the target to be obscured for "history" privacy is specified as History-Info headers alone. In addition, the RFC clearly describes that History-Info headers are also the target when "header" and "session" privacy are requested. On the other hand, RFC 3325 defines P-Asserted-Identity header and a priv-value of "id", which is used to request privacy manipulation on the P-Asserted-Identity headers alone, but it does not specify how other priv-values may impact the privacy handling of P-Asserted- Identity header. Because of this implicitness, it has been observed that some implementations are suffering from the inability to realize the intended privacy due to the discrepancy of interpretations. Munakata, et al. Expires April 15, 2007 [Page 2] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 This document tries to clarify the target to be obscured among the existing SIP headers for each of the priv-value. It also offers guidelines on providing privacy considerations in the future draft and RFC that defines a new SIP header imposing a privacy implication. 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 defined to be used in Privacy header. The existing priv-values are "header", "session", "user", "none", and "critical" defined in RFC 3323 [3], "id" defined in RFC 3325 [4], and "history" defined in RFC 4244 [5]. 3. Clarification of the existing privacy mechanism This section describes the semantics of each priv-value according to the existing privacy mechanism documents, RFCs 3323 [3], 3325 [4], and 4244 [5], and organizes the target to be obscured among the existing SIP headers. 3.1. Clarification of the existing priv-values This section tries to provide clear semantics on each of the priv- value defined in RFCs 3323, 3325, and 4244. The first sentence of each definition is taken from the description registered with IANA. The rest of the definition is extracts from the RFCs and it needs more clarification. priv-value (RFC) Outline of definitions user (3323) Request that privacy services provide a user-level privacy function. This privacy level is usually set only by intermediaries, in order to communicate that user level privacy functions must be provided by the network, presumably because the user agent is unable to provide them. The privacy service must remove any non-essential informational headers that have been added by the user agent. Munakata, et al. Expires April 15, 2007 [Page 3] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 header (3323) Request that privacy services modify headers that cannot be set arbitrarily by the user (Contact/Via). The user requests that a privacy service obscure those headers which cannot be completely expunged of identifying information without the assistance of intermediaries (such as Via and Contact). Also, no unnecessary headers should be added by the service that might reveal personal information about the originator of the request. session (3323) Request that privacy services provide privacy for session media. The user requests that a privacy service provide anonymization for the session(s) (described, for example, in a Session Description Protocol [6] body) initiated by this message. This will mask the IP address from which the session traffic would ordinarily appear to originate. none (3323) Privacy services must not perform any privacy function. The user requests that a privacy service apply no privacy functions to this message. The privacy services must not perform any privacy function and must not remove or modify the Privacy header. critical (3323) Privacy service must perform the specified services or fail the request. The user asserts that the privacy services requested for this message are critical. If the privacy service is incapable of performing all of the levels of privacy specified in the Privacy header then the privacy service must fail the request with a 500 (Server Error) response code. id (3325) Privacy requested for Third-Party Asserted Identity. It indicates that the Network Asserted Identity to be kept private. Proxy must remove all the P- Asserted-Identity header fields before forwarding messages to elements that are not trusted. history (4244) Privacy requested for History-Info header(s). It indicates that a specific or all History-Info headers should not be forwarded. Proxy should remove any hi-entry(s) prior to forwarding to domain for which the proxy is not responsible, depending upon local policy. Note: Where each privacy service is executed is out of scope. It depends on implementations and network policy. Munakata, et al. Expires April 15, 2007 [Page 4] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 3.2. Target for each priv-value Table 1 below shows the recommended behaviors of proxies who accomplish the privacy service when each of the priv-value is set in a Privacy header in the request. The other existing SIP headers that are not shown in Table 1 are regarded as a non-target of these priv- values. Note 1: The scope of the target in this document is only SIP headers. SDP, RTP and other parameters are out of scope. Note 2: This is just a recommendation and the detailed behaviors are dependent upon implementations and network policy. Note 3: This clarification does not prevent proxies to manipulate other headers depending on the local policy. Note 4: The behaviors without question mark are specified in RFCs 3323, 3325, and 4244. The behaviors with question mark need discussions. Note 5: There may be more headers to be included in this table. Further study will be necessary. Target headers user header session id history From modify Contact modify Reply-To delete Via strip* Call-Info delete not add User-Agent delete Organization delete not add Server not add Subject delete Call-ID modify In-Reply-To delete Warning modify? Record-Route strip* P-Asserted-Identity delete History-Info not add not add delete Path strip*? Referred-By modify? Replaces modify? Service-Route strip*? Target-Dialog modify? Table 1: Recommended proxy behaviors for each priv-value Munakata, et al. Expires April 15, 2007 [Page 5] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 *strip: Privacy services operating on requests should remove all Via/Record-Route/Path/Service-Route headers that have been added to the request prior to its arrival at the privacy service and then should add a single Via/Record-Route/Path/ Service-Route header representing themselves. 4. Guidelines on providing the privacy considerations for future RFCs. This section gives the guidelines on providing the privacy considerations when new SIP headers and/or new priv-values will be defined in the future. 4.1. Guidelines on considering the impact of the existing privacy mechanism to future SIP headers Whenever a new SIP header is defined in the future, it MUST be considered whether the new header is a target of the existing privacy mechanism. If the header is considered to be a target of any one of the priv-values, the privacy considerations SHOULD be included in the document that defines the new header. The privacy considerations need to clearly specify the impact of the relevant priv-values for the new header, including which priv-value results in manipulation of the new header as well as the actual manipulations recommended to the new header by proxy providing privacy services. Without the privacy consideration descriptions, it is regarded that the new header is not a target of any existing priv-values. The example text for privacy considerations is as follows. A UAC that wants to request the removal of XXX header due to privacy considerations SHOULD include a Privacy header with a priv-value(s) of "session" and/or "header" in the request. If a priv-value(s) of "session" and/or "header" is present in a Privacy header, proxies MUST remove the XXX header field before forwarding the request to a UAS. 4.2. Guidelines on specifying new priv-values Whenever a new priv-value is defined in the future, the target headers MUST be clearly specified. The existing SIP headers that are not specified as the target are regarded as a non-target of the new priv-value. Note: Unless new privacy mechanism is required to obscure specific SIP header(s), it is RECOMMENDED to use existing priv-values and avoid defining a new priv-value. Munakata, et al. Expires April 15, 2007 [Page 6] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 The example text for defining a new priv-value is as follows. A UAC who wants to request the removal of XXX header field before it is transmitted to a UAS MAY include a Privacy header in the request with a priv-value of "xxx" defined in this document. If this priv-value "xxx" is present in a Privacy header, proxies MUST remove the XXX header field before forwarding the request to a UAS. 5. Security Considerations This document adds no new security considerations to those discussed in RFCs 3323 [3], 3325 [4], and 4244 [5]. 6. IANA Considerations This document requires no action by IANA. 7. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] 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. [3] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [4] 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. [5] Barnes, M., "An Extension to the Session Initiation Protocol (SIP) for Request History Information", RFC 4244, November 2005. [6] Handley, M., Jacobson, V., C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006. Munakata, et al. Expires April 15, 2007 [Page 7] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 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 April 15, 2007 [Page 8] Internet-Draft Clarification of Privacy Mechanism for SIP October 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Munakata, et al. Expires April 15, 2007 [Page 9]