idnits 2.17.1 draft-ietf-sip-ua-privacy-06.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? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (March 05, 2009) is 5525 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-13 ** 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 (==), 3 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: September 6, 2009 NTT 6 March 05, 2009 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-06 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 September 6, 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 This document defines a guideline for a user agent to generate an 48 anonymous SIP message by utilizing mechanisms such as GRUU (Globally 49 Routable User Agent URIs) and TURN (Traversal Using Relays around 50 NAT) without the need for a privacy service defined in RFC 3323. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 3 57 4. Treatment of Privacy-Sensitive Information . . . . . . . . . . 4 58 4.1. Obtaining a Functional Anonymous URI Using the GRUU 59 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 60 4.2. Obtaining a Functional Anonymous IP Address Using the 61 TURN Mechanism . . . . . . . . . . . . . . . . . . . . . . 5 62 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 63 5.1. Critical Privacy-Sensitive Information . . . . . . . . . . 6 64 5.1.1. Contact Header Field . . . . . . . . . . . . . . . . . 6 65 5.1.2. From Header Field in requests . . . . . . . . . . . . 7 66 5.1.3. Via Header Field in requests . . . . . . . . . . . . . 8 67 5.1.4. IP Addresses in SDP . . . . . . . . . . . . . . . . . 8 68 5.2. Non-Critical Privacy-Sensitive Information . . . . . . . . 8 69 5.2.1. Host Names in Other SIP Header Fields . . . . . . . . 8 70 5.2.2. Optional SIP Header Fields . . . . . . . . . . . . . . 8 71 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 72 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 73 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 74 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 75 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Introduction 80 [RFC3323] defines a privacy mechanism for the SIP (Session Initiation 81 Protocol)[RFC3261], based on techniques available at the time of its 82 publication. This mechanism relies on the use of a separate privacy 83 service to remove privacy-sensitive information from SIP messages 84 sent by a user agent before forwarding those messages to the final 85 destination. Since then, numerous SIP extensions have been proposed 86 and standardized. Some of those enable a user agent to withhold its 87 user's identity and related information without the need for privacy 88 services, which was not possible when RFC 3323 was defined. 90 The purpose of this document is not to obsolete RFC 3323, but to 91 enhance overall privacy mechanism in SIP by allowing a user agent to 92 take control of its privacy, rather than being completely dependent 93 on an external privacy service. 95 The UA-driven privacy mechanism defined in this document will not 96 eliminate the need for the RFC 3323 usage defined in [RFC3325], which 97 instructs a privacy service not to forward a P-Asserted-Identity 98 header field outside the Trust Domain. In order to prevent 99 forwarding a P-Asserted-Identity header field outside the Trust 100 Domain, a user agent needs to include the Privacy header field with 101 value 'id' (Privacy:id) in the request, even when the user agent is 102 utilizing this specification. 104 This document defines a guideline in which a user agent controls all 105 the privacy functions on its own utilizing SIP extensions such as 106 GRUU (Globally Routable User Agent URIs) [I-D.ietf-sip-gruu] and TURN 107 (Traversal Using Relays around NAT) [I-D.ietf-behave-turn]. 109 2. Terminology 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in [RFC2119]. 115 privacy-sensitive information: 116 The information that identifies a user who sends the SIP 117 message, as well as other information that can be used to 118 guess the user's identity. 120 3. Concept of Privacy 122 The concept of privacy in this document is the act of concealing 123 privacy-sensitive information. The protection of network privacy 124 (e.g., topology hiding) is outside the scope for this document. 126 Privacy-sensitive information includes display-name and URI (Uniform 127 Resource Identifier) in a From header field that can reveal the 128 user's name and affiliation (e.g., company name), and IP addresses or 129 host names in a Contact header field, a Via header field, a Call-ID 130 header field, or an SDP (Session Description Protocol) [RFC4566] body 131 that might reveal the location of a user agent. 133 4. Treatment of Privacy-Sensitive Information 135 Some fields of a SIP message potentially contain privacy-sensitive 136 information but are not essential for achieving the intended purpose 137 of the message and can be omitted without any side effects. Other 138 fields are essential for achieving the intended purpose of the 139 message and need to contain anonymized values in order to avoid 140 disclosing privacy-sensitive information. Of the privacy-sensitive 141 information listed in section 3, URIs, host names, and IP addresses 142 in Contact, Via, and SDP must be functional (i.e., suitable for 143 purpose) even when they are anonymized. 145 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 146 [I-D.ietf-behave-turn], a user agent can obtain URIs and IP addresses 147 for media and signaling that are functional yet anonymous, and do not 148 identify either the user agent or the user. Instructions on how to 149 obtain a functional anonymous URI and IP address are given in Section 150 4.1 and 4.2, respectively. 152 Host names should be concealed because the user's identity may be 153 guessed from them, but they are not always regarded as critical 154 privacy-sensitive information. 156 In addition, a user agent should be careful not to include any 157 information that identifies the user in optional SIP header fields 158 such as Subject and User-Agent. 160 4.1. Obtaining a Functional Anonymous URI Using the GRUU Mechanism 162 A user agent wanting to obtain a functional anonymous URI MUST 163 support and utilize the GRUU mechanism unless it is able to obtain a 164 functional anonymous URI through other means outside the scope for 165 this document. By sending a REGISTER request requesting GRUU, the 166 user agent can obtain an anonymous URI, which can later be used for 167 the Contact header field. 169 The detailed process on how a user agent obtains a GRUU is described 170 in [I-D.ietf-sip-gruu]. 172 In order to use the GRUU mechanism to obtain a functional anonymous 173 URI, the UA MUST request GRUU in the REGISTER request. If a "temp- 174 gruu" URI parameter and value are present in the REGISTER response, 175 the user agent MUST use the value of the "temp-gruu" as an anonymous 176 URI representing the user agent. This means that the user agent MUST 177 use this URI as its local target and MUST place this URI in the 178 Contact header field of subsequent requests and responses that 179 require the local target to be sent. 181 If there is no "temp-gruu" URI parameter in the 200 response to the 182 REGISTER request, a user agent SHOULD NOT proceed with its 183 anonymization process, unless something equivalent to "temp-gruu" is 184 provided through some administrative means. 186 It is RECOMMENDED that user agent consult the user before sending a 187 request without a functional anonymous URI when privacy is requested 188 from the user. 190 Due to the nature of how GRUU works, the domain name is always 191 revealed when GRUU is used. If revealing the domain name in the 192 Contact header field is a concern, use of a third party GRUU server 193 is a possible solution, but this is outside the scope of this 194 document. Refer to the Security Considerations section for details. 196 4.2. Obtaining a Functional Anonymous IP Address Using the TURN 197 Mechanism 199 A user agent that is not provided with a functional anonymous IP 200 address through some administrative means MUST obtain a relayed 201 address (IP address of a relay) if anonymity is desired for use in 202 SDP and in the Via header field. Such an IP address is to be derived 203 from a STUN relay server through the TURN mechanism, which allows a 204 STUN server to act as a relay. 206 Anonymous IP addresses are needed for two purposes. The first is for 207 use in the Via header field of a SIP request. By obtaining an IP 208 address from a STUN relay server, using that address in the Via 209 header field of the SIP request, and sending the SIP request to the 210 STUN relay server, the IP address of the user agent will not be 211 revealed beyond the relay server. 213 The second is for use in SDP as an address for receiving media. By 214 obtaining an IP address from a STUN relay server and using that 215 address in SDP, media will be received via the relay server. Also 216 media can be sent via the relay server. In this way, neither SDP nor 217 media packets reveal the IP address of the user agent. 219 It is assumed that a user agent is either manually or automatically 220 configured through means such as the configuration framework 221 [I-D.ietf-sipping-config-framework] with the address of one or more 222 STUN (Session Traversal Utilities for NAT) [I-D.ietf-behave-turn] 223 relay servers to obtain anonymous IP address. 225 5. User Agent Behavior 227 This section describes how to generate an anonymous SIP message at a 228 user agent. 230 A user agent fully compliant with this document MUST obscure or 231 conceal all the critical UA-inserted privacy-sensitive information in 232 SIP requests and responses as shown in Section 5.1 when user privacy 233 is requested. In addition, the user agent SHOULD conceal the non- 234 critical privacy-sensitive information as shown in Section 5.2. 236 Furthermore, when a user agent uses a relay server to conceal its 237 identity, the user agent MUST send requests to the relay server to 238 ensure request and response follow the same signaling path. 240 5.1. Critical Privacy-Sensitive Information 242 5.1.1. Contact Header Field 244 When using this header field in a dialog-forming request or response 245 or in a mid-dialog request or response, this field contains the local 246 target, i.e., a URI used to reach the user agent for mid-dialog 247 requests and possibly out-of-dialog requests, such as REFER 248 [RFC3515]. The Contact header field can also contain a display-name. 249 Since the Contact header field is used for routing further requests 250 to the user agent, it must include a functional URI even when it is 251 anonymized. 253 When using this header field in a dialog-forming request or response 254 or in a mid-dialog request or response, the user agent MUST anonymize 255 the Contact header field using an anonymous URI ("temp-gruu") 256 obtained through the GRUU mechanism, unless an equivalent functional 257 anonymous URI is provided by some other means. For other requests 258 and responses, with the exception of 3xx responses, REGISTER requests 259 and REGISTER 200 responses, the UA MUST either omit the Contact 260 header field or use an anonymous URI. 262 Refer to Section 4.1 for details on how to obtain an anonymous URI 263 through GRUU. 265 A display-name in a Contact header MUST be omitted or "Anonymous". 267 5.1.2. From Header Field in requests 269 Without privacy considerations, this field contains the identity of 270 the user, such as display-name and URI. 272 RFCs 3261 and 3323 recommend to set "sip:anonymous@anonymous.invalid" 273 as a SIP URI in a From header field when user privacy is requested. 274 This raises an issue when the SIP-Identity mechanism [RFC4474] is 275 applied to the message, because SIP-Identity requires an actual 276 domain name in the From header field. 278 A user agent generating an anonymous SIP message supporting this 279 specification MUST anonymize the From header field in one of the two 280 ways described below. 282 Option 1: 284 A user agent anonymizes a From header field using an anonymous 285 display-name and an anonymous URI following the procedure noted in 286 section 4.1.1.3 of RFC 3323. 288 The example form of the From header of option 1 is as follows: 290 From: "Anonymous" ;tag=1928301774 292 Option 2: 294 A user agent anonymizes a From header field using an anonymous 295 display-name and an anonymous URI with user's valid domain name 296 instead of "anonymous.invalid". 298 The example form of the From header of option 2 is as follows: 300 From: "Anonymous" ;tag=1928301774 302 A user agent SHOULD go with option 1 to conceal its domain name in 303 the From header field. However, SIP-Identity cannot be used with a 304 From header field in accordance with option 1, because the SIP- 305 Identity mechanism uses authentication based on the domain name. 307 If a user agent expects the SIP-Identity mechanism to be applied to 308 the request, it is RECOMMENDED to go with option 2. However, the 309 user's domain name will be revealed from the From header field of 310 option 2. 312 If the user wants both anonymity and strong identity, a solution 313 would be to use a third party anonymization service that issues an 314 Address of Record (AoR) for use in the From header field of a request 315 and that also provides a SIP-Identity Authentication Service.Third 316 party anonymization service is out of scope for this document. 318 5.1.3. Via Header Field in requests 320 Without privacy considerations, the bottommost Via header field added 321 to a request by a user agent contains the IP address and port or 322 hostname that are used to reach the user agent for responses. 324 A user agent generating an anonymous SIP request supporting this 325 specification MUST anonymize the IP address in the Via header field 326 using an anonymous IP address obtained through the TURN mechanism, 327 unless an equivalent functional anonymous IP address is provided by 328 some other means. 330 Via header field SHOULD NOT include a host name. 332 5.1.4. IP Addresses in SDP 334 A user agent generating an anonymous SIP message supporting this 335 specification MUST anonymize IP addresses in SDP, if present, using 336 an anonymous IP address obtained through the TURN mechanism, unless 337 an equivalent functional anonymous IP address is provided by some 338 other means. 340 Refer to Section 4.2 for details on how to obtain an IP address 341 through TURN. 343 5.2. Non-Critical Privacy-Sensitive Information 345 5.2.1. Host Names in Other SIP Header Fields 347 A user agent generating an anonymous SIP message supporting this 348 specification SHOULD conceal host names in any SIP header fields, 349 such as Call-ID and Warning header fields, if considered privacy- 350 sensitive. 352 5.2.2. Optional SIP Header Fields 354 Other optional SIP header fields (such as Call-Info, In-Reply-To, 355 Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and 356 Warning) can contain privacy-sensitive information. 358 A user agent generating an anonymous SIP message supporting this 359 specification SHOULD NOT include any information that identifies the 360 user in such optional header fields. 362 6. Security Considerations 364 This specification uses GRUU and TURN and inherits any security 365 considerations described in these drafts. 367 Furthermore, if the provider of the caller intending to obscure its 368 identity consists of a small number of people (e.g. small enterprise, 369 SOHO), the domain name alone can reveal the identity of the caller. 371 The same can be true when the provider is large but the receiver of 372 the call only knows a few people from the source of call. 374 There are mainly two places in the message, From header and Contact 375 header, where domain name must be functional. 377 The domain name in the From header can be obscured as described in 378 section 5.1.2, whereas the Contact header field needs to contain a 379 valid domain name at all times in order to function properly. 381 It is probably important to note that generally a device will not 382 show the contact address to the receiver, but this does not mean that 383 one can not find the domain name in a message. In fact as long as 384 this specification is used to obscure identity, the message will 385 always contain a valid domain name as it inherits key characteristics 386 of GRUU. 388 User Agents that use a temporary GRUU should also note that 389 confidentiality does not extend to parties that are permitted to 390 register to the same AoR or are permitted to obtain temporary GRUUs 391 when subscribed to the 'reg' event package [RFC3680] for the AoR. To 392 limit this, it is recommended that the authorization policy for the 393 'reg' event package permit only those subscribers authorized to 394 register to the AoR to receive temporary GRUUs. With this policy, 395 the confidentiality of the temporary GRUU will be the same whether or 396 not the 'reg' event package is used. 398 If one wants to assure anonymization, it is recommended for the user 399 to seek and rely on a third party anonymization service, which is 400 outside the scope of this document. 402 A third party anonymization service provides registrar and TURN 403 service that have no affiliation with the caller's provider, allowing 404 caller to completely withhold its identity. 406 7. IANA Considerations 408 This document requires no action by IANA. 410 8. References 412 8.1. Normative References 414 [I-D.ietf-behave-turn] 415 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 416 Relays around NAT (TURN): Relay Extensions to Session 417 Traversal Utilities for NAT (STUN)", 418 draft-ietf-behave-turn-13 (work in progress), 419 February 2009. 421 [I-D.ietf-sip-gruu] 422 Rosenberg, J., "Obtaining and Using Globally Routable User 423 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 424 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 425 October 2007. 427 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 428 Requirement Levels", BCP 14, RFC 2119, March 1997. 430 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 431 A., Peterson, J., Sparks, R., Handley, M., and E. 432 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 433 June 2002. 435 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 436 Description Protocol", RFC 4566, July 2006. 438 8.2. Informative References 440 [I-D.ietf-sipping-config-framework] 441 Channabasappa, S., "A Framework for Session Initiation 442 Protocol User Agent Profile Delivery", 443 draft-ietf-sipping-config-framework-15 (work in progress), 444 February 2008. 446 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 447 Initiation Protocol (SIP)", RFC 3323, November 2002. 449 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 450 Extensions to the Session Initiation Protocol (SIP) for 451 Asserted Identity within Trusted Networks", RFC 3325, 452 November 2002. 454 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 455 Method", RFC 3515, April 2003. 457 [RFC3680] Rosenberg, J., "A Session Initiation Protocol (SIP) Event 458 Package for Registrations", RFC 3680, March 2004. 460 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 461 Authenticated Identity Management in the Session 462 Initiation Protocol (SIP)", RFC 4474, August 2006. 464 Authors' Addresses 466 Mayumi Munakata 467 NTT Corporation 469 Email: munakata.mayumi@lab.ntt.co.jp 471 Shida Schubert 472 NTT Corporation 474 Email: shida@ntt-at.com 476 Takumi Ohba 477 NTT Corporation 478 9-11, Midori-cho 3-Chome 479 Musashino-shi, Tokyo 180-8585 480 Japan 482 Phone: +81 422 59 7748 483 Email: ohba.takumi@lab.ntt.co.jp 484 URI: http://www.ntt.co.jp