UA-Driven Privacy Mechanism for SIP
draft-ietf-sip-ua-privacy-04

Status of this Memo

By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”

The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.

The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.

This Internet-Draft will expire on August 9, 2009.

Abstract

This document defines a best current practice for a user agent to generate an anonymous SIP message by utilizing mechanisms such as GRUU (Globally Routable User Agent URIs) and TURN (Traversal Using Relays around NAT) without the need for a privacy service defined in RFC 3323.

Table of Contents

1.  Introduction
2.  Terminology
3.  Concept of Privacy
4.  Treatment of Privacy-Sensitive Information
    4.1.  Obtaining a Functional Anonymous URI Using the GRUU Mechanism
    4.2.  Obtaining a Functional Anonymous IP Address Using the TURN Mechanism
5.  User Agent Behavior
    5.1.  Critical Privacy-Sensitive Information
        5.1.1.  Contact Header Field
        5.1.2.  From Header Field in requests
        5.1.3.  Via Header Field in requests
        5.1.4.  IP Addresses in SDP
    5.2.  Non-Critical Privacy-Sensitive Information
        5.2.1.  Host Names in Other SIP Header Fields
        5.2.2.  Optional SIP Header Fields
6.  Security Considerations
7.  IANA Considerations
8.  References
    8.1.  Normative References
    8.2.  Informative References
§  Authors' Addresses
§  Intellectual Property and Copyright Statements

1.  Introduction

[RFC3323] (Peterson, J., “A Privacy Mechanism for the Session Initiation Protocol (SIP),” November 2002.) defines a privacy mechanism for the SIP (Session Initiation Protocol)[RFC3261] (Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, “SIP: Session Initiation Protocol,” June 2002.), based on techniques available at the time of its publication. This mechanism relies on the use of a separate privacy service to remove privacy-sensitive information from SIP messages sent by a user agent before forwarding those messages to the final destination. Since then, numerous SIP extensions have been proposed and standardized. Some of those enable a user agent to withhold its user's identity and related information without the need for privacy services, which was not possible when RFC 3323 was defined.

The purpose of this document is not to obsolete RFC 3323, but to enhance overall privacy mechanism in SIP by allowing user agent to take control of its privacy, rather than being completely dependent on external privacy service.

The UA-driven privacy mechanism defined in this document will not eliminate the need for the RFC 3323 usage defined in [RFC3325] (Jennings, C., Peterson, J., and M. Watson, “Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks,” November 2002.), which instructs a privacy service not to forward a P-Asserted-Identity header field outside the Trust Domain. In order to prevent forwarding a P-Asserted-Identity header field outside the Trust Domain, a user agent needs to include the Privacy header field with value 'id' (Privacy:id) in the request, even when the user agent is utilizing this specification.

This document defines a best current practice in which a user agent controls all the privacy functions on its own utilizing SIP extensions such as GRUU (Globally Routable User Agent URIs) [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) and TURN (Traversal Using Relays around NAT) [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.).

2.  Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).

privacy-sensitive information:

The information that identifies a user who sends the SIP message, as well as other information that can be used to guess the user's identity.

3.  Concept of Privacy

The concept of privacy in this document is the act of concealing privacy-sensitive information. The protection of network privacy (e.g., topology hiding) is outside the scope for this document.

Privacy-sensitive information includes display-name and URI (Uniform Resource Identifier) in a From header field that can reveal the user's name and affiliation (e.g., company name), and IP addresses or host names in a Contact header field, a Via header field, a Call-ID header field, or an SDP (Session Description Protocol) [RFC4566] (Handley, M., Jacobson, V., and C. Perkins, “SDP: Session Description Protocol,” July 2006.) body that might reveal the location of a user agent.

4.  Treatment of Privacy-Sensitive Information

Some fields of a SIP message potentially contain privacy-sensitive information but are not essential for achieving the intended purpose of the message and can be omitted without any side effects. Other fields are essential for achieving the intended purpose of the message and need to contain anonymized values in order to avoid disclosing privacy-sensitive information. Of the privacy-sensitive information listed in section 3, URIs, host names, and IP addresses in Contact, Via, and SDP must be functional (i.e., suitable for purpose) even when they are anonymized.

With the use of GRUU [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.) and TURN [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.), a user agent can obtain URIs and IP addresses for media and signaling that are functional yet anonymous, and do not identify either the user agent or the user. Instructions on how to obtain a functional anonymous URI and IP address are given in Section 4.1 and 4.2, respectively.

