idnits 2.17.1 draft-dcsgroup-sip-privacy-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Found some kind of copyright notice around line 529 but it does not match any copyright boilerplate known by this tool. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 5) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Missing reference section? '1' on line 42 looks like a reference -- Missing reference section? '3' on line 93 looks like a reference -- Missing reference section? '5' on line 177 looks like a reference -- Missing reference section? '6' on line 190 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIP Working Group W. Marshall 2 Internet Draft K. Ramakrishnan 3 Document: AT&T 4 Category: Informational 5 E. Miller 6 G. Russell 7 CableLabs 9 B. Beser 10 M. Mannette 11 K. Steinbrenner 12 3Com 14 D. Oran 15 Cisco 17 J. Pickens 18 Com21 20 P. Lalwaney 21 J. Fellows 22 General Instrument 24 D. Evans 25 Lucent Cable 27 K. Kelly 28 NetSpeak 30 F. Andreasen 31 Telcordia 33 October, 1999 35 SIP Extensions for Caller Identity and Privacy 37 Status of this Memo 39 This document is an Internet-Draft and is NOT offered in accordance 40 with Section 10 of RFC2026[1], and the author does not provide the 41 IETF with any rights other than to publish as an Internet-Draft. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as Internet- 46 Drafts. Internet-Drafts are draft documents valid for a maximum of 47 six months and may be updated, replaced, or obsoleted by other 48 documents at any time. It is inappropriate to use Internet- Drafts 49 as reference material or to cite them other than as "work in 50 progress." 52 DCS Group Internet Draft - Expiration 4/30/00 1 53 SIP Extensions for Caller Privacy October 1999 55 The list of current Internet-Drafts can be accessed at 56 http://www.ietf.org/ietf/1id-abstracts.txt 58 The list of Internet-Draft Shadow Directories can be accessed at 59 http://www.ietf.org/shadow.html. 61 The distribution of this memo is unlimited. It is filed as , and expires April 30, 2000. Please 63 send comments to the authors. 65 1. Abstract 67 The Session Initiation Protocol (SIP) is an application layer 68 control (signaling) protocol for creating, modifying and terminating 69 sessions with one or more participants. In the current PSTN, call 70 signaling messages travel through switches which act as trusted 71 intermediaries. The signaling messages typically include calling 72 party identification information which may be delivered to the 73 called party. The calling party is able to suppress the delivery of 74 such information to the called party in order to maintain privacy. 76 In a Voice over IP environment using SIP user agents as the 77 equivalent of telephones and SIP proxies as trusted intermediaries, 78 there may still be requirements to provide calling party 79 identification information, yet calling parties may also desire to 80 maintain their privacy. In this document, we describe two proposed 81 SIP extensions. The first one may be used to support calling party 82 identification and the second one allows a party to request privacy 83 in the above mentioned environment. This includes a recognition that 84 privacy in a VoIP environment extends beyond simply hiding SIP level 85 user information, to potentially hiding the parties IP address 86 information as well. 88 2. Conventions used in this document 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 92 this document are to be interpreted as described in RFC-2119 [3]. 94 3. Introduction 96 In the telephone network, calling identity information is needed to 97 support the Calling Number Delivery and Calling Name Delivery 98 services which provide the called party with identity information 99 about the calling party prior to the called party answering the 100 call; the calling party is here identified as the station 101 originating the call. In order for this service to be dependable, 102 the called party must be able to trust that the calling identity 103 information being presented is valid. Consider for example a tele- 105 DCS Group Internet Draft - Expiration 4/30/00 2 106 SIP Extensions for Caller Privacy October 1999 108 marketer presenting himself with the identity of one of your co- 109 workers, or, even worse, an automated credit-card activation system 110 using calling identity information as an authorization check. In 111 order for the calling identity information to be trustworthy, the 112 information must come from a trusted source. 114 Calling identity information may also be needed to support 115 regulatory requirements for a public telephony service. An example 116 of this is the Customer Originated Trace service, which enables a 117 called party to have the identity of a calling party recorded by the 118 telephony service provider. This enables, e.g., the receiver of 119 harassing phone calls to make the identity of the originator of such 120 calls available to the proper authority. Again, in order for this 121 service to be useful, the Calling Identity information recorded must 122 be trustworthy. 124 One scenario for establishing such trust is for a SIP user agent to 125 require that all incoming SIP invitations arrive through a set of 126 trusted SIP proxies. For simplicity we will assume that each SIP 127 user agent is associated with a single SIP proxy, which we will 128 refer to as a DCS-proxy in this document. DCS-proxies are 129 interconnected and maintain a transitive trust relationship. Thus if 130 a SIP user agent originates a call through a DCS-proxy, it trusts 131 that the DCS-proxy will carry out the service requested, even if 132 other DCS-proxies are involved. DCS-proxies however do not trust SIP 133 user agents, since these will typically reside at the customer 134 premise. 136 When a call is placed, the calling identity delivery services reveal 137 privacy information to the called party, and the calling party 138 therefore has the option to block the delivery of this information 139 to the called party. In the PSTN, this is typically achieved by 140 subscribing to a Calling Identity Delivery Blocking service but can 141 be done on an individual call basis as well. When the Calling 142 Identity Delivery Blocking Service is invoked, information about the 143 calling party is still passed through the trusted intermediaries, 144 however presentation restriction indicators are set in the signaling 145 messages to signal the far-end side, that the calling identity 146 information is not to be provided to the called party. 148 More generally, we may say that the service provided is that of 149 preventing the called party from obtaining information about the 150 calling party that may either be used to identify the party or 151 reveal location information about the party. In an IP environment, 152 IP addressing information may provide the other party with 153 information to reach or identify the calling party. IP addressing 154 information may reveal some level of location information, for 155 instance if one has knowledge of which addresses are deployed where, 156 or by revealing that a given caller is using a different IP-address 157 or address block than usual. 159 When such a privacy service is to be provided in a SIP environment, 160 it thus leads to two requirements. First, calling identity 162 DCS Group Internet Draft - Expiration 4/30/00 3 163 SIP Extensions for Caller Privacy October 1999 165 information present in SIP messages must not be delivered in an 166 intelligible form to the called party. Secondly, when using SIP in 167 an IP environment, IP addressing information must be able to hidden 168 from the other party. 170 4. SIP Extensions 172 In the following we present our proposed SIP extensions for Calling 173 Identity Delivery and Privacy. We then present an example of how the 174 privacy extension may be used to provide the privacy service. 176 The following syntax specification uses the augmented Backus-Naur 177 Form (BNF) as described in RFC-2234 [5]. 179 4.1 CALLING IDENTITY DELIVERY 181 For the Calling Identity Delivery, we assume that a SIP user agent 182 can determine if invitations are arriving through its DCS-proxy, and 183 thereby can be trusted, or not. Furthermore, as in the current 184 telephone network, the trusted DCS-proxy is assumed to either 185 receive or possess calling party information that enables it to 186 determine the identity of the calling party. 188 The calling party identity information could be provided to the 189 called party's DCS-proxy as the "display-name" in the "name-addr" 190 part of a From header field [6]. Even though the "display-name" is 191 part of the "From" header, it is not considered part of the call leg 192 identifier. SIP user agents and DCS-proxies would therefore be able 193 to manipulate the value of this parameter, including adding, 194 modifying, and deleting Calling Identity information. This was in 195 fact suggested in a previous version of this document, but based on 196 Working Group feedback, it was preferred to introduce a separate 197 header field for this. 199 The header field suggested is called DCS-Caller, which is added to 200 an INVITE message to identify the caller. The Dcs-Caller header is 201 inserted by the originating SIP user agent, and is verified by the 202 DCS Proxy. The terminating DCS Proxy forwards the Dcs-Caller header 203 to the destination SIP user agent only if it has subscribed to 204 Caller ID/Calling Name service and the originator has not requested 205 privacy: 207 Dcs-Caller = "Dcs-Caller" ":" [ display-name ";" ] 208 Caller-Number [ "/" Caller-Type] 209 [ "<" addr-spec ">" ] 210 Caller-Type = token 211 Caller-Number = local-phone-number | "private" | 212 "not-subscribed" |"not-available" 214 DCS Group Internet Draft - Expiration 4/30/00 4 215 SIP Extensions for Caller Privacy October 1999 217 Display-name is a text string that identifies the account name of 218 the originator. The string "private" is inserted by the destination 219 DCS proxy when the call originator requested caller-name privacy. 220 The string "not-subscribed" is inserted by the destination DCS proxy 221 when the destination SIP user agent does not subscribe to the 222 Calling Name delivery service. The string "not-available" is 223 provided when the information is not available to the Dcs Proxy. 225 Local-phone-number is the telephone number of the originator. The 226 string "private" is inserted by the destination DCS proxy when the 227 call originator requested Calling Number privacy. The string "not- 228 subscribed" is inserted by the destination DCS proxy when the 229 destination SIP user agent does not subscribe to the Calling Number 230 delivery service. The string "not-available" is provided when the 231 information is not available to the Dcs Proxy. 233 Caller-type allows the SIP user agent to extend special privileges 234 to certain types of callers. The string "Operator" is a reserved 235 identifier supplied by the network to the SIP user agent to indicate 236 that a telephony service provider operator is placing the call. The 237 SIP user agent may for instance decide to honor a request for Busy- 238 Line Verification or Emergency Interrupt by an operator; a request 239 it might otherwise normally refuse. 241 Addr-spec is the IP address or Fully Qualified Domain Name (FQDN) of 242 the originator. 244 4.2 PRIVACY 246 In support of privacy, the originator of a call must have a way of 247 suppressing the delivery of calling identity information to the 248 called party. One way of achieving that could simply be to omit the 249 information from the DCS-Caller field. However, for DCS-proxy to 250 DCS-proxy communication, where the information would still be need 251 to be passed, a presentation restriction indicator would then be 252 needed. 254 Also, in order to maintain complete privacy in an IP environment, 255 calling party IP-address information may have to be concealed from 256 the terminating party as well. The cost and complexity of providing 257 IP address level privacy rather than simply SIP level privacy is 258 likely to differ enough to warrant two separate services. The 259 calling party will thus need to signal the DCS-proxy which privacy 260 service it is requesting. 262 We therefore propose to extend SIP with a new header field called 263 Dcs-Anonymity which allows an originating SIP user agent to indicate 264 the degree of privacy that should be provided by the DCS proxy. The 265 value "Caller-Num" requests the originating phone number not be 266 provided to the destination. The value "Caller-Name" requests the 267 calling name not be provided. The value "IPAddr" requests IP 268 privacy such that the destination is not given the originator's IP 270 DCS Group Internet Draft - Expiration 4/30/00 5 271 SIP Extensions for Caller Privacy October 1999 273 address. The value "Full" requests both Caller-Num and Caller-Name 274 blocking and IP address privacy. Any combination of these values 275 may appear in this header. The value "Off" indicates no privacy is 276 requested, and MUST be the only value if present. 278 The extension also allows a receiving SIP user agent to indicate its 279 desire for IP address privacy in its response to the first INVITE 280 request. The value "Full" or "IPAddr" requests IP address privacy. 281 The value "Off indicates no privacy is requested, and MUST be the 282 only value if present. 284 Dcs-Anonymity = "Dcs-Anonymity" ":" *privacy-tag 285 privacy-tag = "Full" | "Caller-Num" | "Caller-Name" | 286 "IPAddr" | "Off" 288 If the caller has not requested privacy, it MUST be "Off". 290 If the caller has requested privacy, it MUST be one or more of 291 "Full", "Caller-Num", "Caller-Name", or "IPAddr". 293 If the callee has requested privacy, it MUST be "Full" or "IPAddr". 295 4.3 Example of Use 297 In this Section, we will illustrate how the request for privacy may 298 work in practice. It should be noted that the privacy service 299 described can be implemented in a number of ways; we merely describe 300 one possible solution in this section. 302 The Figure below illustrates a basic privacy example scenario 304 +---------+ +--------+ 305 1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE 306 +------->| proxy-o |------------>| proxy-t|---------+ 307 | +---------+ +--------+ | 308 | | 309 | trust boundary | 310 . . |. . . . . . . . . . . . . . . . . . . . . . .. . . | . . . 311 | | 312 | \/ 313 +------+ RTP/RTCP +------+ 314 |MTA-o |<------------------------------------------->|MTA-t | 315 +------+ +------+ 317 Figure 1 - Basic Privacy Example 319 The originating user agent (MTA-o) sends an INVITE (1) message 320 requesting caller-name privacy to DCS-proxy-o. DCS-proxy-o ensures 322 DCS Group Internet Draft - Expiration 4/30/00 6 323 SIP Extensions for Caller Privacy October 1999 325 that authentic calling identity information is included in the 326 message before it sends INVITE (2) to DCS-proxy-t. DCS-proxy-t 327 examines the DCS-Anonymity header field included in the INVITE and 328 sees that caller-name privacy is requested. Consequently, DCS-proxy- 329 t replaces the caller-name in "DCS-caller" with the string 330 "private". 332 While this illustrates the basic operation of the service, there are 333 additional issues that need to be considered. In SIP, there are 334 additional fields that can reveal the identity of the calling party, 335 either in part or completely. In the cases of calling name and 336 calling number privacy, the "addr-spec", e.g. SIP-URL, as well as 337 "display-name" part of the From header field may contain calling 338 party information. This privacy problem can be overcome by having 339 MTA-o encrypt the SIP-URL and supplying a user parameter indicating 340 that the SIP-URL is encrypted. The key used is shared between MTA-o 341 and DCS-proxy-o. Also, when the session description protocol (SDP) 342 is used to describe the media in the session, the use of SDP fields 343 revealing calling identity information needs to be examined as well. 344 Similar concerns apply to the use of RTCP. 346 The second example we look at is one where full privacy is 347 requested, i.e. both calling name and number privacy, as well as IP 348 address privacy. The Figure below illustrates how IP address privacy 349 can be achieved by inserting a trusted intermediary, an anonymizer, 350 for the media streams between MTA-o and MTA-t. 352 +---------+ +--------+ 353 1: INVITE | DCS | 2: INVITE | DCS | 3: INVITE 354 +------->| proxy-o |------------>| proxy-t|----------+ 355 | +---------+ +--------+ | 356 | \ / | 357 | \ / | 358 | SIP +--------+ SIP | 359 | +----------------->| anony- |-------------------+ | 360 | | +------>| mizer |--------+ | | 361 | | | +--------+ | | | 362 | | | | | | 363 | | | | | | 364 | | | trust boundary | | | 365 . . |.|. . . . . | . . . . . . . . . . . . | . . .. . |..| . . . 366 | | | | | | 367 | | | | \/ \/ 368 +------+ RTP/RTCP| |RTP/RTCP +------+ 369 |MTA-o |<--------+ +-------->|MTA-t | 370 +------+ +------+ 372 Figure 2 - Full Privacy Example 374 DCS Group Internet Draft - Expiration 4/30/00 7 375 SIP Extensions for Caller Privacy October 1999 377 For all signaling and media exchange purposes, the anonymizer adds a 378 level of indirection thereby hiding the IP address(es) of MTA-o from 379 MTA-t. This indirection is used both for the media streams and SIP 380 signaling, beyond the initial INVITE, exchanged directly between 381 MTA-o and MTA-t. 383 Also, the following commonly used header fields may reveal privacy 384 information, which can be remedied as described: 386 @ The From header field must not reveal any calling identity 387 information in the SIP-URL, e.g. by encrypting it. The "display- 388 name" must be anonymous. 389 @ A Contact header field must be set to point to the anonymizer to 390 prevent any direct signaling between MTA-o and MTA-t 391 @ Via header fields identifying either MTA-o or DCS-proxy-o must be 392 hidden, e.g. by encryption or simple stateful removal and re- 393 insertion by DCS-proxy-t. 394 @ Call-ID should not be based on MTA-o's IP-address 396 Furthermore, when SDP is used to describe the media in the session, 397 the session descriptions exchanged by the user agents need to be 398 modified to direct the media streams to the anonymizer. Again, the 399 use of SDP fields revealing calling identity information needs to be 400 considered as well. Similar concerns apply to the use of RTCP. 402 5. Security Considerations 404 A user requesting complete privacy must still authenticate himself 405 to the DCS-Proxy, and therefore the SIP messages between MTA-o and 406 DCS-proxy-o must be protected. Likewise, it is necessary that the 407 proxies take precautions to protect the user identification 408 information from eavesdropping and interception. Use of IPSec 409 between MTA and DCS-proxy and between proxies is recommended. 411 6. References 413 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 414 9, RFC 2026, October 1996. 416 2. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 417 9, RFC 2026, October 1996. 419 3 Bradner, S., "Key words for use in RFCs to Indicate Requirement 420 Levels", BCP 14, RFC 2119, March 1997 422 4 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 423 "SIP: Session Initiation Protocol," RFC 2543, March 1999. 425 DCS Group Internet Draft - Expiration 4/30/00 8 426 SIP Extensions for Caller Privacy October 1999 428 5 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 429 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 430 Demon Internet Ltd., November 1997 432 6 Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, 433 "SIP: Session Initiation Protocol," RFC 2543, March 1999. 435 7. Acknowledgments 437 The Distributed Call Signaling work in the PacketCable project is 438 the work of a large number of people, representing many different 439 companies. The authors would like to recognize and thank the 440 following for their assistance: John Wheeler, Motorola; David 441 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 442 Jay Strater, Jeff Ollis, Clive Holborow, General Instruments; Doug 443 Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay 444 Networks; Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael 445 Ramalho, Cisco; and Chuck Kalmanek, Doug Nortz, John Lawser, James 446 Cheng, Tung-Hai Hsiao, and Partho Mishra, AT&T. 448 8. Author's Addresses 450 Bill Marshall 451 AT&T 452 Florham Park, NJ 07932 453 Email: wtm@research.att.com 455 K. K. Ramakrishnan 456 AT&T 457 Florham Park, NJ 07932 458 Email: kkrama@research.att.com 460 Ed Miller 461 CableLabs 462 Louisville, CO 80027 463 Email: E.Miller@Cablelabs.com 465 Glenn Russell 466 CableLabs 467 Louisville, CO 80027 468 Email: G.Russell@Cablelabs.com 470 Burcak Beser 471 3Com 472 Rolling Meadows, IL 60008 473 Email: Burcak_Beser@3com.com 475 Mike Mannette 476 3Com 478 DCS Group Internet Draft - Expiration 4/30/00 9 479 SIP Extensions for Caller Privacy October 1999 481 Rolling Meadows, IL 60008 482 Email: Michael_Mannette@3com.com 484 Kurt Steinbrenner 485 3Com 486 Rolling Meadows, IL 60008 487 Email: Kurt_Steinbrenner@3com.com 489 Dave Oran 490 Cisco 491 Acton, MA 01720 492 Email: oran@cisco.com 494 John Pickens 495 Com21 496 San Jose, CA 497 Email: jpickens@com21.com 499 Poornima Lalwaney 500 General Instrument 501 San Diego, CA 92121 502 Email: plalwaney@gi.com 504 Jon Fellows 505 General Instrument 506 San Diego, CA 92121 507 Email: jfellows@gi.com 509 Doc Evans 510 Lucent Cable Communications 511 Westminster, CO 30120 512 Email: n7dr@lucent.com 514 Keith Kelly 515 NetSpeak 516 Boca Raton, FL 33587 517 Email: keith@netspeak.com 519 Flemming Andreasen 520 Telcordia 521 Piscataway, NJ 522 Email: fandreas@telcordia.com 524 DCS Group Internet Draft - Expiration 4/30/00 10 525 SIP Extensions for Caller Privacy October 1999 527 Full Copyright Statement 529 "Copyright (C) The Internet Society (date). All Rights Reserved. 530 This document and translations of it may be copied and furnished to 531 others, and derivative works that comment on or otherwise explain it 532 or assist in its implmentation may be prepared, copied, published 533 and distributed, in whole or in part, without restriction of any 534 kind, provided that the above copyright notice and this paragraph 535 are included on all such copies and derivative works. However, this 536 document itself may not be modified in any way, such as by removing 537 the copyright notice or references to the Internet Society or other 538 Internet organizations, except as needed for the purpose of 539 developing Internet standards in which case the procedures for 540 copyrights defined in the Internet Standards process must be 541 followed, or as required to translate it into languages other than 542 English. The limited permissions granted above are perpetual and 543 will not be revoked by the Internet Society or its successors or 544 assigns. This document and the information contained herein is 545 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 546 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 547 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 548 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 549 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 551 Expiration Date This memo is filed as , and expires April 30, 2000. 554 DCS Group Internet Draft - Expiration 4/30/00 11