idnits 2.17.1 draft-ietf-sip-ua-privacy-08.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 (May 20, 2009) is 5454 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-14 ** 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: November 21, 2009 NTT 6 May 20, 2009 8 UA-Driven Privacy Mechanism for SIP 9 draft-ietf-sip-ua-privacy-08 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 November 21, 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 (UA) to generate 48 an anonymous Session Initiation Protocol (SIP) message by utilizing 49 mechanisms such as Globally Routable User Agent URIs (GRUU) and 50 Traversal Using Relays around NAT (TURN) without the need for a 51 privacy service defined in RFC 3323. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 4 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. UA 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 . . . . . . . . . . . . . . . . . . . . . 10 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 79 1. Introduction 81 [RFC3323] defines a privacy mechanism for the Session Initiation 82 Protocol (SIP)[RFC3261], based on techniques available at the time of 83 its publication. This mechanism relies on the use of a separate 84 privacy service to remove privacy-sensitive information from SIP 85 messages sent by a User Agent (UA) before forwarding those messages 86 to the final destination. Since then, numerous SIP extensions have 87 been proposed and standardized. Some of those enable a UA to 88 withhold its user's identity and related information without the need 89 for privacy services, which was not possible when RFC 3323 was 90 defined. 92 The purpose of this document is not to obsolete RFC 3323, but to 93 enhance the overall privacy mechanism in SIP by allowing a UA to take 94 control of its privacy, rather than being completely dependent on an 95 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 UA needs to include the Privacy header field with value 103 'id' (Privacy:id) in the request, even when the UA is utilizing this 104 specification. 106 This document defines a guideline in which a UA controls all the 107 privacy functions on its own utilizing SIP extensions such as 108 Globally Routable User Agent URIs (GRUU) [I-D.ietf-sip-gruu] and 109 Traversal Using Relays around NAT (TURN) [I-D.ietf-behave-turn]. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in [RFC2119]. 117 privacy-sensitive information: 118 The information that identifies a user who sends the SIP 119 message, as well as other information that can be used to 120 guess the user's identity. 122 3. Concept of Privacy 124 The concept of privacy in this document is the act of concealing 125 privacy-sensitive information. The protection of network privacy 126 (e.g., topology hiding) is outside the scope for this document. 128 Privacy-sensitive information includes display-name and Uniform 129 Resource Identifier (URI) in a From header field that can reveal the 130 user's name and affiliation (e.g., company name), and IP addresses or 131 host names in a Contact header field, a Via header field, a Call-ID 132 header field, or a Session Description Protocol (SDP) [RFC4566] body 133 that might reveal the location of a UA. 135 4. Treatment of Privacy-Sensitive Information 137 Some fields of a SIP message potentially contain privacy-sensitive 138 information but are not essential for achieving the intended purpose 139 of the message and can be omitted without any side effects. Other 140 fields are essential for achieving the intended purpose of the 141 message and need to contain anonymized values in order to avoid 142 disclosing privacy-sensitive information. Of the privacy-sensitive 143 information listed in section 3, URIs, host names, and IP addresses 144 in Contact, Via, and SDP are required to be functional (i.e., 145 suitable for purpose) even when they are anonymized. 147 With the use of GRUU [I-D.ietf-sip-gruu] and TURN 148 [I-D.ietf-behave-turn], a UA can obtain URIs and IP addresses for 149 media and signaling that are functional yet anonymous, and do not 150 identify either the UA or the user. Instructions on how to obtain a 151 functional anonymous URI and IP address are given in Section 4.1 and 152 4.2, respectively. 154 Host names need to be concealed because the user's identity can be 155 guessed from them, but they are not always regarded as critical 156 privacy-sensitive information. 158 In addition, a UA needs to be careful not to include any information 159 that identifies the user in optional SIP header fields such as 160 Subject and User-Agent. 162 4.1. Obtaining a Functional Anonymous URI Using the GRUU Mechanism 164 A UA wanting to obtain a functional anonymous URI MUST support and 165 utilize the GRUU mechanism unless it is able to obtain a functional 166 anonymous URI through other means outside the scope for this 167 document. By sending a REGISTER request requesting GRUU, the UA can 168 obtain an anonymous URI, which can later be used for the Contact 169 header field. 171 The detailed process on how a UA obtains a GRUU is described in 172 [I-D.ietf-sip-gruu]. 174 In order to use the GRUU mechanism to obtain a functional anonymous 175 URI, the UA MUST request GRUU in the REGISTER request. If a "temp- 176 gruu" SIP URI parameter and value are present in the REGISTER 177 response, the user agent MUST use the value of the "temp-gruu" as an 178 anonymous URI representing the UA. This means that the UA MUST use 179 this URI as its local target and that the UA MUST place this URI in 180 the Contact header field of subsequent requests and responses that 181 require the local target to be sent. 183 If there is no "temp-gruu" SIP URI parameter in the 200 (OK) response 184 to the REGISTER request, a UA SHOULD NOT proceed with its 185 anonymization process, unless something equivalent to "temp-gruu" is 186 provided through some administrative means. 188 It is RECOMMENDED that UA consult the user before sending a request 189 without a functional anonymous URI when privacy is requested from the 190 user. 192 Due to the nature of how GRUU works, the domain name is always 193 revealed when GRUU is used. If revealing the domain name in the 194 Contact header field is a concern, use of a third party GRUU server 195 is a possible solution, but this is outside the scope of this 196 document. Refer to the Security Considerations section for details. 198 4.2. Obtaining a Functional Anonymous IP Address Using the TURN 199 Mechanism 201 A UA that is not provided with a functional anonymous IP address 202 through some administrative means MUST obtain a relayed address (IP 203 address of a relay) if anonymity is desired for use in SDP and in the 204 Via header field. Such an IP address is to be derived from a Session 205 Traversal Utilities of NAT (STUN) relay server through the TURN 206 mechanism, which allows a 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 UA will not be revealed 213 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 UA. 221 It is assumed that a UA 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. UA Behavior 229 This section describes how to generate an anonymous SIP message at a 230 UA. 232 A UA fully compliant with this document MUST obscure or conceal all 233 the critical UA-inserted privacy-sensitive information in SIP 234 requests and responses as shown in Section 5.1 when user privacy is 235 requested. In addition, the UA SHOULD conceal the non-critical 236 privacy-sensitive information as shown in Section 5.2. 238 Furthermore, when a UA uses a relay server to conceal its identity, 239 the UA MUST send requests to the relay server to ensure request and 240 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 UA for mid-dialog requests and 249 possibly out-of-dialog requests, such as a REFER request[RFC3515]. 250 The Contact header field can also contain a display-name. Since the 251 Contact header field is used for routing further requests to the UA, 252 the UA MUST include a functional URI even when it is anonymized. 254 When using this header field in a dialog-forming request or response 255 or in a mid-dialog request or response, the UA MUST anonymize the 256 Contact header field using an anonymous URI ("temp-gruu") obtained 257 through the GRUU mechanism, unless an equivalent functional anonymous 258 URI is provided by some other means. For other requests and 259 responses, with the exception of 3xx responses, REGISTER requests and 260 200 (OK) responses to a REGISTER request, the UA MUST either omit the 261 Contact header field or use an anonymous URI. 263 Refer to Section 4.1 for details on how to obtain an anonymous URI 264 through GRUU. 266 The UA MUST omit the display-name in a Contact header field or set 267 the display-name to "Anonymous". 269 5.1.2. From Header Field in requests 271 Without privacy considerations, this field contains the identity of 272 the user, such as display-name and URI. 274 RFCs 3261 and 3323 recommend to set "sip:anonymous@anonymous.invalid" 275 as a SIP URI in a From header field when user privacy is requested. 276 This raises an issue when the SIP-Identity mechanism [RFC4474] is 277 applied to the message, because SIP-Identity requires an actual 278 domain name in the From header field. 280 A UA generating an anonymous SIP message supporting this 281 specification MUST anonymize the From header field in one of the two 282 ways described below. 284 Option 1: 286 A UA anonymizes a From header field using an anonymous display-name 287 and an anonymous URI following the procedure noted in section 4.1.1.3 288 of RFC 3323. 290 The example form of the From header field of option 1 is as follows: 292 From: "Anonymous" ;tag=1928301774 294 Option 2: 296 A UA anonymizes a From header field using an anonymous display-name 297 and an anonymous URI with user's valid domain name instead of 298 "anonymous.invalid". 300 The example form of the From header field of option 2 is as follows: 302 From: "Anonymous" ;tag=1928301774 304 A UA SHOULD go with option 1 to conceal its domain name in the From 305 header field. However, SIP-Identity cannot be used with a From 306 header field in accordance with option 1, because the SIP-Identity 307 mechanism uses authentication based on the domain name. 309 If a UA expects the SIP-Identity mechanism to be applied to the 310 request, it is RECOMMENDED to go with option 2. However, the user's 311 domain name will be revealed from the From header field of option 2. 313 If the user wants both anonymity and strong identity, a solution 314 would be to use a third party anonymization service that issues an 315 Address of Record (AoR) for use in the From header field of a request 316 and that also provides a SIP-Identity Authentication Service.Third 317 party anonymization service is out of scope for this document. 319 5.1.3. Via Header Field in requests 321 Without privacy considerations, the bottommost Via header field added 322 to a request by a UA contains the IP address and port or hostname 323 that are used to reach the UA for responses. 325 A UA generating an anonymous SIP request supporting this 326 specification MUST anonymize the IP address in the Via header field 327 using an anonymous IP address obtained through the TURN mechanism, 328 unless an equivalent functional anonymous IP address is provided by 329 some other means. 331 The UA SHOULD NOT include a host name in a Via header field . 333 5.1.4. IP Addresses in SDP 335 A UA generating an anonymous SIP message supporting this 336 specification MUST anonymize IP addresses in SDP, if present, using 337 an anonymous IP address obtained through the TURN mechanism, unless 338 an equivalent functional anonymous IP address is provided by some 339 other means. 341 Refer to Section 4.2 for details on how to obtain an IP address 342 through TURN. 344 5.2. Non-Critical Privacy-Sensitive Information 346 5.2.1. Host Names in Other SIP Header Fields 348 A UA generating an anonymous SIP message supporting this 349 specification SHOULD conceal host names in any SIP header fields, 350 such as Call-ID and Warning header fields, if considered privacy- 351 sensitive. 353 5.2.2. Optional SIP Header Fields 355 Other optional SIP header fields (such as Call-Info, In-Reply-To, 356 Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and 357 Warning) can contain privacy-sensitive information. 359 A UA generating an anonymous SIP message supporting this 360 specification SHOULD NOT include any information that identifies the 361 user in such optional header fields. 363 6. Security Considerations 365 This specification uses GRUU and TURN and inherits any security 366 considerations described in these drafts. 368 Furthermore, if the provider of the caller intending to obscure its 369 identity consists of a small number of people (e.g. small enterprise, 370 SOHO), the domain name alone can reveal the identity of the caller. 372 The same can be true when the provider is large but the receiver of 373 the call only knows a few people from the source of call. 375 There are mainly two places in the message, From header field and 376 Contact header field, where the domain name is expected to be 377 functional. 379 The domain name in the From header field can be obscured as described 380 in section 5.1.2, whereas the Contact header field needs to contain a 381 valid domain name at all times in order to function properly. 383 Note: Generally a device will not show the contact address to the 384 receiver, but this does not mean that one can not find the domain 385 name in a message. In fact as long as this specification is used to 386 obscure identity, the message will always contain a valid domain name 387 as it inherits key characteristics of GRUU. 389 Note: For UAs that use a temporary GRUU confidentiality does not 390 extend to parties that are permitted to register to the same AoR or 391 are permitted to obtain temporary GRUUs when subscribed to the 'reg' 392 event package [RFC3680] for the AoR. To limit this, it is suggested 393 that the authorization policy for the 'reg' event package permit only 394 those subscribers authorized to register to the AoR to receive 395 temporary GRUUs. With this policy, the confidentiality of the 396 temporary GRUU will be the same whether or not the 'reg' event 397 package is used. 399 If one wants to assure anonymization, it is suggested for the user to 400 seek and rely on a third party anonymization service, which is 401 outside the scope of this document. 403 A third party anonymization service provides registrar and TURN 404 service that have no affiliation with the caller's provider, allowing 405 caller to completely withhold its identity. 407 7. IANA Considerations 409 This document requires no action by IANA. 411 8. References 413 8.1. Normative References 415 [I-D.ietf-behave-turn] 416 Rosenberg, J., Mahy, R., and P. Matthews, "Traversal Using 417 Relays around NAT (TURN): Relay Extensions to Session 418 Traversal Utilities for NAT (STUN)", 419 draft-ietf-behave-turn-14 (work in progress), April 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