idnits 2.17.1 draft-ietf-sip-privacy-03.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 is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 433 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 51 looks like a reference -- Missing reference section? '2' on line 93 looks like a reference -- Missing reference section? '4' on line 666 looks like a reference -- Missing reference section? '3' on line 622 looks like a reference Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group W. Marshall 3 Internet Draft AT&T 4 Document: 5 K. Ramakrishnan 6 TeraOptic Networks 8 E. Miller 9 Terayon 11 G. Russell 12 CableLabs 14 B. Beser 15 Pacific Broadband 17 M. Mannette 18 K. Steinbrenner 19 3Com 21 D. Oran 22 F. Andreasen 23 Cisco 25 J. Pickens 26 Com21 28 P. Lalwaney 29 Nokia 31 J. Fellows 32 Copper Mountain Networks 34 D. Evans 35 D. R. Evans Consulting 37 K. Kelly 38 NetSpeak 40 M. Watson 41 Nortel Networks 43 November 21, 2001 45 SIP Extensions for Caller Identity and Privacy 47 Status of this Memo 49 This document is an Internet-Draft and is in full conformance with 50 all provisions of Section 10 of RFC2026 [1]. 52 SIP Extensions for Caller Identity and Privacy Nov. 2001 54 Internet-Drafts are working documents of the Internet Engineering 55 Task Force (IETF), its areas, and its working groups. Note that 56 other groups may also distribute working documents as Internet- 57 Drafts. Internet-Drafts are draft documents valid for a maximum of 58 six months and may be updated, replaced, or obsoleted by other 59 documents at any time. It is inappropriate to use Internet-Drafts as 60 reference material or to cite them other than as "work in progress." 62 The list of current Internet-Drafts can be accessed at 63 http://www.ietf.org/ietf/1id-abstracts.txt 65 The list of Internet-Draft Shadow Directories can be accessed at 66 http://www.ietf.org/shadow.html. 68 The distribution of this memo is unlimited. It is filed as , and expires May 21, 2002. Please send 70 comments to the authors. 72 1. Abstract 74 This document describes extensions to the Session Initiation 75 Protocol (SIP) that enable parties in a SIP session to be identified 76 by different types of party information, which are authenticated by 77 a trusted entity by means outside the scope of this document. For 78 each type of party information, different types of authenticated 79 identity information, e.g. subscriber, or terminal, can be provided. 80 The party information is added by the trusted entity thereby 81 revealing the identity of the calling or called party. However, the 82 party is able to suppress the delivery of such party information to 83 an untrusted entity, while the trusted entity still ensures that the 84 party can be identified. In addition to suppressing the delivery of 85 party information, the extensions defined here also enable a party 86 to obtain IP address privacy in order to achieve full anonymity. 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 [2]. 94 3. Introduction 96 In order for SIP [4] to be a viable alternative to the current PSTN, 97 SIP must support certain popular telephony services as well as some 98 regulatory and public safety requirements. These include Calling 99 Identity Delivery services, Calling Identity Delivery Blocking, and 100 the ability to trace the originator of a call. While SIP can support 101 each of these services independently, certain combinations cannot be 102 supported. For example, a caller that wants to maintain privacy and 103 consequently provides unintelligible information in the SIP From 104 SIP Extensions for Caller Identity and Privacy Nov. 2001 106 header field will not be identifiable. However, since the contents 107 of the From header field cannot be modified, this will prevent 108 certain services, e.g. call trace, from being performed by entities 109 more than a single hop away. We note that this problem is not 110 telephony specific but applies to other forms of session initiation 111 as well. Furthermore, the issue of privacy in an IP environment is 112 more complicated than in the PSTN. The caller and callee will 113 normally exchange IP traffic directly, and IP address information 114 itself may reveal some privacy. The issue of IP address privacy for 115 both the caller and callee consequently needs to be addressed as 116 well. 118 In order to solve the above we assume an architecture where the 119 caller initiates a session to the callee via some trusted entity. 120 The callee in turn receives the session initiation via some trusted 121 entity. The trusted entities serve as intermediaries that provide 122 the caller and callee with authenticated identity information about 123 the remote party. Furthermore, the trusted entities ensure, that any 124 privacy needed is provided before the message is forwarded across a 125 trust boundary to an untrusted entity, while still being able to 126 trace the originating party if needed. The architecture is 127 illustrated in the following figures. 129 +---------+ . +---------+ 130 | Proxy-o | B). | Proxy-t | 131 +------>| |------{.}------>| |------+ 132 | +---------+ . +---------+ | 133 | . | 134 A) | . | 135 .....|...................................................|..... 136 | . | C) 137 | . | 138 | . v 139 +------+ .D) +------+ 140 | UA-o |<---------------------.--------------------->| UA-t | 141 +------+ . +------+ 143 Figure 1 - Basic Architecture with Trust Boundaries (1) 145 In Figure 1, we show the basic architecture which includes two user 146 agents, two proxies, and four trust boundaries. The trust 147 relationships associated with these are: 149 A) UA-o trusts Proxy-o, however Proxy-o does not trust UA-o. 150 B) Proxy-o may or may not trust Proxy-t, and Proxy-t may or may 151 not trust Proxy-o. 152 C) Proxy-t does not trust UA-t, however UA-t trusts Proxy-t. 153 D) UA-o may or may not trust UA-t, and UA-t may or may not trust 154 UA-o. 156 SIP Extensions for Caller Identity and Privacy Nov. 2001 158 In the above, Proxy-o serves as the trusted intermediary for UA-o, 159 whereas Proxy-t serves as the trusted intermediary for UA-t. Proxy-o 160 authenticates and provides the identity information for UA-o, 161 whereas Proxy-t authenticates and provides the identity information 162 for UA-t. Both UA-o and UA-t are referred to as untrusted user 163 agents in the above. 165 In Figure 2, we consider another example, this time introducing the 166 concept of a trusted user agent: 168 +---------+ . +---------+ 169 | trusted | B). | Proxy-t | 170 | UA-o |------{.}------>| |------+ 171 +---------+ . +---------+ | 172 ^ | 173 A) | . | 174 .........................................................|..... 175 | . | C) 176 | . | 177 | . v 178 | .D) +------+ 179 +------------.--------------------->| UA-t | 180 . +------+ 182 Figure 2 - Basic Architecture with Trust Boundaries (2) 184 The trust relationships associated with the trust boundaries are: 186 A) UA-o does not trust UA-t. UA-t may or may not trust UA-o. 187 B) UA-o may or may not trust Proxy-t, and Proxy-t may or may not 188 trust UA-o. 189 C) Proxy-t does not trust UA-t, however UA-t trusts Proxy-t. 190 D) Same as A. 192 In this case, UA-o is a trusted user agent and hence does not need a 193 trusted intermediary; UA-o simply provides the identity information 194 itself. However, UA-t is an untrusted user agent, and hence Proxy-t, 195 which serves as the trusted intermediary for UA-t, provides 196 authenticated identity information for UA-t. 198 Finally, in Figure 3 we consider the case of two trusted user 199 agents: 201 SIP Extensions for Caller Identity and Privacy Nov. 2001 203 +---------+ . +---------+ 204 | trusted | B). | trusted | 205 | UA-o |------{.}------>| UA-t | 206 +---------+ . +---------+ 207 A) . 208 ............................................................... 209 . C) 210 . 211 . 212 .D) 213 . 214 . 216 Figure 3 - Basic Architecture with Trust Boundaries (3) 218 The trust relationships associated with the trust boundaries are: 220 A) N/A. 221 B) UA-o may or may not trust UA-t, and UA-t may or may not trust 222 UA-o. 223 C) N/A. 224 D) N/A. 226 In this case, both UA-o and UA-t are trusted user agent and hence do 227 not need a trusted intermediary; the user agents simply provide the 228 identity information themselves. 230 In this document we define three extensions to SIP that allow the 231 calling and called parties to be identified by a trusted 232 intermediary while still being able to maintain their privacy. 234 The first extension is a new general header, Remote-Party-ID, which 235 identifies a party and may be added by intermediate entities. 236 Different types of party information can be provided, e.g. calling, 237 or called party, and for each type of party, different types of 238 identity information, e.g. subscriber, or terminal, can be provided. 239 Since a party may not wish to reveal some or all of this information 240 to an untrusted entity, the party can request a specific level of 241 privacy for each. The intermediary also has the ability to specify a 242 required level of privacy. 244 The second extension is a new general header, RPID-Privacy, which 245 specifies the desired privacy handling for any Remote-Party-ID 246 headers added by intermediaries. This enables an entity to control 247 the desired level of privacy when intermediaries add Remote-Party-ID 248 headers that identity the entity. 250 The third extension is a new general header, Anonymity, which 251 defines other types of privacy requested by the party. Currently, 252 the only such type is IP address privacy. 254 SIP Extensions for Caller Identity and Privacy Nov. 2001 256 When a trusted intermediary receives a message from an untrusted 257 entity, or the trusted intermediary originates the SIP session, the 258 trusted intermediary attempts to authenticate the originator (by 259 means outside the scope of this specification). When the identity is 260 known, the trusted intermediary ensures that corresponding Remote- 261 Party-ID information is included in the message sent. Also, the 262 trusted intermediary ensures that any privacy requested, including 263 IP address privacy, is provided prior to forwarding a message across 264 a trust boundary to an untrusted entity. Any Remote-Party-ID 265 information received from an untrusted entity is either verified 266 successfully, or tagged with an indication that it could not be 267 verified, so the receiver knows that it should not necessarily trust 268 the information. 270 This document defines a set of party types and identity information. 271 New types of party and identity information as well as other 272 attributes may be introduced, thereby allowing new services to make 273 use of the generic party information, privacy and authenticity 274 handling defined here. 276 4. Protocol Overview 278 When an untrusted UAC sends an INVITE, OPTIONS, REGISTER or 279 extension method request that is routed through a trusted 280 intermediary, the trusted intermediary MAY be adding one or more 281 Remote-Party-ID headers that identify the calling party. The UAC can 282 indicate the level of privacy that should be afforded to such 283 Remote-Party-ID headers by including one or more RPID-Privacy 284 headers with the request. The RPID-Privacy header allows the entity 285 to control the privacy down to the party-type and identity-type 286 level. If IP address privacy is desired, the UAC MUST also include 287 an Anonymity header set to "ipaddr" - this cannot be done for 288 REGISTER requests though. 290 When a trusted UAC, that supports this extensions, sends an INVITE, 291 OPTIONS, REGISTER or extension method request, the trusted UAC 292 includes a calling subscriber Remote-Party-ID header field in the 293 request in order to identify the originator of the call. The calling 294 subscriber Remote-Party-ID MUST contain a SIP-URL identifying the 295 caller and MAY contain a "display-name" for the caller as well. 296 Other types of authenticated Remote-Party-ID MAY be included as 297 well. If privacy is desired for a given Remote-Party-ID header, the 298 UAC MUST include a privacy token set to one or more of "uri", "name" 299 or "full". Furthermore, if the UAC wants to control privacy for any 300 Remote-Party-ID headers added by downstream proxies, the UAC MUST 301 include one or more RPID-Privacy headers specifying the desired 302 privacy. If IP address privacy is desired, the UAC MUST include an 303 Anonymity header set to "ipaddr" - this cannot be done for REGISTER 304 requests though. 306 When a proxy supporting this extension receives an INVITE, OPTIONS, 307 REGISTER or extension method request from an untrusted entity (UA or 308 SIP Extensions for Caller Identity and Privacy Nov. 2001 310 proxy), the proxy first examines the request for the presence of any 311 Remote-Party-ID headers. The value of these headers cannot be 312 trusted and hence the proxy will either have to validate them (by 313 means outside the scope of this document) or make sure they are not 314 marked as trusted. If the proxy wants to ensure, that the calling 315 party can be identified by the called party, the proxy MUST 316 authenticate the calling party (by means outside the scope of this 317 document) and insert a calling party Remote-Party-ID header that is 318 marked as being trusted. If the proxy is unable to authenticate the 319 calling party, it MAY reject the request, e.g. with a 403 or 407. If 320 the proxy can identify other types of identity information for the 321 calling party, it MAY insert those as trusted Remote-Party-ID 322 headers as well. If the request contained one or more RPID-Privacy 323 header fields, any Remote-Party-ID header fields added MUST have 324 their privacy indication set accordingly. 326 Prior to a trusted entity (UA or proxy) forwarding the INVITE, 327 OPTIONS, REGISTER or extension method request to an untrusted 328 entity, the trusted entity MUST look for the presence of a privacy 329 request indication in each Remote-Party-ID header field. If one is 330 found, the privacy requested MUST be provided for that Remote-Party- 331 ID header field prior to forwarding the request to the untrusted 332 entity. For "uri" and "name" privacy, this typically involves 333 encrypting and possibly removing information provided in the Remote- 334 Party-ID. The proxy MUST also look for the presence of an Anonymity 335 header requesting IP address privacy. If IP Address privacy is 336 requested, the proxy MUST ensure that IP address privacy is provided 337 through a level of indirection for signaling and media referred to 338 as an Anonymizer. Once the IP address privacy has been provided, the 339 request for IP address privacy MUST be removed from the message as 340 well. 342 Once a UAS supporting this extension receives the INVITE, OPTIONS, 343 REGISTER or extension method request through a trusted entity, the 344 UAS can use the calling subscriber Remote-Party-ID information 345 provided to identify the originator of the call, unless the 346 originator had requested privacy. Note that if the UAS did not 347 receive the call through a trusted entity, any Remote-Party-ID 348 information provided may be false. 350 The subsequent behavior now depends on whether the UAS is trusted or 351 not: 353 * If the UAS is trusted, it SHOULD include a called subscriber 354 Remote-Party-ID identifying the called party in the first non-100 355 response. The party information SHOULD be set to "called" and the 356 identity information SHOULD be set to "subscriber". Additional 357 Remote-Party-ID header fields MAY be provided as well. If the UAS 358 desires privacy for a Remote-Party-ID, it MUST include a privacy 359 request indication in that Remote-Party-ID header. Also, if the 360 UAS desires IP address privacy, the UAS MUST include an Anonymity 361 header indicating this in the first non-100 response sent back. 362 Note that either type of privacy request is only guaranteed to be 363 SIP Extensions for Caller Identity and Privacy Nov. 2001 365 satisfied if the previous hop is trusted and it furthermore 366 supports the extensions defined here. If the UAS can not guarantee 367 both, then any privacy desired MUST be provided before the 368 response is forwarded upstream. 370 * If the UAS instead is untrusted, only IP-address privacy applies. 371 If the UAS desires IP address privacy, the UAS MUST include an 372 Anonymity header indicating this in the first non-100 response 373 sent back. Note that such a request for IP address privacy is only 374 guaranteed to be satisfied if the previous hop is trusted and it 375 furthermore supports the extensions defined here. If the UAS can 376 not guarantee both, then it SHOULD NOT depend on the IP address 377 privacy actually being provided. 379 If the UAS (trusted or untrusted) wants to control the level of 380 privacy afforded to any Remote-Party-ID headers that may be inserted 381 by other entities in its response, the UAS MUST include one or more 382 RPID-Privacy header field with the relevant privacy indication(s) in 383 that response. 385 A trusted UAS MAY also include Remote-Party-ID headers in subsequent 386 provisional and final responses to the request. The trusted UAS 387 SHOULD include a called party Remote-Party-ID header if the contents 388 are different than sent in a previous response. The party 389 information SHOULD be set to "called" and the identity information 390 SHOULD be set to "subscriber". Additional Remote-Party-ID header 391 fields may be provided as well. 393 When a proxy supporting this extension receives a non-100 response 394 to an INVITE, OPTIONS, REGISTER or extension method request from an 395 untrusted entity, the proxy first examines the response for the 396 presence of any Remote-Party-ID headers. By definition, the value of 397 these headers cannot be trusted and hence the proxy will either have 398 to validate them (by means outside the scope of this document) or 399 make sure they are not marked as trusted. If the proxy wants to make 400 sure that the called party can be identified, e.g. for mutual 401 authentication, the proxy MUST authenticate the called party (by 402 means outside the scope of this document) and insert a called party 403 Remote-Party-ID header that is marked as being trusted. If the proxy 404 is unable to identify the called party, the proxy SHOULD simply mark 405 any Remote-Party-ID headers in the message as untrusted. If the 406 proxy can identify other types of identity information for the 407 calling party, the proxy MAY insert those as trusted Remote-Party-ID 408 headers as well. If the response contained one or more RPID-Privacy 409 parameters, any Remote-Party-ID header fields added MUST have their 410 privacy indication set accordingly. 412 The proxy MUST also ensure that any privacy requested in the 413 response is provided prior to forwarding it to an untrusted entity. 415 Finally, when a UAC (trusted or not) receives the first non-100 416 response to an INVITE, OPTIONS, or REGISTER request from a trusted 417 entity, the UAC can use the called subscriber Remote-Party-ID 418 SIP Extensions for Caller Identity and Privacy Nov. 2001 420 information (if present) to identify the called party, unless the 421 terminator had requested privacy. Subsequent non-100 responses MAY 422 contain Remote-Party-ID information as well. When the UAC receives 423 the final 200 response, it MAY contain a called subscriber Remote- 424 Party-ID header identifying the party the UAC was connected to. 425 Again, this information SHOULD NOT be trusted if it was not received 426 from a trusted entity. 428 5. Header Field Definitions 430 Table 1 below is an extension of tables 4 and 5 in [4] for the new 431 header fields defined here: 433 where enc. e-e ACK BYE CAN INV OPT REG 434 Anonymity g n h - - - o o - 435 Remote-Party-ID g n h - - - o o o 436 RPID-Privacy g n h - - - o o o 438 Table 1: Summary of header fields. 440 The Anonymity header can be used with the INVITE and OPTIONS methods 441 as well as any response to these. The Remote-Party-ID and the RPID- 442 Privacy headers can be used with the INVITE, OPTIONS, and REGISTER 443 methods as well as any response to these. Extension methods MAY 444 utilize these three headers to achieve anonymity and remote party 445 identification. The procedures at User Agents MAY be specific to 446 particular new methods, however, the generic handling at proxies 447 MUST be as specified in this document. 449 Note that any privacy requested may not be honored unless the 450 request or response is sent through a trusted entity that supports 451 the extensions defined here. Similarly, Remote-Party-ID information 452 may not be trustworthy if it was received in a request or response 453 from a non-trusted entity or an entity that does not support the 454 extensions defined here. 456 5.1 Remote-Party-ID Header Field Definitions 458 The Remote-Party-ID header field provides information about the 459 remote party. Different types of party information can be provided, 460 e.g. calling and called, and for each, different types of identity 461 information can be provided as well. A request or response MAY 462 contain more than one Remote-Party-ID header field with privacy 463 requested independently for each. Remote-Party-ID is defined by the 464 following ABNF [3]: 466 Remote-Party-ID = "Remote-Party-ID" ":" [display-name] 467 "<" addr-spec ">" *(";" rpi-token) 469 rpi-token = rpi-screen | rpi-pty-type | 470 rpi-id-type | rpi-privacy | other-rpi-token 472 SIP Extensions for Caller Identity and Privacy Nov. 2001 474 rpi-screen = "screen" "=" ("no" | "yes" ) 476 rpi-pty-type = "party" "=" ( "calling" | "called" | token ) 478 rpi-id-type = "id-type" "=" ( "subscriber" | "user" | 479 "term" | token ) 481 rpi-privacy = "privacy" "=" 1#( 482 ("full" | "name" | "uri" | "off" | token ) 483 [ "-" ( "network" | token ) ] ) 485 other-rpi-token = ["-"] token ["=" (token | quoted-string)] 487 Furthermore, we define the value "private" for "other-user" in an 488 "addr-spec", to indicate that the user part of an "addr-spec" is in 489 a non-intelligible form. The syntax for "other-user" is therefore 490 refined to: 492 other-user = token | "private" 494 Comparisons follow the case-sensitivity rules defined by SIP [4]. 496 The "display-name" in Remote-Party-ID is a text string that 497 identifies the name of the party. The "addr-spec" contains 498 information identifying the party either in clear-text or encrypted 499 form. In the latter case, the "user" part of the "addr-spec" 500 typically contains the encrypted party information, whereas the 501 "hostport" identifies the entity that can decrypt the information. 502 Furthermore, an "other-user" value of "private" will then be present 503 to indicate that the "addr-spec" is non-intelligible. Depending on 504 the rpi-pty-type, the "addr-spec" can be used as the Request-URI by 505 the UA to initiate certain call control functions or subsequent 506 calls that are required to reference the party. 508 The rpi-screen parameter describes what verification the Remote- 509 Party-ID information has undergone. The value "yes" indicates the 510 Remote-Party-ID was verified successfully by the proxy itself or the 511 proxy received the message from a trusted entity with this 512 indication. The value "no" (assumed by default) indicates the 513 Remote-Party-ID was either not verified successfully by the proxy or 514 the proxy received the message from an untrusted entity. Multiple 515 rpi-screen parameters MAY be present in a Remote-Party-ID - if both 516 "yes" and "no" are present, "no" will take precedence. It should be 517 noted, that the rpi-screen parameter provides a somewhat weak form 518 of authenticity. In particular, it depends on transitive trust as 519 well as correct implementation, configuration and support for the 520 extensions defined here in the associated chain of trust. Should any 521 of these dependencies not hold, the value "yes" may actually not be 522 trustworthy. Future extensions to SIP may define a general and more 523 robust mechanism that can be used here. 525 SIP Extensions for Caller Identity and Privacy Nov. 2001 527 The rpi-pty-type describes the type of party to which this header 528 refers. There MUST NOT be more than one rpi-pty-type present in a 529 Remote-Party-ID. If the rpi-pty-type parameter is absent, the 530 "display-name" and "addr-spec" describe the party from which the 531 request or response was received, i.e., "calling" party in the case 532 of requests and "called" in the case of responses. Additional values 533 MAY be defined as extensions. Such extensions SHALL be registered 534 with IANA. 536 The rpi-id-type describes the nature of the identity provided. 537 Several types of identity can be provided for each party, however 538 there MUST NOT be more than one rpi-id-type present in a given 539 Remote-Party-ID. If the rpi-id-type parameter is absent, the Remote- 540 Party-ID contains the subscriber identity. 542 This document defines three verifiable identity types that can be 543 provided by a trusted intermediary - additional values MAY be 544 defined as extensions in which case they SHALL be registered with 545 IANA. The types are defined based on the nature of the information 546 they represent, as opposed to a particular application. Individual 547 applications requiring verifiable identity information, which is to 548 be provided by a trusted intermediary, will specify which identities 549 should be used for that application: 551 Subscriber identity (rpi-id-type="subscriber"): 553 This identifies the owner of the subscription which is being used 554 for the session. 556 User identity (rpi-id-type="user"): 558 This identifies the individual participating in the session. For 559 example when multiple individuals are able to originate sessions 560 under the same subscription. If absent, this is assumed to be the 561 same as the subscriber identity. 563 Terminal identity (rpi-id-type="term") 565 This identifies the terminal being used for the session. For 566 example several users may be able to 'log in' to a single 567 terminal, in which case the identity of the terminal will differ 568 from that of the user, subscriber, etc. If absent, this is assumed 569 to be the same as the subscriber identity. 571 Entities SHOULD NOT include multiple Remote-Party-ID headers 572 containing the same identity information marked with different rpi- 573 id-types. 575 The rpi-privacy parameter describes whether the identity information 576 must be hidden from untrusted entities. There MAY be multiple rpi- 577 privacy parameters in a Remote-Party-ID. If privacy is requested, it 578 MUST be one or more of "full", "uri", or "name". The value "full" 579 means that both the "display-name" and the "addr-spec" MUST be 580 SIP Extensions for Caller Identity and Privacy Nov. 2001 582 hidden. The values "name" and "uri" mean that the "display-name" or 583 the "addr-spec" MUST be hidden respectively. The value "off" 584 indicates that lack of privacy is explicitly requested, and MUST be 585 the only value if present. The values may be postfixed with a string 586 indicating that the privacy request was made by an entity other than 587 the party itself. Postfixing with the value "-network" indicates 588 that intermediaries ("the network") have requested that the 589 information be hidden. Additional values MAY be defined as 590 extensions. Such extensions SHALL be registered with IANA. 592 It should be noted, that an entity requesting only Remote-Party-ID 593 privacy will not receive complete privacy. The values "uri" and 594 "name" merely affect information that may be displayed as opposed to 595 truly hiding the identity of the requesting entity, since the 596 identity of the host, e.g. IP address, is not hidden. For full 597 privacy, the entity SHOULD request IP address privacy as well - see 598 Section 5.3. 600 Finally, the "other-rpi-token" parameter allows the Remote-Party-ID 601 header field to be extended with other types of parameters which 602 SHALL be registered with IANA. By default, such extensions will be 603 assumed to contain information that may be of importance to the 604 verification, and hence MUST be supported for identity verification 605 to pass successfully. The prefix "-" is used to indicate that a 606 parameter extension does not need to be supported by a given entity 607 in order for the Remote-Party-ID to be verified successfully. 608 Consequently, such extensions MUST NOT begin with the character "-". 610 5.2 RPID-Privacy Header Field Definition 612 The RPID-Privacy header field allows an entity (typically an 613 untrusted user agent) to indicate a desired level of privacy for any 614 Remote-Party-ID header that may be added by subsequent entities, 615 e.g. a downstream proxy. Any Remote-Party-ID header added of the 616 party-type and identity-type indicated, shall have the privacy 617 specified applied to it. If the party-type is omitted, the privacy 618 specified applies to all party-types. If the identity-type is 619 omitted, the privacy specified applies to all identity-types. A 620 request or response MAY contain zero, one or more RPID-Privacy 621 header fields. The RPID-Privacy header field is defined by the 622 following ABNF [3]: 624 RPID-Privacy = "RPID-Privacy" ":" 1*(";" rpid-privacy-token) 625 ; rpi-privacy MUST be present 627 rpid-privacy-token = rpi-pty-type | rpi-id-type | rpi-privacy 629 Comparisons follow the case-sensitivity rules defined by SIP [4]. 631 When multiple RPID-Privacy headers are present, the following 632 precedence rules MUST be used: 634 SIP Extensions for Caller Identity and Privacy Nov. 2001 636 * RPID-Privacy with both rpi-id-type and rpi-pty-type takes 637 precedence over 638 * RPID-Privacy with only rpi-id-type, which takes precedence over 639 * RPID-Privacy with only rpi-pty-type, which takes precedence over 640 * RPID-Privacy with neither rpi-id-type nor rpi-pty-type. 642 Any remaining overlaps or conflicts are resolved by order: a later 643 RPID-Privacy indication in a message will take precedence over an 644 earlier RPID-Privacy indication in that message. The following 645 example illustrates the above: 647 RPID-Privacy: rpi-privacy=full;party=calling;id-type=subscriber 648 RPID-Privacy: party=calling;rpi-privacy=off 649 RPID-Privacy: party=calling;rpi-privacy=uri 651 Per the rules above, a new calling subscriber Remote-Party-ID will 652 get full privacy, and any other calling party Remote-Party-ID will 653 get uri privacy. 655 5.3 Anonymity Header Field Definition 657 The Anonymity header field allows an entity to indicate the degree 658 of other privacy that should be provided to it. The only type of 659 other privacy defined here is IP address privacy. 661 The ABNF for the header field is: 663 Anonymity = "Anonymity" ":" 1#privacy-tag 664 privacy-tag = "ipaddr" | "off" | token 666 Comparisons follow the case-sensitivity rules defined by SIP [4]. 668 If other privacy is requested, it MUST currently be "ipaddr" 669 (extensions may change this). The value "off" indicates that no 670 other privacy is requested, and MUST be the only value if present. 671 Additional values MAY be defined as extensions. Such extensions 672 SHALL be registered with IANA. 674 The value "ipaddr" requests IP address privacy such that the other 675 party does not learn the IP address of this party. Once the IP 676 address privacy has been provided, the request for IP address 677 privacy MUST be removed from the message. Currently, this implies 678 that the Anonymity header field is removed. 680 It should be noted, that an entity requesting only IP address 681 privacy merely hides its IP address without suppressing its 682 identity. For full privacy, the entity should thus also request 683 privacy for its Remote-Party-ID information. Note however, that the 684 use of extensions, which themselves do not consider privacy impacts, 685 may in turn violate privacy. 687 The value "off" indicates that lack of other privacy is explicitly 688 requested, and MUST be the only value if present. 690 SIP Extensions for Caller Identity and Privacy Nov. 2001 692 Absence of the Anonymity header in a request or response is 693 identical to the value "off", unless provisioned otherwise. 695 It should be noted, that the Anonymity header field allows both the 696 originating and terminating UA to indicate their desire for IP 697 address privacy. 699 6. Protocol Semantics 701 Below, we provide the protocol semantics for an untrusted UAC, a 702 trusted UAC, an untrusted UAS, a trusted UAS, and a proxy. 704 6.1 Untrusted UAC Behavior 706 When an untrusted UAC supporting this extension sends an INVITE, 707 OPTIONS, REGISTER or extension method request, and the UAC wants to 708 control the privacy for any Remote-Party-ID header that might be 709 added by a downstream proxy, the UAC MUST include one or more RPID- 710 Privacy headers indicating the desired level of privacy. Each such 711 RPID-Privacy header MUST include an rpi-privacy parameter specifying 712 the desired level of privacy, e.g. "uri", to maintain privacy of the 713 "addr-spec". 715 If the UAC desires "name" or "full" privacy, the UAC MUST NOT reveal 716 the originating subscriber's name in the "display-name" portion of 717 any header. This can be achieved by either not providing a "display- 718 name" or by setting the "display-name" to "Anonymous" in such 719 fields, e.g. From and Contact. 721 If the UAC desires "uri" or "full" privacy, the UAC MUST NOT reveal 722 the subscriber's identity in any header field. In particular, the 723 contents of header fields needs to be considered as described below: 725 * From: The UAC SHOULD supply a cryptographically random 726 identifier for the userinfo, and a non-identifying hostname, e.g. 727 "localhost", in the host name. The cryptographically random 728 identifier ensures a globally unique call leg identification 729 (despite the use of "localhost") while still providing privacy. 731 * To: If a telephone number is used in the addr-spec, the 732 telephone number SHOULD be a full E.164 number (including the 733 country code) that is different from the From header field. If a 734 host name is included, it SHOULD be the non-identifying name 735 "localhost". 737 * Contact: The same cryptographically random identifier used in 738 the From header field SHOULD be supplied for the userinfo, and an 739 IP-address SHOULD be used in the host name. 741 * All other headers that may contain either an IP address or a 742 domain name, e.g. Call-ID, and Via, SHOULD use the IP-address 743 SIP Extensions for Caller Identity and Privacy Nov. 2001 745 form. It should however be noted, that this simple privacy step 746 may be overcome fairly easily in many cases. 748 The UAC may also explicitly request that privacy is not to be 749 provided by setting the rpi-privacy parameter in the corresponding 750 RPID-Privacy header to "off". This is also the default value, unless 751 provisioned otherwise. 753 If the UAC desires IP address privacy, it MUST include an Anonymity 754 header field set to "ipaddr". The value "off", which is the default 755 unless provisioned otherwise, can be provided lack of IP address 756 privacy is explicitly requested. Note that if the UAC does not 757 initiate the call through its trusted proxy, any requested privacy 758 may not be provided. As honoring the privacy requested depends on 759 the proxy supporting the extension, the UAC MUST furthermore include 760 a Proxy-Require header with an option-tag of "privacy". Should a 420 761 response listing "privacy" as an unsupported option be returned, 762 then privacy can not be provided for this call. The UA MUST then 763 either initiate a new session without requiring privacy, or the 764 session initiation attempt MUST be abandoned. 766 If the UAC desires "ipaddr" privacy, then the following header field 767 requirements apply: 769 * From: The UAC MUST use the non-identifying host name 770 "localhost". 772 * Call-ID: The UAC MUST NOT base the Call-ID on the originator's 773 IP address. 775 The first non-100 response to the INVITE, OPTIONS, REGISTER or 776 extension method request received by the UAC through its trusted 777 proxy MAY contain one or more Remote-Party-ID header fields. A 778 Remote-Party-ID with party type "called" will identify the called 779 party. If such a Remote-Party-ID header field either does not 780 contain an rpi-screen parameter, or it contains an rpi-screen 781 parameter with the value "no" (this includes the case where both 782 "yes" and "no" is provided), the UAC SHOULD NOT trust the validity 783 of the information provided. An end-to-end encrypted Remote-Party-ID 784 header field can of course also not be trusted, regardless of the 785 value of the rpi-screen parameter. It should be noted, that the rpi- 786 screen is a somewhat weak form of indicating authenticity. In 787 particular, it depends on transitive trust as well as correct 788 implementation, configuration and support for the extensions defined 789 here in the associated chain of trust. Should any of these 790 dependencies not hold, the value "yes" may actually not be 791 trustworthy. Future extensions to SIP may define a general and more 792 robust mechanism that can be used here. 794 Subsequent responses to the requests MAY also contain Remote-Party- 795 ID header fields. Such Remote-Party-ID header fields with party type 796 "called" identify other parties to which the session has been 797 directed, for whatever reason. 799 SIP Extensions for Caller Identity and Privacy Nov. 2001 801 Remote-Party-ID headers contained in the final response, with rpi- 802 pty-type set to "called" identify the party which provided the final 803 answer. In the case of an INVITE response, this identifies the 804 answering party. Again, end-to-end encrypted Remote-Party-ID header 805 fields can not be trusted. 807 6.2 Trusted UAC Behavior 809 When a trusted UAC supporting this extension sends an INVITE, 810 OPTIONS, REGISTER or extension method request, and it knows the 811 identity of the calling party, the UAC SHOULD include a calling 812 subscriber Remote-Party-ID header in the request in order to 813 identify the originator of the call. However, if the request is part 814 of an existing call leg, and the request is sent directly to the 815 UAS, then the UAC MAY omit the calling subscriber Remote-Party-ID 816 header. The Remote-Party-ID header MUST at a minimum contain an 817 "addr-spec" to uniquely identify the calling subscriber. The "addr- 818 spec" SHOULD be the same string as appears in the Request-URI for 819 incoming call attempts. The Remote-Party-ID SHOULD include an rpi- 820 pty-type set to "calling" and an rpi-id-type set to "subscriber" - 821 we refer to this as a calling subscriber Remote-Party-ID. The rpi- 822 screen parameter SHOULD be set to "yes". The Remote-Party-ID MAY 823 optionally include a "display-name" which SHOULD be set to a name 824 that the trusted UAC has associated with the calling subscriber, 825 e.g. the subscriber's full name. The UAC MAY include other Remote- 826 Party-ID information as well. 828 If the UAC desires privacy for the Remote-Party-ID header fields it 829 added, it MUST include an rpi-privacy parameter for each relevant 830 Remote-Party-ID. The rpi-privacy parameter MUST specify the desired 831 level of privacy, e.g. "uri", to maintain privacy of the "addr- 832 spec". 834 If the UAC wants to control the privacy for any Remote-Party-ID 835 header that might be added by a downstream proxy, the UAC MUST 836 furthermore include one or more RPID-Privacy headers indicating the 837 desired level of privacy. Each such RPID-Privacy header MUST include 838 an rpi-privacy parameter specifying the desired level of privacy, 839 e.g. "uri", to maintain privacy of the "addr-spec". 841 If the UAC indicates "name" or "full" privacy (in either Remote- 842 Party-ID or RPID-Privacy), the UAC MUST NOT reveal the originating 843 subscriber's name in the "display-name" portion of any other header 844 than Remote-Party-ID. This can be achieved by either not providing a 845 "display-name" or setting the "display-name" to "Anonymous" in such 846 fields, e.g. From and Contact. 848 If the UAC desires "uri" or "full" privacy, the UAC MUST NOT reveal 849 the subscriber's identity in any other header field than Remote- 850 Party-ID. In particular, the contents of header fields needs to be 851 considered as described for untrusted UAC's (Section 6.1) 852 SIP Extensions for Caller Identity and Privacy Nov. 2001 854 The UAC may also explicitly request that privacy is not to be 855 provided for a Remote-Party-ID by setting the rpi-privacy parameter 856 to "off". This is also the default value, unless provisioned 857 otherwise. 859 When privacy is requested for one or more Remote-Party-ID headers, 860 the UAC MUST ensure that such privacy is provided prior to 861 forwarding the message to an untrusted entity. Two different options 862 for achieving this are defined here: 864 1) Do not provide the privacy until the message is forwarded to an 865 untrusted entity. 866 2) Provide the privacy before forwarding the message, irrespective 867 of whether the next hop is trusted or not. 869 We first describe option 1, which has the benefit of leaving the 870 Remote-Party-ID in clear as long as possible at the expense of 871 introducing a Proxy-Require "privacy": 873 If privacy was requested, and the next hop is trusted, the UA MUST 874 ensure that a Proxy-Require header with an option-tag of "privacy" 875 is present. This will ensure that a downstream proxy will apply the 876 necessary privacy prior to forwarding the message to an untrusted 877 entity. Should a 420 response listing "privacy" as an unsupported 878 option be returned, then privacy can not be provided for this call. 879 The UA MUST then either initiate a new session without requiring 880 privacy, or the session initiation attempt MUST be abandoned. 881 Furthermore, the UA MUST take precautions to protect the identity 882 information from eavesdropping and interception, e.g. by use of 883 IPSec. 885 If the UA forwards the request to an untrusted entity, and privacy 886 was requested, the UA MUST ensure the privacy requested will be 887 honored. For each Remote-Party-ID requesting privacy, the UAC MUST 888 do the following: 890 * If rpi-privacy contains the value "full" or "uri", the UA MUST 891 replace the "addr-spec" in that Remote-Party-ID header field with 892 a private "addr-spec". The private "addr-spec" MUST list the UA 893 itself in the hostport and include a "user=private" user 894 parameter. 896 * If rpi-privacy contains the value "full" or "name", the UA MUST 897 delete the "display-name" in that Remote-Party-ID header field. 899 Generation of the user part of a private "addr-spec" is a UA 900 internal issue as long as the requested privacy is honored and the 901 ability to trace the originator is preserved. However, it is 902 RECOMMENDED to construct the user part by including: 904 * the initial "addr-spec", 906 * the value of rpi-privacy, and 907 SIP Extensions for Caller Identity and Privacy Nov. 2001 909 * sufficient checksum information to prevent tampering by an 910 untrusted party. 912 All of this information MUST then be encoded or encrypted such that 913 the next hop is unable to discern the original Remote-Party-ID. It 914 is RECOMMENDED that the string be encrypted with a symmetric private 915 key, and converted to a printable string using Base64 encoding. The 916 UA MAY include other information in the user part as well. 918 Prior to forwarding the request to an untrusted entity, the UA 919 SHOULD remove any "privacy" option tag (subject to the Anonymity 920 header field considerations below) present in a Proxy-Require header 921 field to prevent unnecessary failure of the request if downstream 922 proxies do not support this extension. 924 We now describe the second option for providing Remote-Party-ID 925 privacy. With this option, the UA applies the same processing for 926 each Remote-Party-ID as in option 1, however it does it regardless 927 of whether the next hop is trusted or not. Since the privacy has now 928 been applied, there is no need to insert a Proxy-Require "privacy". 929 However, there is also no well-defined way for a downstream 930 (trusted) entity to determine the identity of the calling party, 931 without that entity knowing both the details of how the private 932 "addr-spec" was constructed (crypto algorithm, MAC, encoding, etc.) 933 as well as which key to use for decrypting the information. The 934 solutions to these problems are left as an exercise to the reader, 935 and hence interoperability should not be expected. 937 Having dealt with privacy for Remote-Party-ID headers, we now 938 consider IP-address privacy. If the UAC desires IP address privacy, 939 it MUST include an Anonymity header field set to "ipaddr" - this 940 cannot be done for REGISTER requests though. The header requirements 941 specified for untrusted UACs in Section 6.1 apply here as well. The 942 value "off", which is the default unless provisioned otherwise, may 943 be provided if IP address privacy is explicitly not requested. 945 As for Remote-Party-ID privacy, the UAC MUST ensure, that any 946 desired IP-address privacy is provided prior to forwarding the 947 message to an untrusted entity. This means that the UA MUST ensure 948 that the request is rewritten in a way that ensures that the IP- 949 address of the originating UAC will not be revealed to an untrusted 950 entity. This implies that neither SIP signaling nor IP media streams 951 are exchanged directly between the UAC and UAS. A level of 952 indirection, which we call an Anonymizer, MUST be provided. Once the 953 IP address privacy has been provided, the request for IP address 954 privacy MUST be removed from the message. Currently, this implies 955 that the Anonymity header field is removed. 957 If the next hop is not the Anonymizer, the UA MUST ensure that 958 downstream entities will provide the IP-address privacy prior to 959 forwarding the message to an untrusted entity (note that the next 960 hop MUST be trusted in this case). This is achieved by including a 961 SIP Extensions for Caller Identity and Privacy Nov. 2001 963 Proxy-Require with an option-tag of "privacy" to the message. Should 964 a 420 response listing "privacy" as an unsupported option be 965 returned, then IP-address privacy can not be provided for this call. 966 The UA MUST then either initiate a new session without requiring IP- 967 address privacy, or the session initiation attempt MUST be 968 abandoned. 970 The first non-100 response received by the UAC MAY contain one or 971 more Remote-Party-ID header fields. A Remote-Party-ID with party 972 type "called" will identify the called party. If the response was 973 received via a trusted entity, and the Remote-Party-ID header field 974 either does not contain an rpi-screen parameter, or it contains an 975 rpi-screen parameter with the value "no" (this includes the case 976 where both "yes" and "no" is provided), the UAC SHOULD NOT trust the 977 validity of the information provided. An end-to-end encrypted 978 Remote-Party-ID header field can of course also not be trusted, 979 regardless of the value of the rpi-screen parameter. 981 Subsequent responses received by the UAC MAY also contain Remote- 982 Party-ID header fields. Such Remote-Party-ID header fields with 983 party type "called" identify other parties to which the request has 984 been directed, for whatever reason. 986 Remote-Party-ID headers contained in the final response, with rpi- 987 pty-type set to "called" identify the party which provided the final 988 answer. In the case of an INVITE response, this identifies the 989 answering party. Again, end-to-end encrypted Remote-Party-ID header 990 fields can not be trusted. 992 6.3 Untrusted UAS Behavior 994 A UAS supporting this extension and receiving an INVITE, OPTIONS, 995 REGISTER or extension method request from its trusted proxy looks 996 for a Remote-Party-ID header field with rpi-pty-type "calling" and 997 rpi-id-type "subscriber", i.e. a calling subscriber Remote-Party-ID, 998 to identify the originator of the request. If rpi-pty-type is 999 omitted from a Remote-Party-ID in the request, "calling" is assumed, 1000 and if rpi-id-type is omitted, "subscriber" is assumed. If a calling 1001 subscriber Remote-Party-ID either does not contain an rpi-screen 1002 parameter or it contains an rpi-screen parameter with a value of 1003 "no" (this includes the case where both "yes" and "no" is provided), 1004 the UAS SHOULD NOT trust the validity of the information provided. 1005 An end-to-end encrypted Remote-Party-ID header field can of course 1006 also not be trusted, regardless of the value of the rpi-screen 1007 parameter. Otherwise, the UAS SHOULD use the information provided to 1008 identify the calling party rather than any information provided in 1009 the From or any other header field. Note that the request MAY 1010 contain other Remote-Party-ID header fields. 1012 If the UAS wants to control the privacy for any Remote-Party-ID 1013 header that might be added to its response by an upstream proxy, the 1014 UAS MUST include one or more RPID-Privacy headers indicating the 1015 desired level of privacy. Each such RPID-Privacy header MUST include 1016 SIP Extensions for Caller Identity and Privacy Nov. 2001 1018 an rpi-privacy parameter specifying the desired level of privacy, 1019 e.g. "uri", to maintain privacy of the "addr-spec". 1021 The UAS MAY request IP-address privacy by including an Anonymity 1022 header set to "ipaddr" in the first non-100 response it sends back 1023 through its trusted proxy. It should be noted though, that the UAS 1024 cannot depend on this being honored, unless it somehow knows that 1025 the trusted proxy supports the extensions defined here. Currently, 1026 there is no well-defined mechanism within SIP to determine this. 1028 6.4 Trusted UAS Behavior 1030 A UAS supporting this extension and receiving an INVITE, OPTIONS, 1031 REGISTER or extension method request from a trusted entity looks for 1032 a Remote-Party-ID header field with rpi-pty-type "calling" and rpi- 1033 id-type "subscriber", i.e. a calling subscriber Remote-Party-ID, to 1034 identify the originator of the request. If rpi-pty-type is omitted 1035 from a Remote-Party-ID in the request, "calling" is assumed, and if 1036 rpi-id-type is omitted, "subscriber" is assumed. If a calling 1037 subscriber Remote-Party-ID either does not contain an rpi-screen 1038 parameter or it contains an rpi-screen parameter with a value of 1039 "no" (this includes the case where both "yes" and "no" is provided), 1040 the UAS SHOULD NOT trust the validity of the information provided. 1041 An end-to-end encrypted Remote-Party-ID header field can of course 1042 also not be trusted, regardless of the value of the rpi-screen 1043 parameter. Otherwise, the UAS SHOULD use the information provided to 1044 identify the calling party rather than any information provided in 1045 the From or any other header field. Note that the request MAY 1046 contain other Remote-Party-ID header fields. 1048 If the UAS knows the identity of the party that was reached, it 1049 SHOULD include a called subscriber Remote-Party-ID identifying the 1050 called party in the first non-100 response. However, if the request 1051 was part of an existing call leg, and the request was sent directly 1052 to the UAS, then the UAS MAY omit the called subscriber Remote- 1053 Party-ID header from the response. In addition, the UAS MAY insert 1054 Remote-Party-ID headers in any further non-100 responses. The UAS 1055 SHOULD insert a new called subscriber Remote-Party-ID header if the 1056 called party information changed from the called party information 1057 sent in the previous response. For each of these, the party 1058 information SHOULD be set to "called" and the identity information 1059 SHOULD be set to "subscriber". Otherwise, the rules for the Remote- 1060 Party-ID are similar to those for the INVITE, OPTIONS, REGISTER or 1061 extension method request sent by a trusted UAC. Additional Remote- 1062 Party-ID header fields MAY be provided as well. 1064 If the UAS desires privacy for a Remote-Party-ID header field it 1065 added, it MUST include a privacy request indication in that Remote- 1066 Party-ID header. Also, if the UAS desires IP address privacy, the 1067 UAS MUST include an Anonymity header set to "ipaddr" in the first 1068 non-100 response sent back. Note that either type of privacy request 1069 is only guaranteed to be satisfied if the previous hop is trusted 1070 and it furthermore supports the extensions defined here. If the UAS 1071 SIP Extensions for Caller Identity and Privacy Nov. 2001 1073 cannot guarantee both, then any privacy desired MUST be provided 1074 before the response is forwarded upstream. Alternatively, the UAS 1075 MAY simply omit Remote-Party-ID's requiring privacy from the 1076 response. 1078 6.5 Proxy Behavior 1080 When a proxy supporting this extension receives an INVITE, OPTIONS, 1081 REGISTER or extension method request from a trusted entity, it does 1082 not apply any special processing until the message is forwarded to 1083 the next hop. If the message instead came from an untrusted entity, 1084 the proxy MUST do the following: 1086 First, the proxy MUST examine the message for the presence of any 1087 Remote-Party-ID headers. Since the request was received from an 1088 untrusted entity, each of these MUST be verified by the proxy. If 1089 the proxy is able to successfully verify the information in a 1090 Remote-Party-ID header field (by means outside the scope of this 1091 document), the proxy MUST add an rpi-screen parameter set to "yes" 1092 for that Remote-Party-ID. Furthermore, this MUST be the only rpi- 1093 screen parameter for that Remote-Party-ID. If verification fails 1094 however, further processing depends on the reason for the failure. 1095 Two different failure reasons are defined here: 1097 * The information provided could not be verified because the proxy 1098 does not support verification of this particular Remote-Party-ID. 1100 * The information provided is incorrect and the proxy detected that. 1102 In the first case, the proxy MUST add an rpi-screen parameter set to 1103 "no". The proxy SHOULD furthermore ensure this is the only rpi- 1104 screen parameter. In the second case, the proxy MUST by default add 1105 an rpi-screen parameter set to "no" and ensure this is the only rpi- 1106 screen parameter, however individual extensions and local procedures 1107 MAY specify a different behavior, for example rewrite or removal of 1108 the offending Remote-Party-ID header field. 1110 Second, if the proxy knows the identity of the calling party (by 1111 means outside the scope of this document), and there is no 1112 corresponding calling subscriber Remote-Party-ID header field 1113 present in the request, the proxy SHOULD include a calling 1114 subscriber Remote-Party-ID with the request in order to identify the 1115 originator of the request. The Remote-Party-ID header MUST at a 1116 minimum contain an "addr-spec" to uniquely identify the calling 1117 subscriber. The "addr-spec" SHOULD be the same string as appears in 1118 the Request-URI for incoming call attempts to that party. The 1119 Remote-Party-ID SHOULD include an rpi-pty-type set to "calling" and 1120 an rpi-id-type set to "subscriber". The rpi-screen parameter SHOULD 1121 be set to "yes". The Remote-Party-ID MAY optionally include a 1122 "display-name" which SHOULD be set to a name that the proxy has 1123 associated with the calling subscriber, e.g. the subscriber's full 1124 name. The proxy MAY include other Remote-Party-ID information as 1125 well. 1127 SIP Extensions for Caller Identity and Privacy Nov. 2001 1129 If the proxy is unable to determine the identity of the calling 1130 party, it MAY alternatively reject the request, e.g. with a 403 or 1131 407. The details of this is outside the scope of this document. 1133 If the proxy added one or more Remote-Party-ID headers to the 1134 request, the proxy MUST look for the presence of any RPID-Privacy 1135 header fields and set the rpi-privacy parameter on the Remote-Party- 1136 ID headers the proxy added accordingly (see Section 5.2). If there 1137 were no RPID-Privacy headers present, but the From header field 1138 contained the value "Anonymous" as the display-name, the proxy MUST 1139 apply "full" privacy to all Remote-Party-ID headers it added - this 1140 ensures backwards compatibility with current SIP. Note however, that 1141 the proxy does not check the validity of a display-name provided in 1142 the From header field. 1144 The proxy is now ready to forward the message. If there are no 1145 Remote-Party-ID headers requesting privacy and also no Anonymity 1146 header requesting IP address privacy, the message is simply 1147 forwarded. However, if there is a request for some kind of privacy, 1148 the proxy MUST apply the same processing as a trusted UAC would (see 1149 Section 6.2). In particular, the proxy MUST ensure that any privacy 1150 requested is provided prior to forwarding the message to an 1151 untrusted entity - refer to Section 6.2 for details. 1153 When the proxy receives a response to the INVITE, OPTIONS, REGISTER 1154 or extension method request from a trusted entity, it does not apply 1155 any special processing until the message is forwarded to the next 1156 hop. If the response instead came from an untrusted entity, and it 1157 was a non-100 response, the proxy MUST do the following: 1159 First, the proxy examines the response for the presence of any 1160 Remote-Party-ID headers and applies similar processing as it did for 1161 the request. 1163 Second, if the proxy knows the identity of the party that was 1164 reached (by means outside the scope of this document), and there is 1165 no corresponding called subscriber Remote-Party-ID header field 1166 present in the response, the proxy SHOULD include a called 1167 subscriber Remote-Party-ID with the response in order to identify 1168 the party reached. The Remote-Party-ID header MUST at a minimum 1169 contain an "addr-spec" to uniquely identify the called subscriber. 1170 The "addr-spec" SHOULD be the same string as appears in the Request- 1171 URI for incoming call attempts to that party. The Remote-Party-ID 1172 SHOULD include an rpi-pty-type set to "called" and an rpi-id-type 1173 set to "subscriber". The rpi-screen parameter SHOULD be set to 1174 "yes". The Remote-Party-ID MAY optionally include a "display-name" 1175 which SHOULD be set to a name that the proxy has associated with the 1176 called subscriber, e.g. the subscriber's full name. The proxy MAY 1177 include other Remote-Party-ID information as well. 1179 SIP Extensions for Caller Identity and Privacy Nov. 2001 1181 If the proxy is unable to determine the identity of the party 1182 reached, it SHOULD continue normal processing, and simply omit 1183 adding a called party Remote-Party-ID to the response. 1185 If the proxy added one or more Remote-Party-ID header fields to the 1186 response, the proxy MUST look for the presence of any RPID-Privacy 1187 header fields in the response and set the rpi-privacy parameter on 1188 the Remote-Party-ID headers the proxy added accordingly (see Section 1189 5.2). 1191 The proxy is now ready to forward the response. If there are no 1192 Remote-Party-ID headers requesting privacy and also no Anonymity 1193 header requesting IP address privacy, the response is simply 1194 forwarded upstream. However, if there is a request for some kind of 1195 privacy, the proxy MUST apply the same processing as a trusted UAS 1196 would (see Section 6.4). In particular, the proxy MUST ensure that 1197 any privacy requested is provided prior to forwarding the response 1198 to an untrusted entity - refer to Section 6.4 for details. Again, it 1199 should be noted, that either type of privacy request is only 1200 guaranteed to be satisfied if the previous hop is trusted and it 1201 furthermore supports the extensions defined here. If the proxy 1202 cannot guarantee both, then any privacy desired MUST be provided 1203 before the response is forwarded upstream. Alternatively, the proxy 1204 MAY simply omit Remote-Party-ID's requiring privacy from the 1205 response. 1207 6.6 Additional Proxy and Trusted User Agent Behavior 1209 A proxy or trusted UA supporting this extension SHOULD be prepared 1210 to receive a request containing a SIP-URL with a user parameter of 1211 "private". If the "hostport" part of the SIP-URL identifies the 1212 entity handling the request, the entity MUST recover the private 1213 information. For entities that use the encryption recommendation 1214 provided earlier, this implies decrypting the "user" portion of the 1215 SIP-URL and replacing it with the decrypted SIP-URL that was 1216 contained in the "user" portion as well as any other SIP information 1217 included. Note that the decrypted SIP-URL may itself contain a 1218 "private" SIP-URL. 1220 If the entity is unable to recover a "private" SIP-URL, it MUST fail 1221 the request with a 4xx error code. 1223 7 Example of Use 1225 In this Section, we illustrate how the request for privacy may work 1226 in practice. It should be noted that the privacy service described 1227 can be implemented in a number of ways; we merely describe one 1228 possible solution in this section. 1230 SIP Extensions for Caller Identity and Privacy Nov. 2001 1232 7.1 Basic Privacy Example 1234 The Figure below illustrates a basic privacy example scenario 1236 +---------+ +--------+ 1237 1: INVITE | Proxy-o | 2: INVITE | Proxy-t| 3: INVITE 1238 +------->| |------------>| |---------+ 1239 | +---------+ +--------+ | 1240 | | 1241 | trust boundary | 1242 . . |. . . . . . . . . . . . . . . . . . . . . . .. . . | . . . 1243 | | 1244 | \/ 1245 +------+ RTP/RTCP +------+ 1246 | UA-o |<------------------------------------------->| UA-t | 1247 +------+ +------+ 1249 Figure 4 - Basic Privacy Example 1251 The originating user agent (UA-o) sends an INVITE (1) to Proxy-o 1252 where it requests uri and name, i.e. full, privacy for any Remote- 1253 Party-ID headers that might be added. Since the From header field 1254 contains calling identity information, UA-o supplies a 1255 cryptographically random identifier for the user info, and the non- 1256 identifying hostname "localhost" rather than its true identity: 1258 INVITE 1259 From: sip:xyz@localhost 1260 RPID-Privacy: full 1262 Proxy-o determines the calling subscriber identity, and adds a 1263 corresponding Remote-Party-ID header to the request. The privacy 1264 setting on this header is derived from the RPID-Privacy header 1265 present in the INVITE (1) received from the UA. Since the calling 1266 subscriber Remote-Party-ID is authentic, Proxy-o also includes an 1267 rpi-screen parameter set to "yes". Proxy-o trusts Proxy-t, and hence 1268 the Remote-Party-ID can be passed in clear. However, to ensure 1269 proper privacy processing, Proxy-o adds a Proxy-Require "privacy" to 1270 the request before it sends INVITE(2) to Proxy-t: 1272 INVITE 1273 From: sip:xyz@localhost 1274 Remote-Party-ID: "John Doe" ;party=calling; 1275 id-type=subscriber;privacy=full;screen=yes 1276 Proxy-Require: privacy 1278 When Proxy-t receives the INVITE, it examines the privacy request 1279 included in the INVITE and sees that uri and name privacy is 1280 requested. Since the next hop is untrusted, Proxy-t therefore 1281 removes the "display-name" from the calling subscriber Remote-Party- 1282 ID, encrypts the "addr-spec" and rpi-privacy, puts the result in the 1283 SIP Extensions for Caller Identity and Privacy Nov. 2001 1285 "user" part, inserts itself as the "hostport" and adds a 1286 "user=private" user parameter. Also, Proxy-t removes the 1287 Proxy-Require "privacy" before sending the INVITE(3) to UA-t: 1289 INVITE 1290 From: sip:xyz@localhost 1291 Remote-Party-ID: ;privacy=full 1292 )@proxy-t.foo.com;user=private 1293 >;party=calling;id-type=subscriber; 1294 privacy=full;screen=yes 1296 UA-t notes the presence of the Remote-Party-ID, but since it 1297 indicates full privacy, UA-t can only identify the calling 1298 subscriber as private, however it knows that the subscribers 1299 identity has been verified since the rpi-screen parameter is set to 1300 "yes". UA-t decides to accept the call setup, and responds with a 1301 180 Ringing. In this case, there is no request for privacy for any 1302 Remote-Party-ID headers by upstream proxies, so a normal 180 1303 response is sent back. 1305 Proxy-t determines the identity of UA-T and adds a corresponding 1306 Remote-Party-ID as well as an rpi-screen parameter set to "yes". 1307 Since no privacy was requested, proxy-t can provide the Remote- 1308 Party-ID information to proxy-o in clear: 1310 180 1311 Remote-Party-ID: "Mary Doe" ;party=called; 1312 id-type=subscriber;screen=yes 1314 Proxy-o forwards the response to UA-o as is. 1316 While this illustrates the basic operation of the service, there are 1317 additional issues that need to be considered. In SIP, there are 1318 several fields that can reveal the identity of the calling party, 1319 either in part or completely. Other protocols used, e.g. SDP and RTP 1320 may reveal identity information as well. A user agent wishing to not 1321 reveal its identity should consider each of these. The next example 1322 looks more closely at this. 1324 7.2 Full Privacy Example 1326 The second example we look at is one where IP-address privacy is 1327 requested. The Figure below illustrates how IP address privacy can 1328 be achieved by inserting a trusted intermediary, an anonymizer, for 1329 the media streams between UA-o and UA-t. The interface between the 1330 proxies and the media anonymizer is purposely not defined here: 1332 SIP Extensions for Caller Identity and Privacy Nov. 2001 1334 +---------+ +--------+ 1335 1: INVITE | Proxy-o | 2: INVITE | Proxy-t| 3: INVITE 1336 +------->| |------------>| |----------+ 1337 | +---------+ +--------+ | 1338 | \ / | 1339 | \ / | 1340 | SIP +--------+ SIP | 1341 | +----------------->| anony- |-------------------+ | 1342 | | +------>| mizer |--------+ | | 1343 | | | +--------+ | | | 1344 | | | | | | 1345 | | | | | | 1346 | | | trust boundary | | | 1347 . . |.|. . . . . | . . . . . . . . . . . . | . . .. . |..| . . . 1348 | | | | | | 1349 | | | | \/ \/ 1350 +------+ RTP/RTCP| |RTP/RTCP +------+ 1351 | UA-o |<--------+ +-------->| UA-t | 1352 +------+ +------+ 1354 Figure 5 - Full Privacy Example 1356 For all signaling and media exchange purposes, the anonymizer adds a 1357 level of indirection thereby hiding the IP address(es) of UA-o from 1358 UA-t. This indirection is used both for the media streams and SIP 1359 signaling, beyond the initial INVITE, exchanged directly between 1360 UA-o and UA-t. 1362 In addition to the requirements listed earlier, the following 1363 commonly used header fields may reveal privacy information as well, 1364 which can be remedied as described: 1366 * A Contact header field must be set to point to the anonymizer to 1367 prevent any direct signaling between UA-o and UA-t 1368 * Via, Record-Route, Route, and any other header fields identifying 1369 either UA-o or Proxy-o must be hidden, e.g. by encryption or 1370 simple stateful removal and re-insertion by Proxy-t. 1372 An alternative to the media anonymizer function shown above is to 1373 implement the anonymizer as a back to back User Agent thereby 1374 trivially hiding IP address information in the SIP signaling itself. 1376 Furthermore, when SDP is used to describe the media in the session, 1377 the session descriptions exchanged by the user agents need to be 1378 modified to direct the media streams to the anonymizer. The use of 1379 SDP fields revealing calling identity information needs to be 1380 considered as well. Similar concerns apply to the use of RTCP. 1382 SIP Extensions for Caller Identity and Privacy Nov. 2001 1384 8. Security Considerations 1386 When a trusted entity has obtained entity information for a given 1387 party that wishes to have its identity remain private, and the 1388 trusted entity then sends a message with that party's identity in a 1389 Remote-Party-ID header, the entity MUST take precautions to protect 1390 the identity information from eavesdropping and interception. If the 1391 identity information is always encrypted, then this is trivially 1392 satisfied, however if it is not, then use of IPSec can satisfy this. 1394 Similarly, since Remote-Party-ID is used to identity the party 1395 sending a message, the hop-by-hop integrity of such messages needs 1396 to be ensured. Again, the use of IPSec can satisfy this. 1398 As noted above, Remote-Party-ID information received can only be 1399 trusted if it is received in clear-text vie a trusted entity. Also, 1400 any privacy requested can only be assumed to be honored when the 1401 request is made via a trusted entity. Thus if it is unknown whether 1402 a given request or response is sent or received via the trusted 1403 entity, Remote-Party-ID information should be considered 1404 untrustworthy, and request for privacy (including IP-address 1405 privacy) should not be assumed to be honored. 1407 9. Notice Regarding Intellectual Property Rights 1409 The IETF has been notified of intellectual property rights claimed 1410 in regard to some or all of the specification contained in this 1411 document. For more information consult the online list of claimed 1412 rights. 1414 10. References 1416 1. Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1417 9, RFC 2026, October 1996. 1419 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 1420 Levels", BCP 14, RFC 2119, March 1997 1422 3 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax 1423 Specifications: ABNF", RFC 2234, Internet Mail Consortium and 1424 Demon Internet Ltd., November 1997 1426 4 M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP: 1427 session initiation protocol," Request for Comments (Proposed 1428 Standard) 2543, Internet Engineering Task Force, Mar. 1999. 1430 11. Acknowledgments 1432 The basis of this document is the Distributed Call Signaling work in 1433 the PacketCable project, which is the work of a large number of 1434 people, representing many different companies. The authors would 1435 like to recognize and thank the following for their assistance: John 1436 Wheeler, Motorola; David Boardman, Daniel Paul, Arris Interactive; 1437 Bill Blum, Jon Fellows, Jay Strater, Jeff Ollis, Clive Holborow, 1438 Motorola; Doug Newlin, Guido Schuster, Ikhlaq Sidhu, 3Com; Jiri 1439 Matousek, Bay Networks; Farzi Khazai, Nortel; John Chapman, Bill 1440 Guckel, Michael Ramalho, Cisco; Chuck Kalmanek, Doug Nortz, John 1441 Lawser, James Cheng, Tung-Hai Hsiao, Partho Mishra, AT&T; Telcordia 1442 Technologies; and Lucent Cable Communications. Additionally, the 1443 authors would like to thank the SIP working group, and in particular 1444 the following individuals who all made significant contributions to 1445 this document: Jonathan Rosenberg, Igor Slepchin, Michael Thomas, 1446 and Dean Willis. Alan Johnston provided the "nature of party" 1447 extension in Appendix A. 1449 12. Author's Addresses 1451 Bill Marshall 1452 AT&T 1453 Florham Park, NJ 07932 1454 Email: wtm@research.att.com 1456 K. K. Ramakrishnan 1457 TeraOptic Networks 1458 Sunnyvale, CA 1459 Email: kk@teraoptic.com 1461 Ed Miller 1462 Terayon 1463 Louisville, CO 80027 1464 Email: E.Miller@terayon.com 1466 Glenn Russell 1467 CableLabs 1468 Louisville, CO 80027 1469 Email: G.Russell@Cablelabs.com 1471 Burcak Beser 1472 Pacific Broadband Communications 1473 San Jose, CA 1474 Email: Burcak@pacband.com 1476 Mike Mannette 1477 3Com 1478 Rolling Meadows, IL 60008 1479 Email: Michael-Mannette@3com.com 1480 SIP Extensions for Caller Identity and Privacy Nov. 2001 1482 Kurt Steinbrenner 1483 3Com 1484 Rolling Meadows, IL 60008 1485 Email: Kurt-Steinbrenner@3com.com 1487 Dave Oran 1488 Cisco 1489 Acton, MA 01720 1490 Email: oran@cisco.com 1492 Flemming Andreasen 1493 Cisco 1494 Edison, NJ 1495 Email: fandreas@cisco.com 1497 John Pickens 1498 Com21 1499 San Jose, CA 1500 Email: jpickens@com21.com 1502 Poornima Lalwaney 1503 Nokia 1504 San Diego, CA 92121 1505 Email: poornima.lalwaney@nokia.com 1507 Jon Fellows 1508 Motorola 1509 San Diego, CA 92121 1510 Email: jfellows@gi.com 1512 Doc Evans 1513 D. R. Evans Consulting 1514 Boulder, CO 80303 1515 Email: n7dr@arrl.net 1517 Keith Kelly 1518 NetSpeak 1519 Boca Raton, FL 33587 1520 Email: keith@netspeak.com 1522 Mark Watson 1523 Nortel Networks 1524 Maidenhead, UK 1525 Email: mwatson@nortelnetworks.com 1526 SIP Extensions for Caller Identity and Privacy Nov. 2001 1528 Appendix A: Nature of Party 1530 This document defines a new "other-rpi-token" to identity the nature 1531 of the party in the Remote-Party-id. The Remote-Party-ID Nature of 1532 Party information (rpi-np) is supplied on a "token = value" form as 1533 defined by the following grammar: 1535 rpi-np = "np" "=" ("ordinary" | "residential" | "business" | 1536 "priority" | "hotel" | "failure" | "hospital" | 1537 "prison" | "police" | "test" | "payphone" | 1538 "coin" | "payphone-public" | "payphone-private" | 1539 "coinless" | "restrict" | "coin-restrict" | 1540 "coinless-restrict" | "reserved" | "operator" | 1541 "trans-freephone" | "isdn-res" | "isdn-bus" | 1542 "unknown" | "emergency" | "not-applicable" | 1543 "cellular-ordinary" | "cellular-roaming" | token ) 1545 The rpi-np describes the nature of the party identified - additional 1546 values can be defined as extensions. Typically, this information 1547 will come from ANI information digits (II) which are used in the 1548 Public switched network in the US. Information digits are two digit 1549 codes that precede the Called Party Number and provide information 1550 to the Exchange carriers and IECs about the type of line that 1551 originated the call or any special characteristics of the Billing 1552 number. In the non-US environments, a parameter called the Calling 1553 Party Category (CPC) usually plays the role of information digits in 1554 the US and provides similar information. The rpi-np is meant to be 1555 primarily used in the PSTN to SIP direction. It is not intended to 1556 be used in the SIP to PSTN direction. Mapping to information digits 1557 towards the PSTN might invoke unintended results in the PSTN. 1559 The following example illustrates the use of the Nature of Party: 1561 Remote-Party-ID: "Mary Doe" ;party=called; 1562 id-type=subscriber;np=ordinary;screen=yes 1564 Below is the recommended mapping from II to rpi-np: 1566 00 ordinary 1567 01 not-applicable 1568 02 failure 1569 06 not-applicable 1570 07 not-applicable 1571 20 not-applicable 1572 23 not-applicable 1573 24 trans-freephone 1574 25 trans-freephone and payphone 1575 27 payphone 1576 29 prison 1577 30-32 not-applicable 1578 34 operator 1579 SIP Extensions for Caller Identity and Privacy Nov. 2001 1581 40-49 depends on the carrier's implementation 1582 52 not-applicable 1583 60 not-applicable 1584 61 cellular-ordinary 1585 62 cellular-ordinary 1586 63 cellular-roaming 1587 66 not-applicable 1588 67 not-applicable 1589 70 payphone 1590 80-89 reserved 1591 93 not-applicable 1593 Note that a particular II value could map to two different values of 1594 the rpi-np. For example, II value of 25 can map to rpi-np=trans- 1595 freephone and rpi-np=payphone. 1597 SIP Extensions for Caller Identity and Privacy Nov. 2001 1599 Appendix B: IANA Considerations 1601 The extensions defined in this document are extensible themselves. 1602 Any extensions defined shall be registered with IANA as follows: 1604 * rpi-id-type: A literal name MUST be provided. 1606 * rpi-pty-type: A literal name MUST be provided. 1608 * rpi-privacy: A new privacy indication or a new 1609 privacy postfix can be defined - each of these have a separate 1610 name space: 1612 * privacy indication: A literal name MUST be provided. 1614 * privacy postfix: 1615 A literal name MUST be provided. 1617 * other-rpi-token: A literal name, which MUST NOT start with the 1618 dash character ("-"), MUST be provided. If the extension is on the 1619 form "type = value", then a description of the permissible values 1620 SHOULD furthermore be provided. 1622 * privacy-tag: A literal name MUST be provided. 1624 Also, each extension MUST have a designated contact person. 1625 Furthermore, if such extensions are to see any widespread and/or 1626 interoperable use, they SHOULD be properly defined and described in 1627 a publicly available document. 1629 SIP Extensions for Caller Identity and Privacy Nov. 2001 1631 Full Copyright Statement 1633 "Copyright (C) The Internet Society (2001). All Rights Reserved. 1634 This document and translations of it may be copied and furnished to 1635 others, and derivative works that comment on or otherwise explain it 1636 or assist in its implementation may be prepared, copied, published 1637 and distributed, in whole or in part, without restriction of any 1638 kind, provided that the above copyright notice and this paragraph 1639 are included on all such copies and derivative works. However, this 1640 document itself may not be modified in any way, such as by removing 1641 the copyright notice or references to the Internet Society or other 1642 Internet organizations, except as needed for the purpose of 1643 developing Internet standards in which case the procedures for 1644 copyrights defined in the Internet Standards process must be 1645 followed, or as required to translate it into languages other than 1646 English. The limited permissions granted above are perpetual and 1647 will not be revoked by the Internet Society or its successors or 1648 assigns. This document and the information contained herein is 1649 provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE 1650 INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR 1651 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1652 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1653 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1655 Expiration Date This memo is filed as , and expires May 21, 2002.