idnits 2.17.1 draft-ietf-sip-ua-privacy-02.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 406. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 417. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 430. 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 (July 14, 2008) is 5737 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-09 ** 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: January 15, 2009 NTT 6 July 14, 2008 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-02 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 January 15, 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 and TURN without the need for a privacy service defined in RFC 41 3323. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 46 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 3 48 4. Treatment of Privacy-Sensitive Information . . . . . . . . . . 4 49 4.1. Obtaining Functional Anonymous URI Using GRUU Mechanism . 4 50 4.2. Obtaining Functional Anonymous IP Address Using TURN 51 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 5 52 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 5 53 5.1. Essential Privacy-Sensitive Information . . . . . . . . . 5 54 5.1.1. Contact . . . . . . . . . . . . . . . . . . . . . . . 5 55 5.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5.1.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.1.4. IP addresses in SDP . . . . . . . . . . . . . . . . . 7 58 5.2. Non-Essential Privacy-Sensitive Information . . . . . . . 7 59 5.2.1. Host Names in Other SIP Headers . . . . . . . . . . . 7 60 5.2.2. Optional SIP Headers . . . . . . . . . . . . . . . . . 7 61 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 [RFC3323] defines a privacy mechanism for the Session Initiation 72 Protocol (SIP) [RFC3261], based on techniques available at the time 73 of its publication. This mechanism relies on the use of a separate 74 privacy service to remove sensitive information from SIP messages 75 sent by a user agent before forwarding those messages to the final 76 destination. Since then, numerous SIP extensions have been proposed 77 and standardized. Some of those enable a user agent to withhold its 78 user's identity and related information without the need for privacy 79 services, which was not possible when RFC 3323 was defined. 81 This document defines a best current practice in which a user agent 82 controls all the privacy functions on its own utilizing SIP 83 extensions such as GRUU (Globally Routable User Agent URIs) 84 [I-D.ietf-sip-gruu] and TURN (Traversal Using Relay NAT) 85 [I-D.ietf-behave-turn]. 87 2. Terminology 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 privacy-sensitive information: 94 The information that identifies a user who sends the SIP 95 message, as well as the supplementary information that 96 can be used to guess the user's identity. 98 3. Concept of Privacy 100 The concept of privacy in this document is the act of concealing 101 identity of a user and supplementary information. The scope of this 102 document is to withhold the privacy-sensitive information of the user 103 who sends the SIP message from other users and intermediaries 104 handling the message. The protection of network privacy (e.g., 105 topology hiding) is outside the scope of this document. 107 Privacy-sensitive information includes display-name and URI (Uniform 108 Resource Identifier) in a From header that can reveal the user's name 109 and affiliation (e.g., company name), contact information in a 110 Contact header that is used to communicate with the user agent, IP 111 addresses in Via header and SDP (Session Description Protocol) 112 [RFC4566] that tell the location of a user agent. A host name that 113 appears in headers such as Call-ID is also regarded as privacy- 114 sensitive information because it may reveal the user's domain name. 116 4. Treatment of Privacy-Sensitive Information 118 The two pieces of information that a user agent needs to obscure 119 while sustaining its purpose and functionality are the URI and IP 120 address used for establishing a media/signaling session. 122 Essential privacy-sensitive information in a UA-generated SIP message 123 includes display-names (in From and Contact), as well as URIs (in 124 From and Contact) and IP addresses (in Contact, Via, and SDP). Among 125 these, URIs and IP addresses in Contact, Via, and SDP must be 126 functional even when they are anonymized. 128 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 129 [I-D.ietf-behave-turn], a user agent can obtain URI and IP address 130 for media and signaling that are functional yet anonymous, and do not 131 identify the user agent nor the user. Instructions on how to obtain 132 a functional anonymous URI and IP address are given in Section 4.1 133 and 4.2, respectively. 135 Host names should be concealed because the user's identity may be 136 guessed from them but they are not always regarded as essential 137 privacy-sensitive information. 139 In addition, a user agent should be careful not to include any 140 information that identifies the user in optional SIP headers such as 141 Subject and User-Agent. 143 4.1. Obtaining Functional Anonymous URI Using GRUU Mechanism 145 A user agent wanting to obtain functional anonymous URI MUST support 146 and SHOULD utilize the GRUU mechanism unless the user agent obtains 147 functional anonymous URI through other means outside the scope of 148 this document. By sending a REGISTER request requesting GRUU, the 149 user agent can obtain an anonymous URI, which can later be used for 150 Contact header. 152 The detailed process on how a user agent obtains a GRUU is described 153 in [I-D.ietf-sip-gruu]. 155 If the Registrar supports the GRUU and returns a REGISTER response, 156 the user agent SHOULD search within the REGISTER response for a 157 "temp-gruu" URI parameter, which provides the desired privacy 158 property. 160 If the "temp-gruu" URI parameter and value exist within the REGISTER 161 response, the user agent SHOULD use the value of the "temp-gruu" as 162 an anonymous URI representing the user agent. This URI SHOULD be 163 used for Contact header. 165 If there is no "temp-gruu" URI parameter in the 200 response to the 166 REGISTER request, a user agent SHOULD NOT proceed with its 167 anonymization process, unless something equivalent to "temp-gruu" is 168 provided through some administrative means. 170 It is RECOMMENDED that user agent consult the user before sending a 171 request without a functional anonymous URI when privacy is requested 172 from the user. 174 4.2. Obtaining Functional Anonymous IP Address Using TURN Mechanism 176 It is assumed that a user agent is either manually or automatically 177 configured through means such as a configuration framework 178 [I-D.ietf-sipping-config-framework] with the address of one or more 179 STUN (Session Traversal Utilities for NAT) 180 [I-D.ietf-behave-turn]relay servers. 182 Anonymous IP addresses are needed in two places to maintain privacy, 183 one to be used in signaling such as in a Via header, another to be 184 used in SDP for media. 186 A user agent that is not provided with a functional anonymous IP 187 address through some administrative means, MUST obtain a relayed 188 address if anonymity is desired (IP address of the media relay) for 189 use in SDP and in Via header. Such IP address is to be derived from 190 a STUN relay server through TURN mechanism, which allows a STUN 191 server to act as a media relay. 193 5. User Agent Behavior 195 This section describes how to generate an anonymous SIP message at a 196 user agent. 198 A user agent fully compliant with this document MUST obscure or 199 conceal all the essential UA-inserted privacy-sensitive information 200 in SIP requests and responses as shown in Section 5.1 when user 201 privacy is requested. In addition, the user agent SHOULD conceal the 202 non-essential privacy-sensitive information as shown in Section 5.2. 204 5.1. Essential Privacy-Sensitive Information 206 5.1.1. Contact 208 Without privacy considerations, this field contains a URI or an IP 209 address used to reach the user agent for mid-dialog requests and 210 possibly out-of-dialog requests, such as REFER [RFC3515]. The 211 Contact header can also contain a display-name. Since the Contact 212 header is essential for routing further requests to the user agent, 213 it must include a functional URI of IP address even when it is 214 anonymized. 216 A user agent generating an anonymous SIP message supporting this 217 specification MUST anonymize a Contact header using an anonymous URI 218 ("temp-gruu") through GRUU mechanism or an anonymous IP address 219 through TURN mechanism unless an equivalent functional anonymous URI 220 or IP address is provided by some other means. 222 Refer to Section 4.1 for details on how to obtain an anonymous URI 223 through GRUU, and refer to Section 4.2 for details on how to obtain 224 an IP address through TURN. 226 A display-name in a Contact header MUST be omitted or "Anonymous". 228 5.1.2. From 230 Without privacy considerations, this field contains the identity of 231 the user, such as display-name and URI. 233 RFCs 3261 and 3323 recommend to set "sip:anonymous@anonymous.invalid" 234 as a SIP URI in a From header when user privacy is requested. This 235 raises issues, when the mechanism of SIP-Identity [RFC4474] is 236 applied to the message because the SIP-Identity requires an actual 237 domain name in a From header. 239 A user agent generating an anonymous SIP message supporting this 240 specification MUST anonymize a From header in an either way described 241 below. 243 A user agent SHOULD anonymize a From header using an anonymous 244 display-name and an anonymous URI following the procedure noted in 245 section 4.1.1.3 of RFC 3261 unless it is aware that SIP-Identity 246 mechanism will be applied to the request. 248 The recommended form of the From header is: 250 From: "Anonymous" ;tag=1928301774 252 If a user agent is aware that the SIP-Identity mechanism will be 253 applied to the request, it SHOULD include valid hostname instead of 254 "anonymous.invalid" for a URI in a From header as follows. 256 From: "Anonymous" ;tag=1928301774 258 5.1.3. Via 260 Without privacy considerations, the bottommost Via header added by a 261 user agent contains the IP address and port or hostname that are used 262 to reach the user agent for responses. 264 A user agent generating an anonymous SIP message supporting this 265 specification MUST anonymize an IP address in a Via header, if 266 present, using an anonymous IP address through TURN mechanism unless 267 an equivalent functional anonymous IP address is provided by some 268 other means. 270 Refer to Section 4.2 for details on how to obtain an IP address 271 through TURN. 273 Via header SHOULD NOT include a host name, but it is not essential. 275 5.1.4. IP addresses in SDP 277 A user agent generating an anonymous SIP message supporting this 278 specification MUST anonymize IP addresses in SDP, if present, using 279 an anonymous IP address through TURN mechanism unless an equivalent 280 functional anonymous IP address is provided by some other means. 282 Refer to Section 4.2 for details on how to obtain an IP address 283 through TURN. 285 5.2. Non-Essential Privacy-Sensitive Information 287 5.2.1. Host Names in Other SIP Headers 289 A user agent generating an anonymous SIP message supporting this 290 specification SHOULD conceal host names in any SIP headers, such as 291 Call-ID and Warning headers, but it is not always regarded as 292 essential privacy-sensitive information. 294 5.2.2. Optional SIP Headers 296 Other optional SIP headers (such as Calll-Info, In-Reply-To, 297 Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and 298 Warning) can contain privacy-sensitive information. 300 A user agent generating an anonymous SIP message supporting this 301 specification SHOULD NOT include any information that identifies the 302 user in such optional headers. 304 6. Security Considerations 306 Many of the security considerations in either [RFC3323] and [RFC3325] 307 remains valid even with the use of this specification but this 308 specification does not introduce any new security consideration. 310 In fact, this specification alleviates the security consideration 311 described in RFC 3323 by providing a privacy mechanism which is 312 executed at the user agent rather than being dependent on the network 313 , as a result providing the user agent with certainty that crucial 314 privacy sensitive information are concealed. 316 7. IANA Considerations 318 This document requires no action by IANA. 320 8. References 322 8.1. Normative References 324 [I-D.ietf-behave-turn] 325 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 326 Relays around NAT (TURN): Relay Extensions to Session 327 Traversal Utilities for NAT (STUN)", 328 draft-ietf-behave-turn-09 (work in progress), July 2008. 330 [I-D.ietf-sip-gruu] 331 Rosenberg, J., "Obtaining and Using Globally Routable User 332 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 333 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 334 October 2007. 336 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 337 Requirement Levels", BCP 14, RFC 2119, March 1997. 339 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 340 A., Peterson, J., Sparks, R., Handley, M., and E. 341 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 342 June 2002. 344 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 345 Description Protocol", RFC 4566, July 2006. 347 8.2. Informative References 349 [I-D.ietf-sipping-config-framework] 350 Channabasappa, S., "A Framework for Session Initiation 351 Protocol User Agent Profile Delivery", 352 draft-ietf-sipping-config-framework-15 (work in progress), 353 February 2008. 355 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 356 Initiation Protocol (SIP)", RFC 3323, November 2002. 358 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 359 Extensions to the Session Initiation Protocol (SIP) for 360 Asserted Identity within Trusted Networks", RFC 3325, 361 November 2002. 363 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 364 Method", RFC 3515, April 2003. 366 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 367 Authenticated Identity Management in the Session 368 Initiation Protocol (SIP)", RFC 4474, August 2006. 370 Authors' Addresses 372 Mayumi Munakata 373 NTT Corporation 375 Email: munakata.mayumi@lab.ntt.co.jp 377 Shida Schubert 378 NTT Corporation 380 Email: shida@ntt-at.com 382 Takumi Ohba 383 NTT Corporation 384 9-11, Midori-cho 3-Chome 385 Musashino-shi, Tokyo 180-8585 386 Japan 388 Phone: +81 422 59 7748 389 Email: ohba.takumi@lab.ntt.co.jp 390 URI: http://www.ntt.co.jp 392 Full Copyright Statement 394 Copyright (C) The IETF Trust (2008). 396 This document is subject to the rights, licenses and restrictions 397 contained in BCP 78, and except as set forth therein, the authors 398 retain all their rights. 400 This document and the information contained herein are provided on an 401 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 402 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 403 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 404 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 405 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 406 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 408 Intellectual Property 410 The IETF takes no position regarding the validity or scope of any 411 Intellectual Property Rights or other rights that might be claimed to 412 pertain to the implementation or use of the technology described in 413 this document or the extent to which any license under such rights 414 might or might not be available; nor does it represent that it has 415 made any independent effort to identify any such rights. Information 416 on the procedures with respect to rights in RFC documents can be 417 found in BCP 78 and BCP 79. 419 Copies of IPR disclosures made to the IETF Secretariat and any 420 assurances of licenses to be made available, or the result of an 421 attempt made to obtain a general license or permission for the use of 422 such proprietary rights by implementers or users of this 423 specification can be obtained from the IETF on-line IPR repository at 424 http://www.ietf.org/ipr. 426 The IETF invites any interested party to bring to its attention any 427 copyrights, patents or patent applications, or other proprietary 428 rights that may cover technology that may be required to implement 429 this standard. Please address the information to the IETF at 430 ietf-ipr@ietf.org.