SIPPING WG J. Peterson Internet-Draft NeuStar Expires: August 15, 2005 February 14, 2005 Retargeting and Security in SIP: A Framework and Requirements draft-peterson-sipping-retarget-00 Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract Retargeting, the alteration by intermediaries of the destination of a Session Initiation Protocol (SIP) request, is a common practice performed during the routing of a call. Some forms of retargeting, however, give rise to security problems and potential functional gaps in SIP. This document provides a general framework for discussion of the security problems relating to retargeting, and gives requirements for mechanisms that might overcome these problems. Peterson Expires August 15, 2005 [Page 1] Internet-Draft Retargeting Security February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problems with Retargeting . . . . . . . . . . . . . . . . . . 4 2.1 Legitimacy of Retargeting . . . . . . . . . . . . . . . . 5 2.2 Response Identity . . . . . . . . . . . . . . . . . . . . 6 2.2.1 The Unanticipated Respondent Problem . . . . . . . . . 7 2.3 Establishment of Security Parameters . . . . . . . . . . . 8 2.4 Consent of the UAC . . . . . . . . . . . . . . . . . . . . 10 2.5 Furtherance of Transitive Trust . . . . . . . . . . . . . 11 3. Summary of Threats . . . . . . . . . . . . . . . . . . . . . . 12 4. Benefits of Retargeting . . . . . . . . . . . . . . . . . . . 12 5. Requirements for Securing Retargeting . . . . . . . . . . . . 14 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 8.2 Informative References . . . . . . . . . . . . . . . . . . . 15 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Peterson Expires August 15, 2005 [Page 2] Internet-Draft Retargeting Security February 2005 1. Introduction Retargeting is the process by which a SIP intermediary (such as a proxy server) alters the Request-URI of a SIP request before it forwards that request. A proxy server may retarget when it determines (by accessing a location service, perhaps) that one or more new target URIs are eligible to receive the request. Retargeting to a contact address URI discovered by a location service for the address-of-record in the Request-URI of a request is common. However, proxy servers may also retarget to other proxy servers, potentially leading to significant signaling chains between the UAC and UAS. When one or more new targets have been identified for a request, RFC3261-compliant intermediaries can choose either to retarget or redirect (i.e., send a 3xx response code) on a per-request basis. Perhaps the most important reason for retargeting is efficiency, in terms of overall messages required. In the simplest case (one new target for the request is discovered): A redirecting intermediary must send a 3xx response to the UAC. The UAC must both acknowledge this response and send a new request to the new target. Three messages total are required. A retargeting intermediary sends only one message to the destination UAS - nothing is sent back to the UAC. However, retargeting has its downside: namely, the UAC does not know where its request will be going. This might not immediately seem like a serious problem; after all, when one places a telephone call, one never really knows if it will be forwarded to a different number, who will pick up the line when it rings, and so on. The user-driven signaling environment of SIP, however, makes this condition much more problematic than its analog in traditional telephony. Currently, RFC3261 allows retargeting to occur only under very specific circumstances: a proxy server may retarget only if it is 'responsible' for the domain in the host portion of the Request-URI. Unfortunately, this concept of 'responsibility' is not sufficiently specified, and moreover, a UAC has no way of knowing which proxy server in the network performed any retargeting. Consequently, the UAC has no assurance at a protocol level against malicious or misguided retargeting by intermediaries which are not 'responsible' for the target. In fact, RFC3261 includes a number of normative constraints on intermediary behavior which suggest, tacitly, an authorization relationship between the UAC and a proxy server. However, since there is no explicit account of what exactly a UAC does and does not Peterson Expires August 15, 2005 [Page 3] Internet-Draft Retargeting Security February 2005 authorize a proxy server to do, there is little by way of mechanism in SIP to chaperone proxy server behavior. Since everything that is not prevented by mechanism tends to be permitted in practice, the reality is that SIP proxy servers behave as if UACs have no authority to exert any policy controls over the handling of their requests and accordingly, the normative constraints in RFC3261 are routinely flouted. Unfortunately, this inability to police intermediary behavior leads to practicable attacks against SIP and various weaknesses in the authorization policies needed by user agents. In order to address such problems, a UAC must be capable of implementing authorization policies informed by questions that are, today, essentially unanswerable, such as: How can a UAC determine the URI that a request has eventually reached? How can a UAC determine which intermediary has changed the target of the request? This draft attempts to tease out the actual authority which a UAC invests in a proxy server, in so far as it relates to retargeting, by examining the negative space: the problem cases where clearly, the UAC cannot grant permissions to intermediaries without exposing itself to attacks or policy failures. It then provides some requirements for a corresponding security mechanism that might actually constrain the retargeting behavior of intermediaries in order to improve the overall security of the protocol. 2. Problems with Retargeting SIP is a protocol that relies on intermediaries to perform application-layer routing functions. It is necessary for intermediaries to perform this function in order to support an architectural layer of indirection between the identifiers of users (the SIP "address-of-record" or AoR) and the identifiers of devices (SIP "contact addresses"). The mappings between these two types of identifiers are provided by the abstract location service function of SIP, which is accessed by proxy servers when they make forwarding decisions. This function is essential and integral to SIP's operation. However, this function also makes it difficult to differentiate an intermediary that is behaving legitimately from an attacker. If SIP is designed in such a way that malicious attacks against the protocol cannot be distinguished from the legitimate activities of intermediaries, then SIP will never be securable. Ultimately, intermediaries can discharge their responsibilities while Peterson Expires August 15, 2005 [Page 4] Internet-Draft Retargeting Security February 2005 giving user agents enough information to detect attacks and to make reasonable authorization decisions. In order to understand how intermediaries would need to behave for this to be the case, a detailed examination of the gaps in SIP's current security story relating to retargeting is necessary. The problems discussed in this section exhibit the following three qualities: Undetectable: The originating user agent has no means of anticipating that the condition will arise, nor any means of determining that it has occurred until the negative consequences have already been realized. Unpreventable: There is no existing security mechanism that might be employed by the originating user agent in order to guarantee that the condition will not arise. Entailed by retargeting: If retargeting did not exist, this problem would not arise. 2.1 Legitimacy of Retargeting RFC3261 allows retargeting to occur only if the retargeting intermediary is responsible for the domain indicated by the Request-URI of the request. For example, if a request was sent to sip:bob@example.com, then a proxy server at example.com would be authorized to retarget the request, but a proxy server at example.org would not be authorized to retarget the request. However, RFC3261 offers no way to enforce this rule. There is no way for the UAC or UAS to detect which intermediary retargeted a request. Accordingly, if due to local policy a UAC were forced to send its request through a proxy server example.org on its way to the proxy server at example.com, the example.org proxy server might malicious retarget the request to, say, a user at example.org, and the UAC would have no way to determine that example.com had not authorized this retargeting. The rule in RFC3261 is intended to combat various forms of service hijacking. The domain in the Request-URI is permitted to retarget because it presumably has a business relationship with the target user, since that user can provision its local service with registrations or other administrative means. Other domains, however, have no such relationship with the target user, and might retarget to their own advantage. If we imagine that example.org is a hotel, for example, the example.org proxy server might retarget requests for various local pizza shops (sip:orders@pizza.example.com) to a specific, preferred pizza shop (sip:orders@pizza.example.net) with which the hotel enjoys an underhanded business arrangement. Peterson Expires August 15, 2005 [Page 5] Internet-Draft Retargeting Security February 2005 Nothing will be able to prevent intermediaries from changing the Request-URI of a SIP request. It is impossible to provide integrity protection over the Request-URI because there are cases where it changes of necessity (such as intradomain routing of GRUUs and so on). However, if it were possible to determine which proxy server was responsible for changing the target of the request, the UAC could abandon requests that have been maliciously mishandled and perhaps take up some recourse against the misbehaving domain. As it stands, since the condition in undetectable, domains might engage in this behavior without fear of reproach. 2.2 Response Identity When Alice sends a request to Bob, Bob may want to send a secure response back to Alice. What is the purpose of a secure response? Bob secures his response so that Alice can make certain authorization and policy decisions based on the security of the response. Usually, this requires at least providing integrity protection over the response (as a whole or in part) and providing cryptographic authentication of the sender of the response. Alice might accept the response, or perhaps discard it, on the basis of those security properties. In the absence of this authentication and integrity, it might be possible for a third-party attacker, whom we'll call Edgar, to eavesdrop on the request, and forge their own response (impersonating Bob) with an inappropriate response code, or inappropriate SDP answer, or what have you. In most respects, a security mechanism to defeat this impersonation threat in responses would be very similar to a comparable mechanism for requests - except for the problem of retargeting. If Alice's request to Bob were retargeted to Carol, and Carol wished to send a secure response to Alice, this can create a number of headaches for existing security practices. The first, and perhaps most important, problem is that Carol's domain may not be the domain to which Alice sent the request. Any authentication or integrity provided by a solution like sip-identity [6] would require a signature over the response by the responding domain. If Alice sent the request to sip:bob@biloxi.example.com, and the request is retargeted to sip:carol@cleveland.example.org, then an identity service in Carol's domain, clearly, would not be able to sign for the domain in the To header field of the request and response (which would be biloxi.example.com). This is called the response identity problem (although this problem also arises for requests sent in the backwards direction within a dialog). The root problem here is, of course, that the To header field of the request and response does not contain the identity of the actual Peterson Expires August 15, 2005 [Page 6] Internet-Draft Retargeting Security February 2005 respondent. In these cases, Carol's domain cannot provide an identity signature, and accordingly responses cannot be secured when retargeting has occurred. This creates opportunities for eavesdroppers to launch impersonation attacks in responses. The solution space for this problem generally involves providing an identity for the respondent which the responding domain can sign. There are a number of ways this might be achieved; one common suggestion is that some kind of supplemental identity field, colloquially known as the 'connected party' field, should be added to responses in order to identify the party that was actually reached. Presumably, this field would be understood to clobber the value in the To header field of responses and represent the genuine identity of the respondent. However, this sort of solution gives rise to a new class of 'unanticipated respondent' problems. 2.2.1 The Unanticipated Respondent Problem When retargeting has occurred, the respondent to a request may not be identified by the To header field of the request and response. For example, the To header field of a request may designate sip:bob@biloxi.example.com, but an intermediary may retarget that request to sip:carol@cleveland.example.org. That request might then land at a UAS controlled by Carol, and Carol may be the respondent to that request. In this case we would say that Carol is the 'connected party'. In order to provide secure responses to Alice's request, one could argue that the 'connected party' information, i.e., some URI that identifies Carol, should be communicated to Alice in responses. This would let Alice know that some party other than the anticipated party (Bob) was reached by the request, and give her an identity of this unanticipated party. This information could then be cryptographically signed by the responding domain, presumably resolving any concerns about providing response identity. The problem is that Edgar the eavesdropper can do the same thing that Carol just did. That is, Edgar can construct a response with a 'connected party' value indicating himself. He can even get his domain (evil.example.net) to sign that 'connected party' value. When Edgar sends the response back to Alice, how can Alice tell the difference between his forged reply and Carol's legitimate reply? Ironically, 'connected party' does not provide any new leverage against the very problem that response identity is supposed to solve - preventing an eavesdropper from sending a forged reply. The reason why this is true is because allowing unanticipated respondents makes Alice's authorization decisions very complicated. Peterson Expires August 15, 2005 [Page 7] Internet-Draft Retargeting Security February 2005 If Alice authorize is to authorize some set of respondents other than Bob to reply to her request, how does she arrive at that set? In the current retargeting regime, Alice has no way of knowing what targets might be selected for her request by an intermediary, and accordingly, she has no choice but to accept any respondents that contact her. What is needed to address the response identity and unanticipated respondent problems, then, is a mechanism by which Alice can learn the set of targets which might be respondents to her request. This information would need to come from the domain that is changing the target of the request. In other words, when Alice sends a request to sip:bob@biloxi.example.com, biloxi.example.com would tell Alice that it was redirecting her request to sip:carol@cleveland.example.org. Alice could then set an authorization policy for this transaction that would only accept responses coming from Carol. This would allow Alice to tell the difference between a legitimate target of the request and an attacker. The major distinction between this explicit indication to the UAC of a change of target and the traditional concept of 'connected party' is the source of the indication - 'connected party' assumes that the respondent or respondent's domain provides the identity of the respondent. The requirement articulated here is that the domain that changes the target provides the new target for the request. Of course, it is possible that the target of the request will change several times during the routing of a request; in that case, several such indications would need to be given to the UAC by the mechanism so that a complete chain can be formed from the original form of the Request-URI to the final target. Note that the considerations above treat 'connected party' only as it relates to security and response identity; some have argued that 'connected party' is a nice feature to have in an environment with retargeting even if it were inert from a security perspective. 2.3 Establishment of Security Parameters Consider a case where Alice and Bob would like to share a voice conversation over the Internet which is secured by sRTP. In order to do so, Alice must generate a session key that will be used to encrypt media sent to her and place that session key inside an SDP offer. She must then send that offer to Bob in an INVITE. If the body of that invite is not encrypted, however, an eavesdropper might learn her symmetric key and use it to decrypt the media sent to her by Bob. Accordingly, she must learn a public key for Bob, and use that key to encrypt her SDP offer. One manner in which she might learn a public key for Bob is described in the certs [7] draft. Peterson Expires August 15, 2005 [Page 8] Internet-Draft Retargeting Security February 2005 What happens if Alice's request to Bob is retargeted to Carol? Since Carol does not (and should not) possess the private key corresponding to Bob's public key, she would send some sort of failure response code (perhaps a 493 Undecipherable). Carol and Alice might then reconnect in any of a number of ways; the manner suggest in RFC3261 is that Carol will return her certificate in the body of the 493 response, and the Alice will re-initiate the session, encrypting with Carol's certificate. Retargeting gives rise to a couple of problems here. One is just a variant of the previously-discussed 'unanticipated respondent' problem - Alice has no way of knowing if Carol is actually an attacker who sends a 493 in order to bid-down the security for the ensuing RTP session [note: this is a very serious problem, and is only being de-emphasized here because an essentially identical problem has already been discussed above]. But even beyond determining whether the 493 should be accepted, recovery from a 493 is awkward and fraught with risks because the scope of the key returned in the 493 is ambiguous when retargeting has occurred. When Alice receives a 493, whose key does she think she is learning from the body? What if Alice re-initiates her request, this time with the body encrypted with Carol's key, but the new request lands on a UA controlled by Bob? These cases are especially problematic when Carol's key is self-signed. Ultimately, the very potential for retargeting significantly discourages the use of confidentiality in SIP. Since Alice cannot anticipate when retargeting will occur, she cannot anticipate when she should expect an encrypted message to be accepted. The complexity of managing 493 responses and making the resulting authorization decisions and re-initiated messaging exchanges is fairly prohibitive. The 'connected party' mindset would suggest that Carol should disambiguate the 493 by providing her identity along with the certificate, informing Alice to re-originate the quest directly to Carol and encrypt with Carol's key. In this case, the 493 would behave something like a 3xx response, redirecting Alice's request from Bob to Carol. The problem with this approach is the same as the comparable 'connected party' problems above - the respondent is not the one authorized to retarget the request, and accordingly, the respondent should not be the one to tell the UAC the request's new target. This whole class of failure would be preventable if Alice were able to guess who would eventually receive her request. Since Alice can't access the location service at the domain which her request targets, though, she has to rely on that domain to tell her. If the Peterson Expires August 15, 2005 [Page 9] Internet-Draft Retargeting Security February 2005 intermediary that changed the target of the request could know, hypothetically, that Alice would need to rekey her request if the target changes, it could avoid the whole step of forwarding the retargeting the request to Carol and simply tell Alice (through a 3xx or something comparable) that Carol is the new target. While the example given here is specific to keying, there are a number of ways in which a request might need to be modified if its destination were to change. 2.4 Consent of the UAC Alice may be friends with Bob, but not at all cordial with Bob's friend Carol. If Bob configures his SIP service to forward messages to Carol, then Alice might reach Carol when she sends a request to Bob. While the consequences of this for an INVITE might not be so bad (Alice could hang up when she hears Carol's voice, or what have you), some SIP requests (such as the MESSAGE method) contain content that might be viewed by the recipient without any further activity on the part of the sender. . Because this sort of problem is a fact of life in the existing telephone system, it might seem unavoidable for SIP. However, there are Internet systems where this class of problem doesn't arise. One example would be the ad-blocker software built into web browsers. When a web browser with an ad-blocker downloads a page, it inspects the list of hyperlinks on the page and determines if any of them contain a blacklisted domain known to be associated with an advertiser. Those hyperlinks are never traversed. Ultimately, this works because HTTP has an endpoint consent model - when you access a web resource, it tells you what related resources you might want to access rather than pre-emptively accessing related resources on your behalf. In fact, retargeting is the reason why SIP does not have an endpoint consent model. The lack of an endpoint consent model prevents user agents from exercise valuable authorization policies. Consider the question of how a blacklist might operate. If we imagine that Alice hates Carol, then Alice might add Carol to her user agent's blacklist. Whenever Carol calls Alice, the blacklist is automatically consulted for an authorization decision and Alice's user agent rejects, politely or impolitely, the session initiation request. When Alice places a call, though, she has no control over the target set that will be selected for the call. If Carol is selected by a retargeting intermediary, then Alice will be put in contact with Carol against her will; effectively, this circumvents Alice's blacklist. Of course, if the intermediary sent a redirection Peterson Expires August 15, 2005 [Page 10] Internet-Draft Retargeting Security February 2005 At a high level, the main problem is when retargeting occurs, new targets are chosen by an intermediary without the consent of the UAC. By sending a request to a proxy server, the UAC is essentially giving "implied consent" that the request can be retargeted arbitrarily. To remedy this authorization policy defect, the UAC would have to have some ability to review the new targets for a request that have been chosen by an intermediary, and decide which of these targets it might want to pursue or not pursue before the request is forwarded to a new target. If the UAC does not learn the new target until the respondent responds (i.e., the 'connected party' approach), this will be of little help when the response is an acknowledgment of a MESSAGE request that is grossly inappropriate for the recipient. 2.5 Furtherance of Transitive Trust At a higher level, retargeting is also a source of transitivity for SIP. This is not in and of itself a direct threat, but an overall negative implication for the security model. If Alice sends a request to sip:bob@biloxi.example.com, and that request is retargeted by biloxi.com to sip:carol@cleveland.example.com, it places Alice at a significant disadvantage if she received a Digest authentication challenge response (i.e., a 407) from cleveland.example.com. Per RFC3261 26.3.2.1, the establishment of a direct connection to a challenging proxy allows the UAC to compare the subject of the site certificate presented by that proxy via TLS with the "realm" parameter used in Digest authentication. A correspondence between the two provides reference integrity - it ensures Alice that the challenge she is receiving from the realm 'cleveland.example.com' is actually coming from a proxy server at 'cleveland.example.com' rather than an imposter trying to capture her Digested credentials (which might then be attacked offline). If biloxi.com retargets and proxies the request, Alice will only have established a connection to biloxi.example.com, and thus she will have no may to match the challenge she received against the certificate of cleveland.example.com. If biloxi.example.com redirects, however, Alice can form her own TLS connection to cleveland.example.com to make this determination. Effectively, Alice must rely on Bob's domain to relay messages to and from Carol's domain faithfully, and if there is something suspicious about the response, Alice will not be able to determine authoritatively if Bob's domain or Carol's domain is responsible. In this sense, retargeting has put Alice into a position of increased transitive trust. Peterson Expires August 15, 2005 [Page 11] Internet-Draft Retargeting Security February 2005 3. Summary of Threats In terms of the typical Internet threat model, the sorts of threats described above require a relatively high level of sophistication in an attacker. In order for an attacker to impersonate a respondent, for example, the attacker must be able to capture dialog identifying parameters (which entails inspecting SIP signaling in transit), create plausible responses on the fly, insert this responses back into the signaling stream (or make it appear so to the originator through various forms of spoofing), and possibly squelch legitimate responses that might alert the originator to malfeasance. This essentially requires the attacker to be a man-in-the-middle. The use of judicious channel security, such as TLS, between proxy servers can prevent eavesdropping and many forms of signaling insertion or squelching. Unfortunately, in order to police the behavior of proxy servers themselves, however, one must guard against precisely that: a man-in-the-middle. The primary attacker envisioned by this draft is an intermediary which is legitimately within the path of SIP signaling. In summary, the threats that have been discussed in this section include: Service hijacking: Unscrupulous domains can retarget requests, disobeying the rules of RFC3261, without significant risk of detection. Insecure responses: When retargeting has occurred, traditional signatures cannot be applied to SIP responses because the identity of the sender is not reflected in the response. Modifying responses in order to communicate the identity of the sender does not seem to fix the problem. Confidentiality problems: It is easy to bid-down attempts to use confidentiality in SIP message bodies, and when SIP responses are used as a key distribution mechanism, retargeting makes the intended scope of those keys ambiguous. Circumvention of blacklists: Retargeting can cause a SIP user agent to come into contact with an entity that has been blacklisted. Rampant transitivity: Retargeting increases the amount of indirection between the originating user agent and various intermediaries and endpoints with which it might need to establish a security relationship. 4. Benefits of Retargeting Given that an intermediary has two different ways that it can choose Peterson Expires August 15, 2005 [Page 12] Internet-Draft Retargeting Security February 2005 to change the target of a request - redirection and retargeting - what are the advantages of retargeting over redirection? Messaging Efficiency: Instead sending a response back to the UAC whenever the target needs to change, intermediaries just forward the request. This can be significant in environments where UACs are constrained in terms of computational power or bandwidth. However, it can significantly increase the amount of signaling and state that an intermediary needs to manage, especially in forking cases. Target set privacy: If an intermediary discovers more than one potential target for a request, then the policy of the original target user may favor concealment of the whole target set from the UAC. In retargeting cases, a certain amount of information about the new target would be revealed in successful responses (the Contact header and so on), but unresponding targets would be totally hidden from the UAC. Redirection of course discloses the target set to the UAC. Target set ordering policy: If there is more than one possible target for a request, an intermediary can guarantee strict ordering of the target set by performing sequential forking itself. If the intermediary redirects to the UAC, it may use qvalues to suggest and ordering, but it has no guarantee that the ordering will be followed. Dialog control: By redirecting a dialog-forming request, an intermediary may put itself out of the loop of future signaling in the dialog. When an intermediary retargets a request, it may add a Record-Route header and thus remain in the path of future messages in the dialog. NAT traversal: In some cases, an intermediary that changes the target of a request is, in fact, the one SIP entity that can contact the new target. If, for example, the new target is behind a NAT, and maintains a persistent TLS connection to the retargeting intermediary, any requests heading to the target must go through the intermediary. The most important question about these benefits is the following: are they genuinely achievable only if retargeting transpires, or can they replicated via redirection? For example, the ordering of a target set can be preserved if the targets are shared via redirection one at a time with the UAC (though this will substantially decrease messaging efficiency). Many other effects, including privacy, dialog control, and even NAT traversal can be replicated by redirecting to an synthetic target (like a GRUU or an anonymized URI) which dereferences to an intermediary under the control of the retargeting domain. Peterson Expires August 15, 2005 [Page 13] Internet-Draft Retargeting Security February 2005 5. Requirements for Securing Retargeting In an ideal world, it would be possible for a UAC to have a strong assurance that intermediaries were behaving properly, and furthermore to have the capability to differentiate between properly-behaving intermediaries and attackers. It MUST be possible for a UAC to detect when a request has been retargeted. A domain that changes the target of a request MUST be capable of informing the UAC of the new target(s). The mechanism MUST allow simple intradomain retargeting in cases where persistent TLS connections are used as a NAT traversal mechanism. It must be possible for a domain that changes the target of a request to inform the UAC of the new target(s) prior to contacting any of the new target(s). There MUST furthermore be a way for intermediaries to determine when UACs require prior information about new targets. It MUST be possible to preserve the privacy of targets and potential targets of requests. It MUST be possible to preserve the ordering of a target set desired by the domain that changes the target of a request. 6. Security Considerations This document provides a framework and requirements for addressing an important gap in SIP's existing security practices. 7. IANA Considerations This document contains no considerations for the IANA. 8. References 8.1 Normative References [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [2] Bradner, S., "Key words for use in RFCs to indicate requirement levels", RFC 2119, March 1997. [3] Peterson, J., "A Privacy Mechanism for the Session Initiation Protocol (SIP)", RFC 3323, November 2002. [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Peterson Expires August 15, 2005 [Page 14] Internet-Draft Retargeting Security February 2005 [5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format", RFC 3893, September 2004. [6] Peterson, J., "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", draft-ietf-sip-identity-04 (work in progress), February 2005. [7] Peterson, J. and C. Jennings, "Certificate Management Service for SIP", draft-ietf-sip-certs-01 (work in progress), February 2005. 8.2 Informative References 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/ Appendix A. Acknowledgments Peterson Expires August 15, 2005 [Page 15] Internet-Draft Retargeting Security February 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. Peterson Expires August 15, 2005 [Page 16]