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]