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

Versions: 00

SIP                                                         J. Rosenberg
Internet-Draft                                             Cisco Systems
Expires: January 12, 2006                                    C. Jennings
                                                                   Cisco
                                                             J. Peterson
                                                                 Neustar
                                                           July 11, 2005


       Identity Privacy in the Session Initiation Protocol (SIP)
                draft-rosenberg-sip-identity-privacy-00

Status of this Memo

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

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

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

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

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

   This Internet-Draft will expire on January 12, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   RFC3323 defines procedures for privacy in the Session Initiation
   Protocol (SIP).  These mechanisms make use of a privacy service that
   resides in the network, which can remove identifying information from
   messages.  Its approach to privacy was compatible with the identity
   mechanisms in RFC 3325, which defined the P-Asserted-ID header field.



Rosenberg, et al.       Expires January 12, 2006                [Page 1]


Internet-Draft              Identity Privacy                   July 2005


   However, its approach does not work well with the new cryptographic-
   based mechanisms in draft-ietf-sip-identity.  As such, this document
   proposes a new framework for user privacy in SIP.

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.   Overview of Operation  . . . . . . . . . . . . . . . . . . .   5
   3.   UAC Behavior . . . . . . . . . . . . . . . . . . . . . . . .   7
     3.1  Determining the Level of Anonymity . . . . . . . . . . . .   7
     3.2  Minting an Anonymous AOR . . . . . . . . . . . . . . . . .   8
     3.3  Obtaining an Anonymous IP Address  . . . . . . . . . . . .   9
   4.   Registrar Behavior . . . . . . . . . . . . . . . . . . . . .  10
   5.   Proxy Behavior . . . . . . . . . . . . . . . . . . . . . . .  11
   6.   Anonymity Providers  . . . . . . . . . . . . . . . . . . . .  11
   7.   Grammar  . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   8.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . .  13
   9.   Security Considerations  . . . . . . . . . . . . . . . . . .  13
   10.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  13
   11.  References . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1   Normative References . . . . . . . . . . . . . . . . . .  13
     11.2   Informative References . . . . . . . . . . . . . . . . .  14
        Authors' Addresses . . . . . . . . . . . . . . . . . . . . .  15
        Intellectual Property and Copyright Statements . . . . . . .  16



























Rosenberg, et al.       Expires January 12, 2006                [Page 2]


Internet-Draft              Identity Privacy                   July 2005


1.  Introduction

   RFC 3323 [2] defines procedures for privacy in the Session Initiation
   Protocol (SIP).  It provides guidelines for a UA to follow in the
   construction of its messages, so that identifying information is not
   placed into the message in the first place.  However, it also defines
   a network-based privacy service that can be invoked by the client
   through the insertion of the Privacy header field.  This privacy
   service typically runs within the user's default outbound proxy, and
   is responsible for removal of additional information from the
   messages.  Two levels of privacy can be provided by this service -
   "header" privacy, which obfuscates identifying information from the
   SIP messages, and "session" level privacy, which includes the IP
   addresses used for exchange of media.

   RFC 3325 [9], which defined the P-Asserted-ID header field, has seen
   widespread usage as the means for network authenticated identity in
   SIP.  It defines another privacy service, the "id" service.  This
   service causes elements in the network to strip the P-Asserted-ID
   header field when a request traverses a trust boundary.

   RFC3325's form of identity has numerous drawbacks.  Of these, the
   most significant is that the trustworthiness of the asserted identity
   is equal to the trustworthiness of the least trustworthy provider
   within the network of providers that constitute the trust domain.
   This works well in single provider environments, but in larger scale
   interconnects it eventually breaks apart.  Unfortunately, the
   trustworthiness of an identity is a key property needed for nearly
   all of the VoIP anti-spam techniques [13].  For this reason, amongst
   others, [3] was developed.  It provides strong cryptographic
   assurances of identity.  It does so by providing a signature over the
   From header field in the request, and including in that signature
   information that provides referential integrity of the signature.
   This allows for recipients of the request to validate that the
   asserting domain has truly asserted the requestor's identity for that
   request.  Since the mechanism is fundamentally domain-based, it also
   allows validating entites to apply policies regarding the
   trustworthiness of the asserting provider.  This fundamentally avoids
   the "weakest link" property of RFC 3325.

   There are numerous issues in the direct applicability of RFC 3323 to
   draft-ietf-sip-identity, many of which are pointed out in Section 13
   of [3] (herein referred to as the "SIP identity specification" or the
   "SIP identity mechanism").  These problems are:







