One document matched: draft-dcsgroup-sip-privacy-00.txt
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
| PAFTECH AB 2003-2026 | 2026-04-24 02:48:01 |