SIP M. Munakata
Internet-Draft S. Schubert
Expires: August 23, 2007 T. Ohba
NTT
February 23, 2007
SIP Privacy Clarified
draft-munakata-sip-privacy-clarified-00.txt
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 23, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Abstract
This document defines the privacy mechanisms for the Session
Initiation Protocol (SIP). Specifically, guidelines are provided for
the creation of messages that do not divulge personal identity
information. A "privacy service" logical role for intermediaries is
defined to answer some privacy requirements that user agents cannot
satisfy themselves. Finally, means are presented by which a user can
request particular functions from a privacy service.
Munakata, et al. Expires August 23, 2007 [Page 1]
Internet-Draft SIP Privacy Clarified Feb 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . . . 6
3.1. User-Provided Privacy . . . . . . . . . . . . . . . . . . 6
3.2. Network-Provided Privacy . . . . . . . . . . . . . . . . . 6
3.3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4. Requirements . . . . . . . . . . . . . . . . . . . . . . . 7
4. Privacy Header Definition . . . . . . . . . . . . . . . . . . 7
4.1. Syntax of Privacy Header . . . . . . . . . . . . . . . . . 7
4.2. Semantics of priv-values . . . . . . . . . . . . . . . . . 8
5. Target for Each priv-value . . . . . . . . . . . . . . . . . . 9
5.1. Target SIP Headers for Each priv-value . . . . . . . . . . 10
5.2. Target SIP Parameters and SDP Attributes for Each
priv-value . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Treatment of User Privacy Related Information . . . . . . . . 11
6.1. Display-Names and URIs . . . . . . . . . . . . . . . . . . 11
6.1.1. Display-Names . . . . . . . . . . . . . . . . . . . . 12
6.1.2. URI User Part And Host Name . . . . . . . . . . . . . 12
6.1.3. Obtaining Anonymous URI at a User Agent . . . . . . . 13
6.1.4. IP Addresses . . . . . . . . . . . . . . . . . . . . . 13
6.1.5. Obtaining Anonymous IP Address to be Used by a User
Agent . . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Target SIP Headers . . . . . . . . . . . . . . . . . . . . 14
6.2.1. Call-ID . . . . . . . . . . . . . . . . . . . . . . . 15
6.2.2. Call-Info . . . . . . . . . . . . . . . . . . . . . . 15
6.2.3. Contact . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.4. From . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2.5. Geolocation . . . . . . . . . . . . . . . . . . . . . 16
6.2.6. History-Info . . . . . . . . . . . . . . . . . . . . . 17
6.2.7. Identity/Identity-Info . . . . . . . . . . . . . . . . 17
6.2.8. Organization . . . . . . . . . . . . . . . . . . . . . 18
6.2.9. P-Asserted-Identity . . . . . . . . . . . . . . . . . 18
6.2.10. Record-Route . . . . . . . . . . . . . . . . . . . . . 18
6.2.11. Referred-By . . . . . . . . . . . . . . . . . . . . . 19
6.2.12. Reply-To . . . . . . . . . . . . . . . . . . . . . . . 19
6.2.13. Server . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.14. Subject . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.15. User-Agent . . . . . . . . . . . . . . . . . . . . . . 20
6.2.16. Via . . . . . . . . . . . . . . . . . . . . . . . . . 20
6.2.17. Warning . . . . . . . . . . . . . . . . . . . . . . . 21
6.3. SIP Parameters / SDP Attributes . . . . . . . . . . . . . 21
6.3.1. c/m Lines . . . . . . . . . . . . . . . . . . . . . . 21
6.3.2. o Line . . . . . . . . . . . . . . . . . . . . . . . . 22
6.3.3. i/u/e/p Lines . . . . . . . . . . . . . . . . . . . . 22
6.4. Considerations for Non-Target SIP Headers/Parameters . . . 22
6.4.1. In-Reply-To . . . . . . . . . . . . . . . . . . . . . 22
6.4.2. Path . . . . . . . . . . . . . . . . . . . . . . . . . 23
Munakata, et al. Expires August 23, 2007 [Page 2]
Internet-Draft SIP Privacy Clarified Feb 2007
6.4.3. Replaces Header/Parameter . . . . . . . . . . . . . . 23
6.4.4. Route . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4.5. Service-Route . . . . . . . . . . . . . . . . . . . . 26
6.4.6. Target-Dialog . . . . . . . . . . . . . . . . . . . . 26
7. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 27
7.1. Locating Privacy Service . . . . . . . . . . . . . . . . . 27
7.2. Generating Anonymous Request . . . . . . . . . . . . . . . 28
7.2.1. Intermediary Inserted/Modified Information . . . . . . 29
7.3. Requesting Anonymization at Privacy Service . . . . . . . 29
7.4. Requesting No Privacy Treatment . . . . . . . . . . . . . 29
8. Privacy Service Behavior . . . . . . . . . . . . . . . . . . . 30
8.1. Handling Message with Privacy:nw-level . . . . . . . . . . 31
8.2. Handling Message with Privacy:all . . . . . . . . . . . . 31
8.3. Handling Message with Privacy:none . . . . . . . . . . . . 32
9. Proxy Server Behavior . . . . . . . . . . . . . . . . . . . . 32
10. Guidelines on the Privacy Consideration for Future RFCs . . . 33
10.1. Future RFCs with Privacy Implications . . . . . . . . . . 33
10.2. Future RFCs Defining a New priv-values . . . . . . . . . . 33
11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
13.1. Normative Reference . . . . . . . . . . . . . . . . . . . 35
13.2. Informative Reference . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
Intellectual Property and Copyright Statements . . . . . . . . . . 38
Munakata, et al. Expires August 23, 2007 [Page 3]
Internet-Draft SIP Privacy Clarified Feb 2007
1. Introduction
This document provides privacy requirements and mechanisms for the
Session Initiation Protocol (SIP).
The purpose of this document is to specify and clarify the privacy
mechanism for SIP in order to secure the privacy of message senders.
This document obsoletes RFC 3323 and redefines the privacy mechanism,
if approved. It also clarifies the extensions to the SIP privacy
that are defined in RFCs 3325 and 4244.
Privacy is defined in this document as the withholding of the
identity of a person (and related personal information) from one or
more parties in an exchange of communications, specifically a SIP
dialog. These parties potentially include the intended
destination(s) of messages and/or any intermediaries handling these
messages.
In SIP, identity is most commonly carried in the form of a SIP URI
and an optional display-name. A SIP address-of-record has a form
similar to an email address with a SIP URI scheme (for example,
sip:alice@atlanta.com). A display-name is a string containing a name
for the identified user (for example, "Alice"). SIP identities of
this form commonly appear in the To, From and P-Asserted-Identity
header fields of SIP requests and responses. A user may have many
identities that they use in different contexts.
There are numerous other places in SIP messages in which identity-
related information can be revealed. For example, the Contact header
field contains a SIP URI, one that is commonly as revealing as the
address-of-record in the From. In some headers, the originating user
agent can conceal identity information as a matter of network policy
without affecting the operation of the SIP protocol. However,
certain headers are used in the routing of subsequent messages in a
dialog, and must therefore be populated with functional data when
replaced with information that would provide privacy.
The privacy problem is further complicated by proxy servers (also
referred to in this document as "intermediaries" or "the network")
that add headers of their own or on behalf or the user, such as the
Record-Route, Via, Organization and Identity headers. Information in
these headers could inadvertently reveal something about the
originator of a message; for example, a Via header might reveal the
service provider through whom the user sends requests, which might in
turn strongly hint at the user's identity to some recipients. Many
of the new SIP extensions since the creation of privacy mechanism can
only be added by the intermediaries and therefore the participation
of intermediaries is even more crucial to providing privacy in SIP
than ever before.
Munakata, et al. Expires August 23, 2007 [Page 4]
Internet-Draft SIP Privacy Clarified Feb 2007
Although there are cases where intermediary invokes the privacy
functions on behalf of the user or to fulfill the domain/network
policy (e.g. topology hiding), and this may be done with or without
the privacy mechanism defined in this document. However this
document focuses on the invocation of privacy functions using a SIP
procedures thereby does not go into how intermediaries may conduct
privacy function without the SIP procedures.
This document also makes an assumption that when user requests
privacy, it is based on a binary decision. The user either requests
privacy for the whole message or no privacy at all.
In order to cover all the use cases defined in this document, this
document defines priv-values of "nw-level", "all", and "none" as the
values to be set in a Privacy header. The existing priv-values of
"id" defined in RFC 3325 and "history" defined in RFC 4244 will be
maintained for the sake of backwards compatibility. This document
clarifies the SIP headers and related parameters that need to be
handled by the network entities who execute privacy function for each
priv-value, and provides the recommended behaviors for user agents
and privacy service on treatment of each headers/parameters.
This document begins with a section that provides a general framework
and architecture for the privacy mechanism in SIP (Section 3),
followed by a section that describes definitions of Privacy header
(Section 4), followed by a section that describe the target headers/
parameters (Section 5), followed by a section that describes the
desired treatment of user privacy related information (Section 6),
followed by user agent behavior (Section 7), privacy service behavior
(Section 8), and proxy behavior (Section 9) and provides guidelines
on writing privacy considerations for future RFCs (Section 10).
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 RFC 2119 [1].
priv-value: Values registered with IANA to be used in Privacy header.
Three priv-values, "nw-level", "all", and "none" are
specified in this document. The extended priv-values of
"id" and "history" are specified in RFC 3325 and 4244,
respectively.
privacy service: A network entity which executes privacy functions
before forwarding messages to elements that are not
trusted. It is sometimes abbreviated to PS in this
document.
Munakata, et al. Expires August 23, 2007 [Page 5]
Internet-Draft SIP Privacy Clarified Feb 2007
3. Varieties of Privacy
3.1. User-Provided Privacy
A user agent can execute privacy functions by itself for user
inserted information. For example, the baseline SIP specification
permits a user agent to populate the From header field of a request
with an anonymous value. User agents can take similar steps to avoid
revealing any other unnecessarily identity information in related SIP
headers/parameters including SDP attributes (this is discussed
further in Section 6).
Furthermore by utilizing some of the SIP extensions and existing
internet protocols a user agent can construct a message withholding
all the user inserted information such as Contact and Via headers.
The user agent executing the privacy functions for all the user
inserted information is not suffice to make the message fully
anonymized, this is due to the information that are added or modified
by the intermediaries. Thus aid by network entity to provide privacy
on intermediary inserted/modified information is necessary to provide
full anonymization.
3.2. Network-Provided Privacy
A privacy service can execute partial or full privacy functions on
behalf of a user agent when requested.
A privacy service may execute the privacy functions only for the
intermediary inserted/modified information in a message when the user
inserted information in the message is already anonymized by the user
agent. Otherwise, a privacy service may execute the privacy
functions for all the user privacy related information those inserted
by the user agent as well as those inserted by the intermediaries.
Even if there is no explicit privacy request by the user agent, a
privacy service may obscure the user privacy related information
based on network or domain policy (e.g. based on the contractual
agreement).
When user's privacy is requested, the privacy service either delete
or modify values in headers/parameters that reveal user's identity.
When the privacy services modify headers/parameters that are
essential to route further messages to the originating user agent,
the former value must be recoverable and restored in the further
messages inside the dialog.
Munakata, et al. Expires August 23, 2007 [Page 6]
Internet-Draft SIP Privacy Clarified Feb 2007
3.3. Use Cases
The followings are the most common use cases for invoking privacy
functions. Regarding the user privacy related information,
(1) privacy is required.
(1)-1 A user agent anonymizes all the user inserted information
by itself and the user agent or intermediary requests a
privacy service to execute privacy functions for
intermediary inserted/modified information.
(1)-2 A user agent or intermediary requests a privacy service
to execute all the privacy functions.
(2) privacy is not required. The user does not want privacy at all
and would like to reveal its identity.
If a user agent can execute all the privacy functions for the user
inserted information, then the functions SHOULD be executed at the
user agent. If a user agent can provide only partial or no privacy
function, the user agent SHOULD NOT execute any privacy functions and
rather it SHOULD delegate the task to the privacy service.
3.4. Requirements
The followings are requirements to cover the use cases in the
previous section.
Req 1: A user agent SHOULD be able to indicate to a privacy service
that it desires obfuscation and anonymization on information
that may reveal something about the user.
Req 2: user agent SHOULD be able to indicate to a privacy service
that it desires obfuscation and anonymization on information
that are inserted and modified by intermediaries.
Req 3: A user agent SHOULD be able to indicate to a privacy service
that it desires no privacy and that it would like to reveal
its identity to the recipient.
4. Privacy Header Definition
4.1. Syntax of Privacy Header
This document defines a SIP header, Privacy, that can be used to
specify privacy handling for requests and responses. The ABNF [2]
syntax is as follows.
Munakata, et al. Expires August 23, 2007 [Page 7]
Internet-Draft SIP Privacy Clarified Feb 2007
Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value)
priv-value = "nw-level" / "all" / "none" / token
The following table specifies extensions to Table 2 in [3].
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Privacy amrd o o o o o o
Header field SUB NOT PRK IFO UPD MSG
___________________________________________________________
Privacy o o o o o o
Editor's Note: How does a privacy service deal REGISTER requests
with a Privacy header? Should Privacy headers not
appear in REGISTER request? It needs a further
study.
A user agent SHOULD include a Privacy header when it requires
privacy. Note that some intermediaries may also add the Privacy
header to messages, including privacy services. However, such
intermediaries SHOULD only do so if they are operating at a user's
behest, for example if a user has an administrative arrangement with
the operator of the intermediary that it will add such a Privacy
header. An intermediary SHOULD NOT modify the Privacy header in any
way if the "none" priv-value is already specified.
When a Privacy header is constructed, it MUST consist of at least one
priv-value.
An example of the syntax of the Privacy header is given below:
Privacy: all
4.2. Semantics of priv-values
The semantics of priv-values defined in this document are described
below:
nw-level:
Request that a privacy service removes or obscures intermediary
inserted/modified information. A privacy service should remove or
obscure headers/parameters that are inserted or modified by
intermediaries after a user agent sends out the message (such as
Record-Route, History-Info, P-Asserted-Identity, etc.)
Munakata, et al. Expires August 23, 2007 [Page 8]
Internet-Draft SIP Privacy Clarified Feb 2007
Editor's Note: The priv-value of "nw-level" may not be appropriate.
The other candidates are "intermediary-level" and
"intermediary", which may be too long.
all:
Request that a privacy service removes or obscures all user privacy
related information, i.e. both user inserted information and
intermediary inserted/modified information. A privacy service should
remove or obscure all the user inserted and intermediary inserted/
modified information that may reveal sender's identity.
none:
A privacy service should not perform any privacy functions for the
purpose of obscuring user agent's information. A privacy service
should not remove or modify the Privacy header.
This document doesn't obsolete priv-values of "id" and "history".
For the semantics of these priv-values, refer to RFCs 3325 and 4244.
With this document, "user", "session", and "critical" are NOT
RECOMMENDED to be used and be kept solely for the backward
compatibility reason.
Note: Location of privacy service is out of scope. It depends on
deployments and network policy.
5. Target for Each priv-value
Tables in this section show the recommended treatment of SIP headers/
parameters per priv-value categorized by entity providing the privacy
function. The SIP headers/parameters that are not shown in the
tables are regarded as a nontarget of these priv-values. Some
nontarget headers/parameters may carry user privacy related
information, headers/parameters that may carry user privacy related
information that need privacy treatment despite the lack of priv-
values are described in 6.4.
Note that the SIP headers/parameters that are not covered in this
document are regarded as irrelevant to user privacy.
The treatments listed in the tables are only recommendations. Exact
treatments to obscure SIP headers/parameters listed here may depend
on implementation and network policy. This specification does not
prevent privacy services to manipulate other headers based on the
local policy.
Munakata, et al. Expires August 23, 2007 [Page 9]
Internet-Draft SIP Privacy Clarified Feb 2007
Note: The scope of these tables are SIP headers and related
parameters specified in RFCs or internet drafts that are
likely to be RFCs in near future. There may be more to be
included in these tables. Further study will be necessary.
5.1. Target SIP Headers for Each priv-value
Table 1 below shows a recommended treatment of each SIP headers for
each of the priv-value. The table also illustrates the desired
treatment per entity involved in the privacy function. Detail
description on exactly what kind of treatment is recommended per SIP
headers are covered in section 6.
Behaviors of UA PS PS PS PS
priv-values nw-level nw-level all id history
Target headers
Call-ID anonymize anonymize(Note1)
Call-Info not add delete delete
Contact anonymize anonymize
From anonymize anonymize
Geolocation not add delete delete
History-Info not add delete delete delete
Identity anonymize
Identity-Info anonymize
Organization not add delete delete
P-Asserted-Identity delete delete delete
Record-Route anonymize anonymize
Referred-By anonymize* anonymize*
Reply-To not add delete
Server not add delete
Subject not add delete
User-Agent not add delete
Via anonymize anonymize anonymize
Warning anonymize anonymize
Table 1: Recommended PS/UA behaviors for each SIP headers
Note 1: Any time a privacy service modifies a Call-ID, it SHOULD
retain the former and modified values. Then it SHOULD
restore the former value in a Call-ID header and other
corresponding headers (such as In-Reply-To, Replaces, and
Target-Dialog) in any further relevant messages that are sent
to the originating user agent. It SHOULD also modify a
Call-ID header and other corresponding headers/parameters
(such as Target-Dialog and "replaces" parameter) in any
further relevant messages that are sent by the originating
user agent.
Munakata, et al. Expires August 23, 2007 [Page 10]
Internet-Draft SIP Privacy Clarified Feb 2007
Note 2: Asterisk indicates that involvement of a privacy service and
treatment of the relevant header, depends on the
circumstance. Description can be found in section describing
the treatment of header marked with asterisk in Section 6.
Note 3: In-Reply-To, Path, Route, Service-Route, and Target-Dialog
headers are not the target of these priv-value (should not be
anonymized or modified by a user agent and a privacy service
based on priv-value in a Privacy header). Refer to 6.4 for
details.
5.2. Target SIP Parameters and SDP Attributes for Each priv-value
Table 2 below shows a recommended treatment of each SIP parameters
and SDP attributes per priv-values.
Behaviors of UA PS PS PS PS
priv-values nw-level nw-level all id history
Target parameters
SDP c/m lines anonymize anonymize
SDP o lines anonymize anonymize
SDP i/u/e/p lines anonymize anonymize
Table 2: Recommended PS/UA behaviors for each
SIP parameters and SDP attributes
6. Treatment of User Privacy Related Information
The following URIs, SIP headers and related parameters may be of
privacy concern. This section describes what kind of user privacy
related information is included in each SIP header/parameter, and how
to hide such information at a user agent or a privacy service to
provide anonymity.
6.1. Display-Names and URIs
A certain amount of privacy can be afforded by choosing to populate
SIP headers with URIs and display-names that do not reveal any
identity information. In some of the header fields (for example, the
Reply-To and From headers), URIs are not used in further signaling
within the current dialog. In others, like the Contact header, an
inaccurate URI will result in a failure to route subsequent requests
within the dialog.
Display-names, URIs, and IP addresses used to present/convey user
Munakata, et al. Expires August 23, 2007 [Page 11]
Internet-Draft SIP Privacy Clarified Feb 2007
agent's address SHOULD be obfuscated according to the following
guidelines. Relevant headers that may be affected by this include
From, Reply-To, Contact, and Via.
6.1.1. Display-Names
It is a relatively common practice in email and other applications to
use an assumed name in the display-name component of the From header
field. Outside of a business context (especially in applications
such as instant messaging or Internet gaming) the use of such aliases
is unlikely to provide a cause for distrust.
It is RECOMMENDED to use a display-name of "Anonymous" for anonymous
SIP requests.
6.1.2. URI User Part and Host Name
The structure of a URI itself can reveal or conceal a considerable
amount of personal information such as full name and employer of the
party. Today, the SIP specification recommends a URI with
"anonymous" in the user portion of the From header.
In some URIs, such as those that appear in Contact headers, it MAY
also make sense to omit the username altogether, and provide only a
hostname, like: sip:anonymous-sip.com.
Sometimes, merely changing the username will not be enough to conceal
a user's identity. A user's SIP service provider might decisively
reveal a user's identity (if it reflected something like a small
company or a personal domain). So in this case, even though the URI
would not dereference to the anonymous user, humans might easily
guess the user's identity and know the proper form of their address-
of-record.
For these reasons, the URI hostname SHOULD be anonymized as well as
URI username.
It is assumed that the user that requests privacy wishes to receive
future requests and responses within this dialog. In order to route
future requests and received future response, the URI needs to be
functional even when it is anonymized for a privacy. This imposes a
user agent to construct or obtain a functional anonymous URI rather
than simply using sip:anonymous@anonymous.invalid. How to generate
and obtain a functional anonymous URI at the user agent is described
in Section 6.1.3.
Munakata, et al. Expires August 23, 2007 [Page 12]
Internet-Draft SIP Privacy Clarified Feb 2007
6.1.3. Obtaining Anonymous URI at a User Agent
A user agent wanting to obtain functional anonymous URI SHOULD
support and SHOULD utilize Global Routable User Agent URI (GRUU) [4]
mechanism. By sending a REGISTER request requesting GRUU, UA can
obtains an anonymous URI which can later be used for From, Contact
and other headers where URI of the originator is needed.
The detail process on how a user agent obtains a GRUU is described in
[4]. If the Registrar supports GRUU and returns a REGISTER response,
user agent SHOULD search within the REGISTER response for a "temp-
gruu" uri parameter.
If "temp-gruu" uri parameter with value exists within the REGISTER
response, user agent SHOULD use the value of the "temp-gruu" as an
anonymous URI representing the originator. This URI SHOULD be used
for Contact, From etc where originator of the URI is required.
The user agent setting the "temp-gruu" as a GRUU SHOULD set
"Anonymous" as a display name to any header where display name of the
originator is set, it indicates the anonymity of the request to
intermediaries that may invocate some services based on the anonymity
of the call. The temp-gruu alone is not sufficient to invocate such
services because GRUU is merely a URI and does not indicate that it's
an anonymous URI in any way.
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. Instead the user agent
SHOULD send the request to the privacy service requesting the
complete anonymization by setting "all" to the Privacy header, more
detail on how to request complete anonymization from the privacy
service is covered in section 7.3.
6.1.4. IP Addresses
Is there much additional privacy in using an IP address rather than a
hostname? It does prevent someone who casually inspects a message
from gathering information that they might see otherwise. However,
reverse-resolving such addresses is generally trivial, and
substituting an IP address for a hostname could introduce some
complications, for example due to NAT and firewall traversal
concerns. Headers used in routing may also rely on certain DNS
practices to provide services that would be lost if an IP address is
used in place of a hostname.
A user agents and a privacy services anonymizing SIP messages SHOULD
Munakata, et al. Expires August 23, 2007 [Page 13]
Internet-Draft SIP Privacy Clarified Feb 2007
utilize mechanism to obtain functional anonymous IP address. How to
generate and obtain a functional anonymous IP address at the user
agent is described in Section 6.1.5.
As IP addresses are generally present in SDP, if the privacy function
is executed at the privacy services to anonymize IP addresses, the
privacy service needs to act as a back-to-back user agent (B2BUA).
6.1.5. Obtaining Anonymous IP to be Used by a User Agent
If a user agent wanting to obtain an anonymous IP address and port
for use in the SDP, Via header and other SIP headers requiring source
IP address, a user agent SHOULD contact a Traversal Using Relay NAT
(TURN) [8] server. It uses normal TURN processing to obtain an IP
address on the server which route to it.
Ideally, this is done with a TURN server that is specifically
dedicated to anonymous services, and thus can provide a higher degree
of anonymity by obtaining anonymized IP address from a separate
provider than a one originator is subscribed to.
The client uses the TURN-derived addresses in those fields of the
message where the UA wishes to anonymize an IP address. These
include IP address used in SDP, Call-ID and Via.
If TURN is non-existent and user agent has no other way to obtain
anonymous IP address, user agent SHOULD NOT proceed with its
anonymization process. Instead the user agent SHOULD send the
request to the privacy service requesting the full anonymization by
setting "all" to the Privacy header. Details on how to request
complete anonymization from the privacy service is covered in section
7.3.
6.2. Target SIP Headers
This section describes privacy considerations and recommended
treatment for each SIP header that may reveal user privacy related
information. This section goes into detail of how each header
affects the privacy, the desired treatment of the value by user agent
and privacy service, and other instructions/additional notes
necessary to provide privacy.
In some headers, the originating user agent can conceal identity
information as a matter of network policy without affecting the
operation of the SIP protocol. However, certain headers (such as
Contact) are used in the routing of subsequent messages in a dialog,
and must therefore be populated with functional data.
Munakata, et al. Expires August 23, 2007 [Page 14]
Internet-Draft SIP Privacy Clarified Feb 2007
Any time that a privacy service needs to modify any dialog-matching
headers (such as Call-ID) for privacy reasons, it SHOULD act as a
transparent B2BUA, and it MUST persist the former values of the
dialog-matching headers. These values MUST be restored in any
messages that are sent to the originating user agent.
6.2.1. Call-ID
This field frequently contains an IP address or hostname appended to
the Call-ID value.
A user agent constructing anonymous SIP requests SHOULD exclude host
name and IP address from a Call-ID header or anonymize them by using
functional anonymous URI or IP address.
A privacy service SHOULD delete the host name and IP address from a
Call-ID header or anonymize them by using functional anonymous URI or
IP address when the request contains Privacy:all. Generally this is
done by replacing the IP address or host name with that of the
privacy service.
Call-ID is essential to dialog matching, therefore, any time a
privacy service modifies this field, it SHOULD retain the former
value, then restore the value in a Call-ID header in any messages
that are sent to the originating user agent inside the dialog.
Privacy service SHOULD be prepared to receive a request outside of
the dialog containing the value of the Call-ID set by the PS in other
SIP headers (e.g. In-Reply-To/Replaces/Target-Dialog), at least
while the dialog state is active for the dialog Call-ID was modified
by that PS. When receiving such request, the Call-ID value contained
in the relevant headers indicated above, SHOULD be replaced with one
retained.
Note: This is only possible if the privacy service maintains state
and retains all the information it modified to provide
privacy. Some PS is known to encrypt information prior to
obfuscation in Via header etc. In which case the PS can't
correlate the Call-ID value modified to original Call-ID.
Further challenges are imposed to ensure PS always receives
the message that addresses information PS modified.
Refer to each section, 6.4.1 (In-Reply-To), 6.4.3 (Replaces), and
6.4.6 (Target-Dialog) for detail considerations.
6.2.2. Call-Info
This field contains additional information about the user.
Munakata, et al. Expires August 23, 2007 [Page 15]
Internet-Draft SIP Privacy Clarified Feb 2007
A user agent constructing anonymous SIP requests SHOULD NOT add a
Call-Info header.
A privacy service SHOULD delete the Call-Info headers when the user
privacy is requested with Privacy:nw-level or Privacy:all.
6.2.3. Contact
This field contains a URI used to reach the user agent for mid-dialog
requests and possibly out-of-band requests, such as REFER [9]. Since
the Contact header is essential for routing further requests and
response to the user agent, it must be populated with functional URI
even when it is anonymized.
A user agent constructing anonymous SIP requests SHOULD anonymize a
Contact header using functional anonymous URI or IP address.
A privacy service SHOULD anonymize a Contact header using functional
anonymous URI when the user privacy is requested with Privacy:all.
6.2.4. From
This field contains the identity of the user, such as display-name
and URI.
A user agent constructing anonymous SIP requests SHOULD anonymize a
From header using anonymous display-name and functional anonymous
URI.
A privacy service SHOULD anonymize a From header when the user
privacy is requested with Privacy:all.
6.2.5. Geolocation
This field contains either a URI which may be a cid URI (Content
Identification, per RFC2392 [14]) or a location-by-reference URI to
be dereferenced by a location recipient to retrieve the location of
the UAC. Where the Geolocation header [12] contains a cid URI, the
actual location information is included in the body of the message in
the form of a PIDF-LO [15]. If the URI in the Geolocation header
contains a location-by-reference URI, the location information of the
user agent will be retrieved from the referenced entity.
A user agent constructing anonymous SIP requests SHOULD NOT add a
Geolocation header, as well as PIDF-LO in the message body.
Network entities such as proxy SHOULD NOT add a Geolocation header
when the privacy of Privacy:nw-level or Privacy:all is requested.
Munakata, et al. Expires August 23, 2007 [Page 16]
Internet-Draft SIP Privacy Clarified Feb 2007
A privacy service SHOULD delete the Geolocation header and PIDF-LO if
present in the message when the user privacy is requested with
Privacy:nw-level or Privacy:all.
6.2.6. History Info
History-Info header [11] that is set by user agent contains the
user's URI. History-Info headers set by network entities may contain
URIs to which the request was forwarded or retargeted.
A user agent constructing anonymous SIP requests SHOULD NOT add a
History-Info header.
A privacy service SHOULD delete the History-Info headers when the
user privacy is requested with Privacy:nw-level or Privacy:all.
In addition, the History-Info header can reveal general routing
information. Thus, network policy MAY also be used to determine
whether to include the History-Info header at all, whether to capture
a specific Request-URI in the header, or whether it be included only
in the Request as it is retargeted within a specific domain.
Refer to RFC 4244 [11] for detail behaviors to deal with History-Info
headers.
6.2.7. Identity/Identity-Info
Identity header [17] field contains a signature used for validating
the identity. Identity-Info header field contains a reference to the
certificate of the signer of Identity headers. Identity-Info header
may reveal the information about the administrative domain of the
user.
The signature in an Identity header provides integrity protection
over From, To, Call-ID, Cseq, Date, Contact headers and message body.
The integrity protection is violated if a privacy service modifies
these headers and message body for the purpose of user privacy
protection.
When a privacy service receives a request with an Identity header and
Privacy:all, it SHOULD compute the signature using its own
certificate (Assuming the privacy service has ability to access
domain certificate) and replace the value of an Identity header after
executing privacy functions on relevant headers that are considered
user privacy related (From, Contact, etc.) and/or message body. A
privacy service SHOULD replace the value of an Identity-Info header
with the reference to the certificate it used to compute the
signature.
Munakata, et al. Expires August 23, 2007 [Page 17]
Internet-Draft SIP Privacy Clarified Feb 2007
If the privacy service cannot compute the signature due to lack of
its authority or lack of valid certificate, it SHOULD delete both
Identity and Identity-Info headers when the user privacy is requested
with Privacy:all is requested.
When a privacy service receives a request with an Identity header and
Privacy:nw-level, it SHOULD check the domain portion of From and
domain portion of the Identity-Info value, if they match the header
SHOULD be left untouched, if they mismatched the privacy service
SHOULD remove Identity-Info and Identity header.
6.2.8. Organization
This field contains additional information about the user.
A user agent constructing anonymous SIP requests SHOULD NOT add a
Organization header.
A privacy service SHOULD delete the Organization headers when the
user privacy is requested with Privacy:nw-level or Privacy:all.
6.2.9. P-Asserted-Identity
This header contains a network verified and asserted identity of the
user sending a SIP message.
A privacy service SHOULD delete the P-Asserted-Identity headers
before it forwards the message to an entity that is not trusted, when
the user privacy is requested with Privacy:nw-level, Privacy:all, or
Privacy:id.
6.2.10. Record-Route
This field may reveal information about the administrative domain of
the user.
In order to hide Record-Route headers while keeping routability to
the sender, privacy services can execute a practice referred to as
"stripping". Stripping is to remove all the Record-Route headers
that have been added to the request prior to its arrival at the
privacy service and then add a single Record-Route header
representing itself. In this case, the privacy service needs to
retain the removed headers and restore them in a response.
Besides, privacy services can remove the Record-Route headers, and
encrypt it into a single header. In this case, the privacy service
needs to decrypt the header and restore the former values in a
response.
Munakata, et al. Expires August 23, 2007 [Page 18]
Internet-Draft SIP Privacy Clarified Feb 2007
A privacy service SHOULD strip or encrypt any Record-Route headers
that have been added to a request before it reaches the privacy
service when the user privacy is requested with Privacy:nw-level or
Privacy:all.
6.2.11. Referred-By
Referred-By header [16] carries a SIP URI representing the identity
of the referrer.
Referred-By header is an anonymization target when the REFER request
with Referred-By header is sent by the user whose privacy is
requested to be processed in the privacy service.
A user agent constructing anonymous REFER requests SHOULD anonymize a
Referred-By header using functional anonymous URI.
A privacy service SHOULD anonymize a Referred-By header in REFER
request using functional anonymous URI when the user privacy is
requested with Privacy:all.
On the other hand, Referred-By header is not an anonymization target
when it appears in request other than REFER (e.g. INVITE) because the
URI in the Referred-By header never represents the sender of the
request.
Example 1:
Referrer request no privacy and referee request privacy
Alice > REF(Referred-By:Alice) > Bob
Bob > INV(Referred-By:Alice, Privacy:all) > PS >
INV(Referred-By:Alice) > Carol
Example 2:
Referrer requested privacy and referee request privacy
Alice > REF(Referred-By:Alice, Privacy:all) > PS >
REF(Referred-By:X) > Bob
Bob > INV(Referred-By:X, Privacy:all) > PS >
INV(Referred-By:X) > Carol
6.2.12. Reply-To
This field contains a URI that can be used to reach the user on
subsequent call-backs.
A user agent constructing anonymous SIP messages SHOULD NOT add a
Reply-To header in the message.
A privacy service SHOULD delete a Reply-To header when the user
privacy is requested with Privacy:all.
Munakata, et al. Expires August 23, 2007 [Page 19]
Internet-Draft SIP Privacy Clarified Feb 2007
6.2.13. Server
This field contains information about the software used by the UAS to
handle the request.
A user agent constructing anonymous SIP responses SHOULD NOT add a
Server header in the response.
A privacy service SHOULD delete a Server header when the user privacy
is requested with Privacy:all.
6.2.14. Subject
This field contains freeform text about the subject of the call.
Which may include a text describing something about the user.
A user agent constructing anonymous SIP requests SHOULD NOT add a
Subject header.
A privacy service SHOULD delete a Subject header when the user
privacy is requested with Privacy:all.
6.2.15. User-Agent
This field contains user agent's information.
A user agent constructing anonymous SIP messages SHOULD NOT add a
User-Agent header.
A privacy service SHOULD delete User-Agent header when the user
privacy is requested with Privacy:all.
6.2.16. Via
A bottommost Via header added by a user agent contains an IP address
and port or hostname that are used to reach the user agent for
responses. Via headers added by proxies may reveal information about
the administrative domain of the user.
A user agent constructing anonymous SIP requests SHOULD anonymize a
Via header that represents itself by using functional anonymous IP
address and port. Detail on how to obtain anonymous IP address and
port is covered in section 6.1.5.
A privacy service SHOULD strip or encrypt any Via headers that have
been added prior to reaching the privacy service when the user
privacy is requested with Privacy:nw-level or Privacy:all. Refer to
6.2.10 for details of stripping and encryption.
Munakata, et al. Expires August 23, 2007 [Page 20]
Internet-Draft SIP Privacy Clarified Feb 2007
A privacy service SHOULD recover the original values of Via headers
when handing a response in order to route the response to the
originator.
Even if the bottommost Via header is already anonymized before
reaching a Privacy service, all Via headers including the bottommost
one will be stripped or encrypted by the privacy service. No Via
stripping is required when handling responses.
6.2.17. Warning
This field may contain host name of the user agent.
A user agent constructing anonymous SIP responses SHOULD NOT include
host name in a Warning header.
A privacy service SHOULD modify a Warning header by deleting host
name portion from the header when the user privacy is requested with
Privacy:all.
6.3. SIP Parameters / SDP Attributes
This section describes privacy considerations for each SIP related
parameter including SDP attributes that may reveal information about
the user.
When the privacy functions for user inserted information are
requested to be executed at a privacy service, user agents MUST NOT
encrypt SDP bodies in messages using S/MIME.
6.3.1. c/m Lines
The c and m lines in the SDP body convey an IP address and port for
receiving media.
A user agent constructing anonymous SIP messages SHOULD anonymize the
IP address and port in m and c lines using functional anonymous IP
address and port.
A privacy service SHOULD anonymize the IP address and port in m and c
lines using functional anonymous IP address and port, when the user
privacy is requested with Privacy:all. This is generally done
through replacing IP address and port present in the SDP with that of
a relay server.
How to obtain functional anonymous IP address at a user agent is
covered in section 6.1.5.
Munakata, et al. Expires August 23, 2007 [Page 21]
Internet-Draft SIP Privacy Clarified Feb 2007
6.3.2. o Line
The username and IP address in this attribute may reveal information
about the user.
A user agent constructing anonymous SIP messages SHOULD anonymize the
username and IP address in o lines by setting username to "-" and by
setting functional anonymous IP address as IP address.
A privacy service SHOULD anonymize the username and IP address in o
lines by setting username to "-" and setting functional anonymous IP
address as IP address, when the user privacy is requested with
Privacy:all.
How to obtain functional anonymous IP address at a user agent is
covered in section 6.1.5.
6.3.3. i/u/e/p Lines
These lines may contain information about the user.
A user agent constructing anonymous SIP messages SHOULD NOT include
their information in i, u, e, and p lines.
A privacy service SHOULD modify i, u, e, and p lines to delete user's
identity information when the user privacy is requested with Privacy:
all.
6.4. Considerations for Non-Target SIP Headers/Parameters
6.4.1. In-Reply-To
This field enumerates the Call-IDs that the call references or
returns. The Call-ID may contains an IP address or a host name of
the originator of the referenced call. The originator of the
referenced call cannot be the sender of the request with In-Reply-To
header. Therefore, there is no information of the sender, and this
header is outside the anonymization target.
As described in section 6.2.1 (Call-ID), regardless of priv-value or
presence of a Privacy header, once a privacy service modifies a
Call-ID in the previous request, a privacy service SHOULD restore the
former value in a In-Reply-To header in the related INVITE request.
Example:
Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob
Bob > INV(In-Reply-To:C2, Privacy:none) > PS >
INV(Call-ID:C1) > Alice
Munakata, et al. Expires August 23, 2007 [Page 22]
Internet-Draft SIP Privacy Clarified Feb 2007
Note: This is only possible if the privacy service maintains state
and retains all the information it modified to provide
privacy even after the dialog is terminated, which would be
an unlikely event. Call back is difficult to realize once a
privacy service is involved in forming the dialog to be
referenced.
6.4.2. Path
This field may contain information about the administrative domain
and/or the visited domain of the user agent, however, the Path header
is not the target of any priv-values.
Path headers [17] only appear in REGISTER requests and responses.
Given that a user agent sends a REGISTER request with Privacy:nw-
level or Privacy:all, Path headers inserted by intermediaries may
contain information about the domain where the user is visiting, and
there is no point in hiding such user location information from the
registrar who receives the REGISTER request.
The only reason privacy may be considered desirable is if the visited
domain wants to withhold its topology from the home domain of the
user. However, anonymization of network privacy related information
is out of scope.
Editor's Note: If the Privacy header is not allowed in REGISTER
requests, Path header is automatically outside of the
target.
6.4.3. Replaces Header/Parameter
Replaces header [18] and "replaces" parameter contain dialog
identifiers of a dialog to be replaced, which are composed of
Call-ID, local tag, and remote tag.
The sender of the INVITE with a Replaces header is never an
originating user agent or terminating user agent of the target dialog
to be replaced. And therefore the Call-ID within the Replaces header
is never generated by the sender. Therefore, this header is outside
the anonymization target per priv-value.
The "replaces" parameter is not the target of any particular priv-
values neither. The parameter appears in a Refer-To header in REFER
request, and its functionality when anonymized depends on the
circumstances it is used. The REFER may work and may not work
depending on three criteria below.
Munakata, et al. Expires August 23, 2007 [Page 23]
Internet-Draft SIP Privacy Clarified Feb 2007
1. Who generated the Call-ID.
2. Where on the signaling path is the privacy service.
3. Who initiates the REFER with "replaces" parameter.
As described in section 6.2.1 (Call-ID), regardless of priv-value or
presence of a Privacy header, once a privacy service modifies a
Call-ID in the request, a privacy service SHOULD monitor headers that
may contain Call-ID and restore the portion of the value representing
the modified Call-ID to original Call-ID value in a Replaces header
received.
Main challenge for this to function properly is that privacy service
has to be on a signaling path to the originator for every dialogs.
Which is generally not possible.
Followings are few examples exploring when Replaces parameter works
and fails.
Example 1:
Transfer initiated by the originator PS added for INV and REF
Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:all) > PS >
REF(Refer-To:Bob?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > Bob
Example 2:
Transfer initiated by the originator PS added only for INV
Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1) > Bob (FAIL)
Note: Example 2 would succeed if the same PS (that modifies the
Call-ID in the INVITE from Alice) is added for REFER too and
modifies the value in "replaces" parameter from C1 to C2, even
if there is no Privacy header in the REFER.
Example 3:
Transfer initiated by the originator PS added only for REF
Alice > INV(Call-ID:C1) > INV(Call-ID:C1) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1, Privacy:all) > PS >
REF(Refer-To:Bob?Replaces=C1) > Carol
Carol > INV(Replaces:C1, Privacy:all) > PS' > INV(Replaces:C1) > Bob
Munakata, et al. Expires August 23, 2007 [Page 24]
Internet-Draft SIP Privacy Clarified Feb 2007
Example 4:
Transfer initiated by the terminating party PS added for both INV
Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob
Bob > REF(Refer-To:Alice?Replaces=C2) > Carol
Carol > INV(Replaces:C2) > PS > INV(Replaces:C1) > Alice
Note: Example 4 succeeds because the same PS (that modifies the
Call-ID in the INVITE from Alice) checks the incoming requests
and modifies the value in a Replaces header in the INVITE from
Carol to the former value of Call-ID (C1).
Example 5:
Hold
Alice > INV(Call-ID:C1, Privacy:all) > PS > INV(Call-ID:C2) > Bob
Alice > REF(Refer-To:Bob?Replaces=C1) > Music-Server
Music-Server > INV(Replaces:C1) > Bob (FAIL)
Note: Example 5 would succeed if the same PS (that modifies the
Call-ID in the INVITE from Alice) is added for INVITE from
Music-Server and modifies the value in a Replaces header from
C1 to C2.
As you can see from examples above, in some scenarios, information
carried in Replaces header/parameter would result in failing the
REFER. This would not happen if the anonymization is done at a user
agent.
6.4.4. Route
This field may contain information about the administrative domain of
the user agent, however, the Route header is not the target of any
priv-values.
Route headers appear only in SIP requests to force routing through
the listed set of proxies. If a privacy service anonymizes the Route
header, the routing does not function. Furthermore, there is no risk
to reveal the information in the Route headers to further network
entities including terminating user agent, because a proxy removes
the value from the Route header when it replaces the value in the
Request-URI as defined in RFC 3261.
6.4.5. Service-Route
Service-Route [19] headers only appear in 200 OK responses for
REGISTER requests, and contains information about the registrar. The
purpose of the privacy mechanism defined in this document is to
secure user's privacy, and the case where a registrar sets a Privacy
header is not considered here. Therefore, the Service-Route header
is not the target of any priv-values.
Munakata, et al. Expires August 23, 2007 [Page 25]
Internet-Draft SIP Privacy Clarified Feb 2007
Furthermore, if the Service-Route is replaced with other value less
sensitive (That of a SBC etc.), it is not because it was requested by
the user but rather it would be likely to be at the convenience of
the domain policy/network policy and use of privacy for this purpose
seems illogical.
Editor's Note: If the Privacy header is not allowed in responses
for REGISTER requests, Service-Route header is
automatically outside of the target.
6.4.6. Target-Dialog
Target-Dialog header faces exactly the same issues seen in Replaces
header. Please refer to section 6.4.3 for why this is not a target
for any particular priv-values and how a privacy service still needs
to evaluate and modify the value contained even if no privacy is
requested.
Munakata, et al. Expires August 23, 2007 [Page 26]
Internet-Draft SIP Privacy Clarified Feb 2007
7. User Agent Behavior
A user agent fully compliant to this document SHOULD anonymize its
messages by following the guidelines in section 7.2, when user
privacy is requested. If the ability of the user agent to obfuscate
information is limited to only part of the information listed in
table 1 under UA/nw-level, the user agent SHOULD NOT try to anonymize
the messages but instead utilize the privacy service and delegate the
anonymization as described in the section 7.3.
Any attempt to anonymize the message at the user agent without its
ability to obscure all of the information listed in table 1 under UA/
nw-level may result in privacy implications, revealing information
about the originator to the recipient of the message.
Although when privacy service is temporarily out of service, non
existent or unreachable from the network where originator is
connected, limited anonymization may be useful.
In any case whenever the user agent is aware of the potential privacy
implication due to either a lack of ability to obscure the privacy
sensitive information or absence of privacy services, it is
RECOMMENDED that user agent somehow communicates the possible privacy
implication to the originating user.
7.1. Locating Privacy Service
Even with a user-agent fully compliant to this document, providing
complete anonymity is not always possible as headers modified/
inserted by intermediaries may contain information about the
originator. In order for the user agent to insure message sent is
fully anonymized by the time it is received by the recipient, aid
from privacy services is imperative.
The most obvious means for the user agent to invoke the privacy
function is to direct a request through an intermediary known to act
as a privacy service. Location of privacy service may be learnt
through means such as configuration framework [13], manual
configuration etc.
If the originating user agent is aware of the URI for the privacy
service it SHOULD address the privacy service by setting the URI of
the privacy service in the "Route" header.
If the originating user wishes to keep their local administrative
domain a secret, then they must use a third-party anonymization
service outside of any of the principal domains associated with the
user. Such domain may exist strictly for providing anonymity.
Munakata, et al. Expires August 23, 2007 [Page 27]
Internet-Draft SIP Privacy Clarified Feb 2007
It is highly RECOMMENDED that user agents use network or transport
layer security, such as TLS, when contacting a privacy service.
Ideally, user agents SHOULD establish a direct (i.e., single pre-
loaded Route header) connection to a privacy service; this will both
allow the user to inspect a certificate presented by the privacy
service, and it will provide confidentiality for requests that will
reduce the chances that the information that the privacy service will
obscure is revealed before a message arrives at the privacy service.
By establishing a direct connection to a privacy service, the user
also eliminates the possibility that intermediaries could remove
requests for privacy. If a direct connection is impossible, users
SHOULD use a mechanism like SIPS to guarantee the use of lower-layer
security all the way to the privacy service.
If a user agent believes that it is sending a request directly to a
privacy service, it SHOULD include a Proxy-Require header containing
an option-tag, "privacy", That way, in the unlikely event that the
user agent sends a request to an intermediary that does not support
the extensions described in this document, the request will fail,
although it will not guarantee that privacy function will be executed
as the user agent requested.
When a user agent is aware of the fact that direct connection to
privacy service isn't possible, user agent MAY display a warning to
the user about the possible privacy implication(e.g. "Unable to
guarantee privacy protection").
Note: Currently there is no way for a user agent to tell if a
privacy function was invoked on an outgoing request/response.
There is also no means to insure the invocation of privacy
functions, use of the option-tag in Proxy-Require merely
means that proxy understands the specification and does not
necessary mean the proxy/privacy-service can provide privacy
function requested. It is possible that request with
certain level or privacy requested passes through proxies
and privacy service, and as it happens none of the
intermediaries support the level of privacy and as a
consequences reaching the recipient without any privacy
treatment revealing everything about the originator.
7.2. Generating Anonymous Request
If user agent compliant to this document is aware of its ability that
it can fully anonymize and obscure its request and response on its
own, it SHOULD obscure or conceal all the information listed in table
1 under column "UA". For detail of what kind of treatment UA needs
to conduct over each headers and parameters refer to section 6.
The two imperative information user agent needs to obscure while
Munakata, et al. Expires August 23, 2007 [Page 28]
Internet-Draft SIP Privacy Clarified Feb 2007
sustaining its purpose and functionality is URI and IP address used
for establishing media/signaling session. Instruction on how to
obtain function anonymous URI and IP address is covered in section
6.1.3 and 6.1.5 respectively. For any other headers and information,
the user agent SHOULD follow the instruction in section 6 for the
headers listed in table 1 under column "UA".
7.2.1. Intermediary Inserted/modified Information
Some information inserted by an intermediaries such as History-Info
[11], Record-Route header, P-Asserted Identity [10], Identity-Info
[6], Geolocation [12] etc. may reveal or identify the originator of
the request. These information can not be modified or omitted by a
user agent.
A user agent therefore needs to request the privacy service to help
anonymize the request even if it obscured all the information listed
in table 1 and 2 under column "UA". To request a privacy service to
obscure or omit information set or modified by the intermediaries,
the user agent SHOULD set "nw-level" as the priv-value to the privacy
header.
7.3. Requesting Anonymization at Privacy Service
If a user agent compliant to this document is unaware of its ability
or is aware of lack of ability to fully anonymize its request/
response, it SHOULD request anonymization from the privacy service
whenever anonymization is desired. The User agent delegating the
task of privacy function to the privacy service can do so by setting
the value of Privacy header to "all".
If direct connection to the privacy service is not available or
possible, the ramification may be that request will not be
anonymized. So it is highly recommended to establish a direct
connection to the privacy service whenever its possible to ensure
privacy function is executed or else be notified that level of
privacy requested is not possible.
7.4. Requesting No Privacy Treatment
If a user agent compliant to this document desires no privacy and
rather desires to see no privacy functions be applied to its message
and as a result reveal its identity to the recipient, the user agent
SHOULD request no privacy by setting the value of Privacy header to
"none".
Munakata, et al. Expires August 23, 2007 [Page 29]
Internet-Draft SIP Privacy Clarified Feb 2007
8. Privacy Service Behavior
The privacy service role is instantiated by a network intermediary,
frequently by entities that can act as SIP proxy servers. The
function of a privacy service is to supply privacy functions for SIP
messages that cannot be provided by user agents themselves.
When a message arrives at a server that can act as a privacy service,
the service SHOULD evaluate the level of privacy requested in a
Privacy header. Usually, only the services explicitly requested
should be applied. However, privacy services MAY have some means
outside SIP of ascertaining the preferences of the user (such as a
pre-arranged user profile) and therefore they MAY perform such other
privacy functions without an explicit Privacy header. Performing
even a privacy function on user privacy related information in a
privacy service could be useful, for example, when a user is sending
messages from a legacy client that does support the Privacy header,
or a user agent that does not allow the user to configure the values
of headers that could reveal personal information. However, if the
Privacy header value of "none" is specified in a message, privacy
services SHOULD NOT perform any privacy function on the headers
containing user privacy related information and SHOULD NOT remove or
modify the Privacy header.
If privacy is requested by an originator, it is generally assumed
that privacy is desired for the duration of the dialog. In which
case privacy service SHOULD Record-Route itself in the dialog-forming
request to ensure its ability to provide privacy function for the
duration of the dialog. When doing so, if Record-Route already
present it should modify its value according to section 6.2.10. If
it's not present it should Record-Route itself by adding the Record-
Route header.
Privacy services MUST implement support for the "none" and "id"
privacy tokens, and MAY implement "nw-level", "all", "history" and
any of other privacy tokens that are obsolete by this document. In
some cases, the privacy service will not be capable of fulfilling the
requested level of privacy.
A privacy service SHOULD be prepared to receive a request outside of
a dialog relating to an active dialog privacy service is providing a
service to(Call-ID in Replaces, Target-Dialog etc), in which case the
privacy service SHOULD do its best to recover the original value so
originator can handle the request correctly (e.g. Call-ID modified
by the privacy service in Replaces to Call-ID originator had sent).
When a privacy service performs one of the functions corresponding to
a privacy level listed in the Privacy header, it SHOULD remove the
Munakata, et al. Expires August 23, 2007 [Page 30]
Internet-Draft SIP Privacy Clarified Feb 2007
corresponding priv-value from the Privacy header - otherwise, any
other privacy service involved with routing this message might
unnecessarily apply the same function, which in many cases would be
undesirable. When the priv-value has been removed from the Privacy
header, the entire Privacy header MUST be removed from a message.
When the privacy service removes the entire Privacy header, if the
message is a request, the privacy service MUST also remove any
"privacy" option-tag from the Proxy-Require header field of the
request.
When the privacy service receives a request with a level of privacy
it does not support, the privacy service MUST decline the request
with 4xx response unless it can forward the request to a privacy
service that can provide the level of privacy requested.
Note: Do we need a new response code to notify the user agent
about lack of support for requested level of privacy?
8.1. Handling Message with Privacy:nw-level
If a privacy level of "nw-level" is requested, then the requestor has
asked the privacy service to help to obscure information that may
reveal information about the requestor that were added by the
intermediaries. However, the values that have been so obscured must
be recoverable when further messages in the dialog need to be routed
to the originating user agent. In order to provide these functions
the privacy service must frequently act as a transparent B2BUA.
Firstly, a request with privacy level of "nw-level" entails that the
intermediaries SHOULD NOT add any headers to the message that reveal
any identity or any other user privacy related information which may
impose privacy implication. The relevant information which privacy
service SHOULD omit or obscure when this level of privacy is
requested are listed in table 1 under "nw-level/PS". Detail
treatment of listed headers are described in section 6.
Note that when a privacy service is handling a request and providing
privacy on behalf of the destination of the request, providing
privacy for Record-Route headers downstream of the privacy service is
significantly more complicated. This document recommends no way of
statefully restoring those headers if they are stripped.
8.2. Handling Message with Privacy:all
If a privacy level of "all" is requested, then the requestor has
asked the privacy service to help to obscure every possible
information that may reveal information about the requestor,
Munakata, et al. Expires August 23, 2007 [Page 31]
Internet-Draft SIP Privacy Clarified Feb 2007
including all the listed in section 6. However, the values that have
been so obscured must be recoverable when further messages in the
dialog need to be routed to the originating user agent. In order to
provide these functions the privacy service must frequently act as a
transparent B2BUA.
Firstly, a request with privacy level of "all" entails that the
privacy server SHOULD NOT add any headers to the message that reveal
any identity or any other user-level information which may impose
privacy implication. The relevant information which privacy service
SHOULD omit or obscure when this level of privacy is requested are
listed in table 1 under "all". Detail treatment of listed headers
are described in section 6.
Note that when a privacy service is handling a request and providing
privacy on behalf of the destination of the request, providing
privacy for Record-Route headers downstream of the privacy service is
significantly more complicated. This document recommends no way of
statefully restoring those headers if they are stripped.
8.3. Handling Message with Privacy:none
If a privacy level of "none" is requested, then the originator has
asked the privacy service to apply no privacy functions to the
relevant message.
The privacy services SHOULD NOT remove or alter headers to obscure.
Intermediaries SHOULD NOT remove or alter a Privacy header whose
priv- value is "none".
9. Proxy Server Behavior
If a proxy server receives a request containing a Privacy header with
values "all" or "nw-level", the proxy server should route the call to
a privacy service if it is aware of the location of the privacy
service and if no pre-configured route set exists in the request.
When proxy server receives a request containing a Privacy header with
values "all" or "nw-level", the proxy server SHOULD not add any
information that may reveal something about the originator that is
irrelevant to routing.
Munakata, et al. Expires August 23, 2007 [Page 32]
Internet-Draft SIP Privacy Clarified Feb 2007
10. Guidelines on the privacy consideration for future RFCs
This section gives the guidelines on providing a privacy
considerations for future documents defining new SIP headers,
parameters and/or new priv-values that may impact privacy in someway.
10.1. Future RFCs with Privacy Implications
Whenever a new SIP header or a SIP parameter is defined,
consideration MUST be made whether the new header/parameter is a
target of the privacy mechanism. In other words, if the header/
parameter carries privacy sensitive information, the privacy
considerations SHOULD be part of the document that defines the new
header/parameter. The privacy considerations SHOULD specify the
treatment desired for each priv-values on the header/parameter, the
document defines. This may include but not limited to clarifying the
priv-value that imposes manipulation/obfuscation and the desired
treatment of relevant header/parameter by the privacy function.
Understating the privacy consideration when defined extension carries
privacy sensitive information may have the ramification undesired.
10.2. Future RFCs defining a new priv-values
When defining a new priv-value, the target headers/parameters MUST be
specified. If the specified priv-value requires different treatment
from what's specified in this document, that needs to be clarified as
well.
Note: It is RECOMMENDED to use existing priv-values and avoid
defining a new priv-value to keep the privacy mechanism
simple.
11. Security Considerations
Messages that request privacy require confidentiality and integrity.
Without integrity, the requested privacy functions could be
downgraded or eliminated, potentially exposing identity information.
Without confidentiality, eavesdroppers on the network (or any
intermediaries between the user and the privacy service) could see
the very personal information that the user has asked the privacy
service to obscure.
All of the network-provided privacy functions in this document entail
a good deal of trust for the privacy service. Users should only
trust privacy services that are somehow accountable to them.
Munakata, et al. Expires August 23, 2007 [Page 33]
Internet-Draft SIP Privacy Clarified Feb 2007
Operators of privacy services should be aware that in the eyes of
downstream entities, a privacy service will be the only source to
which anonymous messages can be traced.
Note that authentication mechanisms, including the Digest
authentication method described in the SIP specification, are outside
the scope of the privacy considerations in this document. Revealing
identity through authentication is highly selective, and may not
result in the compromise of any private information. Obviously,
users that do not wish to reveal their identity to servers that issue
authentication challenges MAY elect not to respond to such
challenges.
Some recommendations are provided to secure the messages when privacy
services are in use.
o It is recommended that user agent uses SIPS or TLS for transport
protocol to secure the message from malicious entity eavesdropping
on the call.
o If the privacy service's URI is known It is also recommended to
use S/MIME to protect the message for both confidentiality and
integrity.
12. IANA Considerations
This document adds values to the IANA registry for priv-value tokens.
If more values are to be added they should be indexed by priv-value
tokens and should contain a short semantic description of the new
value. The values to be added with this draft are as follows:
o nw-level: Request that a privacy service removes or obscures
intermediary inserted/modified information.
o all: Request that a privacy service removes or obscures all user
privacy related information.
New values for the "Privacy" header can only be defined by IETF
Consensus including RFC publication (RFC 2434). IANA registration
for the "Privacy" header field values is required along with the RFC
publication.
Authors of extensions to the SIP protocol that expose personal
information about the participants in sessions are advised against
extending the "Privacy" header - rather, it is preferable to create
new identity mechanisms whose privacy can be managed by the user
agent without the agency of intermediaries.
Munakata, et al. Expires August 23, 2007 [Page 34]
Internet-Draft SIP Privacy Clarified Feb 2007
13. References
13.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[3] 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.
[4] Rosenberg, J., "Obtaining and Using Globally Routable User
Agent (UA) URIs (GRUU) in the Session Initiation Protocol
(SIP)", draft draft-ietf-sip-gruu-10, November 2006.
[5] Peterson, J., "A Privacy Mechanism for the Session Initiation
Protocol (SIP)", RFC 3323, November 2002.
[6] Peterson, J. and C. Jennings, "Enhancements for Authenticated
Identity Management in the Session Initiation Protocol (SIP)",
RFC 4474, August 2006.
[7] Rosenberg, J., "Traversal Using Relay NAT (TURN)",
Draft draft-rosenberg-midcom-turn-08, September 2005.
[8] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, July 2006.
13.2. Informative Reference
[9] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3315, April 2003.
[10] 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.
[11] Barnes, M., "An Extension to the Session Initiation Protocol
(SIP) for Request History Information", RFC 4244,
November 2005.
[12] Polk, J. and B. Rosen, "Session Initiation Protocol (SIP)
Location Conveyance",
Draft draft-ietf-sip-location-conveyance-07.txt, Feb 2007.
Munakata, et al. Expires August 23, 2007 [Page 35]
Internet-Draft SIP Privacy Clarified Feb 2007
[13] Petrie, D. and S. Channabasappa, "A Framework for Session
Initiation Protocol User Agent Profile Delivery",
Draft draft-ietf-sipping-config-framework-10, March 2007.
[14] Levington, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[15] Peterson, J., "A Presence-based GEOPRIV Location Object
Format", RFC 4119, December 2005.
[16] Sparks, R., "The Session Initiation Protocol (SIP) Referred-By
Mechanism", RFC 3892, September 2004.
[17] Willis, D. and H. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Registering Non-Adjacent Contacts",
RFC 3327, December 2002.
[18] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, September 2004.
[19] Willis, D. and H. Hoeneisen, "Session Initiation Protocol (SIP)
Extension Header Field for Service Route Discovery During
Registration", RFC 3608, October 2003.
[20] Rosenberg, J., "Request Authorization through Dialog
Identification in the Session Initiation Protocol (SIP)",
RFC 4538, June 2006.
Munakata, et al. Expires August 23, 2007 [Page 36]
Internet-Draft SIP Privacy Clarified Feb 2007
Authors' Addresses
Mayumi Munakata
NTT Corporation
Phone: +81 422 36 7565
Email: munakata.mayumi at lab.ntt.co.jp
Shida Schubert
NTT Corporation
Phone: +1 604 762 5606
Email: shida at 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 at lab.ntt.co.jp
URI: http://www.ntt.co.jp
Munakata, et al. Expires August 23, 2007 [Page 37]
Internet-Draft SIP Privacy Clarified Feb 2007
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
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.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Munakata, et al. Expires August 23, 2007 [Page 38]