Rosenberg, et al.       Expires January 12, 2006                [Page 3]


Internet-Draft              Identity Privacy                   July 2005


   Intra-Domain Privacy: Because the SIP identity mechanism relies on
      the domain of the From header field as a key for obtaining
      certificates used to validate the identity in the From header
      field, anonymity is restricted to being within a domain.  It is no
      longer possible, as described in RFC 3323, to populate the From
      header field with "anonymous.invalid" as the domain.  As a
      consequence, a recipient of the request will be able to determine
      the domain of the originator of the request, though they will not
      be able to determine which user within that domain sent the
      request.  This limitation is not very troubling for domains with
      extremely large numbers of users.  However, for small domains,
      such as enterprises or home networks, it can be equally revealing
      as the identity of the requestor themselves.

   Contact Privacy lost: Because the SIP identity mechanism relies on a
      signature over the Contact header field for referential integrity,
      a privacy service that provides header privacy cannot actually
      modify the Contact value.  This will reveal the IP address of the
      requestor to the recipient of the request, which can often provide
      substantial information about the requestor.

   Session Privacy lost: Session privacy is accomplished through a back-
      to-back user agent (b2bua) that rewrites the SDP to relay session
      media through an intermediary.  This no longer works at all with
      the SIP identity mechanism, as it relies on a signature over the
      body of the request (which contains the SDP) to provide
      referential integrity.

   Subscriber Identity Lost within Originating Domain: One of the
      benefits of the P-Asserted-ID header field when used in
      conjunction with the "id" level of privacy is that elements within
      the domain of the originator of the request will still be able to
      determine the identity of the originator.  This is necessary for
      providing features for the requestor, accounting for their usage,
      and so on.  With the SIP identity mechanism, if privacy is needed,
      the From header field contains an anonymous URI.  As a result, the
      request has no information that can identity the user within their
      own domain, unless the SIP identity mechanism is used in
      conjunction with RFC3325, which is redundant.

   These problems are in addition to the problems inherent in RFC 3323
   to begin with:

   Sensitivity to Boundary Configuration: Although RFC3323 argues
      strongly in favor of placing the privacy service very near the
      originator of the request, this goal is at odds with RFC 3325,
      which requires the privacy service to be on the egress edge of the
      trust domain.  As a result, privacy is actually provided only if



Rosenberg, et al.       Expires January 12, 2006                [Page 4]


Internet-Draft              Identity Privacy                   July 2005


      every egress proxy is properly configured to take positive action
      and remove the P-Asserted-ID header field.  Because positive
      action from the network is required to provide privacy, this
      mechanism is sensitive to misconfiguration of network elements,
      particularly in large interconnected trust domains.

   Complicated Call Trace: In many networks, there is a requirement to
      provide a call trace feature that allows for malicious callers to
      be traced back to their source so that legal action can be taken.
      The utility of such features in a global SIP network aside, RFC
      3323 makes such a feature difficult to provide since the identity
      of the requestor is literally removed from the request.  This
      complicates the tracking procedures needed to identify the
      originator later on.

   Limited Flexibility The degrees of privacy that RFC 3323 could
      provide were coded into the tokens valid in the Privacy header
      field.  More complicated combinations - anonymity for certain
      media streams but not others, for example - were not possible.

   This specification provides an alternate formulation for user privacy
   that works well in conjunction with [3].  This mechanism resolves
   nearly all of the limitations described above by moving more
   intelligence to the client, and having it act in cooperation with
   network services that provide atomic anonymity functions - IP address
   privacy via Traversal Using Relay NAT (TURN) [5] and URI privacy via
   an anonymous URI minting process.