Host names should be concealed because the user's identity may be guessed from them, but they are not always regarded as critical privacy-sensitive information.

In addition, a user agent should be careful not to include any information that identifies the user in optional SIP header fields such as Subject and User-Agent.

4.1.  Obtaining a Functional Anonymous URI Using the GRUU Mechanism

A user agent wanting to obtain a functional anonymous URI MUST support and utilize the GRUU mechanism unless it is able to obtain a functional anonymous URI through other means outside the scope for this document. By sending a REGISTER request requesting GRUU, the user agent can obtain an anonymous URI, which can later be used for the Contact header field.

The detailed process on how a user agent obtains a GRUU is described in [I‑D.ietf‑sip‑gruu] (Rosenberg, J., “Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP),” October 2007.).

In order to use the GRUU mechanism to obtain a functional anonymous URI, the UA MUST request GRUU in the REGISTER request. If a "temp-gruu" URI parameter and value are present in the REGISTER response, the user agent MUST use the value of the "temp-gruu" as an anonymous URI representing the user agent. This means that the user agent MUST use this URI as its local target and MUST place this URI in the Contact header field of subsequent requests and responses that require the local target to be sent.

If there is no "temp-gruu" URI parameter in the 200 response to the REGISTER request, a user agent SHOULD NOT proceed with its anonymization process, unless something equivalent to "temp-gruu" is provided through some administrative means.

It is RECOMMENDED that user agent consult the user before sending a request without a functional anonymous URI when privacy is requested from the user.

Due to the nature of how GRUU works, the domain name is always revealed when GRUU is used. If revealing the domain name in Contact header field is a concern, usage of a third-party GRUU server to obtain a temp-gruu that is irrelevant to users' domain, which is outside the scope of this document SHOULD be considered. Refer to the Security Considerations section for details.

4.2.  Obtaining a Functional Anonymous IP Address Using the TURN Mechanism

A user agent that is not provided with a functional anonymous IP address through some administrative means, MUST obtain a relayed address if anonymity is desired (IP address of a relay) for use in SDP and in Via header. Such IP address is to be derived from a STUN relay server through TURN mechanism, which allows a STUN server to act as a media relay.

Anonymous IP addresses are needed for two purposes. The first is for use in the Via header field of a SIP request. By obtaining an IP address from a STUN relay server, using that address in the Via header field of the SIP request, and sending the SIP request to the STUN relay server, the IP address of the user agent will not be revealed beyond the relay server.

The second is for use in SDP as an address for receiving media. By obtaining an IP address from a STUN relay server and using that address in SDP, media will be received via the relay server. Also media can be sent via the relay server. In this way, neither SDP nor media packets reveal the IP address of the user agent.

It is assumed that a user agent is either manually or automatically configured through means such as the configuration framework [I‑D.ietf‑sipping‑config‑framework] (Channabasappa, S., “A Framework for Session Initiation Protocol User Agent Profile Delivery,” February 2010.) with the address of one or more STUN (Session Traversal Utilities for NAT) [I‑D.ietf‑behave‑turn] (Rosenberg, J., Mahy, R., and P. Matthews, “Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN),” July 2009.) relay servers to obtain anonymous IP address.

5.  User Agent Behavior

This section describes how to generate an anonymous SIP message at a user agent.

A user agent fully compliant with this document MUST obscure or conceal all the critical UA-inserted privacy-sensitive information in SIP requests and responses as shown in Section 5.1 when user privacy is requested. In addition, the user agent SHOULD conceal the non-critical privacy-sensitive information as shown in Section 5.2.

Furthermore, when a user agent uses a relay server to conceal its identity, the user agent MUST send requests to the relay server to ensure request and response follow the same signaling path.

5.1.  Critical Privacy-Sensitive Information

5.1.1.  Contact Header Field

When using this header field in a dialog-forming request or response or in a mid-dialog request or response, this field contains the local target, i.e., a URI used to reach the user agent for mid-dialog requests and possibly out-of-dialog requests, such as REFER [RFC3515] (Sparks, R., “The Session Initiation Protocol (SIP) Refer Method,” April 2003.). The Contact header field can also contain a display-name. Since the Contact header field is used for routing further requests to the user agent, it must include a functional URI even when it is anonymized.

When using this header field in a dialog-forming request or response or in a mid-dialog request or response, the user agent MUST anonymize the Contact header field using an anonymous URI ("temp-gruu") obtained through the GRUU mechanism, unless an equivalent functional anonymous URI is provided by some other means. For out-of-dialog request, anonymous URI MAY be set when anonymization is required.

