Network Working Group J. Peterson
Internet-Draft NeuStar
Expires: November 25, 2002 May 27, 2002
A Privacy Mechanism for the Session Initiation Protocol (SIP)
draft-ietf-sip-privacy-general-00
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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 November 25, 2002.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Abstract
This document defines new mechanisms for the Session Initiation
Protocol (SIP) in support of privacy. Specifically, guidelines are
provided for the creation of messages that do not divulge personal
identity information. A new "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.
Peterson Expires November 25, 2002 [Page 1]
Internet-Draft SIP Privacy May 2002
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Varieties of Privacy . . . . . . . . . . . . . . . . . . . . . 6
3.1 When is Privacy Necessary? . . . . . . . . . . . . . . . . . . 6
3.2 User-Provided Privacy . . . . . . . . . . . . . . . . . . . . 8
3.3 Network-Provided Privacy . . . . . . . . . . . . . . . . . . . 8
4. User Agent Behavior . . . . . . . . . . . . . . . . . . . . . 10
4.1 Constructing Private Messages . . . . . . . . . . . . . . . . 10
4.2 Expressing Privacy Preferences . . . . . . . . . . . . . . . . 11
4.3 Routing Requests to Privacy Services . . . . . . . . . . . . . 12
4.4 Routing Responses to Privacy Services . . . . . . . . . . . . 13
5. URIs, Display-Names and Privacy . . . . . . . . . . . . . . . 15
5.1 Display-Names . . . . . . . . . . . . . . . . . . . . . . . . 15
5.2 URI Usernames . . . . . . . . . . . . . . . . . . . . . . . . 15
5.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . . . . 16
6. Privacy Service Behavior . . . . . . . . . . . . . . . . . . . 18
6.1 Header Privacy . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2 Session Privacy . . . . . . . . . . . . . . . . . . . . . . . 20
6.3 Applying User-Level Privacy Functions at a Privacy Service . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 25
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
References . . . . . . . . . . . . . . . . . . . . . . . . . . 25
B. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 28
Peterson Expires November 25, 2002 [Page 2]
Internet-Draft SIP Privacy May 2002
1. Introduction
This document provides privacy requirements and mechanisms for the
Session Initiation Protocol (SIP).
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. Withholding the identity of a user will, among other
things, render the other parties in the dialog unable to send new SIP
requests to the user outside of the context of the current dialog.
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 quoted string containing
a name for the identified user (for example, "Alice"). SIP
identities of this form commonly appear in the To and From 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 local 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.
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, such as the Record-Route and Via
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. For these reasons, the participation of
intermediaries is also crucial to providing privacy in SIP.
Two complimentary principles have guided the design of this privacy
mechanism: Users are empowered to hide their identity and related
personal information when they issue requests, but intermediaries and
designated recipients of requests are entitled to reject requests
whose originator cannot be identified.
Peterson Expires November 25, 2002 [Page 3]
Internet-Draft SIP Privacy May 2002
The scope of these privacy requirements is solely the SIP protocol as
it is described in [1]. The mechanisms at the disposal of user
agents and proxy servers are restricted to those described in the SIP
specification. Also, the privacy properties of the headers listed in
the core SIP specification alone, as opposed to headers defined by
any existing or planned extension, are considered here.
There are other aspects of the general privacy problem for SIP that
are not addressed by this draft. Most significantly, the mechanisms
for managing the confidentiality of SIP headers and bodies, as well
the security of session traffic, are not reconsidered here. The
author maintains that these problems are sufficiently well addressed
in the baseline SIP specification and related documents, and that no
new mechanisms are required.
Peterson Expires November 25, 2002 [Page 4]
Internet-Draft SIP Privacy May 2002
2. Terminology
In this document, the key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
described in RFC2119 [2] and indicate requirement levels for
compliant SIP implementations.
Peterson Expires November 25, 2002 [Page 5]
Internet-Draft SIP Privacy May 2002
3. Varieties of Privacy
A user may possess many identities that are used in various contexts;
generally, identities are addresses-of-record which are bound to
particular registrars (operated by the administrators of a domain)
with whom SIP user agents register. The operators of these domains
may be employers, service providers, or unaffiliated users
themselves.
When a user voluntarily asserts an identity in a request, they are
claiming that they can receive requests sent to that identity in that
domain. Strictly speaking, privacy entails the restriction of the
distribution of a specific identity from some particular party or
parties that are potentially recipients of the message. In
particular, there are scenarios in which a party desiring anonymity
may:
send a message and withhold an identity from the final
destination(s) while still communicating an identity to one or
more intermediaries
send a message and withhold their identity from some or all
intermediaries, but still communicate an identity end-to-end to
the final destination(s)
withhold identity from both intermediaries and final
destination(s)
The result of withholding an identity is that the parties in question
would be unable, for example, to attempt to initiate a new dialog
with the anonymous party at a later time. However, the anonymous
party still must be capable of receiving responses and new requests
during the dialog in which it is participating.
It may be desirable to restrict identity information on both requests
and responses. Initially, it might seem unusual to suggest that a
response has privacy concerns - presumably, the originator of the
request knows who they were attempting to contact, so the identity of
the respondent can hardly be confidential. However, some personal
information in responses (such as the contact address at which the
respondent is currently registered) is subject to privacy concerns
and can be addressed by these mechanisms.
3.1 When is Privacy Necessary?
Users may wish for identity information to be withheld from a given
party for any number of reasons, for example:
Peterson Expires November 25, 2002 [Page 6]
Internet-Draft SIP Privacy May 2002
Users might want to contact a particular party without revealing
their identity in order to impart information with which they
would not like to be associated
Users might fear that the exposure of their identity or personal
information to some networks or destinations will make them a
target for unsolicited advertising, legal censure or other
undesirable consequences
Users might want to withhold from participants in a session the
identity by which they are known to network intermediaries for the
purposes of billing and accounting
When a user agent decides to send a request through a proxy server,
it may be difficult for the originator to anticipate the final
destination of that message. For that reason, users are advised not
to base their estimation of their privacy needs on where they expect
a message will go. For example, if a user sends a request to
telephone number, they may believe that the final destination of the
request will be a station in the public switched telephone network
(PSTN) that is unable to inspect, say, SIP Contact headers, and
therefore assume that it is safe to leave such headers in the clear;
however, such a request might very well end up being retargeted by
the network to a native SIP endpoint to which Contact headers are
quite legible.
This document describes three degrees of privacy - one level of user-
provided privacy, and two levels of network-provided privacy (header
privacy and session privacy). How much privacy does a user need for
any given session? Generally, if a user is seeking privacy, they're
going to need as much of it as they can get. However, if a user
knows of no privacy service, they must be content with user-provided
privacy alone. Similarly, if a user knows of an anonymization
service that can provide session privacy, but is unable to secure
session traffic to prevent the anonymizer from possibly eavesdropping
on the session, they might judge the loss of session privacy to be
the lesser evil. The user might also be aware of exceptional
conditions about the architecture in which the user agent is deployed
that may obviate one or more privacy concerns.
A user may not always be the best judge of when privacy is required
even under ideal circumstances, and thus privacy may in some
architectures by applied by intermediaries without the user's
explicit per-message request. By sending a request through
intermediaries that can provide a privacy role, the user tacitly
permits privacy functions to be invoked as needed.
It is also important that users understand that intermediaries may be
Peterson Expires November 25, 2002 [Page 7]
Internet-Draft SIP Privacy May 2002
unable to provide privacy functions requested by users. Requests for
privacy may not be honored due to legal constraints, unimplemented or
misconfigured features, or other exceptional conditions.
Note that just as it is the prerogative of a user to conceal their
identity, so it must also be the prerogative of proxy servers and
other users to refuse to process requests from users whom they cannot
identify. Therefore users should not just automatically withhold
their identity for all requests and responses - inability to
ascertain the identity of the originator of the request will
frequently be grounds for rejection. Privacy should only be
requested when the user has a need for it.
Further to this point, withholding some information in signaling
might not be necessary for all user agents to ensure privacy. For
example, user agents may acquire their IP addresses and hostnames
dynamically, and these dynamic addresses may not reveal any
information about the user whatsoever. In these cases, restricting
access to hostnames (as described in Section 5.3) is unnecessary.
3.2 User-Provided Privacy
There is a certain amount of privacy that a user agent can provide
itself. For example, the baseline SIP specification permits a user
agent to populate the From header field of a request with an
anonymous value. Users can take similar steps to avoid revealing any
other unnecessarily identity information in related SIP headers (this
is discussed further in Section 5).
A user may have different privacy needs for a message if it traverses
intermediaries rather than going directly end-to-end. A user may
attempt to conceal things from intermediaries which are not concealed
from the final destination, and vice versa. For example, using
baseline SIP mechanisms, a user agent can encrypt SIP bodies end-to-
end in order to prevent intermediaries from inspecting them. If a
SIP message will not pass through intermediaries, however, this step
might not be necessary (i.e. lower-layer security, without the
addition of security for SIP bodies, could be sufficient).
Also note that if a dialog goes directly end-to-end between
participants, however, it will not be possible to conceal the network
addresses of the participants.
3.3 Network-Provided Privacy
If a user is sending a request through intermediaries, a user agent
can conceal its identity to only a limited extent without the
intermediaries' cooperation. Also, some information can only be
Peterson Expires November 25, 2002 [Page 8]
Internet-Draft SIP Privacy May 2002
concealed from destination endpoints if an intermediary is entrusted
to remove it.
For these reasons a user must have a way to request privacy from
intermediaries, a means that allows users both to signal some
indications of the desired privacy services, and to ensure that their
call is routed to an intermediary that is capable of providing these
services. A user may be aware of a specific third-party anonymizing
host, one with which they have a pre-existing relationship, or a user
may request that their local administrative domain provide privacy
services.
Intermediaries may also be empowered to apply privacy to a message
without any explicit signaling from the originating user, since user
agents may not always be cognizant or capable of requesting privacy
when it is necessary.
Peterson Expires November 25, 2002 [Page 9]
Internet-Draft SIP Privacy May 2002
4. User Agent Behavior
There are three different ways that a user agent can contribute to
the privacy of a request - by populating headers with values that
reflect privacy requirements, by requesting further privacy services
from the network, and by using cryptographic confidentiality to
secure headers and bodies. Note that the last of these is outside
the scope of this document.
The mechanisms provided in this section assume that a user agent is
sufficiently configurable that a user can select header values and
provision privacy preferences (ideally on a per-call basis). If this
isn't the case, it is possible that a user can route their call
through a privacy service that is configured to groom signaling from
this user agent in order to provide some of the function described
below (see Section 6).
4.1 Constructing Private Messages
Privacy starts with the user agent. The bulk of the steps that are
required to conceal private information about the sender of a message
are, appropriately enough, the sender's responsibility.
The following SIP headers, when generated by a user agent, can
directly or indirectly reveal identity information about the
originator of a message: From, Contact, Reply-To, Via, Call-Info,
User-Agent, Organization, Subject, Call-ID, In-Reply-To
The first and most obvious step is that user agents SHOULD not to
include any optional headers that might divulge personal information;
there's certainly no reason for a user seeking privacy to include a
Call-Info. Secondly, the user SHOULD populate URIs throughout the
message in accordance with the guidelines given in Section 5; for
example, users SHOULD create an anonymous From header field for the
request. Finally, users MAY also need to request certain privacy
functions from the network, as described in Section 4.2.
The Call-ID header, which is frequently constructed in a manner that
reveals the IP address or hostname of the originating client,
requires special mention. User agents SHOULD substitute for the IP
address or hostname that is frequently appended to the Call-ID value
a suitably long random value (the value used as the 'tag' for the
From header of the request might even be reused).
Note that if the user wants to conceal any of the above headers from
intermediaries alone, without withholding them from the final
destination of the message, users MAY also place legitimate values
for these headers in encapsulated 'message/sip' S/MIME bodies as
Peterson Expires November 25, 2002 [Page 10]
Internet-Draft SIP Privacy May 2002
described in the SIP specification.
4.2 Expressing Privacy Preferences
There are some headers that a user agent cannot conceal itself,
because they are used in routing, that could be concealed by an
intermediary that subsequently takes responsibility for directing
messages to and from the anonymous user. The user agent must have
some way to request such privacy services from the network. For that
purpose, this document defines a new SIP header, Privacy, that can be
used to specify privacy handling for requests and responses.
Privacy-hdr = "Privacy" HCOLON priv-value *(COMMA priv-value)
priv-value = "header" | "session" | "user" | "none" | "critical" | token
User agents SHOULD include a Privacy header when network-provided
privacy (as described in Section 3.3) is required. 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 MUST NOT modify
the Privacy header in any way if the 'none' priv-value is already
specified.
The values of priv-value today are restricted to the above options,
although further options can be defined as appropriate (see Section
8). Each legitimate priv-value can appear zero or one times in a
Privacy header. The current values are:
header: The user requests that a privacy service obscure those
headers cannot be completely expunged of identifying information
without the assistance of intermediaries (such as Via and
Contact). Also, no unnecessary headers should be added by the
service that might reveal personal information about the
originator of the request.
session: The user requests that a privacy service provide
anonymization for the session(s) (described, for example, in a
Session Description Protocol [4] body) initiated by this message.
This will mask the IP address from which the session traffic would
ordinarily appear to originate. When session privacy is
requested, user agents MUST NOT encrypt SDP bodies in messages.
Note that requesting session privacy when end-to-end session
encryption is not possible raises serious security concerns (see
Section 6.2).
user: This privacy level is set only by intermediaries, in order to
Peterson Expires November 25, 2002 [Page 11]
Internet-Draft SIP Privacy May 2002
communicate that user level privacy functions (as discussed in
Section 6.3) must be provided by the network, presumably because
the user agent is unable to provide them. User agents MUST NOT
set the "user" privacy level.
none: The user requests that a privacy service apply no privacy
functions to this message, regardless of any pre-provisioned
profile for the user or default behavior of the service. User
agents can specify this option when they are forced to route a
message through a privacy service which will, if no Privacy header
is present, apply some privacy functions which the user does not
desire for this message. Intermediaries MUST NOT remove or alter
a Privacy header whose priv-value is 'none'. User agents MUST NOT
populate any other priv-values (including 'critical') in a Privacy
header that contains a value of 'none'.
critical: The user asserts that the privacy services requested for
this message are critical, and that therefore, if these privacy
services cannot be provided by the network, this request should be
rejected. Criticality cannot be managed appropriately for
responses.
The following table specifies extensions to Table 2 in [1].
Header field where proxy ACK BYE CAN INV OPT REG
___________________________________________________________
Privacy amrd o o o o o -
Header field SUB NOT PRK IFO UPD MSG
___________________________________________________________
Privacy o o o o o o
4.3 Routing Requests to Privacy Services
The most obvious way for a user agent to invoke the privacy function
is to direct a request through an intermediary known to act as a
privacy service. Doing so traditionally entails the configuration of
pre-loaded Route headers that designate the privacy service.
It is RECOMMENDED that service providers couple the privacy service
function with a local outbound proxy. Users can thereby send their
messages that request privacy through their usual outbound route.
Users should not assume, however, that the administrative domain that
is the destination of the request would be willing and able to
perform the privacy service function on their behalf. If the
originating user wishes to keep their local administrative domain a
Peterson Expires November 25, 2002 [Page 12]
Internet-Draft SIP Privacy May 2002
secret, then they must use a third-party anonymization service
outside of any of the principal administrative domains associated
with the session.
It is highly RECOMMENDED that user agents use network or transport
layer security, such as TLS, when contacting a privacy service.
Ideally, users 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 obscures
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.
4.4 Routing Responses to Privacy Services
Making sure that responses will go through a privacy service is a
little bit trickier. The path traversed by SIP responses is the same
as the path over which the request traveled. Thus, the responding
user agent, for example, cannot force a privacy service to be
injected in the response path after it has received a request.
What a responding user agent can do, however, is ensure that the path
by which requests reach them traverses their privacy service. In
some architectures, the privacy service function will be fulfilled by
the same server to which requests for the local administrative domain
are sent, and hence it will automatically be in the path of incoming
requests. However, if this is not the case, the user will have to
ensure that requests are directed through a third-party privacy
service. The simplest way to accomplish this is to procure a
'private' URI from the third-party service and to distribute this as
an address-of-record. The user would then register their normal
address-of-record as a contact address with the third-party service.
Users are also advised to use transport or network layer security in
the response path. This may involve registering a SIPS URI and/or
maintaining persistent TLS connections over which their user agent
receives requests.
Privacy services MAY in turn route requests through other privacy
services. This may be necessary if a privacy service does not
support a particular privacy function, but it knows of a peer that
does. Privacy services may also cluster themselves into networks
that exchange session traffic between one another in order to further
Peterson Expires November 25, 2002 [Page 13]
Internet-Draft SIP Privacy May 2002
disguise the participants in a session, although no specific
architecture or method for doing so is described in this document.
Peterson Expires November 25, 2002 [Page 14]
Internet-Draft SIP Privacy May 2002
5. URIs, Display-Names and Privacy
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.
The techniques described in this section do not extend to the
creation of falsified but plausible URIs and display-names that do
not identify the originator but may fool the remote party into
believing that the originator is not anonymous. Ultimately, the
presentation of identity URIs will be predicated on cryptographic
proofs of identity - users that claim anonymity should do so openly.
5.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.
Note that there is a fine line between identity fraud and humor in
some cases. Many email clients by default render to the user only
the display-name of the sender of a message. It is easy to populate
the display-name in a way that many would consider abusive; it is
best not to select any display-name that may suggest an attempt to
impersonate someone else.
It is RECOMMENDED that user agents seeking anonymity use a display-
name of "Anonymous".
5.2 URI Usernames
The structure of a URI itself can reveal or conceal a considerable
amount of personal information. Consider the difference between:
sip:jon.peterson@neustar.biz
and
sip:a0017@anonymous-sip.com
From the former, the full name and employer of the party in question
can easily be gleaned. From the latter, you learn nothing other than
Peterson Expires November 25, 2002 [Page 15]
Internet-Draft SIP Privacy May 2002
that the party desires anonymity. In some cases, sufficient
anonymity can be achieved by selecting an oblique URI. 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
5.3 URI Hostnames and IP Addresses
It is assumed by this document that the user that requests privacy
wishes to receive future requests and responses within this dialog,
but does not wish to reveal an identity that could be used to send
new requests to him outside the scope of this dialog. For that
reason, different treatment must be recommended for URIs that are
used in the context of routing further requests in the dialog, as
opposed to routing new requests outside the context of the dialog.
For headers indicating how the user would like to be contacted for
future sessions (such as the From header), it might not immediately
be obvious why changing the hostname would be necessary - if the
username is 'anonymous', requests will not be routable to the
anonymous user.
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
in the From header 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 hostname value 'anonymous.invalid' SHOULD be
used for anonymous URIs. The full recommended form of the From
header for anonymity is (note that this From header, like all others,
MUST contain a valid and unique 'tag=' parameter):
From: "Anonymous" <sip:anonymous@anonymous.invalid>;tag=1928301774
For headers indicating how further requests in the current dialog
should be routed (such as the Contact header), there seems to be
little that a user can do to disguise the existing URI, because users
MUST provide a value that will allow them to receive further
requests. In some cases, disguising or failing to provide the
Peterson Expires November 25, 2002 [Page 16]
Internet-Draft SIP Privacy May 2002
username, as described above, may create some level of privacy, but
the hostname provides a more significant obstacle.
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.
This document thus recommends that the host portion of URIs that are
used in the routing of subsequent requests, such as URIs appearing in
the Contact header, SHOULD NOT be altered by the user agent due to
privacy considerations. If these headers require anonymization, the
user MUST request that service from an intermediary, namely a privacy
service.
Note that many of the considerations regarding the Contact header
above apply equal well to SIP headers in which a hostname, rather
than a URI, is used for some routing purpose (namely the Via header).
Peterson Expires November 25, 2002 [Page 17]
Internet-Draft SIP Privacy May 2002
6. Privacy Service Behavior
This document defines a new SIP logical role called a "privacy
service". 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 user-level privacy function 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 MUST NOT perform
any privacy function.
Privacy services MUST implement the 'none' and 'critical' privacy
levels, and MAY implement any of other privacy levels described in
Section 4.2 as well as any extensions that are not detailed in this
document. In some cases, the privacy service will not be capable of
fulfilling the requested level of privacy. It MAY, however, re-route
the request to another server which is capable of providing the
needed functions, if it can. If the 'critical' privacy level is
present in the Privacy header of a request, then if the privacy
service is incapable of performing all of the levels of privacy
specified in the Privacy header then it MUST either fail the request,
or it MUST forward the request to another privacy service which can
fulfill these functions (note that before forwarding the request, the
privacy service SHOULD complete a subset of the functions if it can).
When a privacy service performs one of the functions corresponding to
a privacy level listed in the Privacy header, it SHOULD remove the
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 last priv-value (not counting 'critical') has
been removed from the Privacy header, the entire Privacy header MUST
be removed from a message.
Peterson Expires November 25, 2002 [Page 18]
Internet-Draft SIP Privacy May 2002
6.1 Header Privacy
If a privacy level of 'header' is requested, then the originating
user has asked the privacy service to help to obscure headers that
might otherwise reveal information about the originator of the
request. 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 back-to-back
user agent (B2BUA).
Firstly, a request for header privacy entails that the server SHOULD
NOT add any of the following headers to the message: Call-Info,
Server, and Organization. All of these provide optional information
that could reveal facts about the user that has request anonymity.
Privacy services operating on requests SHOULD remove all Via headers
that have been added to the request prior to its arrival at the
privacy service (a practice commonly referred to as "Via hiding") and
then SHOULD add a single Via header representing themselves. Note
that the topmost such Via header in a request contains an IP address
or hostname that designates the originating client, and subsequent
Via headers may indicate hosts in the same administrative domain as
the client. No Via hiding is required when handling responses.
Contact headers are added by user agents to both requests and
responses. A privacy service SHOULD replace the value of the Contact
header in a message with a URI that does not dereference to the
originator of the message (such as the anonymous URI described in
Section 5.3). When a privacy service alters the Contact header of a
request, it MUST insert a Record-Route header pointing to itself so
that it can restore the appropriate contact address as necessary.
In a manner similar to Via hiding, a privacy service SHOULD also hide
any Record-Route headers that have been added to a request before it
reaches the privacy service. Such Record-Route headers might also
divulge information about the administrative domain of the client.
Once Record-Route headers have been hidden, however, the privacy
service MUST add appropriate Route headers to future requests as
needed.
For the purposes of this document, it is assumed that the privacy
service has locally persisted the values of any of the above headers
that are so removed, which requires the privacy service to keep a
pretty significant amount of state on a per-session basis. When
further requests or responses associated with the dialog reach the
privacy service, it MUST restore values for the Via, Record-
Route/Route or Contact headers that it has previously removed in the
Peterson Expires November 25, 2002 [Page 19]
Internet-Draft SIP Privacy May 2002
interests of privacy. There may be alternative ways (outside the
scope of this document) to perform this function that do not require
keeping state in the privacy service (usually means that involve
encrypting and persisting the values in the signaling somehow).
6.2 Session Privacy
If a privacy level of 'session' is requested, then the user has
requested that the privacy service anonymize the session traffic
(e.g. for SIP telephony calls, the audio media) associated with this
dialog.
The SIP specification dictates that intermediaries such as proxy
servers cannot inspect and modify message bodies. The privacy
service logical role MUST therefore act as a transparent back-to-back
user agent in order to provide media privacy, effectively terminating
and re-originating the messages that initiate a session. In order to
introduce an anonymizer for session traffic, the privacy service
needs to control a middlebox [6] that can provide an apparent source
and sink for session traffic. The details of the implementation of
an anonymizer, and the modifications that must be made to the Session
Description Protocol (SDP [4]) bodies in the messages that initiate a
session are outside the scope of this document.
The risk, of course, of using such an anonymizer is that the
anonymizer itself is party to your communications. For that reason,
requesting session-level privacy without resort to some sort of end-
to-end security for the session traffic (with RTP [5] media, for
example, SRTP [3]) is NOT RECOMMENDED.
6.3 Applying User-Level Privacy Functions at a Privacy Service
If a privacy level of 'user' is requested, then the originating user
has requested that privacy services perform the user-level privacy
functions described in Section 4.1.
Note that the privacy service MUST remove any non-essential
informational headers that have been added by the client, including
the Subject, Call-Info, Organization, User-Agent, Reply-To and In-
Reply-To.
Significantly, user-level privacy could entail the modification of
the From header, changing it from its original value to an anonymous
value. Prior to the current issue of the SIP specification, the
modification of the values of the To and From headers by
intermediaries was not permitted, and would result in improper dialog
matching by the endpoints. Currently, dialog matching uses only the
tags in the To and From headers, rather than the whole header fields.
Peterson Expires November 25, 2002 [Page 20]
Internet-Draft SIP Privacy May 2002
Thus, under the new rules the URI values in the To and From headers
themselves could be altered by intermediaries. However, some legacy
clients might consider it an error condition if the value of the URI
in the From header altered between the request and the response.
Also, performing user-level privacy functions MAY entail the
modification of the Call-ID header, since the Call-ID commonly
contains a hostname or IP address corresponding to the originating
client. This field is essential to dialog matching, and it cannot be
altered by intermediaries.
Therefore, any time that a privacy service needs to modify any
dialog-matching headers for privacy reasons, it SHOULD act as a
transparent back-to-back user agent, 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.
Peterson Expires November 25, 2002 [Page 21]
Internet-Draft SIP Privacy May 2002
7. 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 could see
personal information that the user has requested that the privacy
service 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.
Privacy services would be wise to authenticate users before providing
a privacy function. To downstream entities, the privacy service will
be the only responsible party to whom anonymous messages can be
traced, and in abuse cases the privacy service could be held
accountable for the actions of parties that it shelters.
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.
Peterson Expires November 25, 2002 [Page 22]
Internet-Draft SIP Privacy May 2002
8. IANA Considerations
This document defines a new SIP header called "Privacy" that allows a
user agent to request a certain degree of privacy for a message.
This header is defined in Section 4.2.
The current values of the "Privacy" header are restricted to
'header', 'session', 'user', 'none' and 'critical'. However, further
values for the "Privacy" header can be defined in RFCs approved by
the SIP working group. IANA registration for these "Privacy" header
field values is required.
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. This applies especially
to the creation of new SIP headers.
Peterson Expires November 25, 2002 [Page 23]
Internet-Draft SIP Privacy May 2002
Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, May 2002.
[2] Bradner, S., "Key words for use in RFCs to indicate requirement
levels", RFC 2119, March 1997.
Peterson Expires November 25, 2002 [Page 24]
Internet-Draft SIP Privacy May 2002
Informative References
[3] Baugher, M., McGrew, D., Oran, D., Blom, R., Carrara, E.,
Naslund, M. and K. Normann, "The Secure Real Time Transport
Protocol", draft-ietf-avt-srtp-03 (work in progress), February
2002.
[4] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[5] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[6] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A.
Rayhan, "Middlebox communication architecture and framework",
draft-ietf-midcom-framework-07 (work in progress), February
2002.
Author's Address
Jon Peterson
NeuStar, Inc.
1800 Sutter St
Suite 570
Concord, CA 94520
US
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Peterson Expires November 25, 2002 [Page 25]
Internet-Draft SIP Privacy May 2002
Appendix A. Acknowledgments
The author would like to thank Allison Mankin, Rohan Mahy, Eric
Rescorla, Mark Watson, Cullen Jennings and Robert Sparks for their
comments.
Peterson Expires November 25, 2002 [Page 26]
Internet-Draft SIP Privacy May 2002
Appendix B. Changelog
From draft-peterson-sip-privacy-longterm-00
Added new priv-values for 'none', 'critical' and 'user', with
accompanying behavior
Intermediaries may now add and modify the Privacy header (but only
in accordance with user's preferences)
Other miscellaneous fixes
Peterson Expires November 25, 2002 [Page 27]
Internet-Draft SIP Privacy May 2002
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Peterson Expires November 25, 2002 [Page 28]