2.  Overview of Operation

   When a user wishes to make an anonymous request, the user agent
   determines the set of identifying information that is to be
   obfuscated.  This identifying information includes IP addresses, such
   as those in the Session Description Protocol (SDP) [6] and Via header
   fields, and URIs, such as those in the From header field and Contact
   header field of the request.  User agents can anonymize any subset of
   this information in the request.

   To anonymize IP addresses, the client contacts a TURN server [5], and
   obtains an IP address and port on the server which route to it.
   Ideally, this is done with a TURN server that is specifically
   dedicated to anonymous services, and thus can provide a higher degree
   of anonymity by obtaining anonymized IP address from a separate
   provider (see Section 6) than a normal one.  The client uses the
   TURN-derived addresses in those fields of the message where the UA
   wishes to anonymize an IP address.

   To anonymize URIs, and in particular the URI in the From header



Rosenberg, et al.       Expires January 12, 2006                [Page 5]


Internet-Draft              Identity Privacy                   July 2005


   field, the client needs to obtain a URI from its domain that
   possesses both the AOR property and the anonymity property (see [4]
   for a discussion of URI properties).  To do that, it generates a
   special REGISTER request that effectively asks the provider to create
   a new URI for the user, and at the same time, register it.  The
   network will construct this URI such that other network elements
   within the domain can use it to identify the requestor, but those
   outside cannot.  This is readily done by creating the URI by
   encrypting the actual identity of the requestor combined with a large
   random number.  Any element that shares the decryption key can know
   the identity of the user, but others cannot.  In addition, the URI
   will have the "user" URI parameter present, and set to the value of
   "anonymous".  This signals to all elements that the requestor is
   asking for anonymity.  This is needed to prevent downstream elements
   within the domain from inserting additional identifying information,
   and also for properly rendering the fact that the caller was
   anonmyous.

   The UAC then places this URI in the From header field of the request.
   It populates the Contact header field value with a Globally Routable
   User Agent URI (GRUU) [4] that was obtained through the registration
   which yielded the minted From URI.  Beyond that, the other procedures
   of RFC 3323 around display names, Call-ID and other fields are
   followed.

   This request is then sent into the network.  There is no Privacy
   header field or other network involvement needed in order to further
   anonymize the request.  Within the domain of the originator, proxy
   servers that see that the From header field contains an anonymous URI
   can decrypt it to obtain the identity of the requestor.  Of course,
   elements outside of the domain will not possess the key, and
   therefore will not know the identity of the requestor.  Because
   positive action is required in the network to obtain their identity
   (namely, acquisition of the decryption key and decryption of the
   URI), the mechanism is privacy-safe.  Network misconfiguration can,
   in the worst case, result in a proxy not determining the identity of
   the requestor.

   Furthermore, since the From field URI is carried all the way to the
   recipient of the request, it is possible to "call them back", even
   though the request was anonymous.  Of course, the originating domain
   can decide to reject such requests, but this becomes a matter of
   local policy.  The fact that the identity of the requestor, suitably
   encrypted, is carried all the way to the recipient of the request
   also facilitates services like malicious call trace.  A network
   provider can contact the domain administrator of the domain on the
   right hand side of the at-sign, and request decryption of the user
   part in order to identify the malicious caller.  Since these requests



Rosenberg, et al.       Expires January 12, 2006                [Page 6]


Internet-Draft              Identity Privacy                   July 2005


   are handled off-line and not in real time, they can be suitably
   authorized.

3.  UAC Behavior

