[Search] [txt|pdf|bibtex] [Tracker] [Email] [Nits]

Versions: 00 01 02                                                      
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