idnits 2.17.1 draft-ietf-sip-ua-privacy-01.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 404. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 415. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 422. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 428. 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 (February 18, 2008) is 5913 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) == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-06 ** 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: Standards Track T. Ohba 5 Expires: August 22, 2007 NTT 6 February 18, 2008 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-01 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 August 22, 2007. 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. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 5 54 5. Treatment of Privacy-Sensitive Information . . . . . . . . . . 5 55 5.1. Anonymous URI and Display-Name . . . . . . . . . . . . . . 5 56 5.2. Anonymous IP Address . . . . . . . . . . . . . . . . . . . 6 57 6. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 7 58 6.1. Generating Anonymous Message . . . . . . . . . . . . . . . 7 59 6.2. Indication to Maintain Privacy . . . . . . . . . . . . . . 7 60 7. Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . . . 8 61 8. Security Considerations . . . . . . . . . . . . . . . . . . . 8 62 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 9 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 67 Intellectual Property and Copyright Statements . . . . . . . . . . 10 69 1. Introduction 71 Privacy is defined in [RFC3323] as the withholding of the identity of 72 a person (and related personal information) from destination(s) of 73 messages and/or intermediaries handling these messages in an exchange 74 of SIP (Session Initiation Protocol) [RFC3261] communications. 76 In SIP, identity is most commonly carried in the form of a SIP URI 77 and an optional display-name, which commonly appear in the To, From 78 and other header fields of SIP requests and responses. 80 There are numerous other places in SIP messages in which identity- 81 related information can be revealed. For example, the Contact header 82 field contains a SIP URI. Moreover, information in the Record-Route 83 and Via headers could inadvertently reveal something about the 84 originator of a message. 86 RFC 3323 defines privacy mechanisms for SIP, based on techniques 87 available at the time of publication. Some of these mechanisms rely 88 on the use of a separate privacy service to remove sensitive 89 information from messages sent by a user agent before forwarding 90 those messages to the final destination. Since then, numerous SIP 91 extensions have been proposed and standardized. Some of those seem 92 to enable a user agent to withhold its user's identity and related 93 information without dependency on privacy services, which was not 94 possible when RFC 3323 was defined. 96 A number of issues have been identified with the mechanisms defined 97 in RFC 3323, especially with mechanisms that depend on a privacy 98 service. 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 must be present in the 107 signaling path of any subsequent requests that carry that 108 Call-ID. For requests within the same dialog this can be 109 achieved using the record-route mechanism. For requests outside 110 the dialog that carry the Call-ID in a Replaces, Join or Target- 111 Dialog header field, for example, there is no defined mechanism. 113 4. To map the referenced dialog to a dialog attempt invoked by 114 REFER, for example, the privacy service needs to retain the 115 correspondence relation between original information and modified 116 information beyond the actual dialog duration of the referenced 117 dialog. 119 To solve the problems, this document proposes a new privacy mechanism 120 in which a user agent controls all the privacy functions on its own 121 utilizing SIP extensions such as GRUU (Globally Routable User Agent 122 URIs)[I-D.ietf-sip-gruu] and TURN (Traversal Using Relay 123 NAT)[I-D.ietf-behave-turn]. 125 2. Terminology 127 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 128 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 129 document are to be interpreted as described in [RFC2119]. 131 privacy-sensitive information: 132 The information that identifies a user who sends the SIP 133 message, as well as the supplementary information that 134 can be used to guess the user's identity. 136 3. Concept of Privacy 138 The concept of privacy in this document means the concealing of the 139 identity of a user and supplementary information. The scope of this 140 document is to withhold the privacy-sensitive information of the user 141 who sends the SIP message from other users and intermediaries 142 handling the message. The protection of network privacy (e.g., 143 topology hiding) is outside the scope of this document. 145 Privacy-sensitive information includes display-name and URI in a From 146 header that can reveal the user's name and affiliation (e.g., company 147 name), contact information in a Contact header that is used to 148 communicate with the user's UA, an IP address in an SDP (Session 149 Description Protocol)[RFC4566] that tells the location of a user's UA 150 and can be used to establish a connection. A host name in Call-ID is 151 also regarded as privacy-sensitive information because it may reveal 152 the user's domain name. 154 Privacy-sensitive information is divided into two types, information 155 inserted by the user's UA and information inserted by other SIP 156 entities (e.g., proxies, B2BUAs). A user agent can maintain privacy 157 of the UA-inserted information by itself. On the other hand, 158 regarding the information inserted by other entities, a user agent 159 can insert a privacy flag and request intermediaries not to add the 160 privacy-sensitve information. 162 4. Requirements 164 The requirements for the UA-driven privacy mechanism are as follows: 166 Req 1: A user agent MUST be able to send a SIP request that is fully 167 anonymized. This is, any headers and body inserted by the 168 user agent does not jeopardize user privacy. 170 Req 2: It MUST be possible for a user agent to indicate to 171 downstream entities that a user is requesting privacy. 173 Req 3: When privacy is requested, a proxy SHOULD honor the request 174 and only add information necessary to route the call while 175 withholding any sensitive information that may reveal 176 anything about the user if possible. 178 Req 4: Mechanism defined here MUST be backward compatible with the 179 pre-existing privacy mechanism already in place. 181 5. Treatment of Privacy-Sensitive Information 183 Except by means of a privacy service, RFC 3323 does not provide means 184 to obscure two important pieces of information about the user agent, 185 which are a URI used to exchange signaling (Contact, From, for 186 example), and IP address(es) used to exchange media. 188 RFC 3323 recommends to set sip:anonymous@anonymous.invalid as a SIP 189 URI in a From header when user privacy is required. Although, the 190 From header field URI may need to be an anonymous but functional URI. 191 For example, a mechanism of SIP-Identity [RFC4474] requires a 192 functional From header even if it is anonymous. 194 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 195 [I-D.ietf-behave-turn], a user agent can now obtain URI(s) and IP 196 address(es) for media that are functional yet anonymous, in that they 197 do not identify the user agent. 199 5.1. Anonymous URI and Display-Name 201 A user agent wanting to obtain functional anonymous URI SHOULD 202 support and SHOULD utilize the GRUU mechanism. By sending a REGISTER 203 request requesting GRUU, the UA can obtain an anonymous URI, which 204 can later be used for Contact header. 206 The detailed process on how a user agent obtains a GRUU is described 207 in [I-D.ietf-sip-gruu]. If the Registrar supports GRUU and returns a 208 REGISTER response, the user agent SHOULD search within the REGISTER 209 response for a "temp-gruu" URI parameter, which provides the desired 210 privacy property. 212 If the "temp-gruu" URI parameter and value exist within the REGISTER 213 response, the user agent SHOULD use the value of the "temp-gruu" as 214 an anonymous URI representing the user agent. This URI SHOULD be 215 used for Contact header. 217 The user agent using the "temp-gruu" as a contact URI is RECOMMENDED 218 to set "Anonymous" as a display-name in any header where the display- 219 name of the originator is set. That indicates the anonymity of the 220 request to intermediaries that may invoke some services based on the 221 anonymity of the call. The temp-gruu alone is not sufficient to 222 invoke such service because GRUU is merely a URI that is a sequence 223 of strings and digits with no explicit semantics to indicate that it 224 is an anonymous URI. 226 If there is no "temp-gruu" URI parameter in the 200 response to the 227 REGISTER request, a user agent SHOULD NOT proceed with its 228 anonymization process, unless something equivalent to "temp-gruu" is 229 provided through some administrative means. 231 Note: How to obtain an anonymous URI for From and any headers other 232 than the Contact is FFS. 234 It is RECOMMENDED that user agent consult the user before sending a 235 request without a functional anonymous URI when privacy is request 236 from the user. 238 5.2. Anonymous IP Address 240 It is assumed that a user agent is either manually or automatically 241 configured through means such as a configuration framework 242 [I-D.ietf-sipping-config-framework] with the address of one or more 243 STUN relay servers. 245 Two IP addresses are needed to maintain privacy, one to be used in 246 signaling such as in a Via header, another to be used in SDP for 247 media. 249 A user agent that is not provided with a functional anonymous IP 250 address through some administrative means, SHOULD obtain a relayed 251 address (IP address of the media relay) for use in SDP, derived from 252 a STUN [I-D.ietf-behave-turn] relay server using the STUN relay 253 usage, which allows a STUN server to act as a media relay. 255 Note: A relayed IP address may be used for a Via header, but some 256 commented that is not an appropriate to be used for signaling. 257 There was a comment about the IP address in Via being stripped 258 by the proxy, but that would require that a proxy compliant to 259 this specification is in the signaling path. 261 6. User Agent Behavior 263 A user agent fully compliant with this document SHOULD obscure or 264 conceal all the UA-inserted privacy-sensitive information in SIP 265 requests and responses when user privacy is requested. Section 6.1 266 describes how to generate an anonymous message at a user agent. 268 When a user agent generates an anonymous message based on this 269 specification, it SHOULD set an indication to tell intermediaries not 270 to add privacy-sensitive information. Section 6.2 describes more 271 about this. 273 6.1. Generating Anonymous Message 275 The two pieces of information that a user agent needs to obscure 276 while sustaining its purpose and functionality are the URI and IP 277 address used for establishing a media/signaling session. 278 Instructions on how to obtain an functional anonymous URI and IP 279 address are given in Section 5.1 and 5.2, respectively. 281 For anonymizing any headers and information in a SIP message, the 282 user agent SHOULD follow the instructions in this document. 284 Note: Instructions to treat each SIP header/parameter in generating 285 an anonymous SIP message will be given in a future version of 286 this draft. 288 6.2. Indication to Maintain Privacy 290 This document defines a privacy flag, which indicates that the user 291 requires privacy for the SIP message. Without a privacy flag, 292 intermediaries might add some privacy-sensitive information in the 293 message, even if a user agent had anonymized the message as perfectly 294 as possible. 296 When a user agent generates an anonymous message by itself according 297 to the guidelines in Section 6.1, it SHOULD set a flag to request 298 intermediaries not to add privacy-sensitive information. 300 Note: The mechanism of the flag is FFS. 302 7. Proxy Behavior 304 When a proxy receives a SIP message containing a privacy flag, the 305 proxy compliant with this specification MUST NOT add any information 306 that may reveal something about the sender that is irrelevant to 307 routing unless the proxy knows that such information will be deleted 308 before it leaves the boundary of the Trust Domain[RFC3324]. 310 A proxy MUST NOT modify the privacy flag, if present. 312 8. Security Considerations 314 TBD 316 9. IANA Considerations 318 TBD 320 10. References 322 10.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-06 (work in progress), 329 January 2008. 331 [I-D.ietf-sip-gruu] 332 Rosenberg, J., "Obtaining and Using Globally Routable User 333 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 334 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 335 October 2007. 337 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 338 Requirement Levels", BCP 14, RFC 2119, March 1997. 340 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 341 A., Peterson, J., Sparks, R., Handley, M., and E. 342 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 343 June 2002. 345 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 346 Description Protocol", RFC 4566, July 2006. 348 10.2. Informative References 350 [I-D.ietf-sipping-config-framework] 351 Channabasappa, S., "A Framework for Session Initiation 352 Protocol User Agent Profile Delivery", 353 draft-ietf-sipping-config-framework-15 (work in progress), 354 February 2008. 356 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 357 Initiation Protocol (SIP)", RFC 3323, November 2002. 359 [RFC3324] Watson, M., "Short Term Requirements for Network Asserted 360 Identity", RFC 3324, November 2002. 362 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 363 Authenticated Identity Management in the Session 364 Initiation Protocol (SIP)", RFC 4474, August 2006. 366 Authors' Addresses 368 Mayumi Munakata 369 NTT Corporation 371 Phone: +81 422 36 7565 372 Email: munakata.mayumi@lab.ntt.co.jp 374 Shida Schubert 375 NTT Corporation 377 Phone: +1 604 762 5606 378 Email: shida@ntt-at.com 380 Takumi Ohba 381 NTT Corporation 382 9-11, Midori-cho 3-Chome 383 Musashino-shi, Tokyo 180-8585 384 Japan 386 Phone: +81 422 59 7748 387 Email: ohba.takumi@lab.ntt.co.jp 388 URI: http://www.ntt.co.jp 390 Full Copyright Statement 392 Copyright (C) The IETF Trust (2007). 394 This document is subject to the rights, licenses and restrictions 395 contained in BCP 78, and except as set forth therein, the authors 396 retain all their rights. 398 This document and the information contained herein are provided on an 399 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 400 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 401 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 402 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 403 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 404 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 406 Intellectual Property 408 The IETF takes no position regarding the validity or scope of any 409 Intellectual Property Rights or other rights that might be claimed to 410 pertain to the implementation or use of the technology described in 411 this document or the extent to which any license under such rights 412 might or might not be available; nor does it represent that it has 413 made any independent effort to identify any such rights. Information 414 on the procedures with respect to rights in RFC documents can be 415 found in BCP 78 and BCP 79. 417 Copies of IPR disclosures made to the IETF Secretariat and any 418 assurances of licenses to be made available, or the result of an 419 attempt made to obtain a general license or permission for the use of 420 such proprietary rights by implementers or users of this 421 specification can be obtained from the IETF on-line IPR repository at 422 http://www.ietf.org/ipr. 424 The IETF invites any interested party to bring to its attention any 425 copyrights, patents or patent applications, or other proprietary 426 rights that may cover technology that may be required to implement 427 this standard. Please address the information to the IETF at 428 ietf-ipr@ietf.org. 430 Acknowledgment 432 Funding for the RFC Editor function is provided by the IETF 433 Administrative Support Activity (IASA).