idnits 2.17.1 draft-ietf-sip-ua-privacy-00.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 400. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 411. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 418. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 424. 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 (November 12, 2007) is 6003 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Normative reference to a draft: ref. 'I-D.rosenberg-midcom-turn' -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 9 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: Standards Track T. Ohba 5 Expires: May 15, 2008 NTT 6 November 12, 2007 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-00 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 15, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 To withhold a user's identity and related information, RFC 3323 43 defines a Privacy mechanism for SIP, which requires the use of an 44 privacy service. This document proposes a new privacy mechanism that 45 a user agent can facilitate to conceal privacy-sensitive information 46 without the need for aid from a privacy service. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 4 53 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 6. Treatment of User Privacy Related Information . . . . . . . . 5 56 6.1. Anonymous URI . . . . . . . . . . . . . . . . . . . . . . 6 57 6.2. Anonymous IP Address . . . . . . . . . . . . . . . . . . . 6 58 7. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 59 7.1. Generating Anonymous Message . . . . . . . . . . . . . . . 7 60 7.2. Indication to maintain Privacy . . . . . . . . . . . . . . 7 61 8. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8 63 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 65 11.1. Normative References . . . . . . . . . . . . . . . . . . . 8 66 11.2. Informative References . . . . . . . . . . . . . . . . . . 9 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 68 Intellectual Property and Copyright Statements . . . . . . . . . . 10 70 1. Introduction 72 Privacy is defined in this document as the withholding of the 73 identity of a person (and related personal information) from 74 destination(s) of messages and/or intermediaries handling these 75 messages in a SIP (Session Initiation Protocol) [RFC3261] dialog. 77 In SIP, identity is most commonly carried in the form of a SIP URI 78 and an optional display name, which commonly appear in the To, From 79 and other header fields of SIP requests and responses. 81 There are numerous other places in SIP messages in which identity- 82 related information can be revealed. For example, the Contact header 83 field contains a SIP URI. Moreover, information in the Record-Route 84 and Via headers could inadvertently reveal something about the 85 originator of a message. 87 To provide privacy, [RFC3323] defines a privacy mechanism for SIP, 88 which was then the best current practice to maintain privacy. Since 89 then, numerous SIP extensions have been proposed and standardized. 90 Some of those seem to enable a user agent to withhold its user's 91 identity and related information without dependency on privacy 92 services, which was not possible when RFC3323 was defined. 94 Some aspect of RFC 3323, especially its dependency on a privacy 95 service to provide privacy, seems to cause some issues, which we hope 96 that we can resolve with this specification. 98 Some of the issues identified with the RFC 3323 are shown below. 100 1. There is no assurance that a privacy service exists in the 101 signaling path. 103 2. There is no way that the user requesting the privacy can figure 104 out that the privacy function was properly executed. 106 3. A privacy service that modifies a Call-ID in the establishment of 107 the original dialog must be in the signaling path of the 108 subsequent request such as REFER. If a privacy service 109 anonymizes a Call-ID and the anonymized Call-ID is referenced in 110 a subsequent SIP message for the purpose of a call-back or a call 111 replacement, the privacy service needs to be in a signaling path 112 to replace the anonymized Call-ID with the original Call-ID 113 appropriately, regardless of being inside/outside the dialog. 115 4. To map the referenced dialog to a dialog attempt invoked by 116 REFER, for example, the privacy service needs to retain the 117 correspondence relation between original information and modified 118 information beyond the actual dialog duration of the referenced 119 dialog. 121 To solve the problems, this document proposes a new privacy mechanism 122 in which a user agent executes all the privacy functions on its own 123 utilizing SIP extensions such as GRUU (Globally Routable User Agent 124 URIs)[I-D.ietf-sip-gruu] and TURN (Traversal Using Relay 125 NAT)[I-D.rosenberg-midcom-turn]. 127 2. Terminology 129 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 130 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 131 document are to be interpreted as described in [RFC2119]. 133 3. Concept of Privacy 135 The concept of privacy in this document means the concealing of 136 information that relates to a user, identifies a user, and belongs to 137 a user, as well as the supplementary information that can be used to 138 guess the user's identity. The scope of this document is to withhold 139 the identity of a user and supplementary information from other users 140 and intermediaries handling the message. The protection of network 141 privacy (e.g., topology hiding) is outside the scope of this 142 document. 144 User-privacy-related information includes display name and URI in a 145 From header that can reveal the user's name and affiliation (e.g., 146 company name), contact information in a Contact header that is used 147 to communicate with the user, an IP address in an SDP (Session 148 Description Protocol)[RFC4566] that tells the location of a user's 149 terminal and can be used to establish a connection. A host name in 150 Call-ID is also regarded as user-privacy-related information because 151 it may reveal the user's domain name. 153 Privacy-sensitive information is divided into two types, user- 154 inserted information and network-inserted information. A user agent 155 can maintain privacy of the user-inserted information by itself. On 156 the other hand, regarding the network-inserted information, a user 157 agent can insert a privacy flag and request intermediaries not to add 158 the user-privacy-related information. 160 4. Use Cases 162 The following are the use cases from the viewpoint of privacy. 164 Case 1: User privacy is required and a user agent can anonymize all 165 of the user-inserted privacy-related information by itself. 167 Case 2: User privacy is required but a user agent cannot anonymize 168 the user-inserted privacy-related information all by itself. 170 Case 3: User privacy is not required. The user does not want 171 privacy at all and would like to reveal his/her identity. 173 Note that Case 2 is based on the premise that the user agent has 174 limited capabilities and it cannot find a GRUU or TURN server. Case 175 2 is outside the scope of this document. 177 5. Requirements 179 The following are requirements to cover the use cases in the previous 180 section. 182 Req 1: A user agent MUST be able to send a SIP request that is fully 183 anonymized. This is, any headers and body inserted by the UA 184 does not jeopardize user privacy. 186 Req 2: It MUST be possible for a user agent to indicate to 187 downstream entities that a user is requesting privacy. 189 Req 3: When privacy is requested, a proxy SHOULD honor the request 190 and only add information necessary to route the call while 191 withholding any sensitive information that may reveal 192 anything about the user if possible. 194 Req 4: Mechanism defined here MUST be backward compatible with the 195 pre-existing privacy mechanism already in place. 197 6. Treatment of User Privacy Related Information 199 RFC 3323 does not provide means to obscure two important pieces of 200 information about the user agent, which are a URI used to exchange 201 signaling (Contact, From, for example), and an IP address used to 202 exchange media. 204 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 205 [I-D.rosenberg-midcom-turn], UA can now obtain URI and IP address 206 that are functional, which are usable to exchange either signaling or 207 media while providing privacy. 209 6.1. Anonymous URI 211 A user agent wanting to obtain functional anonymous URI SHOULD 212 support and SHOULD utilize the Global Routable User Agent URI (GRUU) 213 mechanism. By sending a REGISTER request requesting GRUU, the UA can 214 obtain an anonymous URI, which can later be used for From, Contact 215 and other headers where the URI of the originator is needed. 217 The detailed process on how a user agent obtains a GRUU is described 218 in [I-D.ietf-sip-gruu]. If the Registrar supports GRUU and returns a 219 REGISTER response, the user agent SHOULD search within the REGISTER 220 response for a "temp-gruu" URI parameter, which provides the desired 221 privacy property. 223 If the "temp-gruu" URI parameter and value exist within the REGISTER 224 response, the user agent SHOULD use the value of the "temp-gruu" as 225 an anonymous URI representing the originator. This URI SHOULD be 226 used for Contact and From, for example, wherever the originator of 227 the URI is required. 229 The user agent setting the "temp-gruu" as a GRUU SHOULD set 230 "Anonymous" as a display name in any header where the display name of 231 the originator is set. That indicates the anonymity of the request 232 to intermediaries that may invoke some services based on the 233 anonymity of the call. The temp-gruu alone is not sufficient to 234 invoke such service because GRUU is merely a URI that is a sequence 235 of strings and digits with no explicit semantics to indicate that it 236 is an anonymous URI. 238 If there is no "temp-gruu" URI parameter in the 200 response to the 239 REGISTER request, a user agent SHOULD NOT proceed with its 240 anonymization process, unless something equivalent to "temp-gruu" is 241 provided through some administrative means. 243 It is RECOMMENDED that user agent consult the user before sending a 244 request without a functional anonymous URI when privacy is request 245 from the user. 247 6.2. Anonymous IP Address 249 It is assumed that a user agent is either manually or automatically 250 configured through means such as a configuration framework with one 251 or more STUN relay servers. 253 Two IP addresses are needed to maintain privacy, one to be used in 254 signaling such as in a Via header, another to be used in SDP for 255 media. 257 A user agent that is not provided with a functional anonymous IP 258 address through some administrative means, SHOULD obtain a relayed 259 address (IP address of the media relay) for use in SDP, derived from 260 a STUN relay server using the STUN Relay 261 Usage[I-D.rosenberg-midcom-turn], which allows a STUN server to act 262 as a media relay. 264 Note: A relayed IP address may be used for a Via header, but some 265 commented that is not an appropriate to be used for signaling. 266 There was a comment about the IP address in Via being stripped 267 by the proxy, but that would require that a proxy compliant to 268 this specification is in the signaling path. 270 7. User Agent Behavior 272 A user agent fully compliant with this document SHOULD obscure or 273 conceal all the user-inserted privacy-related information in SIP 274 requests and responses when user privacy is requested. Section 7.1 275 describes how to generate an anonymous message at a user agent. 277 When a user agent generates an anonymous message based on this 278 specification, it SHOULD set an indication to tell intermediaries not 279 to add or modify user-privacy-related information. Section 7.2 280 describes more about this. 282 7.1. Generating Anonymous Message 284 The two pieces of information that a user agent needs to obscure 285 while sustaining its purpose and functionality are the URI and IP 286 address used for establishing a media/signaling session. 287 Instructions on how to obtain an functional anonymous URI and IP 288 address are given in Section 6.1 and 6.2, respectively. 290 For anonymizing any headers and information in a SIP message, the 291 user agent SHOULD follow the instructions in this document. 293 Note: Instructions to treat each SIP header/parameter in generating 294 an anonymous SIP message SIP message will be given in a future. 296 7.2. Indication to maintain Privacy 298 This document defines a privacy flag, which indicates that the user 299 requires privacy for the SIP message. Without a privacy flag, 300 intermediaries might add some user-privacy-related information in the 301 message, even if a user agent had anonymized the message as perfectly 302 as possible. 304 When a user agent generates an anonymous message by itself according 305 to the guidelines in Section 7.1, it SHOULD set a flag to request 306 intermediaries not to add user-privacy-related information. 308 Note: The mechanism of the flag is FFS. 310 8. Proxy Behavior 312 When a proxy receives a SIP message containing a privacy flag, the 313 proxy compliant with this specification MUST NOT add any information 314 that may reveal something about the sender that is irrelevant to 315 routing unless the proxy knows that such information will be deleted 316 before it leaves the boundary of the Trust Domain[RFC3324]. 318 A proxy MUST NOT modify the privacy flag, if present. 320 9. Security Considerations 322 TBD 324 10. IANA Considerations 326 TBD 328 11. References 330 11.1. Normative References 332 [I-D.ietf-sip-gruu] 333 Rosenberg, J., "Obtaining and Using Globally Routable User 334 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 335 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 336 October 2007. 338 [I-D.rosenberg-midcom-turn] 339 Rosenberg, J., "Traversal Using Relay NAT (TURN)", 340 draft-rosenberg-midcom-turn-08 (work in progress), 341 September 2005. 343 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 344 Requirement Levels", BCP 14, RFC 2119, March 1997. 346 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 347 A., Peterson, J., Sparks, R., Handley, M., and E. 348 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 349 June 2002. 351 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 352 Initiation Protocol (SIP)", RFC 3323, November 2002. 354 11.2. Informative References 356 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 357 Identity", RFC 3324, November 2002. 359 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 360 Description Protocol", RFC 4566, July 2006. 362 Authors' Addresses 364 Mayumi Munakata 365 NTT Corporation 367 Phone: +81 422 36 7565 368 Email: munakata.mayumi@lab.ntt.co.jp 370 Shida Schubert 371 NTT Corporation 373 Phone: +1 604 762 5606 374 Email: shida@ntt-at.com 376 Takumi Ohba 377 NTT Corporation 378 9-11, Midori-cho 3-Chome 379 Musashino-shi, Tokyo 180-8585 380 Japan 382 Phone: +81 422 59 7748 383 Email: ohba.takumi@lab.ntt.co.jp 384 URI: http://www.ntt.co.jp 386 Full Copyright Statement 388 Copyright (C) The IETF Trust (2007). 390 This document is subject to the rights, licenses and restrictions 391 contained in BCP 78, and except as set forth therein, the authors 392 retain all their rights. 394 This document and the information contained herein are provided on an 395 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 396 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 397 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 398 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 399 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 400 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 402 Intellectual Property 404 The IETF takes no position regarding the validity or scope of any 405 Intellectual Property Rights or other rights that might be claimed to 406 pertain to the implementation or use of the technology described in 407 this document or the extent to which any license under such rights 408 might or might not be available; nor does it represent that it has 409 made any independent effort to identify any such rights. Information 410 on the procedures with respect to rights in RFC documents can be 411 found in BCP 78 and BCP 79. 413 Copies of IPR disclosures made to the IETF Secretariat and any 414 assurances of licenses to be made available, or the result of an 415 attempt made to obtain a general license or permission for the use of 416 such proprietary rights by implementers or users of this 417 specification can be obtained from the IETF on-line IPR repository at 418 http://www.ietf.org/ipr. 420 The IETF invites any interested party to bring to its attention any 421 copyrights, patents or patent applications, or other proprietary 422 rights that may cover technology that may be required to implement 423 this standard. Please address the information to the IETF at 424 ietf-ipr@ietf.org. 426 Acknowledgment 428 Funding for the RFC Editor function is provided by the IETF 429 Administrative Support Activity (IASA).