[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                        J. Peterson
Internet-Draft                                                   NeuStar
Expires: August 30, 2002                                      March 2002


     A Privacy Mechanism for the Session Initiation Protocol (SIP)
                 draft-peterson-sip-privacy-longterm-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 August 30, 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 August 30, 2002                [Page 1]

Internet-Draft                 SIP Privacy                    March 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  . . . . . . . . . . . . 12
   5.  URIs, Display-Names and Privacy  . . . . . . . . . . . . . . . 14
   5.1 Display-Names  . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.2 URI Usernames  . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.3 URI Hostnames and IP Addresses . . . . . . . . . . . . . . . . 15
   6.  Privacy Service Behavior . . . . . . . . . . . . . . . . . . . 17
   6.1 Header Privacy . . . . . . . . . . . . . . . . . . . . . . . . 17
   6.2 Session Privacy  . . . . . . . . . . . . . . . . . . . . . . . 18
   6.3 Applying User-Level Privacy Functions at a Privacy Service . . 19
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 21
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
       Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23
   A.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 24
       References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   B.  To Do  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 26























Peterson                 Expires August 30, 2002                [Page 2]

Internet-Draft                 SIP Privacy                    March 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 include both the intended destination(s) of
   messages and/or any intermediaries handling these messages.
   Withholding the identity of a user will, among other things, renders
   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 URI has a form similar to an
   email address with a SIP URI scheme (for example,
   sip:alice@atlanta.com); addresses-of-record by which SIP users are
   known are such SIP URIs.  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
   SIP URI 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 other
   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 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 August 30, 2002                [Page 3]

Internet-Draft                 SIP Privacy                    March 2002


   The scope of these privacy requirements applies solely to 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
   authors maintain that these problems are sufficiently well addressed
   in the baseline SIP specification and related documents, and that no
   new mechanisms are required.





































Peterson                 Expires August 30, 2002                [Page 4]

Internet-Draft                 SIP Privacy                    March 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 August 30, 2002                [Page 5]

Internet-Draft                 SIP Privacy                    March 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 even 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:

      Users might want to contact a particular party without revealing



Peterson                 Expires August 30, 2002                [Page 6]

Internet-Draft                 SIP Privacy                    March 2002


      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 imagine
   the final destination will be.  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, 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
   routed to a native SIP endpoint to which Contact headers are quite
   legible.

   This document describes three levels 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 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
   unable to provide privacy functions requested by users.  Requests for



Peterson                 Expires August 30, 2002                [Page 7]

Internet-Draft                 SIP Privacy                    March 2002


   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).

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
   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



Peterson                 Expires August 30, 2002                [Page 8]

Internet-Draft                 SIP Privacy                    March 2002


   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 have a specific third-party anonymizing host in
   mind, 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 request
   without the direct solicitation of the user.  User agents may not
   always be cognizant or capable of requesting privacy when it is
   necessary.








































Peterson                 Expires August 30, 2002                [Page 9]

Internet-Draft                 SIP Privacy                    March 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.3).

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 August 30, 2002               [Page 10]

Internet-Draft                 SIP Privacy                    March 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" | token

   User agents SHOULD include a Privacy header when network-provided
   privacy (as described in Section 3.3) is required.

   The values of priv-value today are restricted to two options,
   although further options can be defined as appropriate (see Section
   8).  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 by the Session
      Description Protocol (SDP [4]) body in 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).

   The following table specifies extensions to Table 2 in [1].











Peterson                 Expires August 30, 2002               [Page 11]

Internet-Draft                 SIP Privacy                    March 2002


   Header field          where   proxy ACK BYE CAN INV OPT REG
   ___________________________________________________________
   Privacy                         rd   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
   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.



Peterson                 Expires August 30, 2002               [Page 12]

Internet-Draft                 SIP Privacy                    March 2002


   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.



































Peterson                 Expires August 30, 2002               [Page 13]

Internet-Draft                 SIP Privacy                    March 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 August 30, 2002               [Page 14]

Internet-Draft                 SIP Privacy                    March 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 August 30, 2002               [Page 15]

Internet-Draft                 SIP Privacy                    March 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 otherwise see.  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.

   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 August 30, 2002               [Page 16]

Internet-Draft                 SIP Privacy                    March 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 by the
   user in a Privacy header.  Usually, only the services explicitly
   requested by the user should be applied.  However, privacy services
   MAY have some other means of ascertaining the preferences of the user
   (such as a pre-configured user profile) and MAY act accordingly, as
   described in Section 6.3.

   Privacy services MAY implement either the 'header' or the 'session'
   levels of privacy, or both, 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 degree of privacy.  It
   MAY, however, re-route the request to another server which is capable
   of providing the needed functions, if it can.

   Once the functions specified in the Privacy header have been
   performed, the Privacy header SHOULD be removed.

6.1 Header Privacy

   If a Privacy level of 'header' is requested, then the originating
   user agent 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



Peterson                 Expires August 30, 2002               [Page 17]

Internet-Draft                 SIP Privacy                    March 2002


   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
   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 agent has
   requested that the privacy service anonymize the session traffic (for
   example, 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



Peterson                 Expires August 30, 2002               [Page 18]

Internet-Draft                 SIP Privacy                    March 2002


   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

   Privacy services MAY also need to perform the user-level privacy
   functions described in Section 4.1.  If a user has pre-configured a
   profile for their privacy service, the service MAY apply this profile
   on behalf of the user without any explicit indications in messages
   themselves.  This 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.

   First, the privacy service SHOULD 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.
   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 August 30, 2002               [Page 19]

Internet-Draft                 SIP Privacy                    March 2002


   In accordance with the pre-configured user profile, the privacy
   service MAY also need to invoke 'header' or 'session' level privacy.

















































Peterson                 Expires August 30, 2002               [Page 20]

Internet-Draft                 SIP Privacy                    March 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 August 30, 2002               [Page 21]

Internet-Draft                 SIP Privacy                    March 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'
   and 'media'.  However, further values for the "Privacy" header can be
   defined in standards track RFCs.  IANA registration for these
   "Privacy" header field values is required.









































Peterson                 Expires August 30, 2002               [Page 22]

Internet-Draft                 SIP Privacy                    March 2002


References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", draft-ietf-sip-rfc2543bis-09 (work
        in progress), February 2002.

   [2]  Bradner, S., "Key words for use in RFCs to indicate requirement
        levels", RFC 2119, March 1997.

   [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 August 30, 2002               [Page 23]

Internet-Draft                 SIP Privacy                    March 2002


Appendix A. Acknowledgments

   The authors would like to thank Allison Mankin, Rohan Mahy and Eric
   Rescorla for their comments.















































Peterson                 Expires August 30, 2002               [Page 24]

Internet-Draft                 SIP Privacy                    March 2002


Appendix B. To Do

      Should there be a way for users to send a message that requests
      privacy, but to suggest that if the requested privacy is not
      available, the request should be failed?














































Peterson                 Expires August 30, 2002               [Page 25]

Internet-Draft                 SIP Privacy                    March 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 August 30, 2002               [Page 26]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/