3.1  Determining the Level of Anonymity

   When a user wishes to send a request, whether it is an INVITE to
   initiate a session, or a SUBSCRIBE [10], MESSAGE [11] or any other
   method, the UA makes a determination about the level of anonymity
   that is desired.  Typically, this would be based on user input or on
   local configuration or policy.  The precise means for making this
   determination is outside of the scope of this specification.

   Ultimately, however, the level of anonymity is expressed as a
   function of which types of identifying information (IP address,
   hostname, URI or display name) are to be anonymized, and in which
   fields of the SIP message.  The following fields typically contain
   identifying information about the user:

   From: This field contains the identity of the requestor, and will be
      signed by an identity service within the domain of the requestor.
      As such, clients desiring anonymity SHOULD populate this with a
      URI obtained through the procedures of Section 3.2.  The display
      name also contains identifying information.  It is RECOMMENDED
      that this be omitted when the requestor requires anonymity.  This
      is a change from RFC 3323, which recommended a value of
      "Anonymous".  Rather than relying on a display name to indicate an
      anonymous call, which is language-specific and not meant for
      consumption by an automata, the "user" URI parameter of the From
      header field indicates that the request was anonymous.

   Contact: This field contains a URI used to reach the UA for mid-
      dialog requests and possibly out-of-band requests, such as REFER
      [12].  It is RECOMMENDED that this field be populated with the
      GRUU obtained through the minting procedures of Section 3.2.  The
      display name also contains identifying information.  It is
      RECOMMENDED that this be omitted when the requestor requires
      anonymity.

   Reply-To: This field contains a URI that can be used to reach the
      user on subsequent call-backs.  Clients desiring anonymity SHOULD
      populate this with a URI obtained through the procedures of
      Section 3.2.  The display name also contains identifying
      information.  It is RECOMMENDED that this be omitted when the
      requestor requires anonymity.





Rosenberg, et al.       Expires January 12, 2006                [Page 7]


Internet-Draft              Identity Privacy                   July 2005


   Via: This field contains an IP address and port that is used to reach
      the user agent for responses.  It is RECOMMENDED that this field
      be populated with an IP address and port learned through a TURN
      server Section 3.3.

   Call-Info: This field contains additional information about the
      requestor.  It is RECOMMENDED that this field be omitted from
      requests.

   Call-Info: This field contains additional information about the
      requestor's user agent.  It is RECOMMENDED that this field be
      omitted from requests.

   Organization: This field contains additional information about the
      requestor.  It is RECOMMENDED that this field be omitted from
      requests.

   Subject: This field contains freeform text about the subject of the
      call.  Since it is not possible to know what content a user has
      inadvertently placed into such a header field, it is RECOMMENDED
      that this field be omitted from requests.

   Call-ID: 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).

   SDP c/m lines: The c and m lines in the SDP body convey an IP address
      and port for receiving media.  It is RECOMMENDED that this field
      be populated with an IP address and port learned through a TURN
      server Section 3.3.

   SDP o line: The username SHOULD be set to "-".  The IP address in
      this field SHOULD be populated with an IP address and port learned
      through a TURN server Section 3.3.

   SDP s line: The session name SHOULD be set to "-".

   SDP i,u,e,p lines: These lines SHOULD be omitted from the SDP.


3.2  Minting an Anonymous AOR

   A key aspect of this specification is the ability of a UA to obtain
   an anonymous URI for placement into the From and Reply-To header
   fields, along with a GRUU that can be placed into the Contact header
   field.  It is RECOMMENDED that the UA obtain a new anonymous URI for
   each new request outside of an existing dialog that it generates.



Rosenberg, et al.       Expires January 12, 2006                [Page 8]


