idnits 2.17.1 draft-dcsgroup-sip-privacy-02.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 9) 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. ** The abstract seems to contain references ([4]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 175 has weird spacing: '... where enc. ...' -- 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? '1' on line 42 looks like a reference -- Missing reference section? '4' on line 252 looks like a reference -- Missing reference section? '2' on line 78 looks like a reference -- Missing reference section? '5' on line 101 looks like a reference -- Missing reference section? '3' on line 189 looks like a reference Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group W. Marshall 3 Internet Draft K. Ramakrishnan 4 Document: AT&T 6 E. Miller 7 G. Russell 8 CableLabs 10 B. Beser 11 M. Mannette 12 K. Steinbrenner 13 3Com 15 D. Oran 16 F. Andreasen 17 Cisco 19 J. Pickens 20 Com21 22 P. Lalwaney 23 Nokia 25 J. Fellows 26 Motorola 28 D. Evans 29 Secure Cable Solutions 31 K. Kelly 32 NetSpeak 34 June, 2000 36 SIP Extensions for Caller Identity and Privacy 38 Status of this Memo 40 This document is an Internet-Draft and is in full conformance with 41 all provisions of Section 10 of RFC2026 [1]. 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 The list of current Internet-Drafts can be accessed at 53 http://www.ietf.org/ietf/1id-abstracts.txt 55 DCS Group Internet Draft - Expiration 12/31/00 1 56 The list of Internet-Draft Shadow Directories can be accessed at 57 http://www.ietf.org/shadow.html. 59 The distribution of this memo is unlimited. It is filed as , and expires December 31, 2000. Please 61 send comments to the authors. 63 1. Abstract 65 This document describes two extensions to the Session Initiation 66 Protocol (SIP) [4]. The extensions allow callers and callees to 67 maintain their privacy in an environment where one or more proxies 68 serve as intermediaries which can provide the identity of the 69 parties either directly or indirectly. The extensions allow the 70 parties to be identified either by name or by type the latter of 71 which can be used to identify some group of callers and callees. 73 2. Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 77 this document are to be interpreted as described in RFC-2119 [2]. 79 3. Introduction 81 In order for SIP to be a viable alternative to the current PSTN, SIP 82 must support certain popular telephony services as well as some 83 regulatory and public safety requirements. These include Calling 84 Identity Delivery services, Calling Identity Delivery Blocking, as 85 well as the ability to trace the originator of a call. While SIP can 86 support each of these services independently, certain combinations 87 cannot be supported. For example, a caller that wants to maintain 88 privacy and consequently provides unintelligible information in the 89 From header field will not be identifiable, e.g. for a return call 90 or call trace, by entities more than a single hop away, since the 91 contents of the From header cannot be modified. We note that this 92 problem is not telephony specific but applies to other forms of 93 session initiation as well. Furthermore, the issue of privacy in an 94 IP environment is more complicated than in the PSTN, as the caller 95 and callee will normally exchange IP traffic directly and IP address 96 information itself may reveal some privacy. The issue of IP address 97 privacy for both the caller and callee consequently needs to be 98 addressed as well. 100 In order to solve the above we assume an architecture as described 101 in [5] , where a SIP User Agent is associated with a trusted proxy, 102 and proxies in turn communicate with other proxies and user agents 103 which may or may not be trusted. Calls utilizing the services of 105 DCS Group Internet Draft - Expiration 12/31/00 2 106 this architecture must both be placed and received through the 107 trusted proxy. 109 This document defines two extensions to SIP that allow the calling 110 and called party to be identified by a trusted intermediary while 111 still being able to maintain their privacy. A new general header, 112 Remote-Party-ID, identifies each party, and another new general 113 header, Anonymity, defines the level of privacy requested by the 114 party. The trusted intermediary verifies the Remote-Party-ID 115 information supplied and ensures the privacy requested is provided 116 when forwarding a message across an untrusted boundary. 118 4. Protocol Overview 120 UACs that wish to use the extensions defined here MUST include a 121 Proxy-Require header in the initial INVITE request containing the 122 option tag "privacy". When such a UAC makes a call, it SHOULD 123 include a Remote-Party-ID header in the initial INVITE request in 124 order to identify the originator of the call. The Remote-Party-ID 125 MUST contain a SIP-URL identifying the UAC and MAY contain a 126 "display-name" for the UAC as well. Additionally, if privacy is 127 desired, the UAC MUST include an Anonymity header, which can request 128 one or more of URI, Name, and IP address privacy. 130 When a proxy supporting this extension receives an INVITE from an 131 untrusted entity, it looks for the presence of a Remote-Party-ID 132 header. If one is found, the proxy determines if the previous hop 133 was a UA the proxy serves. If so, the Remote-Party-ID information is 134 verified and modified if needed. If the request instead came from 135 another untrusted entity, the proxy either removes the Remote-Party- 136 ID information or marks it as being untrusted. Alternatively, the 137 proxy MAY reject the request, e.g. with a 403 or 407. 139 Prior to forwarding the request to an untrusted entity, the proxy 140 MUST look for the presence of an Anonymity header requesting 141 privacy. If one is found, the privacy requested MUST be provided 142 prior to forwarding the request. For URI and Name privacy, this 143 involves encrypting and possibly removing information provided in 144 the Remote-Party-ID. For IP Address privacy, it involves providing a 145 level of indirection for signaling and media through an entity we 146 refer to as an Anonymizer. The Anonymity header is removed as well. 148 Once a UAS supporting this extension receives the INVITE, it can use 149 the Remote-Party-ID information provided to identify the originator 150 of the call, unless the originator had requested privacy. If the 151 INVITE contained a Proxy-Require with an option tag of "privacy", 152 the UAS SHOULD include a Remote-Party-ID identifying it in the first 153 non-100 response. Irrespective, the UAS MUST include an Anonymity 154 header if it desires any privacy. 156 When a proxy supporting this extension receives a non-100 response 157 to the initial INVITE, it looks for a Remote-Party-ID header field 159 DCS Group Internet Draft - Expiration 12/31/00 3 160 and applies similar processing as for the initial INVITE with one 161 difference. If the INVITE did not contain a Proxy-Require with an 162 option tag of "privacy", the proxy MUST ensure that any privacy 163 requested in the response is provided prior to forwarding it, 164 irrespective of whether the previous hop is trusted or not. 166 Finally, when the UAC receives the first non-100 response from the 167 UAS, it can use Remote-Party-ID information provided to identify the 168 terminating party, unless the terminator had requested privacy. 170 5. Header Field Definitions 172 Table 1 below is an extension of tables 4 and 5 in [4] for the new 173 headers defined here: 175 where enc. e-e ACK BYE CAN INV OPT REG 176 Anonymity g n h - - - o - - 177 Remote-Party-ID g n h - - - o - - 179 Table 1: Summary of header fields. 181 The headers can be used in an INVITE as well as any response to an 182 INVITE. 184 5.1 Remote-Party-ID Header Field Definitions 186 The Remote-Party-ID header field provides the identity of the remote 187 party. At the called party it contains the identity of the caller, 188 and at the calling party, it contains the translated identity of the 189 called party. Remote-Party-ID is defined by the following ABNF [3]: 191 Remote-Party-ID = "Remote-Party-ID" ":" [display-name] 192 "<" addr-spec ">" *(";" rpi-token) 194 rpi-token = rpi-screen | rpi-type | other-rpi-token 196 rpi-screen = "rpi-screen" "=" ("no" | "yes" ) 198 rpi-type = "rpi-type" "=" 1#token 200 other-rpi-token = token ["=" (token | quoted-string)] 202 Furthermore, we define the value "private" for "other-user" in an 203 "addr-spec", to indicate that the user part of an "addr-spec" is in 204 a non-intelligible form. The syntax for "other-user" is therefore 205 refined to: 207 other-user = token | "private" 209 DCS Group Internet Draft - Expiration 12/31/00 4 210 Comparisons follow the case-sensitivity rules defined by SIP [4]. 212 The "display-name" in Remote-Party-ID is a text string that 213 identifies the name of the party. The "addr-spec" contains 214 information identifying the party either in clear-text or encrypted 215 form. In the latter case, the "user" part of the "addr-spec" 216 contains the encrypted party information, whereas the "hostport" 217 identifies the entity that can decrypt the information. Furthermore, 218 an "other-user" value of "private" will then be present to indicate 219 that the "addr-spec" is encrypted. 221 The "rpi-screen" describes what verification the Remote-Party-ID 222 information has undergone. The value "yes" (assumed by default) 223 indicates the Remote-Party-ID was verified successfully by the proxy 224 itself or the proxy received the INVITE from a trusted proxy with 225 this indication. The value "no" indicates the Remote-Party-ID was 226 either not verified successfully by the proxy or the proxy received 227 the message from an untrusted entity. 229 The "rpi-type" allows a group of users to be identified by some 230 common denominator. The denominator(s) used as well as the semantics 231 associated with these are a local issue and hence outside the scope 232 of this document. One example use might be to define an "rpi-type" 233 of "operator". An "operator" caller type might request special 234 privileges, e.g. performing an emergency interrupt on a voice call, 235 that the UA might not normally allow. Again, we purposely do not 236 define any particular rpi-types or semantics here. 238 Finally, the "other-rpi-token" parameter allows Remote-Party-ID to 239 be extended. 241 5.2 Anonymity Header Field Definition 243 The Anonymity header field allows an originating SIP user agent to 244 indicate the degree of privacy that should be provided to its 245 session. 247 The ABNF for the proposed header field follows: 249 Anonymity = "Anonymity" ":" 1#privacy-tag 250 privacy-tag = "full" | "uri" | "name" | "ipaddr" | "off" 252 Comparisons follow the case-sensitivity rules defined by SIP [4]. 254 If privacy is requested, it MUST be one or more of "full", "uri", 255 "name", or "ipaddr". The value "off" indicates that no privacy is 256 requested, and MUST be the only value if present. 258 The value "uri" requests the party's identity not be provided to the 259 destination. The value "name" requests the party's name not be 260 provided. The value "ipaddr" requests IP privacy such that the 262 DCS Group Internet Draft - Expiration 12/31/00 5 263 other party does not learn the IP address of this party. The value 264 "full" requests both URI, Name, and IP address privacy. 266 It should be noted, that the header field allows both the 267 originating and terminating user agent to indicate its desire for 268 privacy. 270 6. Protocol Semantics 272 Below, we provide the protocol semantics for a UAC, a UAS, and a 273 proxy. 275 6.1 UAC Behavior 277 When a UAC supporting this extension initiates a call through its 278 trusted proxy, it SHOULD include a Remote-Party-ID header in the 279 initial INVITE request in order to identify the originator of the 280 call. The Remote-Party-ID header MUST at a minimum contain an "addr- 281 spec" to uniquely identify the calling party. The "addr-spec" SHOULD 282 be the same string as appears in the Request-URI for incoming call 283 attempts. The Remote-Party-ID may optionally include a "display- 284 name" and an "rpi-type". The "display-name" SHOULD be a name that 285 the proxy has associated with the calling party, e.g. the 286 subscribers full name. The "rpi-type" can be used as a convenience 287 to identify some group of users. 289 If the UAC desires privacy for the call, it MUST include an 290 Anonymity header specifying the desired level of privacy, e.g. "uri" 291 to maintain privacy of the "addr-spec". As honoring the privacy 292 requested depends on the proxy, the UAC MUST furthermore include a 293 Proxy-Require header with an option-tag of "privacy". 295 If the UAC desires "name" or "full" privacy, the UAC MUST NOT reveal 296 the originating subscriber's name in the "display-name" portion of 297 the From header. This can be achieved by, e.g., not providing a 298 "display-name" or setting the "display-name" to "anonymous". 300 If the UAC desires "uri" or "full" privacy, the UAC MUST NOT reveal 301 the originating subscriber's identity in the SIP-URL in the From 302 header field. The UAC SHOULD instead supply a cryptographically 303 random identifier for the userinfo, and a non-identifying hostname, 304 e.g. "localhost", for the hostport. 306 If the UAC desires "ipaddr" or "full" privacy, the UAC MUST NOT base 307 the Call-ID on the originator's IP address. 309 The first non-100 response received by the UAC MAY also contain a 310 Remote-Party-ID identifying the called party. If the Remote-Party-ID 311 contains an "rpi-screen" parameter with a value of "no", the UAC 312 SHOULD NOT trust the validity of the information provided. 313 Otherwise, the UAC SHOULD use the information provided to identify 314 the called-party rather than any information originally put in the 316 DCS Group Internet Draft - Expiration 12/31/00 6 317 To header field. The "addr-spec" contained in this Remote-Party-ID 318 can be used as the Request-URI by the UAC to initiate certain call 319 control functions or subsequent calls that are required to reference 320 the party reached. Examples of these include call transfer and 321 repeat call. 323 6.2 UAS Behavior 325 A UAS supporting this extension and receiving an INVITE from its 326 trusted proxy looks for a Remote-Party-ID header field to identify 327 the originator of the request. If the Remote-Party-ID contains an 328 "rpi-screen" parameter with a value of "no", the UAS SHOULD NOT 329 trust the validity of the information provided. Otherwise, the UAS 330 SHOULD use the information provided to identify the caller rather 331 than any information provided in the From header field. 333 The "addr-spec" contained in the Remote-Party-ID received can be 334 used as the Request-URI by the UAS to initiate certain call control 335 functions or subsequent calls that are required to reference the 336 party reached. Examples of these include call transfer and return 337 call. 339 If the initial INVITE contained a Proxy-Require header field with an 340 option tag of "privacy", the UAS SHOULD insert a Remote-Party-ID 341 header field identifying itself into the first non-100 response it 342 sends. The rules for the Remote-Party-ID are similar to those for 343 the initial INVITE for a UAC. 345 Regardless of whether the UAS provides a Remote-Party-ID in the 346 first non-100 response, the UAS MAY insert an Anonymity header in 347 that response to request any desired called party privacy. It should 348 be noted though, that the UAS can not depend on this privacy being 349 honored, if the original INVITE did not contain a Proxy-Require with 350 an option tag of "privacy". 352 6.3 Proxy Behavior 354 When a proxy supporting this extension receives an INVITE from an 355 untrusted entity, the proxy first determines if the request came 356 from a UAC that it serves. If so, it examines the INVITE for the 357 presence of a Remote-Party-ID header field. If a Remote-Party-ID 358 header field is present, the information supplied is verified and, 359 if needed, rewritten. The proxy MUST verify that the "addr-spec" 360 provided is a valid "addr-spec" for that UAC; if not, the proxy MUST 361 rewrite the "addr-spec" with a valid "addr-spec" for that UAC. If 362 "display-name" is provided in Remote-Party-ID, the proxy MUST verify 363 that the "display-name" is a valid string for the UAC; if not or if 364 the "display-name" is omitted, the proxy MUST rewrite the "display- 365 name" with a valid string for the UAC or remove the "display-name". 366 Note, that the proxy does not check a "display-name" provided in the 367 From header field. If "rpi-type" is provided, the proxy MUST verify 369 DCS Group Internet Draft - Expiration 12/31/00 7 370 that the UAC is of the indicated "rpi-type"(s); if not, the proxy 371 MUST remove the offending "rpi-type"(s) - this includes removing 372 unrecognized "rpi-type"(s). 374 If a Remote-Party-ID header was not present in the INVITE, but the 375 proxy is able to identify the originating UAC anyway, the proxy 376 inserts a Remote-Party-ID header with the correct information. 378 If the request instead came from an untrusted entity, and it was not 379 a UAC the proxy serves or the proxy is unable to identify the 380 entity, the proxy MUST either remove any Remote-Party-ID header or 381 add "rpi-screen=no" before the request is forwarded. Alternatively, 382 the proxy MAY reject the request, e.g. with a 403 or 407. 384 The proxy furthermore looks for the presence of an Anonymity header. 385 If an Anonymity header is present and the next hop is trusted, the 386 proxy MUST ensure that a Proxy-Require header with an option-tag of 387 "privacy" is present. 389 If the proxy forwards the request to an untrusted entity, and the 390 Anonymity header is present, the proxy MUST remove the Anonymity 391 header and ensure the privacy requested will be honored. 393 For non IP-address privacy, the proxy MUST do the following: If the 394 Anonymity header contains the value "full" or "uri", the proxy MUST 395 replace the "addr-spec" in the Remote-Party-ID header in the initial 396 INVITE with a private "addr-spec" and add a "user=private" 397 parameter. If the Anonymity header contains the value "full" or 398 "name", the proxy MUST delete the "display-name" in the Remote- 399 Party-ID header field in the initial INVITE. To generate the user 400 part of a private "addr-spec", the proxy MUST include (1) the 401 initial "addr-spec", (2) the value of Anonymity, and (3) sufficient 402 checksum information to prevent tampering by the untrusted party. It 403 MAY contain any other information the proxy desires as well. This 404 information MUST be encoded or encrypted such that the next hop is 405 unable to discern the initial "addr-spec". It is RECOMMENDED that 406 the string be encrypted with a symmetric privately-held key, and 407 converted to a printable string using Base64 encoding. The proxy 408 MUST identify itself in the hostname of the private "addr-spec". 410 For IP-address privacy, the proxy MUST rewrite the request to ensure 411 that the IP-address of the originating UAC will not be revealed. 412 This implies that neither SIP signaling nor IP media streams are 413 exchanged directly between the UAC and UAS. A level of indirection 414 which we call an Anonymizer MUST be provided. 416 Prior to forwarding the request, the proxy SHOULD remove any 417 "privacy" option tag present in a Proxy-Require header field to 418 prevent unnecessary failure of the request if downstream proxies do 419 not support this extension. 421 DCS Group Internet Draft - Expiration 12/31/00 8 422 When receiving the first non-100 response to the initial INVITE from 423 an untrusted entity, the proxy first determines if the response came 424 from a UAS that it serves. 426 If it did, the proxy examines the response for the presence of a 427 Remote-Party-ID and Anonymity header and applies similar processing 428 as for an INVITE received from a UAC served by the proxy. 429 Furthermore, if the original INVITE did not contain a Proxy-Require 430 header field with an option tag of "privacy", the proxy can not 431 determine if the previous hop supports the extension or not. 432 Consequently, if the response contains a request for privacy, the 433 privacy MUST be applied by this proxy, irrespective of whether the 434 upstream hop is trusted or not. 436 If the response came from an untrusted entity, and it was not a UAS 437 the proxy serves, the proxy MUST either remove any Remote-Party-ID 438 header provided or set "rpi-screen=no" before the response is 439 forwarded upstream. The same action MUST be taken when the initial 440 INVITE did not contain a Proxy-Require with an option tag of 441 "private", irrespective of whether the downstream hop was trusted or 442 not. 444 6.4 Additional proxy behavior 446 A proxy supporting this extension SHOULD be prepared to receive a 447 request containing a SIP-URL with a user parameter of "private". If 448 the "hostport" part of the SIP-URL identifies the proxy handling the 449 request, the proxy MUST decrypt the "user" portion of the SIP-URL 450 and replace it with the decrypted SIP-URL that was contained in the 451 "user" portion as well as any other information included, e.g. 452 Anonymity. Note that the decrypted SIP-URL may itself contain a 453 "private" SIP-URL. If the proxy is unable to decrypt and recover 454 such a "private" SIP-URL, it MUST fail the request with a 4xx error 455 code. 457 7 Example of Use 459 In this Section, we will illustrate how the request for privacy may 460 work in practice. It should be noted that the privacy service 461 described can be implemented in a number of ways; we merely describe 462 one possible solution in this section. 464 7.1 Basic Privacy Example 466 The Figure below illustrates a basic privacy example scenario 468 DCS Group Internet Draft - Expiration 12/31/00 9 469 +---------+ +--------+ 470 1: INVITE | Proxy-o | 2: INVITE | Proxy-t| 3: INVITE 471 +------->| |------------>| |---------+ 472 | +---------+ +--------+ | 473 | | 474 | trust boundary | 475 . . |. . . . . . . . . . . . . . . . . . . . . . .. . . | . . . 476 | | 477 | \/ 478 +------+ RTP/RTCP +------+ 479 | UA-o |<------------------------------------------->| UA-t | 480 +------+ +------+ 482 Figure 1 - Basic Privacy Example 484 The originating user agent (UA-o) sends an INVITE (1) to Proxy-o 485 where it identifies itself and requests URI and Name privacy. Since 486 the From header field contains calling identity information, UA-o 487 supplies a cryptographically random identifier for the user info, 488 and a non-identifying hostname, e.g. "localhost" rather than its 489 true identity: 491 INVITE 492 From: sip:xyz@localhost 493 Remote-Party-ID: "John Doe" 494 Anonymity: uri, name 495 Proxy-Require: privacy 497 Proxy-o verifies the calling identity information before it sends 498 INVITE (2) to Proxy-t, which in this case is trusted. Proxy-t 499 examines the Anonymity header field included in the INVITE and sees 500 that URI and Name privacy is requested. Proxy-t therefore removes 501 the "display-name" from Remote-Party-ID, encrypts the "addr-spec" 502 ID, puts the result in the "user" part, inserts itself as the "host" 503 and adds a "user=private" parameter. Also, Proxy-t removes the 504 Anonymity header: 506 INVITE 507 From: sip:xyz@localhost 508 Remote-Party-ID: )@proxy-t.foo.com; 509 user=private> 510 Proxy-Require: privacy 512 UA-o notes the presence of the Remote-Party-ID, but since a 513 "user=private" parameter is provided, it can only identify the 514 calling party as private. UA-o decides to accept the call, and 515 responds with a 180 Ringing. In this case, there is no request for 516 Anonymity, so only the Remote-Party-ID of the called party is added: 518 DCS Group Internet Draft - Expiration 12/31/00 10 519 180 520 Remote-Party-ID: 522 Proxy-t verifies the information provided and adds the omitted 523 "display-name" to the Remote-Party-ID. Since no Anonymity was 524 requested, proxy-t can provide the Remote-Party-ID information to 525 proxy-o in clear: 527 180 528 Remote-Party-ID: "Mary Doe" 530 Proxy-o forwards the response to UA-o as is. 532 While this illustrates the basic operation of the service, there are 533 additional issues that need to be considered. In SIP, there are 534 several fields that can reveal the identity of the calling party, 535 either in part or completely. Other protocols used, e.g. SDP and RTP 536 may reveal identity information as well. A user agent wishing to not 537 reveal its identity should consider each of these. Our next example 538 looks more closely at this. 540 7.2 Full Privacy Example 542 The second example we look at is one where full privacy is 543 requested, i.e. both calling name and number privacy, as well as IP 544 address privacy. The Figure below illustrates how IP address privacy 545 can be achieved by inserting a trusted intermediary, an anonymizer, 546 for the media streams between UA-o and UA-t. 548 +---------+ +--------+ 549 1: INVITE | Proxy-o | 2: INVITE | Proxy-t| 3: INVITE 550 +------->| |------------>| |----------+ 551 | +---------+ +--------+ | 552 | \ / | 553 | \ / | 554 | SIP +--------+ SIP | 555 | +----------------->| anony- |-------------------+ | 556 | | +------>| mizer |--------+ | | 557 | | | +--------+ | | | 558 | | | | | | 559 | | | | | | 560 | | | trust boundary | | | 561 . . |.|. . . . . | . . . . . . . . . . . . | . . .. . |..| . . . 562 | | | | | | 563 | | | | \/ \/ 564 +------+ RTP/RTCP| |RTP/RTCP +------+ 565 | UA-o |<--------+ +-------->| UA-t | 566 +------+ +------+ 568 Figure 2 - Full Privacy Example 570 DCS Group Internet Draft - Expiration 12/31/00 11 571 For all signaling and media exchange purposes, the anonymizer adds a 572 level of indirection thereby hiding the IP address(es) of UA-o from 573 UA-t. This indirection is used both for the media streams and SIP 574 signaling, beyond the initial INVITE, exchanged directly between UA- 575 o and UA-t. 577 Also, the following commonly used header fields may reveal privacy 578 information, which can be remedied as described: 580 @ The From header field must not reveal any calling identity 581 information in the SIP-URL. This can be remedied, e.g. by 582 supplying a cryptographically random identifier for the userinfo, 583 and a non-identifying hostname, e.g. "localhost". The "display- 584 name" can either be omitted or provided as "anonymous". 585 @ A Contact header field must be set to point to the anonymizer to 586 prevent any direct signaling between UA-o and UA-t 587 @ Via header fields identifying either UA-o or Proxy-o must be 588 hidden, e.g. by encryption or simple stateful removal and re- 589 insertion by Proxy-t. 590 @ Call-ID should not be based on UA-o's IP-address 592 Furthermore, when SDP is used to describe the media in the session, 593 the session descriptions exchanged by the user agents need to be 594 modified to direct the media streams to the anonymizer. The use of 595 SDP fields revealing calling identity information needs to be 596 considered as well. Similar concerns apply to the use of RTCP. 598 8. Security Considerations 600 A user requesting complete privacy must still authenticate himself 601 to the proxy, and therefore the SIP messages between the UA and the 602 proxy MUST be protected. Likewise, it is necessary that the proxies 603 take precautions to protect the user identification information from 604 eavesdropping and interception. Use of IPSec between the UA and 605 proxy as well as between proxies is recommended. 607 9. Notice Regarding Intellectual Property Rights 609 AT&T may seek patent or other intellectual property protection for 610 some or all of the technologies disclosed in the document. If any 611 standards arising from this disclosure are or become protected by 612 one or more patents assigned to AT&T, AT&T intends to disclose those 613 patents and license them on reasonable and non-discriminatory terms. 614 Future revisions of this draft may contain additional information 615 regarding specific intellectual property protection sought or 616 received. 618 3COM may seek patent or other intellectual property protection for 619 some or all of the technologies disclosed in the document. If any 621 DCS Group Internet Draft - Expiration 12/31/00 12 622 standards arising from this disclosure are or become protected by 623 one or more patents assigned to 3COM, 3COM intends to disclose those 624 patents and license them on reasonable and non-discriminatory terms. 625 Future revisions of this draft may contain additional information 626 regarding specific intellectual property protection sought or 627 received. 629 10. References 631 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 632 9, RFC 2026, October 1996. 634 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 635 Levels", BCP 14, RFC 2119, March 1997 637 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 638 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 639 Demon Internet Ltd., November 1997 641 4 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg,"SIP: 642 session initiation protocol," Request for Comments (Proposed 643 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 645 5 Marshall, W. et. al, "Architectural Considerations for Providing 646 Carrier Class Telephony Services Utilizing SIP-based Distributed 647 Call Control Mechanisms", Internet Draft, Internet Engineering 648 Task Force, draft-dcsgroup-sip-arch-02, June 2000, Work In 649 Progress 651 11. Acknowledgments 653 The Distributed Call Signaling work in the PacketCable project is 654 the work of a large number of people, representing many different 655 companies. The authors would like to recognize and thank the 656 following for their assistance: John Wheeler, Motorola; David 657 Boardman, Daniel Paul, Arris Interactive; Bill Blum, Jon Fellows, 658 Jay Strater, Jeff Ollis, Clive Holborow, Motorola; Doug Newlin, 659 Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri Matousek, Bay Networks; 660 Farzi Khazai, Nortel; John Chapman, Bill Guckel, Michael Ramalho, 661 Cisco; Chuck Kalmanek, Doug Nortz, John Lawser, James Cheng, Tung- 662 Hai Hsiao, Partho Mishra, AT&T; Telcordia Technologies; and Lucent 663 Cable Communications. 665 12. Author's Addresses 667 Bill Marshall 668 AT&T 669 Florham Park, NJ 07932 670 Email: wtm@research.att.com 672 DCS Group Internet Draft - Expiration 12/31/00 13 673 K. K. Ramakrishnan 674 AT&T 675 Florham Park, NJ 07932 676 Email: kkrama@research.att.com 678 Ed Miller 679 CableLabs 680 Louisville, CO 80027 681 Email: E.Miller@Cablelabs.com 683 Glenn Russell 684 CableLabs 685 Louisville, CO 80027 686 Email: G.Russell@Cablelabs.com 688 Burcak Beser 689 3Com 690 Rolling Meadows, IL 60008 691 Email: Burcak_Beser@3com.com 693 Mike Mannette 694 3Com 695 Rolling Meadows, IL 60008 696 Email: Michael_Mannette@3com.com 698 Kurt Steinbrenner 699 3Com 700 Rolling Meadows, IL 60008 701 Email: Kurt_Steinbrenner@3com.com 703 Dave Oran 704 Cisco 705 Acton, MA 01720 706 Email: oran@cisco.com 708 Flemming Andreasen 709 Cisco 710 Edison, NJ 711 Email: fandreas@cisco.com 713 John Pickens 714 Com21 715 San Jose, CA 716 Email: jpickens@com21.com 718 Poornima Lalwaney 719 Nokia 720 San Diego, CA 92121 721 Email: poornima.lalwaney@nokia.com 723 Jon Fellows 724 Motorola 726 DCS Group Internet Draft - Expiration 12/31/00 14 727 San Diego, CA 92121 728 Email: jfellows@gi.com 730 Doc Evans 731 Secure Cable Solutions 732 Westminster, CO 30120 733 Email: drevans@securecable.com 735 Keith Kelly 736 NetSpeak 737 Boca Raton, FL 33587 738 Email: keith@netspeak.com 740 DCS Group Internet Draft - Expiration 12/31/00 15 741 Full Copyright Statement 743 "Copyright (C) The Internet Society (date). All Rights Reserved. 744 This document and translations of it may be copied and furnished to 745 others, and derivative works that comment on or otherwise explain it 746 or assist in its implementation may be prepared, copied, published 747 and distributed, in whole or in part, without restriction of any 748 kind, provided that the above copyright notice and this paragraph 749 are included on all such copies and derivative works. However, this 750 document itself may not be modified in any way, such as by removing 751 the copyright notice or references to the Internet Society or other 752 Internet organizations, except as needed for the purpose of 753 developing Internet standards in which case the procedures for 754 copyrights defined in the Internet Standards process must be 755 followed, or as required to translate it into languages other than 756 English. The limited permissions granted above are perpetual and 757 will not be revoked by the Internet Society or its successors or 758 assigns. This document and the information contained herein is 759 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 760 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 761 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 762 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 763 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 765 Expiration Date This memo is filed as , and expires December 31, 2000. 768 DCS Group Internet Draft - Expiration 12/31/00 16