SIP M. Munakata Internet-Draft S. Schubert Intended status: Standards Track T. Ohba Expires: December 20, 2007 NTT June 18, 2007 UA-Driven Privacy Mechanism for SIP draft-munakata-sip-privacy-new-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 December 20, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract In order to withhold user's identity and related information, RFC 3323 defines a Privacy mechanism for SIP, which requires a use of an intermediary after the name of privacy service. This document proposes a new privacy mechanism that a user agent utilizes to conceal privacy sensitive information without the need for an aid from privacy service. Munakata, et al. Expires December 20, 2007 [Page 1] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 4 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Treatment of User Privacy Related Information . . . . . . . . 5 6.1. Anonymous URI . . . . . . . . . . . . . . . . . . . . . . 6 6.2. Anonymous IP Address . . . . . . . . . . . . . . . . . . . 6 7. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 7.1. Generating Anonymous Message . . . . . . . . . . . . . . . 7 7.2. Indication to maintain Privacy . . . . . . . . . . . . . . 7 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . . . 10 Munakata, et al. Expires December 20, 2007 [Page 2] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 1. Introduction Privacy is defined in this document as the withholding of the identity of a person (and related personal information) from destination(s) of messages and/or intermediaries handling these messages in a SIP (Session Initiation Protocol) [RFC3261] dialog. In SIP, identity is most commonly carried in the form of a SIP URI and an optional display-name, which commonly appear in the To, From and other header fields of SIP requests and responses. 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. Moreover, information in the Record-Route and Via headers could inadvertently reveal something about the originator of a message. In order to provide the privacy, [RFC3323] defines a privacy mechanism for SIP, which was then the best current practice to maintain privacy. Since then, numerous SIP extensions have been proposed and standardized, with some of which it seems possible now for a user agent to withhold its user's identity and related information without a dependency on privacy services, which when RFC3323 was defined was not possible. Some aspect of RFC 3323 especially its dependency on privacy service to provide privacy seems to cause some issues, which hope we can resolve with this specification. Some of the issues realized with the RFC 3323 are shown below. 1. There is no assurance that privacy server exists in the signaling path. 2. There is no mechanism to inform the user requesting the privacy that privacy function was properly executed. 3. For out of band dialog such as dialog attempt invoked by REFER etc, when the original dialog it references was mediated by privacy server, the same privacy server must get involved in the dialog attempt. 4. To map the referenced dialog to dialog attempt invoked by REFER etc, the privacy service needs to retain the mapping of an original information untreated by the privacy and that of what it treated beyond the actual dialog duration of the referenced dialog. Munakata, et al. Expires December 20, 2007 [Page 3] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 In order to solve the problems, this document proposes a new privacy mechanism that a user agent executes all the privacy functions on its own utilizing SIP extensions such as GRUU (Globally Routable User Agent URIs)[I-D.ietf-sip-gruu] and TURN (Traversal Using Relay NAT)[I-D.rosenberg-midcom-turn]. 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 [RFC2119]. 3. Concept of Privacy The privacy in this document means the concealing of the information that relates to a user, identifies a user, and belongs to a user, as well as the supplementary information which can be used to guess the user's identity. The scope of this document is to withhold an identity of a user and supplementary information from other users and intermediaries handling the message. The protection of network privacy (e.g. topology hiding) is out of scope. User-privacy-related information includes such as a display-name and a URI in a From header that can reveal user name and user's affiliation (e.g. company name), a contact information in a Contact header that is used to communicate with the user, an IP address in an SDP (Session Description Protocol)[RFC4566] that tells the location of user's terminal and be used to establish a connection. A host name in Call-ID is also regarded as user-privacy-related information because it may reveal the user's domain name. Privacy-sensitive information is divided into two types, user- inserted information and network-inserted information. A user agent can keep privacy of the user-inserted information by itself. On the other hand, regarding the network-inserted information, a user agent can insert a privacy flag and request intermediaries not to add the user-privacy-related information. 4. Use Cases The followings are the use cases from the viewpoint of privacy. Munakata, et al. Expires December 20, 2007 [Page 4] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 Case 1: User's privacy is required and a user agent can anonymize all of the user-inserted privacy-related information by itself. Case 2: User's privacy is required but a user agent cannot anonymize the user-inserted privacy-related information all by itself. Case 3: User's privacy is not required. The user does not want privacy at all and would like to reveal its identity. The case 2 is out of scope of this document. 5. Requirements The followings are requirements to cover the use cases in the previous section. Req 1: A user agent MUST be able to send a SIP request that is fully anonymized. This is to say that any headers and body inserted by the UA doesn't jeopardize users' privacy. Req 2: It MUST be possible for a user agent to indicate to a down stream entities that a user is requesting privacy. Req 3: When privacy is requested, a proxy SHOULD honor the request and only add information necessary to route the call, while withholding any sensitive information that may reveal anything about the user if possible. Req 4: Mechanism defined here MUST be backward compatible with the pre-existing privacy mechanism already in place. 6. Treatment of User Privacy Related Information URI used to exchange signaling (Contact, From etc.) and IP address used to exchange medias are two imperative information RFC 3323 could not provide means to obscure at the user agent. With the use of GRUU [I-D.ietf-sip-gruu] and TURN [I-D.rosenberg-midcom-turn], UA can now obtain URI and IP address that are functional, by which is usable to exchange either signaling or media while providing privacy. Munakata, et al. Expires December 20, 2007 [Page 5] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 6.1. Anonymous URI A user agent wanting to obtain functional anonymous URI SHOULD support and SHOULD utilize Global Routable User Agent URI (GRUU) 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 [I-D.ietf-sip-gruu]. If the Registrar supports GRUU and returns a REGISTER response, user agent SHOULD search within the REGISTER response for a "temp-gruu" URI parameter, which provides the privacy property desired. 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 wherever the 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 service as GRUU is merely a URI which is sequence of strings and digits with no explicit semantics that it's an anonymous URI. 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. It is RECOMMENDED that user agent consult the user before sending a request without functional anonymous URI when privacy is request from the user. 6.2. Anonymous IP Address It is assumed that User Agent is either manually or automatically configured through means such as configuration framework with one or more STUN relay server. Two IP addresses are needed to maintain privacy, one for signaling that is to be used in signaling such as in Via header, another to be used in SDP for media. User Agent which isn't provided with functional anonymous IP address through some administrative means, SHOULD obtain relayed address (IP Munakata, et al. Expires December 20, 2007 [Page 6] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 address of the media relay) for usage in SDP, derived from STUN relay server using the STUN Relay Usage[I-D.rosenberg-midcom-turn], which allows a STUN server to act as a media relay. Note: Relayed IP address may be used for Via header, but some commented that it's not an appropriate usage to use it for signaling. It was commented that IP address in Via is stripped by the proxy but that would impose proxy compliant to this specification to be in the signaling path. 7. User Agent Behavior A user agent fully compliant to this document SHOULD obscure or conceal all the user-inserted privacy-related information in SIP requests and responses when user privacy is requested. Section 7.1 describes how to generate an anonymous message at a user agent. When a user agent generates an anonymous message based on this specification, it SHOULD set an indication to tell intermediaries not to add or modify user-privacy-related information. Section 7.2 describes more about this. 7.1. Generating Anonymous Message The two imperative information user agent needs to obscure while sustaining its purpose and functionality is URI and IP address used for establishing media/signaling session. Instructions on how to obtain function anonymous URI and IP address are covered in Section 6.1 and 6.2, respectively. For anonymizing any headers and information in a SIP message, the user agent SHOULD follow the instructions in this document. Note: Instructions to treat each SIP header/parameter in generating an anonymous SIP message is FFS. 7.2. Indication to maintain Privacy This document defines a privacy flag, which indicates that the user requires privacy for the SIP message. Without a privacy flag, intermediaries might add some user-privacy-related information in the message, even if a user agent had anonymized the message as perfectly as possible. When a user agent generates an anonymous message by itself according to the guidelines in Section 7.1, it SHOULD set a flag to request intermediaries not to add user-privacy-related information. Munakata, et al. Expires December 20, 2007 [Page 7] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 Note: The solution of the flag is FFS. 8. Proxy Behavior When a proxy receives a SIP message containing a privacy flag, the proxy compliant to this specification MUST NOT add any information that may reveal something about the sender that is irrelevant to routing unless it knows that such information will be deleted before it leaves the boundary of the Trust Domain[RFC3324]. A proxy MUST NOT modify the privacy flag, if present. 9. Security Considerations TBD 10. IANA Considerations TBD 11. References 11.1. Normative References [I-D.ietf-sip-gruu] Rosenberg, J., "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)", draft-ietf-sip-gruu-13 (work in progress), April 2007. [I-D.rosenberg-midcom-turn] Rosenberg, J., "Traversal Using Relay NAT (TURN)", draft-rosenberg-midcom-turn-08 (work in progress), September 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3261] 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. [RFC3323] Peterson, J., "A Privacy Mechanism for the Session Munakata, et al. Expires December 20, 2007 [Page 8] Internet-Draft UA-Driven Privacy Mechanism for SIP June 2007 Initiation Protocol (SIP)", RFC 3323, November 2002. 11.2. Informative References [RFC3324] Watson, M., "Short Term Requirements for Network Asserted Identity", RFC 3324, November 2002. [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 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 December 20, 2007 [Page 9] Internet-Draft UA-Driven Privacy Mechanism for SIP June 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 December 20, 2007 [Page 10]