idnits 2.17.1 draft-ietf-sip-ua-privacy-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 478. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 489. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 496. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 502. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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.) -- The document date (October 30, 2008) is 5650 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-11 ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) == Outdated reference: A later version (-18) exists of draft-ietf-sipping-config-framework-15 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP M. Munakata 3 Internet-Draft S. Schubert 4 Intended status: Informational T. Ohba 5 Expires: May 3, 2009 NTT 6 October 30, 2008 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 3, 2009. 36 Abstract 38 This document defines a best current practice for a user agent to 39 generate an anonymous SIP message by utilizing mechanisms such as 40 GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using 41 Relays around NAT) without the need for a privacy service defined in 42 RFC 3323. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 3 49 4. Treatment of Privacy-Sensitive Information . . . . . . . . . . 4 50 4.1. Obtaining a Functional Anonymous URI Using the GRUU 51 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 52 4.2. Obtaining a Functional Anonymous IP Address Using the 53 TURN Mechanism . . . . . . . . . . . . . . . . . . . . . . 5 54 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 55 5.1. Critical Privacy-Sensitive Information . . . . . . . . . . 6 56 5.1.1. Contact Header Field . . . . . . . . . . . . . . . . . 6 57 5.1.2. From Header Field . . . . . . . . . . . . . . . . . . 7 58 5.1.3. Via Header Field . . . . . . . . . . . . . . . . . . . 8 59 5.1.4. IP Addresses in SDP . . . . . . . . . . . . . . . . . 8 60 5.2. Non-Critical Privacy-Sensitive Information . . . . . . . . 8 61 5.2.1. Host Names in Other SIP Header Fields . . . . . . . . 8 62 5.2.2. Optional SIP Header Fields . . . . . . . . . . . . . . 8 63 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 64 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 69 Intellectual Property and Copyright Statements . . . . . . . . . . 12 71 1. Introduction 73 [RFC3323] defines a privacy mechanism for the SIP (Session Initiation 74 Protocol)[RFC3261], based on techniques available at the time of its 75 publication. This mechanism relies on the use of a separate privacy 76 service to remove privacy-sensitive information from SIP messages 77 sent by a user agent before forwarding those messages to the final 78 destination. Since then, numerous SIP extensions have been proposed 79 and standardized. Some of those enable a user agent to withhold its 80 user's identity and related information without the need for privacy 81 services, which was not possible when RFC 3323 was defined. 83 The purpose of this document is not to obsolete RFC 3323, but to 84 enhance overall privacy mechanism in SIP by allowing user agent to 85 take control of its privacy, rather than being completely dependent 86 on external privacy service. 88 The UA-driven privacy mechanism defined in this document will not 89 eliminate the need for RFC 3323 usage defined in [RFC3325] which 90 instructs privacy service to delete P-Asserted-Identity header. In 91 order to delete a P-Asserted-Identity header, a user agent needs to 92 set Privacy:id even when the user agent is utilizing this 93 specification. 95 This document defines a best current practice in which a user agent 96 controls all the privacy functions on its own utilizing SIP 97 extensions such as GRUU (Globally Routable User Agent URIs) 98 [I-D.ietf-sip-gruu] and TURN (Traversal Using Relays around NAT) 99 [I-D.ietf-behave-turn]. 101 2. Terminology 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 privacy-sensitive information: 108 The information that identifies a user who sends the SIP 109 message, as well as the supplementary information that 110 can be used to guess the user's identity. 112 3. Concept of Privacy 114 The concept of privacy in this document is the act of concealing 115 identity of a user and supplementary information. The protection of 116 network privacy (e.g., topology hiding) is outside the scope of this 117 document. 119 Privacy-sensitive information includes display-name and URI (Uniform 120 Resource Identifier) in a From header field that can reveal the 121 user's name and affiliation (e.g., company name), and IP addresses or 122 host names in a Contact header field, a Via header field, a Call-ID 123 header field, or an SDP (Session Description Protocol) [RFC4566] body 124 that might reveal the location of a user agent. 126 4. Treatment of Privacy-Sensitive Information 128 Some fields of SIP messages that potentially contain privacy- 129 sensitive information do not interfere with establishing dialog and 130 can be omitted without any side effects. Other fields are essential 131 for establishing dialog and need to have its value replaced to 132 anonymized values in order to obscure privacy-sensitive information. 133 Of the privacy-sensitive information listed in section 3, URIs, host 134 names, and IP addresses in Contact, Via, and SDP must be functional 135 (i.e., suitable for purpose) even when they are anonymized. 137 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 138 [I-D.ietf-behave-turn], a user agent can obtain URIs and IP addresses 139 for media and signaling that are functional yet anonymous, and do not 140 identify either the user agent or the user. Instructions on how to 141 obtain a functional anonymous URI and IP address are given in Section 142 4.1 and 4.2, respectively. 144 Host names should be concealed because the user's identity may be 145 guessed from them, but they are not always regarded as critical 146 privacy-sensitive information. 148 In addition, a user agent should be careful not to include any 149 information that identifies the user in optional SIP header fields 150 such as Subject and User-Agent. 152 4.1. Obtaining a Functional Anonymous URI Using the GRUU Mechanism 154 A user agent wanting to obtain a functional anonymous URI MUST 155 support and utilize the GRUU mechanism unless it is able to obtain a 156 functional anonymous URI through other means outside the scope of 157 this document. By sending a REGISTER request requesting GRUU, the 158 user agent can obtain an anonymous URI, which can later be used for 159 the Contact header field. 161 The detailed process on how a user agent obtains a GRUU is described 162 in [I-D.ietf-sip-gruu]. 164 If the Registrar supports the GRUU and returns a REGISTER response, 165 the user agent SHOULD search within the REGISTER response for a 166 "temp-gruu" URI parameter, which provides the desired privacy 167 property. If the "temp-gruu" URI parameter and value is present 168 within the REGISTER response, the user agent SHOULD use the value of 169 the "temp-gruu" as an anonymous URI representing the user agent. 170 This URI SHOULD be used for the Contact header in subsequent requests 171 and responses. 173 If there is no "temp-gruu" URI parameter in the 200 response to the 174 REGISTER request, a user agent SHOULD NOT proceed with its 175 anonymization process, unless something equivalent to "temp-gruu" is 176 provided through some administrative means. 178 It is RECOMMENDED that user agent consult the user before sending a 179 request without a functional anonymous URI when privacy is requested 180 from the user. 182 Due to the nature of how GRUU works, the domain name is always 183 revealed when GRUU is used. If revealing the domain name in Contact 184 header field is a concern, usage of a third-party GRUU server to 185 obtain a temp-gruu that is irrelevant to users' domain SHOULD be 186 considered. Refer to the Security Considerations section for 187 details. 189 4.2. Obtaining a Functional Anonymous IP Address Using the TURN 190 Mechanism 192 A user agent that is not provided with a functional anonymous IP 193 address through some administrative means, MUST obtain a relayed 194 address if anonymity is desired (IP address of the media relay) for 195 use in SDP and in Via header. Such IP address is to be derived from 196 a STUN relay server through TURN mechanism, which allows a STUN 197 server to act as a media relay. 199 Anonymous IP addresses are needed for two purposes. The first is for 200 use in the Via header field of a SIP request. By obtaining an IP 201 address from a STUN relay server, using that address in the Via 202 header field of the SIP request, and sending the SIP request to the 203 STUN relay server, the IP address of the user agent will not be 204 revealed beyond the relay server. 206 The second is for use in SDP as an address for receiving media. By 207 obtaining an IP address from a STUN relay server and using that 208 address in SDP, media will be received via the relay server. Also 209 media can be sent via the relay server. In this way, neither SDP nor 210 media packets reveal the IP address of the user agent. 212 It is assumed that a user agent is either manually or automatically 213 configured through means such as the configuration framework 214 [I-D.ietf-sipping-config-framework] with the address of one or more 215 STUN (Session Traversal Utilities for NAT) [I-D.ietf-behave-turn] 216 relay servers to obtain anonymous IP address. 218 5. User Agent Behavior 220 This section describes how to generate an anonymous SIP message at a 221 user agent. 223 A user agent fully compliant with this document MUST obscure or 224 conceal all the critical UA-inserted privacy-sensitive information in 225 SIP requests and responses as shown in Section 5.1 when user privacy 226 is requested. In addition, the user agent SHOULD conceal the non- 227 critical privacy-sensitive information as shown in Section 5.2. 229 Furthermore, when a user agent uses relay server to conceal its 230 identity, the user agent MUST send requests to the relay server to 231 ensure request and response bypass the same signaling path. 233 5.1. Critical Privacy-Sensitive Information 235 5.1.1. Contact Header Field 237 Without privacy considerations, this field contains a URI used to 238 reach the user agent for mid-dialog requests and possibly out-of- 239 dialog requests, such as REFER [RFC3515]. The Contact header field 240 can also contain a display-name. Since the Contact header field is 241 used for routing further requests to the user agent, it must include 242 a functional URI even when it is anonymized. 244 A user agent generating an anonymous SIP message supporting this 245 specification MUST anonymize a Contact header using an anonymous URI 246 ("temp-gruu") obtained through the GRUU mechanism or an anonymous URI 247 containing an IP address obtained through the TURN mechanism, unless 248 an equivalent functional anonymous URI is provided by some other 249 means. 251 Refer to Section 4.1 for details on how to obtain an anonymous URI 252 through GRUU, and refer to Section 4.2 for details on how to obtain 253 an IP address through TURN. 255 A display-name in a Contact header MUST be omitted or "Anonymous". 257 5.1.2. From Header Field 259 Without privacy considerations, this field contains the identity of 260 the user, such as display-name and URI. 262 RFCs 3261 and 3323 recommend to set "sip:anonymous@anonymous.invalid" 263 as a SIP URI in a From header field when user privacy is requested. 264 This raises an issue when the SIP-Identity mechanism [RFC4474] is 265 applied to the message, because SIP-Identity requires an actual 266 domain name in the From header field. 268 A user agent generating an anonymous SIP message supporting this 269 specification MUST anonymize the From header field in one of the two 270 ways described below. 272 Option 1: 274 A user agent anonymizes a From header field using an anonymous 275 display-name and an anonymous URI following the procedure noted in 276 section 4.1.1.3 of RFC 3323. 278 The example form of the From header of option 1 is as follows: 280 From: "Anonymous" ;tag=1928301774 282 Option 2: 284 A user agent anonymizes a From header field using an anonymous 285 display-name and an anonymous URI with user's valid domain name 286 instead of "anonymous.invalid". 288 The example form of the From header of option 2 is as follows: 290 From: "Anonymous" ;tag=1928301774 292 A user agent SHOULD go with option 1 to conceal its domain name in 293 From header field. However, the SIP-Identity will fail with the From 294 header of option 1 because the SIP-Identity mechanism uses 295 authentication based on the domain name. 297 If a user agent is aware that SIP-Identity mechanism will be applied 298 to the request, it is RECOMMENDED to go with option 2. However, the 299 user's domain name will be revealed from the From header field of 300 option 2. 302 If user wants both anonymity and strong identity, use a third party 303 anonymization service which issues AoR for the use in From address 304 which also provides SIP-Identity. 306 5.1.3. Via Header Field 308 Without privacy considerations, the bottommost Via header field added 309 by a user agent contains the IP address and port or hostname that are 310 used to reach the user agent for responses. 312 A user agent generating an anonymous SIP request supporting this 313 specification MUST anonymize the IP address in the Via header field 314 using an anonymous IP address obtained through the TURN mechanism, 315 unless an equivalent functional anonymous IP address is provided by 316 some other means. 318 Refer to Section 4.2 for details on how to obtain an IP address 319 through TURN. 321 Via header SHOULD NOT include a host name. 323 5.1.4. IP Addresses in SDP 325 A user agent generating an anonymous SIP message supporting this 326 specification MUST anonymize IP addresses in SDP, if present, using 327 an anonymous IP address obtained through the TURN mechanism, unless 328 an equivalent functional anonymous IP address is provided by some 329 other means. 331 Refer to Section 4.2 for details on how to obtain an IP address 332 through TURN. 334 5.2. Non-Critical Privacy-Sensitive Information 336 5.2.1. Host Names in Other SIP Header Fields 338 A user agent generating an anonymous SIP message supporting this 339 specification SHOULD conceal host names in any SIP header fields, 340 such as Call-ID and Warning header fields, if considered privacy- 341 sensitive. 343 5.2.2. Optional SIP Header Fields 345 Other optional SIP header fields (such as Call-Info, In-Reply-To, 346 Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and 347 Warning) can contain privacy-sensitive information. 349 A user agent generating an anonymous SIP message supporting this 350 specification SHOULD NOT include any information that identifies the 351 user in such optional header fields. 353 6. Security Considerations 355 This specification uses GRUU and TURN and inherits any security 356 considerations described in these drafts. 358 Furthermore, if the provider of the caller intending to obscure its 359 identity consists of a small number of people (e.g. small enterprise, 360 SOHO), the domain name alone can reveal the identity of the caller 361 when this specification is used. 363 Same can be true when the provider is large, but the receiver of the 364 call only knows few people from the source of call. 366 There are mainly two places in the message, From header and Contact 367 header, where domain name must be functional. 369 The domain name in From header can be obscured as described in 370 section 5.1.2, on contrary the Contact header needs to contain a 371 valid domain name at all time to function properly. 373 It is probably important to note that generally a device will not 374 show the contact address to the receiver, but this does not mean that 375 one can not find the domain name in a message. In fact as long as 376 this specification is used to obscure identity, the message will 377 always contain a valid domain name as it inherits key characteristics 378 of GRUU. 380 If one wants to assure anonymization, it is recommended for the user 381 to seek and rely on third party anonymization service. 383 A third party anonymization service provides registrar and TURN 384 service which has no affiliation with the caller's provider, allowing 385 caller to completely withhold its identity. 387 7. IANA Considerations 389 This document requires no action by IANA. 391 8. References 393 8.1. Normative References 395 [I-D.ietf-behave-turn] 396 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 397 Relays around NAT (TURN): Relay Extensions to Session 398 Traversal Utilities for NAT (STUN)", 399 draft-ietf-behave-turn-11 (work in progress), 400 October 2008. 402 [I-D.ietf-sip-gruu] 403 Rosenberg, J., "Obtaining and Using Globally Routable User 404 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 405 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 406 October 2007. 408 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 409 Requirement Levels", BCP 14, RFC 2119, March 1997. 411 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 412 A., Peterson, J., Sparks, R., Handley, M., and E. 413 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 414 June 2002. 416 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 417 Description Protocol", RFC 4566, July 2006. 419 8.2. Informative References 421 [I-D.ietf-sipping-config-framework] 422 Channabasappa, S., "A Framework for Session Initiation 423 Protocol User Agent Profile Delivery", 424 draft-ietf-sipping-config-framework-15 (work in progress), 425 February 2008. 427 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 428 Initiation Protocol (SIP)", RFC 3323, November 2002. 430 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 431 Extensions to the Session Initiation Protocol (SIP) for 432 Asserted Identity within Trusted Networks", RFC 3325, 433 November 2002. 435 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 436 Method", RFC 3515, April 2003. 438 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 439 Authenticated Identity Management in the Session 440 Initiation Protocol (SIP)", RFC 4474, August 2006. 442 Authors' Addresses 444 Mayumi Munakata 445 NTT Corporation 447 Email: munakata.mayumi@lab.ntt.co.jp 449 Shida Schubert 450 NTT Corporation 452 Email: shida@ntt-at.com 454 Takumi Ohba 455 NTT Corporation 456 9-11, Midori-cho 3-Chome 457 Musashino-shi, Tokyo 180-8585 458 Japan 460 Phone: +81 422 59 7748 461 Email: ohba.takumi@lab.ntt.co.jp 462 URI: http://www.ntt.co.jp 464 Full Copyright Statement 466 Copyright (C) The IETF Trust (2008). 468 This document is subject to the rights, licenses and restrictions 469 contained in BCP 78, and except as set forth therein, the authors 470 retain all their rights. 472 This document and the information contained herein are provided on an 473 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 474 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 475 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 476 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 477 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 478 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 480 Intellectual Property 482 The IETF takes no position regarding the validity or scope of any 483 Intellectual Property Rights or other rights that might be claimed to 484 pertain to the implementation or use of the technology described in 485 this document or the extent to which any license under such rights 486 might or might not be available; nor does it represent that it has 487 made any independent effort to identify any such rights. Information 488 on the procedures with respect to rights in RFC documents can be 489 found in BCP 78 and BCP 79. 491 Copies of IPR disclosures made to the IETF Secretariat and any 492 assurances of licenses to be made available, or the result of an 493 attempt made to obtain a general license or permission for the use of 494 such proprietary rights by implementers or users of this 495 specification can be obtained from the IETF on-line IPR repository at 496 http://www.ietf.org/ipr. 498 The IETF invites any interested party to bring to its attention any 499 copyrights, patents or patent applications, or other proprietary 500 rights that may cover technology that may be required to implement 501 this standard. Please address the information to the IETF at 502 ietf-ipr@ietf.org.