Internet-Draft              Identity Privacy                   July 2005


   To obtain a new URI that is suitable for placement into the From
   header field of a new request, a UA constructs a query REGISTER
   request according to the procedures of RFC 3261.  This request is not
   anonymous; a UA MUST correctly populate the To, From and other header
   fields of the request.  This request MUST utilize the GRUU mechanism,
   and thus include the Supported header field with the value "gruu"
   [4].  The Contact header fields, however, are omitted as this is a
   query registration.  However, the UA MUST include the Require header
   field with the option tag "anonymous".  This instructs the registrar
   to view this request as a special query; one that provides the UA
   with a brand new set of anonyous URIs that represent aliases for the
   user's AOR and registered contacts.

   The REGISTER response will contain the set of currently registered
   Contacts against the AOR in the To header field.  In addition, the
   response will contain the Anonymous-To header field.  This header
   field will contain a URI that has both the AOR and anonymous
   properties, and which represents an alias of sorts for the user's
   actual AOR.  Its not a pure alias, in that requests sent to that URI
   don't get equivalent treatment to requests sent to the AOR.  Domain
   policy may result in different treatment for requests made to that
   URI.  This specification provides no automated means for the user to
   request specific policies.  The URI from the Anonymous-To header
   field can be placed into the From and Reply-To header fields of an
   outgoing request.  Note that each and every REGISTER transaction sent
   by the client with the "anonymous" option tag in the Require header
   field will mint a new anonymous URI in the Anonymous-To header field.

   In addition, because the client had indicated support for the GRUU
   mechanism, the REGISTER response will also contain a GRUU for each
   registered contact.  However, these GRUU will also be freshly minted,
   and have the anonymous property as well as the GRUU property.  Like
   Anonymous-To, each REGISTER transaction produces a new set of GRUU in
   the Contact header field of the REGISTER response.  The client then
   uses the GRUU for its own instance in the Contact header field of a
   request.

3.3  Obtaining an Anonymous IP Address

   To obtain an anonymous IP address and port for usage in the SDP, Via
   header field and other parts of the SIP message, a client contacts a
   configured TURN server [5].  It uses normal TURN processing to
   allocate those addresses.  Local policy in the TURN server will
   produce IP addresses and ports with poor correlation properties, as
   discussed below.






Rosenberg, et al.       Expires January 12, 2006                [Page 9]


Internet-Draft              Identity Privacy                   July 2005


4.  Registrar Behavior

   A registrar compliant to this specification MUST support the GRUU
   specification in addition to this one.

   When the registrar receives a REGISTER request, it checks for the
   presence of the Require header field.  If present, and if it includes
   the option tag "anonymous", processing follows as described in this
   section.

   If the REGISTER request contains any Contact header fields, the
   registrar MUST reject the request with a 403.  REGISTER requests that
   mint anonymous URIs have to be query registrations.  As such, the
   registrar follows normal RFC3261 and GRUU processing for constructing
   the response.

   Next, the registrar generates an anonymous URI that has the AOR and
   anonymous properties.  This URI can be within the domain of the
   provider, however, ideally it is within a domain or set of domains
   set aside explicitly for anonymous URI.  See Section 6.  This
   specificaiton makes no normative recommendations on how such a URI is
   constructed.  However, it MUST have the following properties:

   o  The user part has at least 256 bits of randomness.

   o  There is no correlation possible between two URIs given to the
      same user.

   o  Network elements within the domain of the user, to whom explicit
      keying material has been granted, can extract the actual AOR of
      the user from the URI.

   o  The URI MUST include the URI "user" parameter with the value
      "anonymous".

   One simple way to obtain a URI with these properties is to form the
   user part of the URI by encrypting the AOR of the subsciber
   concatenated with 256 bits of random salt.

   Once done, the registrar places this URI in the Anonymous-To header
   field of the REGISTER response.  Furthermore, it takes each GRUU
   present in the Contact header fields of the REGISTER response, and
   replaces them with an anonymous URI that has the following
   properties:

   o  The user part has at least 256 bits of randomness.





Rosenberg, et al.       Expires January 12, 2006               [Page 10]


Internet-Draft              Identity Privacy                   July 2005


   o  There is no correlation possible between two URIs given to the
      same user.

   o  Network elements within the domain of the user, to whom explicit
      keying material has been granted, can extract the actual GRUU of
      the user from the URI.

   o  The URI MUST include the URI "user" parameter with the value
      "anonymous".

   A domain MAY confer other properties upon the Anonymous-To and GRUU
   URI.  In particular, it is expected that the service treatment
   property would be applied, though the services invoked for incoming
   requests to that URI would likely be different.  It is expected that
   services like special call logs, or time-based call blocking, would
   be applied.

