INTERNET-DRAFT Ian Elz Intended Status: Informational Expires: September 8, 2011 March 7, 2011 Requirements for 3rd Party Privacy in SIP Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html This Internet-Draft will expire on September 8, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Ian Elz Expires September 8, 2011 [Page 1] INTERNET DRAFT Requirements for 3rd Party Privacy in SIP March 7, 2011 Abstract Table of Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 2 Problem Scenarios . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 Privacy of 3rd Party Identities . . . . . . . . . . . . . . 3 2.2 Precedence of Privacy Headers . . . . . . . . . . . . . . . 4 2.3 Requirements . . . . . . . . . . . . . . . . . . . . . . . 5 3 Security Considerations . . . . . . . . . . . . . . . . . . . . 5 4 IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5.1 Normative References . . . . . . . . . . . . . . . . . . . 5 5.2 Informative References . . . . . . . . . . . . . . . . . . 6 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 Ian Elz Expires September 8, 2011 [Page 2] INTERNET DRAFT Requirements for 3rd Party Privacy in SIP March 7, 2011 1 Introduction The introduction of the Privacy mechanism {RFC3323only allows the setting of privacy for 'user' and 'header' identities from a UAC perspective in the Request and the UAS in the Response. The privacy mechanism was extended by {RFC3325] to include the 'id' privacy. At the time this was all that was required as SIP did not provide headers for carrying a third party identity in a Request or Response. The introduction of the REFER Method [RFC3515] and then the Referred- by mechanism [RFC3892] allowed for passing of a third party identity. The introduction of History-info [RFC4244] introduced an additional mechanism for passing of third part identities and modified the privacy specifically for History-info by use of the 'history' tag. There is still no mechanism in SIP for indicating the privacy of third party identities in a Request or Response other than the specific extension for History-info. 1.1 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 [RFC2119]. 2 Problem Scenarios Two individual issues arise from the addition of new headers and their impact on privacy: - How to specify the Privacy of 3rd Party Identities which occurs due to passing of these identities; e.g. Referred-by - The precedence of privacy values when there is a Privacy header and and privacy parameter as specified for History-info 2.1 Privacy of 3rd Party Identities The following scenario describes the case where a third party identity is passed in a SIP Request but the existing Privacy mechanism does not allow for the setting of privacy for the third party identity. Ian Elz Expires September 8, 2011 [Page 3] INTERNET DRAFT Requirements for 3rd Party Privacy in SIP March 7, 2011 Alice Bob Charlie | 1. REFER Alice | | |<-------------------------| | | Refer-to: Charlie | | | Referred-by: Bob | | | Privacy: user,header,id | | | | | | 2. INVITE Charlie Privacy: none Referred-by: Bob | |---------------------------------------------------->| | | Figure 1 - Referred-by privacy? 1. Bob sends a REFER to Alice to advise how she may contact Charlie. Bob includes a Privacy header as he does not want his identities made available. In the REFER request this should also be applicable to the Referred-by header as it also contains Bob's identity. 2. Alice sends and INVITE to Charlie following receipt of the REFER. The INVITE request has an explicit Privacy header of "none". This indicates that Alice does not require privacy for any of the identities included in the INVITE. This will also be applicable to the Referred-by header. As Bob has explicitly requested privacy when he sent the REFER request it is implicit that his identity should be kept private. The INVITE request has no mechanism for indicating that the Referred-by should be private as it is a third party identity whilst other identities may be revealed. 2.2 Precedence of Privacy Headers The following scenario illustrates a conflict in privacy settings where the existing standards do not define which value has precedence. Alice Bob Charlie | 1. INVITE Bob | | |------------------------->| | | Privacy: none | | | | | | | 2. INVITE Charlie | | |------------------------->| | | Privacy: none | | | H-I: ;index=1 | | H-I: ;index=1 Figure 2 - Privacy precedence Ian Elz Expires September 8, 2011 [Page 4] INTERNET DRAFT Requirements for 3rd Party Privacy in SIP March 7, 2011 1. Alice sends an INVITE to Bob and sets Privacy as "none". 2. Bob forwards the INVITE to Charlie and includes History-info headers. As Bob does not want his identity revealed to Charlie he includes a Privacy header parameter. The second INVITE has an issue as the Privacy header of "none" conflicts with the "history" privacy value included in the History- info header. What privacy should be applied by Charlie to the received message. Should the "none" apply which would allow Bob's identity in the History-info to be revealed? Should the privacy associated with the URI in the History-info take precedence over the "none"? At present the existing standards do not specify any precedence in this case. 2.3 Requirements Additional standardization work is required to fulfil the following requirements. 1. Capability is required to allow passing of privacy values related to third party identity in SIP messages. 2. When privacy is set for a third party identity in a SIP message the precedence of conflicting privacy values must be understood. 3 Security Considerations Not applicable 4 IANA Considerations Not applicable 5 References 5.1 Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3323] J. Peterson, "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC3323, November 2002 [RFC3325] C. Jennings, "Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Ian Elz Expires September 8, 2011 [Page 5] INTERNET DRAFT Requirements for 3rd Party Privacy in SIP March 7, 2011 Trusted Networks", RFC3325, November 2002 [RFC4244] M. Barnes, "An Extension to the Session Initiation Protocol (SIP)for Request History Information", RFC4244, November 2005 5.2 Informative References [RFC3892] R. Sparks, "The Session Initiation Protocol (SIP) Referred-By Mechanism", RFC3892, September 2004 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer Method", RFC33515, April 2003 Author's Addresses Ian Elz Coventry United Kingdom EMail: ian_elz@yahoo.co.uk Ian Elz Expires September 8, 2011 [Page 6]