Refer to Section 4.1 for details on how to obtain an anonymous URI through GRUU, and refer to Section 4.2 for details on how to obtain an IP address through TURN.

A display-name in a Contact header MUST be omitted or "Anonymous".

5.1.2.  From Header Field in requests

Without privacy considerations, this field contains the identity of the user, such as display-name and URI.

RFCs 3261 and 3323 recommend to set "sip:anonymous@anonymous.invalid" as a SIP URI in a From header field when user privacy is requested. This raises an issue when the SIP-Identity mechanism [RFC4474] (Peterson, J. and C. Jennings, “Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP),” August 2006.) is applied to the message, because SIP-Identity requires an actual domain name in the From header field.

A user agent generating an anonymous SIP message supporting this specification MUST anonymize the From header field in one of the two ways described below.

Option 1:

A user agent anonymizes a From header field using an anonymous display-name and an anonymous URI following the procedure noted in section 4.1.1.3 of RFC 3323.

The example form of the From header of option 1 is as follows:

From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774

Option 2:

A user agent anonymizes a From header field using an anonymous display-name and an anonymous URI with user's valid domain name instead of "anonymous.invalid".

The example form of the From header of option 2 is as follows:

From: "Anonymous" <sip:anonymous@atlanta.com>;tag=1928301774

A user agent SHOULD go with option 1 to conceal its domain name in From header field. However, SIP-Identity cannot be used with a From header field in accordance with option 1, because the SIP-Identity mechanism uses authentication based on the domain name.

If a user agent expects the SIP-Identity mechanism to be applied to the request, it is RECOMMENDED to go with option 2. However, the user's domain name will be revealed from the From header field of option 2.

If user wants both anonymity and strong identity, use of a third party anonymization service which issues AoR for the use in From address which also provides SIP-Identity should be considered. Third party anonymization service is out of scope for this document.

5.1.3.  Via Header Field in requests

Without privacy considerations, the bottommost Via header field added by a user agent contains the IP address and port or hostname that are used to reach the user agent for responses.

A user agent generating an anonymous SIP request supporting this specification MUST anonymize the IP address in the Via header field using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided by some other means.

Refer to Section 4.2 for details on how to obtain an IP address through TURN.

Via header SHOULD NOT include a host name.

5.1.4.  IP Addresses in SDP

A user agent generating an anonymous SIP message supporting this specification MUST anonymize IP addresses in SDP, if present, using an anonymous IP address obtained through the TURN mechanism, unless an equivalent functional anonymous IP address is provided by some other means.

Refer to Section 4.2 for details on how to obtain an IP address through TURN.

5.2.  Non-Critical Privacy-Sensitive Information

5.2.1.  Host Names in Other SIP Header Fields

A user agent generating an anonymous SIP message supporting this specification SHOULD conceal host names in any SIP header fields, such as Call-ID and Warning header fields, if considered privacy-sensitive.

5.2.2.  Optional SIP Header Fields

Other optional SIP header fields (such as Call-Info, In-Reply-To, Organization, Referred-By, Reply-To, Server, Subject, User-Agent, and Warning) can contain privacy-sensitive information.

A user agent generating an anonymous SIP message supporting this specification SHOULD NOT include any information that identifies the user in such optional header fields.

6.  Security Considerations

This specification uses GRUU and TURN and inherits any security considerations described in these drafts.

Furthermore, if the provider of the caller intending to obscure its identity consists of a small number of people (e.g. small enterprise, SOHO), the domain name alone can reveal the identity of the caller when this specification is used.

Same can be true when the provider is large, but the receiver of the call only knows few people from the source of call.

There are mainly two places in the message, From header and Contact header, where domain name must be functional.

The domain name in From header can be obscured as described in section 5.1.2, on contrary the Contact header needs to contain a valid domain name at all time to function properly.

It is probably important to note that generally a device will not show the contact address to the receiver, but this does not mean that one can not find the domain name in a message. In fact as long as this specification is used to obscure identity, the message will always contain a valid domain name as it inherits key characteristics of GRUU.

If one wants to assure anonymization, it is recommended for the user to seek and rely on third party anonymization service, which is outside the scope of this document.

A third party anonymization service provides registrar and TURN service which has no affiliation with the caller's provider, allowing caller to completely withhold its identity.

7.  IANA Considerations

This document requires no action by IANA.

8.  References

8.1. Normative References

8.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © The IETF Trust (2009).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an “AS IS” basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.