MMUSIC Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-mmusic-privacy-00.txt> AT&T Category: Informational E. Miller G. Russell CableLabs B. Beser M. Mannette K. Steinbrenner 3Com D. Oran Cisco J. Pickens Com21 P. Lalwaney J. Fellows General Instrument D. Evans Lucent Cable K. Kelly NetSpeak F. Andreasen Telcordia June, 1999 SIP Extensions for Caller Privacy Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026, and the author does not provide the IETF with any rights other than to publish as an Internet-Draft. 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." DCS Group Internet Draft - Expiration 12/31/99 1 SIP Extensions for Caller Privacy June 1999 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. The distribution of this memo is unlimited. It is filed as <draft- dcsgroup-mmusic-privacy-00.txt>, and expires December 31, 1999. Please send comments to the authors. 1. Abstract The Session Initiation Protocol (SIP) is an application layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. In the current PSTN, call signaling messages travel through switches which act as trusted intermediaries. The signaling messages typically include calling party identification information which may be delivered to the called party. The calling party is able to suppress the delivery of such information to the called party in order to maintain privacy. In a Voice over IP environment using SIP user agents as the equivalent of telephones and SIP proxies as trusted intermediaries, calling parties may also desire to maintain their privacy. In this document, we describe a proposed SIP extension that may be used to request calling party privacy in the above mentioned environment. This includes a recognition that privacy in a VoIP environment extends beyond simply hiding SIP level user information to potentially hiding calling party IP address information as well. 2. Conventions used in this document 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]. 3. Introduction In the telephone network, the Calling Number Delivery and Calling Name Delivery services provide the called party with identity information about the calling party prior to the called party answering the call; the calling party is here identified as the station originating the call. In order for this service to be dependable, the called party must be able to trust that the calling identity information being presented is valid. Consider for example a tele-marketer presenting himself with the identity of one of your co-workers, or, even worse, an automated credit-card activation system using calling identity information as an authorization check. DCS Group Internet Draft - Expiration 12/31/99 2 SIP Extensions for Caller Privacy June 1999 In order for the calling identity information to be trustworthy, the information must come from a trusted source. One scenario for establishing such trust is for a SIP user agent to require that all incoming SIP invitations arrive through a set of trusted SIP proxies; for simplicity we will assume that each SIP user agent is associated with a single SIP proxy, which we will refer to as a DCS-proxy in this document. DCS-proxies are interconnected and maintain a transitive trust relationship. Thus if a SIP user agent originates a call through a DCS-proxy, it trusts that the DCS-proxy will carry out the service requested, even if other DCS-proxies are involved. DCS-proxies however do not trust SIP user agents, since these will typically reside at the customer premise. When a call is placed, the calling identity delivery services reveal privacy information to the called party, and the calling party therefore has the option to block the delivery of this information to the called party. This is typically achieved by subscribing to a Calling Identity Delivery Blocking service but can be done on an individual call basis as well. When the Calling Identity Delivery Blocking Service is invoked, information about the calling party is still passed through the trusted intermediaries, however presentation restriction indicators are set in the signaling messages to signal the far-end side, that the calling identity information is not to be provided to the called party. More generally, we may say that the service provided is that of preventing the called party from obtaining information about the calling party that may either be used to identify the party or reveal location information about the party. In an IP environment, IP addressing information may provide the called party with information to reach or identify the calling party. IP addressing information may reveal some level of location information, for instance if one has knowledge of which addresses are deployed where, or by revealing that a given caller is using a different IP-address or address block than usual. When such a privacy service is to be provided in a SIP environment, it leads to two requirements. First, calling identity information present in SIP messages must not be delivered in an intelligible form to the called party. Secondly, when using SIP in an IP environment, IP addressing information must be hidden from the called party. We assume that a SIP user agent can recognize invitations arriving through its trusted DCS-proxy. Furthermore, as in the current telephone network, the trusted DCS-proxy is expected to either receive or possess calling party information enabling it to identify the calling party. The calling party identification information can be provided to the called party's DCS-proxy as the "display-name" in the "name-addr" DCS Group Internet Draft - Expiration 12/31/99 3 SIP Extensions for Caller Privacy June 1999 part of a From header field [2]. In such a scenario, the calling party may have excluded the "display-name" field from the invitation it issued in order to not reveal its identity to the called party. The absence of this field could by itself be an indication to the DCS proxy, that privacy was requested. For DCS-proxy to DCS-proxy communication, where the information would still be passed, a presentation restriction indicator would then be needed. In order to maintain complete privacy in an IP environment, calling party IP-address information may have to be concealed from the terminating party as well. The cost and complexity of providing IP address level privacy rather than simply SIP level privacy is likely to differ enough to warrant two separate services. The calling party will thus need to signal the DCS-proxy which privacy service it is requesting. 4. SIP Extension In the following we first present a proposed SIP extension to address the privacy issues identified. We then present an example of how this may be used to provide the privacy service. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [3]. 4.1 PRIVACY We propose to extend SIP with a new header field called DCS-Privacy which allows the calling party to indicate the degree of privacy that should be provided by the DCS-proxy. The syntax of the proposed extension is as follows: Privacy = "Privacy" ":" *privacy-tag privacy-tag = "Full" | "Caller-Num" | "Caller-Name" | "IPAddr" The value "Caller-Num" requests the originating phone number not be displayed to the destination. The value "Caller-Name" requests the calling name not be displayed. The value "IPAddr" requests IP privacy such that the destination is not given the originator's IP address. The value "Full" requests both Caller-Num and Caller-Name blocking and IP address privacy. Any combination of these values may appear in this header. 4.2 Example of Use In this Section, we will illustrate how the request for privacy may work in practice. It should be noted that the privacy service described can be implemented in a number of ways; we merely describe one possible solution in this section. DCS Group Internet Draft - Expiration 12/31/99 4 SIP Extensions for Caller Privacy June 1999 The Figure below illustrates a basic privacy example scenario +---------+ +--------+ 1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE +------->| proxy-o |------------>| proxy-t|---------+ | +---------+ +--------+ | | | | trust boundary | . . |. . . . . . . . . . . . . . . . . . . . . . .. . . | . . . | | | \/ +------+ RTP/RTCP +------+ |MTA-o |<------------------------------------------->|MTA-t | +------+ +------+ Figure 1 - Basic Privacy Example The originating user agent (MTA-o) sends an INVITE (1) message requesting caller-name privacy to DCS-proxy-o. DCS-proxy-o ensures that authentic calling identity information is included in the message before it sends INVITE (2) to DCS-proxy-t. DCS-proxy-t examines the DCS-caller header field included in the INVITE and sees that caller-name privacy is requested. Consequently, DCS-proxy-t replaces the caller-name in "display-name" with the string "anonymous". While this illustrates the basic operation of the service, there are additional issues that need to be considered. In SIP, there are other fields than "display-name" that can reveal the identity of the calling party, either in part or completely. In the cases of calling name and calling number privacy, the "addr-spec", e.g. SIP-URL, part of the From header field may contain calling party information. This privacy problem can be overcome by having MTA-o encrypt the SIP-URL and supplying a user parameter indicating that the SIP-URL is encrypted. The key used is shared between MTA-o and DCS-proxy-o. Also, when the session description protocol (SDP) is used to describe the media in the session, the use of SDP fields revealing calling identity information needs to be examined as well. Similar concerns apply to the use of RTCP. The second example we look at is one where full privacy is requested, i.e. both calling name and number privacy, as well as IP address privacy. The Figure below illustrates how IP address privacy can be achieved by inserting a trusted intermediary, an anonymizer, for the media streams between MTA-o and MTA-t. DCS Group Internet Draft - Expiration 12/31/99 5 SIP Extensions for Caller Privacy June 1999 +---------+ +--------+ 1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE +------->| proxy-o |------------>| proxy-t|----------+ | +---------+ +--------+ | | \ / | | \ / | | SIP +--------+ SIP | | +----------------->| anony- |-------------------+ | | | +------>| mizer |--------+ | | | | | +--------+ | | | | | | | | | | | | | | | | | | trust boundary | | | . . |.|. . . . . | . . . . . . . . . . . . | . . .. . |..| . . . | | | | | | | | | | \/ \/ +------+ RTP/RTCP| |RTP/RTCP +------+ |MTA-o |<--------+ +-------->|MTA-t | +------+ +------+ Figure 2 - Full Privacy Example For all signaling and media exchange purposes, the anonymizer adds a level of indirection thereby hiding the IP address(es) of MTA-o from MTA-t. This indirection is used both for the media streams and SIP signaling, beyond the initial INVITE, exchanged directly between MTA-o and MTA-t. Also, the following commonly used header fields may reveal privacy information, which can be remedied as described: @ The From header field must not reveal any calling identity information in the SIP-URL, e.g. by encrypting it. The "display- name" must be anonymous. @ A Contact header field must be set to point to the anonymizer to prevent any direct signaling between MTA-o and MTA-t @ Via header fields identifying either MTA-o or DCS-proxy-o must be hidden, e.g. by encryption or simple stateful removal and re- insertion by DCS-proxy-t. @ Call-ID should not be based on MTA-o's IP-address Furthermore, when SDP is used to describe the media in the session, the session descriptions exchanged by the user agents need to be modified to direct the media streams to the anonymizer. Again, the use of SDP fields revealing calling identity information needs to be considered as well. Similar concerns apply to the use of RTCP. 5. Security Considerations A user requesting complete privacy must still authenticate himself to the DCS-Proxy, and therefore the SIP messages between MTA-o and DCS Group Internet Draft - Expiration 12/31/99 6 SIP Extensions for Caller Privacy June 1999 DCS-proxy-o must be protected. Likewise, it is necessary that the proxies take precautions to protect the user identification information from eavesdropping and interception. Use of IPSec between MTA and DCS-proxy and between proxies is recommended. 6. References 1 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 2 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol," RFC 2543, March 1999. 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 7. Acknowledgments The Distributed Call Signaling work in the PacketCable project is the work of a large number of people, representing many different companies. The authors would like to recognize and thank the following for their assistance: John Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckle, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, and Partho Mishra, AT&T. 8. Author's Addresses Bill Marshall AT&T Florham Park, NJ 07932 Email: wtm@research.att.com K. K. Ramakrishnan AT&T Florham Park, NJ 07932 Email: kkrama@research.att.com Ed Miller CableLabs Louisville, CO 80027 Email: E.Miller@Cablelabs.com Glenn Russell DCS Group Internet Draft - Expiration 12/31/99 7 SIP Extensions for Caller Privacy June 1999 CableLabs Louisville, CO 80027 Email: G.Russell@Cablelabs.com Burcak Beser 3Com Rolling Meadows, IL 60008 Email: Burcak_Beser@3com.com Mike Mannette 3Com Rolling Meadows, IL 60008 Email: Michael_Mannette@3com.com Kurt Steinbrenner 3Com Rolling Meadows, IL 60008 Email: Kurt_Steinbrenner@3com.com Dave Oran Cisco Acton, MA 01720 Email: oran@cisco.com John Pickens Com21 San Jose, CA Email: jpickens@com21.com Poornima Lalwaney General Instrument San Diego, CA 92121 Email: plalwaney@gi.com Jon Fellows General Instrument San Diego, CA 92121 Email: jfellows@gi.com Doc Evans Lucent Cable Communications Westminster, CO 30120 Email: n7dr@lucent.com Keith Kelly NetSpeak Boca Raton, FL 33587 Email: keith@netspeak.com Flemming Andreasen Telcordia Piscataway, NJ Email: fandreas@telcordia.com DCS Group Internet Draft - Expiration 12/31/99 8 SIP Extensions for Caller Privacy June 1999 DCS Group Internet Draft - Expiration 12/31/99 9 SIP Extensions for Caller Privacy June 1999 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Expiration Date This memo is filed as <draft-dcsgroup-mmmusic- privacy-00.txt>, and expires December 31, 1999. DCS Group Internet Draft - Expiration 12/31/99 10