5.  Proxy Behavior

   A proxy that receives a request whose From header field has a URI
   whose user parameter has the value "anonymous", but needs to know the
   identity of the requestor for processing, SHOULD attempt to extract
   the AOR from the URI in the From header field based on domain-
   specific procedures.  [[OPEN ISSUE: for multi-vendor SIP networks
   within a single domain, do we require these algorithms to be
   standardized?]]

   When a proxy compliant to this specification sees a request whose
   From header field has a URI whose user parameter has the value
   "anonymous", it MUST NOT insert additional information into the
   request that identifies the originator of the request, if the
   originator is known to the proxy.  Besides the header fields listed
   in Section 3.1, the Path [7], Service-Route [8] and Record-Route
   header fields are inserted by proxies and often contain identifying
   information.

6.  Anonymity Providers

   Note - this section is likely to be highly contentious and it is also
   highly speculative.  It is readily extracted from the rest of the
   specification and it provides the mechanisms necessary for the
   highest levels of anonymity.

   Since the mechanism defined in this specification is meant to be
   compatible with [3], it relies on domain-based signatures.  As such,
   identity is always within the scope of a domain that will be known to
   the recipient of the request.  Similarly, IP addresses obtained from
   TURN servers will be within the IP address space of the provider of



Rosenberg, et al.       Expires January 12, 2006               [Page 11]


