SIP M. Munakata
Internet-Draft S. Schubert
Intended status: Informational T. Ohba
Expires: January 15, 2009 NTT
July 14, 2008
UA-Driven Privacy Mechanism for SIP
draft-ietf-sip-ua-privacy-02
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 January 15, 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 and TURN without the need for a privacy service defined in RFC
3323.
Munakata, et al. Expires January 15, 2009 [Page 1]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Concept of Privacy . . . . . . . . . . . . . . . . . . . . . . 3
4. Treatment of Privacy-Sensitive Information . . . . . . . . . . 4
4.1. Obtaining Functional Anonymous URI Using GRUU Mechanism . 4
4.2. Obtaining Functional Anonymous IP Address Using TURN
Mechanism . . . . . . . . . . . . . . . . . . . . . . . . 5
5. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 5
5.1. Essential Privacy-Sensitive Information . . . . . . . . . 5
5.1.1. Contact . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.2. From . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1.3. Via . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1.4. IP addresses in SDP . . . . . . . . . . . . . . . . . 7
5.2. Non-Essential Privacy-Sensitive Information . . . . . . . 7
5.2.1. Host Names in Other SIP Headers . . . . . . . . . . . 7
5.2.2. Optional SIP Headers . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
Intellectual Property and Copyright Statements . . . . . . . . . . 10
Munakata, et al. Expires January 15, 2009 [Page 2]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
1. Introduction
[RFC3323] defines a privacy mechanism for the Session Initiation
Protocol (SIP) [RFC3261], based on techniques available at the time
of its publication. This mechanism relies on the use of a separate
privacy service to remove 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.
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] and TURN (Traversal Using Relay NAT)
[I-D.ietf-behave-turn].
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].
privacy-sensitive information:
The information that identifies a user who sends the SIP
message, as well as the supplementary 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
identity of a user and supplementary information. The scope of this
document is to withhold the privacy-sensitive information of the user
who sends the SIP message from other users and intermediaries
handling the message. The protection of network privacy (e.g.,
topology hiding) is outside the scope of this document.
Privacy-sensitive information includes display-name and URI (Uniform
Resource Identifier) in a From header that can reveal the user's name
and affiliation (e.g., company name), contact information in a
Contact header that is used to communicate with the user agent, IP
addresses in Via header and SDP (Session Description Protocol)
[RFC4566] that tell the location of a user agent. A host name that
appears in headers such as Call-ID is also regarded as privacy-
sensitive information because it may reveal the user's domain name.
Munakata, et al. Expires January 15, 2009 [Page 3]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
4. Treatment of Privacy-Sensitive Information
The two pieces of information that a user agent needs to obscure
while sustaining its purpose and functionality are the URI and IP
address used for establishing a media/signaling session.
Essential privacy-sensitive information in a UA-generated SIP message
includes display-names (in From and Contact), as well as URIs (in
From and Contact) and IP addresses (in Contact, Via, and SDP). Among
these, URIs and IP addresses in Contact, Via, and SDP must be
functional even when they are anonymized.
With the use of GRUU [I-D.ietf-sip-gruu] and TURN
[I-D.ietf-behave-turn], a user agent can obtain URI and IP address
for media and signaling that are functional yet anonymous, and do not
identify the user agent nor 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 essential
privacy-sensitive information.
In addition, a user agent should be careful not to include any
information that identifies the user in optional SIP headers such as
Subject and User-Agent.
4.1. Obtaining Functional Anonymous URI Using GRUU Mechanism
A user agent wanting to obtain functional anonymous URI MUST support
and SHOULD utilize the GRUU mechanism unless the user agent obtains
functional anonymous URI through other means outside the scope of
this document. By sending a REGISTER request requesting GRUU, the
user agent can obtain an anonymous URI, which can later be used for
Contact header.
The detailed process on how a user agent obtains a GRUU is described
in [I-D.ietf-sip-gruu].
If the Registrar supports the GRUU and returns a REGISTER response,
the user agent SHOULD search within the REGISTER response for a
"temp-gruu" URI parameter, which provides the desired privacy
property.
If the "temp-gruu" URI parameter and value exist within the REGISTER
response, the user agent SHOULD use the value of the "temp-gruu" as
an anonymous URI representing the user agent. This URI SHOULD be
used for Contact header.
Munakata, et al. Expires January 15, 2009 [Page 4]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
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.
4.2. Obtaining Functional Anonymous IP Address Using TURN Mechanism
It is assumed that a user agent is either manually or automatically
configured through means such as a configuration framework
[I-D.ietf-sipping-config-framework] with the address of one or more
STUN (Session Traversal Utilities for NAT)
[I-D.ietf-behave-turn]relay servers.
Anonymous IP addresses are needed in two places to maintain privacy,
one to be used in signaling such as in a Via header, another to be
used in SDP for media.
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 the media 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.
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 essential 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-essential privacy-sensitive information as shown in Section 5.2.
5.1. Essential Privacy-Sensitive Information
5.1.1. Contact
Without privacy considerations, this field contains a URI or an IP
address used to reach the user agent for mid-dialog requests and
possibly out-of-dialog requests, such as REFER [RFC3515]. The
Contact header can also contain a display-name. Since the Contact
Munakata, et al. Expires January 15, 2009 [Page 5]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
header is essential for routing further requests to the user agent,
it must include a functional URI of IP address even when it is
anonymized.
A user agent generating an anonymous SIP message supporting this
specification MUST anonymize a Contact header using an anonymous URI
("temp-gruu") through GRUU mechanism or an anonymous IP address
through TURN mechanism unless an equivalent functional anonymous URI
or IP address is provided by some other means.
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
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 when user privacy is requested. This
raises issues, when the mechanism of SIP-Identity [RFC4474] is
applied to the message because the SIP-Identity requires an actual
domain name in a From header.
A user agent generating an anonymous SIP message supporting this
specification MUST anonymize a From header in an either way described
below.
A user agent SHOULD anonymize a From header using an anonymous
display-name and an anonymous URI following the procedure noted in
section 4.1.1.3 of RFC 3261 unless it is aware that SIP-Identity
mechanism will be applied to the request.
The recommended form of the From header is:
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
If a user agent is aware that the SIP-Identity mechanism will be
applied to the request, it SHOULD include valid hostname instead of
"anonymous.invalid" for a URI in a From header as follows.
From: "Anonymous" <sip:anonymous@atlanta.com>;tag=1928301774
Munakata, et al. Expires January 15, 2009 [Page 6]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
5.1.3. Via
Without privacy considerations, the bottommost Via header 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 message supporting this
specification MUST anonymize an IP address in a Via header, if
present, using an anonymous IP address through 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, but it is not essential.
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 through 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-Essential Privacy-Sensitive Information
5.2.1. Host Names in Other SIP Headers
A user agent generating an anonymous SIP message supporting this
specification SHOULD conceal host names in any SIP headers, such as
Call-ID and Warning headers, but it is not always regarded as
essential privacy-sensitive information.
5.2.2. Optional SIP Headers
Other optional SIP headers (such as Calll-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 headers.
Munakata, et al. Expires January 15, 2009 [Page 7]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
6. Security Considerations
Many of the security considerations in either [RFC3323] and [RFC3325]
remains valid even with the use of this specification but this
specification does not introduce any new security consideration.
In fact, this specification alleviates the security consideration
described in RFC 3323 by providing a privacy mechanism which is
executed at the user agent rather than being dependent on the network
, as a result providing the user agent with certainty that crucial
privacy sensitive information are concealed.
7. IANA Considerations
This document requires no action by IANA.
8. References
8.1. Normative References
[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)",
draft-ietf-behave-turn-09 (work in progress), July 2008.
[I-D.ietf-sip-gruu]
Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft-ietf-sip-gruu-15 (work in progress),
October 2007.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
Munakata, et al. Expires January 15, 2009 [Page 8]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
8.2. Informative References
[I-D.ietf-sipping-config-framework]
Channabasappa, S., "A Framework for Session Initiation
Protocol User Agent Profile Delivery",
draft-ietf-sipping-config-framework-15 (work in progress),
February 2008.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
Authors' Addresses
Mayumi Munakata
NTT Corporation
Email: munakata.mayumi@lab.ntt.co.jp
Shida Schubert
NTT Corporation
Email: shida@ntt-at.com
Takumi Ohba
NTT Corporation
9-11, Midori-cho 3-Chome
Musashino-shi, Tokyo 180-8585
Japan
Phone: +81 422 59 7748
Email: ohba.takumi@lab.ntt.co.jp
URI: http://www.ntt.co.jp
Munakata, et al. Expires January 15, 2009 [Page 9]
Internet-Draft UA-Driven Privacy Mechanism for SIP July 2008
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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.
Munakata, et al. Expires January 15, 2009 [Page 10]
