SIP Working Group W. Marshall Internet Draft K. Ramakrishnan Document: <draft-dcsgroup-sip-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 October, 1999 SIP Extensions for Caller Identity and Privacy Status of this Memo This document is an Internet-Draft and is NOT offered in accordance with Section 10 of RFC2026[1], 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 4/30/00 1 SIP Extensions for Caller Privacy October 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-sip-privacy-01.txt>, and expires April 30, 2000. 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, there may still be requirements to provide calling party identification information, yet calling parties may also desire to maintain their privacy. In this document, we describe two proposed SIP extensions. The first one may be used to support calling party identification and the second one allows a party to request 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 the parties 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 [3]. 3. Introduction In the telephone network, calling identity information is needed to support the Calling Number Delivery and Calling Name Delivery services which 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- DCS Group Internet Draft - Expiration 4/30/00 2 SIP Extensions for Caller Privacy October 1999 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. In order for the calling identity information to be trustworthy, the information must come from a trusted source. Calling identity information may also be needed to support regulatory requirements for a public telephony service. An example of this is the Customer Originated Trace service, which enables a called party to have the identity of a calling party recorded by the telephony service provider. This enables, e.g., the receiver of harassing phone calls to make the identity of the originator of such calls available to the proper authority. Again, in order for this service to be useful, the Calling Identity information recorded must be trustworthy. 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. In the PSTN, 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 other 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 thus leads to two requirements. First, calling identity DCS Group Internet Draft - Expiration 4/30/00 3 SIP Extensions for Caller Privacy October 1999 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 able to hidden from the other party. 4. SIP Extensions In the following we present our proposed SIP extensions for Calling Identity Delivery and Privacy. We then present an example of how the privacy extension may be used to provide the privacy service. The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in RFC-2234 [5]. 4.1 CALLING IDENTITY DELIVERY For the Calling Identity Delivery, we assume that a SIP user agent can determine if invitations are arriving through its DCS-proxy, and thereby can be trusted, or not. Furthermore, as in the current telephone network, the trusted DCS-proxy is assumed to either receive or possess calling party information that enables it to determine the identity of the calling party. The calling party identity information could be provided to the called party's DCS-proxy as the "display-name" in the "name-addr" part of a From header field [6]. Even though the "display-name" is part of the "From" header, it is not considered part of the call leg identifier. SIP user agents and DCS-proxies would therefore be able to manipulate the value of this parameter, including adding, modifying, and deleting Calling Identity information. This was in fact suggested in a previous version of this document, but based on Working Group feedback, it was preferred to introduce a separate header field for this. The header field suggested is called DCS-Caller, which is added to an INVITE message to identify the caller. The Dcs-Caller header is inserted by the originating SIP user agent, and is verified by the DCS Proxy. The terminating DCS Proxy forwards the Dcs-Caller header to the destination SIP user agent only if it has subscribed to Caller ID/Calling Name service and the originator has not requested privacy: Dcs-Caller = "Dcs-Caller" ":" [ display-name ";" ] Caller-Number [ "/" Caller-Type] [ "<" addr-spec ">" ] Caller-Type = token Caller-Number = local-phone-number | "private" | "not-subscribed" |"not-available" DCS Group Internet Draft - Expiration 4/30/00 4 SIP Extensions for Caller Privacy October 1999 Display-name is a text string that identifies the account name of the originator. The string "private" is inserted by the destination DCS proxy when the call originator requested caller-name privacy. The string "not-subscribed" is inserted by the destination DCS proxy when the destination SIP user agent does not subscribe to the Calling Name delivery service. The string "not-available" is provided when the information is not available to the Dcs Proxy. Local-phone-number is the telephone number of the originator. The string "private" is inserted by the destination DCS proxy when the call originator requested Calling Number privacy. The string "not- subscribed" is inserted by the destination DCS proxy when the destination SIP user agent does not subscribe to the Calling Number delivery service. The string "not-available" is provided when the information is not available to the Dcs Proxy. Caller-type allows the SIP user agent to extend special privileges to certain types of callers. The string "Operator" is a reserved identifier supplied by the network to the SIP user agent to indicate that a telephony service provider operator is placing the call. The SIP user agent may for instance decide to honor a request for Busy- Line Verification or Emergency Interrupt by an operator; a request it might otherwise normally refuse. Addr-spec is the IP address or Fully Qualified Domain Name (FQDN) of the originator. 4.2 PRIVACY In support of privacy, the originator of a call must have a way of suppressing the delivery of calling identity information to the called party. One way of achieving that could simply be to omit the information from the DCS-Caller field. However, for DCS-proxy to DCS-proxy communication, where the information would still be need to be passed, a presentation restriction indicator would then be needed. Also, 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. We therefore propose to extend SIP with a new header field called Dcs-Anonymity which allows an originating SIP user agent to indicate the degree of privacy that should be provided by the DCS proxy. The value "Caller-Num" requests the originating phone number not be provided to the destination. The value "Caller-Name" requests the calling name not be provided. The value "IPAddr" requests IP privacy such that the destination is not given the originator's IP DCS Group Internet Draft - Expiration 4/30/00 5 SIP Extensions for Caller Privacy October 1999 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. The value "Off" indicates no privacy is requested, and MUST be the only value if present. The extension also allows a receiving SIP user agent to indicate its desire for IP address privacy in its response to the first INVITE request. The value "Full" or "IPAddr" requests IP address privacy. The value "Off indicates no privacy is requested, and MUST be the only value if present. Dcs-Anonymity = "Dcs-Anonymity" ":" *privacy-tag privacy-tag = "Full" | "Caller-Num" | "Caller-Name" | "IPAddr" | "Off" If the caller has not requested privacy, it MUST be "Off". If the caller has requested privacy, it MUST be one or more of "Full", "Caller-Num", "Caller-Name", or "IPAddr". If the callee has requested privacy, it MUST be "Full" or "IPAddr". 4.3 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. 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 DCS Group Internet Draft - Expiration 4/30/00 6 SIP Extensions for Caller Privacy October 1999 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-Anonymity header field included in the INVITE and sees that caller-name privacy is requested. Consequently, DCS-proxy- t replaces the caller-name in "DCS-caller" with the string "private". While this illustrates the basic operation of the service, there are additional issues that need to be considered. In SIP, there are additional fields 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, as well as "display-name" 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. +---------+ +--------+ 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 DCS Group Internet Draft - Expiration 4/30/00 7 SIP Extensions for Caller Privacy October 1999 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-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., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 4 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol," RFC 2543, March 1999. DCS Group Internet Draft - Expiration 4/30/00 8 SIP Extensions for Caller Privacy October 1999 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, Internet Mail Consortium and Demon Internet Ltd., November 1997 6 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol," RFC 2543, March 1999. 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 Guckel, Michael Ramalho, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung-Hai Hsiao, 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 CableLabs Louisville, CO 80027 Email: G.Russell@Cablelabs.com Burcak Beser 3Com Rolling Meadows, IL 60008 Email: Burcak_Beser@3com.com Mike Mannette 3Com DCS Group Internet Draft - Expiration 4/30/00 9 SIP Extensions for Caller Privacy October 1999 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 4/30/00 10 SIP Extensions for Caller Privacy October 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-sip-privacy- 01.txt>, and expires April 30, 2000. DCS Group Internet Draft - Expiration 4/30/00 11