Internet-Draft              Identity Privacy                   July 2005


   the server.  Unfortunately, the allocations of IP addresses to
   providers is a well-known property, and thus the provider can often
   be determined from examination of the IP address.  As discussed
   above, simply knowing the provider of the user sending the request
   can reveal substantial information about the requestor.

   To deal with this, this specification recommends the creation of
   special providers called "anonymity providers".  These are large
   providers (indeed, ideally there is a single one for the Internet),
   whose sole responsibility is to obtain and delegate names and
   addresses to actual providers using randomized allocation procedures.
   Actual SIP providers would contract with the anonymity provider under
   some form of agreement.

   An anonymity provider would obtain a relatively large block of IP
   addresses from IP address blocks throughout the Internet.  When a SIP
   provider is asked by one of its own customers to allocate an IP
   address and port for the purposes of anonymous calling, the TURN
   server that has received the request will obtain an IP address from
   the anonymity provider.  This can be done in many ways.  The simplest
   way is to have the SIP providers TURN server send a TURN request to
   the anonymity provider's TURN server, which then chooses one of its
   large number of addresses randomly.  This approach has the drawback
   of funneling traffic through the anonymity provider.  A more
   interesting approach is to have the SIP providers, on a daily or
   hourly basis, literally lease a block of addresses from the anonymity
   provider, and then inject BGP routes into the Internet for that
   address block.  In this case, the anonymity provider serves the role
   of coordinator, making sure it is clear which SIP provider owns that
   particular block of IP addresses at any point in time.  That avoids
   injection of the prefix into BGP from duplicate providers.

   Similarly, the anonymity provider would ideally own a TLD
   (.anonymous, for example), act as a root CA, and be capable of
   creating sub-domains within this TLD.  On a daily or hourly basis,
   each SIP provider would be given a new sub-domain whose value was
   newly minted and randomized (for example, h77asff-
   dg98asdkjkasdpapiasdddd.anonymous), along with certificates that
   would allow a SIP provider to sign requests with that domain.  All
   SIP endpoints would possess the root CA certificate for the anonymity
   provider (which is why there can't be too many of them).

   For this approach to work, automated protocols need to be put in
   place for the assignment of IP address blocks, subdomains in the
   anonymous TLD, and domain certificates within those subdomains.
   Future work is needed to define the protocols appropriate for such
   procedures.




Rosenberg, et al.       Expires January 12, 2006               [Page 12]


Internet-Draft              Identity Privacy                   July 2005


   Presumably, such an anonymity provider would be required to maintain
   the strictest standards of process and security, in order to provide
   high levels of anonymity in concert with the necessary levels of
   audit and tracing when government authorities require it.  For this
   reason, it would seem likely that these anonymity providers would be
   country specific, though it need not be the case.

   It should be further noted that such an anonymity provider is
   providing services that aren't specific to SIP, and could be utilized
   by any application provider that wishes to provide anonymous services
   to its own customers.  It would allow, for example, anonymous email
   or anonymous instant messaging services, or anonymous web browsing.

7.  Grammar

   This specification defines a new header field, Anonymous-To, a SIP
   option tag, anonymous, and a new value of the user parameter of the
   SIP URI:


   Anonymous-To    =     "Anonymous-To" HCOLON ( name-addr / addr-spec )
                  *( SEMI generic-param )
   anonymous-tag   =     "anonymous"
   user-param      =  "user=" ( "phone" / "ip" / "anonymous" /
                      other-user)


8.  Examples

   TODO.

9.  Security Considerations

   This specification is intimately concerned with issues of security.
   A nice summary needs to go here.

10.  IANA Considerations

   This specification registers a new SIP option tag, a new SIP header
   field, and a new value of an existing URI parameter.  Those
   registrations will go here.

11.  References

11.1  Normative References

   [1]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:



Rosenberg, et al.       Expires January 12, 2006               [Page 13]


Internet-Draft              Identity Privacy                   July 2005


        Session Initiation Protocol", RFC 3261, June 2002.

   [2]  Peterson, J., "A Privacy Mechanism for the Session Initiation
        Protocol (SIP)", RFC 3323, November 2002.

   [3]  Peterson, J. and C. Jennings, "Enhancements for Authenticated
        Identity Management in the Session Initiation  Protocol (SIP)",
        draft-ietf-sip-identity-05 (work in progress), May 2005.

   [4]  Rosenberg, J., "Obtaining and Using Globally Routable User Agent
        (UA) URIs (GRUU) in the  Session Initiation Protocol (SIP)",
        draft-ietf-sip-gruu-03 (work in progress), February 2005.

   [5]  Rosenberg, J., "Traversal Using Relay NAT (TURN)",
        draft-rosenberg-midcom-turn-07 (work in progress),
        February 2005.

   [6]  Handley, M. and V. Jacobson, "SDP: Session Description
        Protocol", RFC 2327, April 1998.

   [7]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
        Extension Header Field for Registering Non-Adjacent Contacts",
        RFC 3327, December 2002.

   [8]  Willis, D. and B. Hoeneisen, "Session Initiation Protocol (SIP)
        Extension Header Field for Service Route Discovery During
        Registration", RFC 3608, October 2003.

11.2  Informative References

   [9]   Jennings, C., Peterson, J., and M. Watson, "Private Extensions
         to the Session Initiation Protocol (SIP) for Asserted Identity
         within Trusted Networks", RFC 3325, November 2002.

   [10]  Roach, A., "Session Initiation Protocol (SIP)-Specific Event
         Notification", RFC 3265, June 2002.

   [11]  Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C., and
         D. Gurle, "Session Initiation Protocol (SIP) Extension for
         Instant Messaging", RFC 3428, December 2002.

   [12]  Sparks, R., "The Session Initiation Protocol (SIP) Refer
         Method", RFC 3515, April 2003.

   [13]  Rosenberg, J., "The Session Initiation Protocol (SIP) and
         Spam", draft-ietf-sipping-spam-00 (work in progress),
         February 2005.




Rosenberg, et al.       Expires January 12, 2006               [Page 14]


Internet-Draft              Identity Privacy                   July 2005


Authors' Addresses

   Jonathan Rosenberg
   Cisco Systems
   600 Lanidex Plaza
   Parsippany, NJ  07054
   US

   Phone: +1 973 952-5000
   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net


   Cullen Jennings
   Cisco
   170 West Tasman Dr.
   San Jose, CA  95134
   US

   Phone: +1 408 527-9132
   Email: fluffy@cisco.com


   Jon Peterson
   Neustar
   1800 Sutter Street
   Suite 570
   Concord, CA  94520
   US

   Phone: +1 925 363-8720
   Email: jon.peterson@neustar.biz
   URI:   http://www.neustar.biz


















Rosenberg, et al.       Expires January 12, 2006               [Page 15]


Internet-Draft              Identity Privacy                   July 2005


Intellectual Property Statement

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

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

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


Disclaimer of Validity

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


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Rosenberg, et al.       Expires January 12, 2006               [Page 16]


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