idnits 2.17.1 draft-ietf-sip-ua-privacy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 and authors 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 5, 2009) is 5553 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-12 ** 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 (==), 4 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: August 9, 2009 NTT 6 February 5, 2009 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-04 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 9, 2009. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. 46 Abstract 48 This document defines a best current practice for a user agent to 49 generate an anonymous SIP message by utilizing mechanisms such as 50 GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using 51 Relays around NAT) without the need for a privacy service defined in 52 RFC 3323. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Treatment of Privacy-Sensitive Information . . . . . . . . . . 4 60 4.1. Obtaining a Functional Anonymous URI Using the GRUU 61 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4.2. Obtaining a Functional Anonymous IP Address Using the 63 TURN Mechanism . . . . . . . . . . . . . . . . . . . . . . 5 64 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. Critical Privacy-Sensitive Information . . . . . . . . . . 6 66 5.1.1. Contact Header Field . . . . . . . . . . . . . . . . . 6 67 5.1.2. From Header Field in requests . . . . . . . . . . . . 7 68 5.1.3. Via Header Field in requests . . . . . . . . . . . . . 8 69 5.1.4. IP Addresses in SDP . . . . . . . . . . . . . . . . . 8 70 5.2. Non-Critical Privacy-Sensitive Information . . . . . . . . 8 71 5.2.1. Host Names in Other SIP Header Fields . . . . . . . . 8 72 5.2.2. Optional SIP Header Fields . . . . . . . . . . . . . . 8 73 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 74 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 75 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 76 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 77 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 80 1. Introduction 82 [RFC3323] defines a privacy mechanism for the SIP (Session Initiation 83 Protocol)[RFC3261], based on techniques available at the time of its 84 publication. This mechanism relies on the use of a separate privacy 85 service to remove privacy-sensitive information from SIP messages 86 sent by a user agent before forwarding those messages to the final 87 destination. Since then, numerous SIP extensions have been proposed 88 and standardized. Some of those enable a user agent to withhold its 89 user's identity and related information without the need for privacy 90 services, which was not possible when RFC 3323 was defined. 92 The purpose of this document is not to obsolete RFC 3323, but to 93 enhance overall privacy mechanism in SIP by allowing user agent to 94 take control of its privacy, rather than being completely dependent 95 on external privacy service. 97 The UA-driven privacy mechanism defined in this document will not 98 eliminate the need for the RFC 3323 usage defined in [RFC3325], which 99 instructs a privacy service not to forward a P-Asserted-Identity 100 header field outside the Trust Domain. In order to prevent 101 forwarding a P-Asserted-Identity header field outside the Trust 102 Domain, a user agent needs to include the Privacy header field with 103 value 'id' (Privacy:id) in the request, even when the user agent is 104 utilizing this specification. 106 This document defines a best current practice in which a user agent 107 controls all the privacy functions on its own utilizing SIP 108 extensions such as GRUU (Globally Routable User Agent URIs) 109 [I-D.ietf-sip-gruu] and TURN (Traversal Using Relays around NAT) 110 [I-D.ietf-behave-turn]. 112 2. Terminology 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in [RFC2119]. 118 privacy-sensitive information: 119 The information that identifies a user who sends the SIP 120 message, as well as other information that can be used to 121 guess the user's identity. 123 3. Concept of Privacy 125 The concept of privacy in this document is the act of concealing 126 privacy-sensitive information. The protection of network privacy 127 (e.g., topology hiding) is outside the scope for this document. 129 Privacy-sensitive information includes display-name and URI (Uniform 130 Resource Identifier) in a From header field that can reveal the 131 user's name and affiliation (e.g., company name), and IP addresses or 132 host names in a Contact header field, a Via header field, a Call-ID 133 header field, or an SDP (Session Description Protocol) [RFC4566] body 134 that might reveal the location of a user agent. 136 4. Treatment of Privacy-Sensitive Information 138 Some fields of a SIP message potentially contain privacy-sensitive 139 information but are not essential for achieving the intended purpose 140 of the message and can be omitted without any side effects. Other 141 fields are essential for achieving the intended purpose of the 142 message and need to contain anonymized values in order to avoid 143 disclosing privacy-sensitive information. Of the privacy-sensitive 144 information listed in section 3, URIs, host names, and IP addresses 145 in Contact, Via, and SDP must be functional (i.e., suitable for 146 purpose) even when they are anonymized. 148 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 149 [I-D.ietf-behave-turn], a user agent can obtain URIs and IP addresses 150 for media and signaling that are functional yet anonymous, and do not 151 identify either the user agent or the user. Instructions on how to 152 obtain a functional anonymous URI and IP address are given in Section 153 4.1 and 4.2, respectively. 155 Host names should be concealed because the user's identity may be 156 guessed from them, but they are not always regarded as critical 157 privacy-sensitive information. 159 In addition, a user agent should be careful not to include any 160 information that identifies the user in optional SIP header fields 161 such as Subject and User-Agent. 163 4.1. Obtaining a Functional Anonymous URI Using the GRUU Mechanism 165 A user agent wanting to obtain a functional anonymous URI MUST 166 support and utilize the GRUU mechanism unless it is able to obtain a 167 functional anonymous URI through other means outside the scope for 168 this document. By sending a REGISTER request requesting GRUU, the 169 user agent can obtain an anonymous URI, which can later be used for 170 the Contact header field. 172 The detailed process on how a user agent obtains a GRUU is described 173 in [I-D.ietf-sip-gruu]. 175 In order to use the GRUU mechanism to obtain a functional anonymous 176 URI, the UA MUST request GRUU in the REGISTER request. If a "temp- 177 gruu" URI parameter and value are present in the REGISTER response, 178 the user agent MUST use the value of the "temp-gruu" as an anonymous 179 URI representing the user agent. This means that the user agent MUST 180 use this URI as its local target and MUST place this URI in the 181 Contact header field of subsequent requests and responses that 182 require the local target to be sent. 184 If there is no "temp-gruu" URI parameter in the 200 response to the 185 REGISTER request, a user agent SHOULD NOT proceed with its 186 anonymization process, unless something equivalent to "temp-gruu" is 187 provided through some administrative means. 189 It is RECOMMENDED that user agent consult the user before sending a 190 request without a functional anonymous URI when privacy is requested 191 from the user. 193 Due to the nature of how GRUU works, the domain name is always 194 revealed when GRUU is used. If revealing the domain name in Contact 195 header field is a concern, usage of a third-party GRUU server to 196 obtain a temp-gruu that is irrelevant to users' domain, which is 197 outside the scope of this document SHOULD be considered. Refer to 198 the Security Considerations section for details. 200 4.2. Obtaining a Functional Anonymous IP Address Using the TURN 201 Mechanism 203 A user agent that is not provided with a functional anonymous IP 204 address through some administrative means, MUST obtain a relayed 205 address if anonymity is desired (IP address of a relay) for use in 206 SDP and in Via header. Such IP address is to be derived from a STUN 207 relay server through TURN mechanism, which allows a STUN server to 208 act as a media relay. 210 Anonymous IP addresses are needed for two purposes. The first is for 211 use in the Via header field of a SIP request. By obtaining an IP 212 address from a STUN relay server, using that address in the Via 213 header field of the SIP request, and sending the SIP request to the 214 STUN relay server, the IP address of the user agent will not be 215 revealed beyond the relay server. 217 The second is for use in SDP as an address for receiving media. By 218 obtaining an IP address from a STUN relay server and using that 219 address in SDP, media will be received via the relay server. Also 220 media can be sent via the relay server. In this way, neither SDP nor 221 media packets reveal the IP address of the user agent. 223 It is assumed that a user agent is either manually or automatically 224 configured through means such as the configuration framework 225 [I-D.ietf-sipping-config-framework] with the address of one or more 226 STUN (Session Traversal Utilities for NAT) [I-D.ietf-behave-turn] 227 relay servers to obtain anonymous IP address. 229 5. User Agent Behavior 231 This section describes how to generate an anonymous SIP message at a 232 user agent. 234 A user agent fully compliant with this document MUST obscure or 235 conceal all the critical UA-inserted privacy-sensitive information in 236 SIP requests and responses as shown in Section 5.1 when user privacy 237 is requested. In addition, the user agent SHOULD conceal the non- 238 critical privacy-sensitive information as shown in Section 5.2. 240 Furthermore, when a user agent uses a relay server to conceal its 241 identity, the user agent MUST send requests to the relay server to 242 ensure request and response follow the same signaling path. 244 5.1. Critical Privacy-Sensitive Information 246 5.1.1. Contact Header Field 248 When using this header field in a dialog-forming request or response 249 or in a mid-dialog request or response, this field contains the local 250 target, i.e., a URI used to reach the user agent for mid-dialog 251 requests and possibly out-of-dialog requests, such as REFER 252 [RFC3515]. The Contact header field can also contain a display-name. 253 Since the Contact header field is used for routing further requests 254 to the user agent, it must include a functional URI even when it is 255 anonymized. 257 When using this header field in a dialog-forming request or response 258 or in a mid-dialog request or response, the user agent MUST anonymize 259 the Contact header field using an anonymous URI ("temp-gruu") 260 obtained through the GRUU mechanism, unless an equivalent functional 261 anonymous URI is provided by some other means. For out-of-dialog 262 request, anonymous URI MAY be set when anonymization is required. 264 Refer to Section 4.1 for details on how to obtain an anonymous URI 265 through GRUU, and refer to Section 4.2 for details on how to obtain 266 an IP address through TURN. 268 A display-name in a Contact header MUST be omitted or "Anonymous". 270 5.1.2. From Header Field in requests 272 Without privacy considerations, this field contains the identity of 273 the user, such as display-name and URI. 275 RFCs 3261 and 3323 recommend to set "sip:anonymous@anonymous.invalid" 276 as a SIP URI in a From header field when user privacy is requested. 277 This raises an issue when the SIP-Identity mechanism [RFC4474] is 278 applied to the message, because SIP-Identity requires an actual 279 domain name in the From header field. 281 A user agent generating an anonymous SIP message supporting this 282 specification MUST anonymize the From header field in one of the two 283 ways described below. 285 Option 1: 287 A user agent anonymizes a From header field using an anonymous 288 display-name and an anonymous URI following the procedure noted in 289 section 4.1.1.3 of RFC 3323. 291 The example form of the From header of option 1 is as follows: 293 From: "Anonymous" ;tag=1928301774 295 Option 2: 297 A user agent anonymizes a From header field using an anonymous 298 display-name and an anonymous URI with user's valid domain name 299 instead of "anonymous.invalid". 301 The example form of the From header of option 2 is as follows: 303 From: "Anonymous" ;tag=1928301774 305 A user agent SHOULD go with option 1 to conceal its domain name in 306 From header field. However, SIP-Identity cannot be used with a From 307 header field in accordance with option 1, because the SIP-Identity 308 mechanism uses authentication based on the domain name. 310 If a user agent expects the SIP-Identity mechanism to be applied to 311 the request, it is RECOMMENDED to go with option 2. However, the 312 user's domain name will be revealed from the From header field of 313 option 2. 315 If user wants both anonymity and strong identity, use of a third 316 party anonymization service which issues AoR for the use in From 317 address which also provides SIP-Identity should be considered. Third 318 party anonymization service is out of scope for this document. 320 5.1.3. Via Header Field in requests 322 Without privacy considerations, the bottommost Via header field added 323 by a user agent contains the IP address and port or hostname that are 324 used to reach the user agent for responses. 326 A user agent generating an anonymous SIP request supporting this 327 specification MUST anonymize the IP address in the Via header field 328 using an anonymous IP address obtained through the TURN mechanism, 329 unless an equivalent functional anonymous IP address is provided by 330 some other means. 332 Refer to Section 4.2 for details on how to obtain an IP address 333 through TURN. 335 Via header SHOULD NOT include a host name. 337 5.1.4. IP Addresses in SDP 339 A user agent generating an anonymous SIP message supporting this 340 specification MUST anonymize IP addresses in SDP, if present, using 341 an anonymous IP address obtained through the TURN mechanism, unless 342 an equivalent functional anonymous IP address is provided by some 343 other means. 345 Refer to Section 4.2 for details on how to obtain an IP address 346 through TURN. 348 5.2. Non-Critical Privacy-Sensitive Information 350 5.2.1. Host Names in Other SIP Header Fields 352 A user agent generating an anonymous SIP message supporting this 353 specification SHOULD conceal host names in any SIP header fields, 354 such as Call-ID and Warning header fields, if considered privacy- 355 sensitive. 357 5.2.2. Optional SIP Header Fields 359 Other optional SIP header fields (such as Call-Info, In-Reply-To, 360 Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and 361 Warning) can contain privacy-sensitive information. 363 A user agent generating an anonymous SIP message supporting this 364 specification SHOULD NOT include any information that identifies the 365 user in such optional header fields. 367 6. Security Considerations 369 This specification uses GRUU and TURN and inherits any security 370 considerations described in these drafts. 372 Furthermore, if the provider of the caller intending to obscure its 373 identity consists of a small number of people (e.g. small enterprise, 374 SOHO), the domain name alone can reveal the identity of the caller 375 when this specification is used. 377 Same can be true when the provider is large, but the receiver of the 378 call only knows few people from the source of call. 380 There are mainly two places in the message, From header and Contact 381 header, where domain name must be functional. 383 The domain name in From header can be obscured as described in 384 section 5.1.2, on contrary the Contact header needs to contain a 385 valid domain name at all time to function properly. 387 It is probably important to note that generally a device will not 388 show the contact address to the receiver, but this does not mean that 389 one can not find the domain name in a message. In fact as long as 390 this specification is used to obscure identity, the message will 391 always contain a valid domain name as it inherits key characteristics 392 of GRUU. 394 If one wants to assure anonymization, it is recommended for the user 395 to seek and rely on third party anonymization service, which is 396 outside the scope of this document. 398 A third party anonymization service provides registrar and TURN 399 service which has no affiliation with the caller's provider, allowing 400 caller to completely withhold its identity. 402 7. IANA Considerations 404 This document requires no action by IANA. 406 8. References 408 8.1. Normative References 410 [I-D.ietf-behave-turn] 411 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 412 Relays around NAT (TURN): Relay Extensions to Session 413 Traversal Utilities for NAT (STUN)", 414 draft-ietf-behave-turn-12 (work in progress), 415 November 2008. 417 [I-D.ietf-sip-gruu] 418 Rosenberg, J., "Obtaining and Using Globally Routable User 419 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 420 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 421 October 2007. 423 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 424 Requirement Levels", BCP 14, RFC 2119, March 1997. 426 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 427 A., Peterson, J., Sparks, R., Handley, M., and E. 428 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 429 June 2002. 431 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 432 Description Protocol", RFC 4566, July 2006. 434 8.2. Informative References 436 [I-D.ietf-sipping-config-framework] 437 Channabasappa, S., "A Framework for Session Initiation 438 Protocol User Agent Profile Delivery", 439 draft-ietf-sipping-config-framework-15 (work in progress), 440 February 2008. 442 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 443 Initiation Protocol (SIP)", RFC 3323, November 2002. 445 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 446 Extensions to the Session Initiation Protocol (SIP) for 447 Asserted Identity within Trusted Networks", RFC 3325, 448 November 2002. 450 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 451 Method", RFC 3515, April 2003. 453 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 454 Authenticated Identity Management in the Session 455 Initiation Protocol (SIP)", RFC 4474, August 2006. 457 Authors' Addresses 459 Mayumi Munakata 460 NTT Corporation 462 Email: munakata.mayumi@lab.ntt.co.jp 464 Shida Schubert 465 NTT Corporation 467 Email: shida@ntt-at.com 469 Takumi Ohba 470 NTT Corporation 471 9-11, Midori-cho 3-Chome 472 Musashino-shi, Tokyo 180-8585 473 Japan 475 Phone: +81 422 59 7748 476 Email: ohba.takumi@lab.ntt.co.jp 477 URI: http://www.ntt.co.jp