idnits 2.17.1 draft-ietf-sip-ua-privacy-05.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 9, 2009) is 5556 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 13, 2009 NTT 6 February 9, 2009 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-05 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 13, 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 guideline for a user agent to generate an 49 anonymous SIP message by utilizing mechanisms such as GRUU (Globally 50 Routable User Agent URIs) and TURN (Traversal Using Relays around 51 NAT) without the need for a privacy service defined in RFC 3323. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 3 58 4. Treatment of Privacy-Sensitive Information . . . . . . . . . . 4 59 4.1. Obtaining a Functional Anonymous URI Using the GRUU 60 Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 4 61 4.2. Obtaining a Functional Anonymous IP Address Using the 62 TURN Mechanism . . . . . . . . . . . . . . . . . . . . . . 5 63 5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 6 64 5.1. Critical Privacy-Sensitive Information . . . . . . . . . . 6 65 5.1.1. Contact Header Field . . . . . . . . . . . . . . . . . 6 66 5.1.2. From Header Field in requests . . . . . . . . . . . . 7 67 5.1.3. Via Header Field in requests . . . . . . . . . . . . . 8 68 5.1.4. IP Addresses in SDP . . . . . . . . . . . . . . . . . 8 69 5.2. Non-Critical Privacy-Sensitive Information . . . . . . . . 8 70 5.2.1. Host Names in Other SIP Header Fields . . . . . . . . 8 71 5.2.2. Optional SIP Header Fields . . . . . . . . . . . . . . 8 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 79 1. Introduction 81 [RFC3323] defines a privacy mechanism for the SIP (Session Initiation 82 Protocol)[RFC3261], based on techniques available at the time of its 83 publication. This mechanism relies on the use of a separate privacy 84 service to remove privacy-sensitive information from SIP messages 85 sent by a user agent before forwarding those messages to the final 86 destination. Since then, numerous SIP extensions have been proposed 87 and standardized. Some of those enable a user agent to withhold its 88 user's identity and related information without the need for privacy 89 services, which was not possible when RFC 3323 was defined. 91 The purpose of this document is not to obsolete RFC 3323, but to 92 enhance overall privacy mechanism in SIP by allowing a user agent to 93 take control of its privacy, rather than being completely dependent 94 on an external privacy service. 96 The UA-driven privacy mechanism defined in this document will not 97 eliminate the need for the RFC 3323 usage defined in [RFC3325], which 98 instructs a privacy service not to forward a P-Asserted-Identity 99 header field outside the Trust Domain. In order to prevent 100 forwarding a P-Asserted-Identity header field outside the Trust 101 Domain, a user agent needs to include the Privacy header field with 102 value 'id' (Privacy:id) in the request, even when the user agent is 103 utilizing this specification. 105 This document defines a guideline in which a user agent controls all 106 the privacy functions on its own utilizing SIP extensions such as 107 GRUU (Globally Routable User Agent URIs) [I-D.ietf-sip-gruu] and TURN 108 (Traversal Using Relays around NAT) [I-D.ietf-behave-turn]. 110 2. Terminology 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 113 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 114 document are to be interpreted as described in [RFC2119]. 116 privacy-sensitive information: 117 The information that identifies a user who sends the SIP 118 message, as well as other information that can be used to 119 guess the user's identity. 121 3. Concept of Privacy 123 The concept of privacy in this document is the act of concealing 124 privacy-sensitive information. The protection of network privacy 125 (e.g., topology hiding) is outside the scope for this document. 127 Privacy-sensitive information includes display-name and URI (Uniform 128 Resource Identifier) in a From header field that can reveal the 129 user's name and affiliation (e.g., company name), and IP addresses or 130 host names in a Contact header field, a Via header field, a Call-ID 131 header field, or an SDP (Session Description Protocol) [RFC4566] body 132 that might reveal the location of a user agent. 134 4. Treatment of Privacy-Sensitive Information 136 Some fields of a SIP message potentially contain privacy-sensitive 137 information but are not essential for achieving the intended purpose 138 of the message and can be omitted without any side effects. Other 139 fields are essential for achieving the intended purpose of the 140 message and need to contain anonymized values in order to avoid 141 disclosing privacy-sensitive information. Of the privacy-sensitive 142 information listed in section 3, URIs, host names, and IP addresses 143 in Contact, Via, and SDP must be functional (i.e., suitable for 144 purpose) even when they are anonymized. 146 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 147 [I-D.ietf-behave-turn], a user agent can obtain URIs and IP addresses 148 for media and signaling that are functional yet anonymous, and do not 149 identify either the user agent or the user. Instructions on how to 150 obtain a functional anonymous URI and IP address are given in Section 151 4.1 and 4.2, respectively. 153 Host names should be concealed because the user's identity may be 154 guessed from them, but they are not always regarded as critical 155 privacy-sensitive information. 157 In addition, a user agent should be careful not to include any 158 information that identifies the user in optional SIP header fields 159 such as Subject and User-Agent. 161 4.1. Obtaining a Functional Anonymous URI Using the GRUU Mechanism 163 A user agent wanting to obtain a functional anonymous URI MUST 164 support and utilize the GRUU mechanism unless it is able to obtain a 165 functional anonymous URI through other means outside the scope for 166 this document. By sending a REGISTER request requesting GRUU, the 167 user agent can obtain an anonymous URI, which can later be used for 168 the Contact header field. 170 The detailed process on how a user agent obtains a GRUU is described 171 in [I-D.ietf-sip-gruu]. 173 In order to use the GRUU mechanism to obtain a functional anonymous 174 URI, the UA MUST request GRUU in the REGISTER request. If a "temp- 175 gruu" URI parameter and value are present in the REGISTER response, 176 the user agent MUST use the value of the "temp-gruu" as an anonymous 177 URI representing the user agent. This means that the user agent MUST 178 use this URI as its local target and MUST place this URI in the 179 Contact header field of subsequent requests and responses that 180 require the local target to be sent. 182 If there is no "temp-gruu" URI parameter in the 200 response to the 183 REGISTER request, a user agent SHOULD NOT proceed with its 184 anonymization process, unless something equivalent to "temp-gruu" is 185 provided through some administrative means. 187 It is RECOMMENDED that user agent consult the user before sending a 188 request without a functional anonymous URI when privacy is requested 189 from the user. 191 Due to the nature of how GRUU works, the domain name is always 192 revealed when GRUU is used. If revealing the domain name in the 193 Contact header field is a concern, usage of a third-party GRUU server 194 to obtain a temp-gruu that is irrelevant to users' domain, which is 195 outside the scope of this document SHOULD be considered. Refer to 196 the Security Considerations section for details. 198 4.2. Obtaining a Functional Anonymous IP Address Using the TURN 199 Mechanism 201 A user agent that is not provided with a functional anonymous IP 202 address through some administrative means MUST obtain a relayed 203 address (IP address of a relay) if anonymity is desired for use in 204 SDP and in the Via header field. Such an IP address is to be derived 205 from a STUN relay server through the TURN mechanism, which allows a 206 STUN server to act as a relay. 208 Anonymous IP addresses are needed for two purposes. The first is for 209 use in the Via header field of a SIP request. By obtaining an IP 210 address from a STUN relay server, using that address in the Via 211 header field of the SIP request, and sending the SIP request to the 212 STUN relay server, the IP address of the user agent will not be 213 revealed beyond the relay server. 215 The second is for use in SDP as an address for receiving media. By 216 obtaining an IP address from a STUN relay server and using that 217 address in SDP, media will be received via the relay server. Also 218 media can be sent via the relay server. In this way, neither SDP nor 219 media packets reveal the IP address of the user agent. 221 It is assumed that a user agent is either manually or automatically 222 configured through means such as the configuration framework 223 [I-D.ietf-sipping-config-framework] with the address of one or more 224 STUN (Session Traversal Utilities for NAT) [I-D.ietf-behave-turn] 225 relay servers to obtain anonymous IP address. 227 5. User Agent Behavior 229 This section describes how to generate an anonymous SIP message at a 230 user agent. 232 A user agent fully compliant with this document MUST obscure or 233 conceal all the critical UA-inserted privacy-sensitive information in 234 SIP requests and responses as shown in Section 5.1 when user privacy 235 is requested. In addition, the user agent SHOULD conceal the non- 236 critical privacy-sensitive information as shown in Section 5.2. 238 Furthermore, when a user agent uses a relay server to conceal its 239 identity, the user agent MUST send requests to the relay server to 240 ensure request and response follow the same signaling path. 242 5.1. Critical Privacy-Sensitive Information 244 5.1.1. Contact Header Field 246 When using this header field in a dialog-forming request or response 247 or in a mid-dialog request or response, this field contains the local 248 target, i.e., a URI used to reach the user agent for mid-dialog 249 requests and possibly out-of-dialog requests, such as REFER 250 [RFC3515]. The Contact header field can also contain a display-name. 251 Since the Contact header field is used for routing further requests 252 to the user agent, it must include a functional URI even when it is 253 anonymized. 255 When using this header field in a dialog-forming request or response 256 or in a mid-dialog request or response, the user agent MUST anonymize 257 the Contact header field using an anonymous URI ("temp-gruu") 258 obtained through the GRUU mechanism, unless an equivalent functional 259 anonymous URI is provided by some other means. For out-of-dialog 260 request, anonymous URI MAY be set when anonymization is required. 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 f the user wants both anonymity and strong identity, a solution would 313 be to use a third party anonymization service that issues an Address 314 of Record (AoR) for use in the From header field of a request and 315 that also provides a SIP-Identity Authentication Service.Third party 316 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 If one wants to assure anonymization, it is recommended for the user 389 to seek and rely on a third party anonymization service, which is 390 outside the scope of this document. 392 A third party anonymization service provides registrar and TURN 393 service that have no affiliation with the caller's provider, allowing 394 caller to completely withhold its identity. 396 7. IANA Considerations 398 This document requires no action by IANA. 400 8. References 402 8.1. Normative References 404 [I-D.ietf-behave-turn] 405 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 406 Relays around NAT (TURN): Relay Extensions to Session 407 Traversal Utilities for NAT (STUN)", 408 draft-ietf-behave-turn-12 (work in progress), 409 November 2008. 411 [I-D.ietf-sip-gruu] 412 Rosenberg, J., "Obtaining and Using Globally Routable User 413 Agent (UA) URIs (GRUU) in the Session Initiation Protocol 414 (SIP)", draft-ietf-sip-gruu-15 (work in progress), 415 October 2007. 417 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 418 Requirement Levels", BCP 14, RFC 2119, March 1997. 420 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 421 A., Peterson, J., Sparks, R., Handley, M., and E. 422 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 423 June 2002. 425 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 426 Description Protocol", RFC 4566, July 2006. 428 8.2. Informative References 430 [I-D.ietf-sipping-config-framework] 431 Channabasappa, S., "A Framework for Session Initiation 432 Protocol User Agent Profile Delivery", 433 draft-ietf-sipping-config-framework-15 (work in progress), 434 February 2008. 436 [RFC3323] Peterson, J., "A Privacy Mechanism for the Session 437 Initiation Protocol (SIP)", RFC 3323, November 2002. 439 [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private 440 Extensions to the Session Initiation Protocol (SIP) for 441 Asserted Identity within Trusted Networks", RFC 3325, 442 November 2002. 444 [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer 445 Method", RFC 3515, April 2003. 447 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 448 Authenticated Identity Management in the Session 449 Initiation Protocol (SIP)", RFC 4474, August 2006. 451 Authors' Addresses 453 Mayumi Munakata 454 NTT Corporation 456 Email: munakata.mayumi@lab.ntt.co.jp 458 Shida Schubert 459 NTT Corporation 461 Email: shida@ntt-at.com 463 Takumi Ohba 464 NTT Corporation 465 9-11, Midori-cho 3-Chome 466 Musashino-shi, Tokyo 180-8585 467 Japan 469 Phone: +81 422 59 7748 470 Email: ohba.takumi@lab.ntt.co.jp 471 URI: http://www.ntt.co.jp