idnits 2.17.1 draft-peterson-sipping-retarget-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 704. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 681. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 688. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 694. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 710), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 97 has weird spacing: '...it will be fo...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 14, 2005) is 7004 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '1' is defined on line 632, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 636, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 639, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 642, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 645, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-sip-identity-04 == Outdated reference: A later version (-15) exists of draft-ietf-sip-certs-01 Summary: 6 errors (**), 0 flaws (~~), 12 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 SIPPING WG J. Peterson 2 Internet-Draft NeuStar 3 Expires: August 15, 2005 February 14, 2005 5 Retargeting and Security in SIP: A Framework and Requirements 6 draft-peterson-sipping-retarget-00 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on August 15, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 Retargeting, the alteration by intermediaries of the destination of a 40 Session Initiation Protocol (SIP) request, is a common practice 41 performed during the routing of a call. Some forms of retargeting, 42 however, give rise to security problems and potential functional gaps 43 in SIP. This document provides a general framework for discussion of 44 the security problems relating to retargeting, and gives requirements 45 for mechanisms that might overcome these problems. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 2. Problems with Retargeting . . . . . . . . . . . . . . . . . . 4 51 2.1 Legitimacy of Retargeting . . . . . . . . . . . . . . . . 5 52 2.2 Response Identity . . . . . . . . . . . . . . . . . . . . 6 53 2.2.1 The Unanticipated Respondent Problem . . . . . . . . . 7 54 2.3 Establishment of Security Parameters . . . . . . . . . . . 8 55 2.4 Consent of the UAC . . . . . . . . . . . . . . . . . . . . 10 56 2.5 Furtherance of Transitive Trust . . . . . . . . . . . . . 11 57 3. Summary of Threats . . . . . . . . . . . . . . . . . . . . . . 12 58 4. Benefits of Retargeting . . . . . . . . . . . . . . . . . . . 12 59 5. Requirements for Securing Retargeting . . . . . . . . . . . . 14 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 61 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 15 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 8.1 Normative References . . . . . . . . . . . . . . . . . . . . 14 65 8.2 Informative References . . . . . . . . . . . . . . . . . . . 15 66 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 67 Intellectual Property and Copyright Statements . . . . . . . . 16 69 1. Introduction 71 Retargeting is the process by which a SIP intermediary (such as a 72 proxy server) alters the Request-URI of a SIP request before it 73 forwards that request. A proxy server may retarget when it 74 determines (by accessing a location service, perhaps) that one or 75 more new target URIs are eligible to receive the request. 76 Retargeting to a contact address URI discovered by a location service 77 for the address-of-record in the Request-URI of a request is common. 78 However, proxy servers may also retarget to other proxy servers, 79 potentially leading to significant signaling chains between the UAC 80 and UAS. 82 When one or more new targets have been identified for a request, 83 RFC3261-compliant intermediaries can choose either to retarget or 84 redirect (i.e., send a 3xx response code) on a per-request basis. 85 Perhaps the most important reason for retargeting is efficiency, in 86 terms of overall messages required. In the simplest case (one new 87 target for the request is discovered): 88 A redirecting intermediary must send a 3xx response to the UAC. 89 The UAC must both acknowledge this response and send a new request 90 to the new target. Three messages total are required. 91 A retargeting intermediary sends only one message to the 92 destination UAS - nothing is sent back to the UAC. 94 However, retargeting has its downside: namely, the UAC does not know 95 where its request will be going. This might not immediately seem 96 like a serious problem; after all, when one places a telephone call, 97 one never really knows if it will be forwarded to a different 98 number, who will pick up the line when it rings, and so on. The 99 user-driven signaling environment of SIP, however, makes this 100 condition much more problematic than its analog in traditional 101 telephony. 103 Currently, RFC3261 allows retargeting to occur only under very 104 specific circumstances: a proxy server may retarget only if it is 105 'responsible' for the domain in the host portion of the Request-URI. 106 Unfortunately, this concept of 'responsibility' is not sufficiently 107 specified, and moreover, a UAC has no way of knowing which proxy 108 server in the network performed any retargeting. Consequently, the 109 UAC has no assurance at a protocol level against malicious or 110 misguided retargeting by intermediaries which are not 'responsible' 111 for the target. 113 In fact, RFC3261 includes a number of normative constraints on 114 intermediary behavior which suggest, tacitly, an authorization 115 relationship between the UAC and a proxy server. However, since 116 there is no explicit account of what exactly a UAC does and does not 117 authorize a proxy server to do, there is little by way of mechanism 118 in SIP to chaperone proxy server behavior. Since everything that is 119 not prevented by mechanism tends to be permitted in practice, the 120 reality is that SIP proxy servers behave as if UACs have no authority 121 to exert any policy controls over the handling of their requests and 122 accordingly, the normative constraints in RFC3261 are routinely 123 flouted. 125 Unfortunately, this inability to police intermediary behavior leads 126 to practicable attacks against SIP and various weaknesses in the 127 authorization policies needed by user agents. In order to address 128 such problems, a UAC must be capable of implementing authorization 129 policies informed by questions that are, today, essentially 130 unanswerable, such as: 131 How can a UAC determine the URI that a request has eventually 132 reached? 133 How can a UAC determine which intermediary has changed the target 134 of the request? 136 This draft attempts to tease out the actual authority which a UAC 137 invests in a proxy server, in so far as it relates to retargeting, by 138 examining the negative space: the problem cases where clearly, the 139 UAC cannot grant permissions to intermediaries without exposing 140 itself to attacks or policy failures. It then provides some 141 requirements for a corresponding security mechanism that might 142 actually constrain the retargeting behavior of intermediaries in 143 order to improve the overall security of the protocol. 145 2. Problems with Retargeting 147 SIP is a protocol that relies on intermediaries to perform 148 application-layer routing functions. It is necessary for 149 intermediaries to perform this function in order to support an 150 architectural layer of indirection between the identifiers of users 151 (the SIP "address-of-record" or AoR) and the identifiers of devices 152 (SIP "contact addresses"). The mappings between these two types of 153 identifiers are provided by the abstract location service function of 154 SIP, which is accessed by proxy servers when they make forwarding 155 decisions. This function is essential and integral to SIP's 156 operation. 158 However, this function also makes it difficult to differentiate an 159 intermediary that is behaving legitimately from an attacker. If SIP 160 is designed in such a way that malicious attacks against the protocol 161 cannot be distinguished from the legitimate activities of 162 intermediaries, then SIP will never be securable. 164 Ultimately, intermediaries can discharge their responsibilities while 165 giving user agents enough information to detect attacks and to make 166 reasonable authorization decisions. In order to understand how 167 intermediaries would need to behave for this to be the case, a 168 detailed examination of the gaps in SIP's current security story 169 relating to retargeting is necessary. 171 The problems discussed in this section exhibit the following three 172 qualities: 173 Undetectable: The originating user agent has no means of 174 anticipating that the condition will arise, nor any means of 175 determining that it has occurred until the negative consequences 176 have already been realized. 177 Unpreventable: There is no existing security mechanism that might 178 be employed by the originating user agent in order to guarantee 179 that the condition will not arise. 180 Entailed by retargeting: If retargeting did not exist, this 181 problem would not arise. 183 2.1 Legitimacy of Retargeting 185 RFC3261 allows retargeting to occur only if the retargeting 186 intermediary is responsible for the domain indicated by the 187 Request-URI of the request. For example, if a request was sent to 188 sip:bob@example.com, then a proxy server at example.com would be 189 authorized to retarget the request, but a proxy server at example.org 190 would not be authorized to retarget the request. 192 However, RFC3261 offers no way to enforce this rule. There is no way 193 for the UAC or UAS to detect which intermediary retargeted a request. 194 Accordingly, if due to local policy a UAC were forced to send its 195 request through a proxy server example.org on its way to the proxy 196 server at example.com, the example.org proxy server might malicious 197 retarget the request to, say, a user at example.org, and the UAC 198 would have no way to determine that example.com had not authorized 199 this retargeting. 201 The rule in RFC3261 is intended to combat various forms of service 202 hijacking. The domain in the Request-URI is permitted to retarget 203 because it presumably has a business relationship with the target 204 user, since that user can provision its local service with 205 registrations or other administrative means. Other domains, however, 206 have no such relationship with the target user, and might retarget to 207 their own advantage. If we imagine that example.org is a hotel, for 208 example, the example.org proxy server might retarget requests for 209 various local pizza shops (sip:orders@pizza.example.com) to a 210 specific, preferred pizza shop (sip:orders@pizza.example.net) with 211 which the hotel enjoys an underhanded business arrangement. 213 Nothing will be able to prevent intermediaries from changing the 214 Request-URI of a SIP request. It is impossible to provide integrity 215 protection over the Request-URI because there are cases where it 216 changes of necessity (such as intradomain routing of GRUUs and so 217 on). However, if it were possible to determine which proxy server 218 was responsible for changing the target of the request, the UAC could 219 abandon requests that have been maliciously mishandled and perhaps 220 take up some recourse against the misbehaving domain. As it stands, 221 since the condition in undetectable, domains might engage in this 222 behavior without fear of reproach. 224 2.2 Response Identity 226 When Alice sends a request to Bob, Bob may want to send a secure 227 response back to Alice. What is the purpose of a secure response? 228 Bob secures his response so that Alice can make certain authorization 229 and policy decisions based on the security of the response. Usually, 230 this requires at least providing integrity protection over the 231 response (as a whole or in part) and providing cryptographic 232 authentication of the sender of the response. Alice might accept the 233 response, or perhaps discard it, on the basis of those security 234 properties. In the absence of this authentication and integrity, it 235 might be possible for a third-party attacker, whom we'll call Edgar, 236 to eavesdrop on the request, and forge their own response 237 (impersonating Bob) with an inappropriate response code, or 238 inappropriate SDP answer, or what have you. 240 In most respects, a security mechanism to defeat this impersonation 241 threat in responses would be very similar to a comparable mechanism 242 for requests - except for the problem of retargeting. If Alice's 243 request to Bob were retargeted to Carol, and Carol wished to send a 244 secure response to Alice, this can create a number of headaches for 245 existing security practices. 247 The first, and perhaps most important, problem is that Carol's domain 248 may not be the domain to which Alice sent the request. Any 249 authentication or integrity provided by a solution like sip-identity 250 [6] would require a signature over the response by the responding 251 domain. If Alice sent the request to sip:bob@biloxi.example.com, and 252 the request is retargeted to sip:carol@cleveland.example.org, then an 253 identity service in Carol's domain, clearly, would not be able to 254 sign for the domain in the To header field of the request and 255 response (which would be biloxi.example.com). This is called the 256 response identity problem (although this problem also arises for 257 requests sent in the backwards direction within a dialog). 259 The root problem here is, of course, that the To header field of the 260 request and response does not contain the identity of the actual 261 respondent. In these cases, Carol's domain cannot provide an 262 identity signature, and accordingly responses cannot be secured when 263 retargeting has occurred. This creates opportunities for 264 eavesdroppers to launch impersonation attacks in responses. 266 The solution space for this problem generally involves providing an 267 identity for the respondent which the responding domain can sign. 268 There are a number of ways this might be achieved; one common 269 suggestion is that some kind of supplemental identity field, 270 colloquially known as the 'connected party' field, should be added to 271 responses in order to identify the party that was actually reached. 272 Presumably, this field would be understood to clobber the value in 273 the To header field of responses and represent the genuine identity 274 of the respondent. However, this sort of solution gives rise to a 275 new class of 'unanticipated respondent' problems. 277 2.2.1 The Unanticipated Respondent Problem 279 When retargeting has occurred, the respondent to a request may not be 280 identified by the To header field of the request and response. For 281 example, the To header field of a request may designate 282 sip:bob@biloxi.example.com, but an intermediary may retarget that 283 request to sip:carol@cleveland.example.org. That request might then 284 land at a UAS controlled by Carol, and Carol may be the respondent to 285 that request. 287 In this case we would say that Carol is the 'connected party'. In 288 order to provide secure responses to Alice's request, one could argue 289 that the 'connected party' information, i.e., some URI that 290 identifies Carol, should be communicated to Alice in responses. This 291 would let Alice know that some party other than the anticipated party 292 (Bob) was reached by the request, and give her an identity of this 293 unanticipated party. This information could then be 294 cryptographically signed by the responding domain, presumably 295 resolving any concerns about providing response identity. 297 The problem is that Edgar the eavesdropper can do the same thing that 298 Carol just did. That is, Edgar can construct a response with a 299 'connected party' value indicating himself. He can even get his 300 domain (evil.example.net) to sign that 'connected party' value. When 301 Edgar sends the response back to Alice, how can Alice tell the 302 difference between his forged reply and Carol's legitimate reply? 303 Ironically, 'connected party' does not provide any new leverage 304 against the very problem that response identity is supposed to solve 305 - preventing an eavesdropper from sending a forged reply. 307 The reason why this is true is because allowing unanticipated 308 respondents makes Alice's authorization decisions very complicated. 310 If Alice authorize is to authorize some set of respondents other than 311 Bob to reply to her request, how does she arrive at that set? In the 312 current retargeting regime, Alice has no way of knowing what targets 313 might be selected for her request by an intermediary, and 314 accordingly, she has no choice but to accept any respondents that 315 contact her. 317 What is needed to address the response identity and unanticipated 318 respondent problems, then, is a mechanism by which Alice can learn 319 the set of targets which might be respondents to her request. This 320 information would need to come from the domain that is changing the 321 target of the request. In other words, when Alice sends a request to 322 sip:bob@biloxi.example.com, biloxi.example.com would tell Alice that 323 it was redirecting her request to sip:carol@cleveland.example.org. 324 Alice could then set an authorization policy for this transaction 325 that would only accept responses coming from Carol. This would allow 326 Alice to tell the difference between a legitimate target of the 327 request and an attacker. 329 The major distinction between this explicit indication to the UAC of 330 a change of target and the traditional concept of 'connected party' 331 is the source of the indication - 'connected party' assumes that the 332 respondent or respondent's domain provides the identity of the 333 respondent. The requirement articulated here is that the domain that 334 changes the target provides the new target for the request. Of 335 course, it is possible that the target of the request will change 336 several times during the routing of a request; in that case, several 337 such indications would need to be given to the UAC by the mechanism 338 so that a complete chain can be formed from the original form of the 339 Request-URI to the final target. 341 Note that the considerations above treat 'connected party' only as it 342 relates to security and response identity; some have argued that 343 'connected party' is a nice feature to have in an environment with 344 retargeting even if it were inert from a security perspective. 346 2.3 Establishment of Security Parameters 348 Consider a case where Alice and Bob would like to share a voice 349 conversation over the Internet which is secured by sRTP. In order to 350 do so, Alice must generate a session key that will be used to encrypt 351 media sent to her and place that session key inside an SDP offer. 352 She must then send that offer to Bob in an INVITE. If the body of 353 that invite is not encrypted, however, an eavesdropper might learn 354 her symmetric key and use it to decrypt the media sent to her by Bob. 355 Accordingly, she must learn a public key for Bob, and use that key to 356 encrypt her SDP offer. One manner in which she might learn a public 357 key for Bob is described in the certs [7] draft. 359 What happens if Alice's request to Bob is retargeted to Carol? Since 360 Carol does not (and should not) possess the private key corresponding 361 to Bob's public key, she would send some sort of failure response 362 code (perhaps a 493 Undecipherable). Carol and Alice might then 363 reconnect in any of a number of ways; the manner suggest in RFC3261 364 is that Carol will return her certificate in the body of the 493 365 response, and the Alice will re-initiate the session, encrypting with 366 Carol's certificate. 368 Retargeting gives rise to a couple of problems here. One is just a 369 variant of the previously-discussed 'unanticipated respondent' 370 problem - Alice has no way of knowing if Carol is actually an 371 attacker who sends a 493 in order to bid-down the security for the 372 ensuing RTP session [note: this is a very serious problem, and is 373 only being de-emphasized here because an essentially identical 374 problem has already been discussed above]. But even beyond 375 determining whether the 493 should be accepted, recovery from a 493 376 is awkward and fraught with risks because the scope of the key 377 returned in the 493 is ambiguous when retargeting has occurred. When 378 Alice receives a 493, whose key does she think she is learning from 379 the body? What if Alice re-initiates her request, this time with the 380 body encrypted with Carol's key, but the new request lands on a UA 381 controlled by Bob? These cases are especially problematic when 382 Carol's key is self-signed. 384 Ultimately, the very potential for retargeting significantly 385 discourages the use of confidentiality in SIP. Since Alice cannot 386 anticipate when retargeting will occur, she cannot anticipate when 387 she should expect an encrypted message to be accepted. The 388 complexity of managing 493 responses and making the resulting 389 authorization decisions and re-initiated messaging exchanges is 390 fairly prohibitive. 392 The 'connected party' mindset would suggest that Carol should 393 disambiguate the 493 by providing her identity along with the 394 certificate, informing Alice to re-originate the quest directly to 395 Carol and encrypt with Carol's key. In this case, the 493 would 396 behave something like a 3xx response, redirecting Alice's request 397 from Bob to Carol. The problem with this approach is the same as the 398 comparable 'connected party' problems above - the respondent is not 399 the one authorized to retarget the request, and accordingly, the 400 respondent should not be the one to tell the UAC the request's new 401 target. 403 This whole class of failure would be preventable if Alice were able 404 to guess who would eventually receive her request. Since Alice can't 405 access the location service at the domain which her request targets, 406 though, she has to rely on that domain to tell her. If the 407 intermediary that changed the target of the request could know, 408 hypothetically, that Alice would need to rekey her request if the 409 target changes, it could avoid the whole step of forwarding the 410 retargeting the request to Carol and simply tell Alice (through a 3xx 411 or something comparable) that Carol is the new target. 413 While the example given here is specific to keying, there are a 414 number of ways in which a request might need to be modified if its 415 destination were to change. 417 2.4 Consent of the UAC 419 Alice may be friends with Bob, but not at all cordial with Bob's 420 friend Carol. If Bob configures his SIP service to forward messages 421 to Carol, then Alice might reach Carol when she sends a request to 422 Bob. While the consequences of this for an INVITE might not be so 423 bad (Alice could hang up when she hears Carol's voice, or what have 424 you), some SIP requests (such as the MESSAGE method) contain content 425 that might be viewed by the recipient without any further activity on 426 the part of the sender. 428 . Because this sort of problem is a fact of life in the existing 429 telephone system, it might seem unavoidable for SIP. However, there 430 are Internet systems where this class of problem doesn't arise. One 431 example would be the ad-blocker software built into web browsers. 432 When a web browser with an ad-blocker downloads a page, it inspects 433 the list of hyperlinks on the page and determines if any of them 434 contain a blacklisted domain known to be associated with an 435 advertiser. Those hyperlinks are never traversed. Ultimately, this 436 works because HTTP has an endpoint consent model - when you access a 437 web resource, it tells you what related resources you might want to 438 access rather than pre-emptively accessing related resources on your 439 behalf. 441 In fact, retargeting is the reason why SIP does not have an endpoint 442 consent model. The lack of an endpoint consent model prevents user 443 agents from exercise valuable authorization policies. Consider the 444 question of how a blacklist might operate. If we imagine that Alice 445 hates Carol, then Alice might add Carol to her user agent's 446 blacklist. Whenever Carol calls Alice, the blacklist is 447 automatically consulted for an authorization decision and Alice's 448 user agent rejects, politely or impolitely, the session initiation 449 request. When Alice places a call, though, she has no control over 450 the target set that will be selected for the call. If Carol is 451 selected by a retargeting intermediary, then Alice will be put in 452 contact with Carol against her will; effectively, this circumvents 453 Alice's blacklist. Of course, if the intermediary sent a redirection 454 At a high level, the main problem is when retargeting occurs, new 455 targets are chosen by an intermediary without the consent of the UAC. 456 By sending a request to a proxy server, the UAC is essentially giving 457 "implied consent" that the request can be retargeted arbitrarily. To 458 remedy this authorization policy defect, the UAC would have to have 459 some ability to review the new targets for a request that have been 460 chosen by an intermediary, and decide which of these targets it might 461 want to pursue or not pursue before the request is forwarded to a new 462 target. 464 If the UAC does not learn the new target until the respondent 465 responds (i.e., the 'connected party' approach), this will be of 466 little help when the response is an acknowledgment of a MESSAGE 467 request that is grossly inappropriate for the recipient. 469 2.5 Furtherance of Transitive Trust 471 At a higher level, retargeting is also a source of transitivity for 472 SIP. This is not in and of itself a direct threat, but an overall 473 negative implication for the security model. 475 If Alice sends a request to sip:bob@biloxi.example.com, and that 476 request is retargeted by biloxi.com to 477 sip:carol@cleveland.example.com, it places Alice at a significant 478 disadvantage if she received a Digest authentication challenge 479 response (i.e., a 407) from cleveland.example.com. Per RFC3261 480 26.3.2.1, the establishment of a direct connection to a challenging 481 proxy allows the UAC to compare the subject of the site certificate 482 presented by that proxy via TLS with the "realm" parameter used in 483 Digest authentication. A correspondence between the two provides 484 reference integrity - it ensures Alice that the challenge she is 485 receiving from the realm 'cleveland.example.com' is actually coming 486 from a proxy server at 'cleveland.example.com' rather than an 487 imposter trying to capture her Digested credentials (which might then 488 be attacked offline). 490 If biloxi.com retargets and proxies the request, Alice will only have 491 established a connection to biloxi.example.com, and thus she will 492 have no may to match the challenge she received against the 493 certificate of cleveland.example.com. If biloxi.example.com 494 redirects, however, Alice can form her own TLS connection to 495 cleveland.example.com to make this determination. Effectively, Alice 496 must rely on Bob's domain to relay messages to and from Carol's 497 domain faithfully, and if there is something suspicious about the 498 response, Alice will not be able to determine authoritatively if 499 Bob's domain or Carol's domain is responsible. In this sense, 500 retargeting has put Alice into a position of increased transitive 501 trust. 503 3. Summary of Threats 505 In terms of the typical Internet threat model, the sorts of threats 506 described above require a relatively high level of sophistication in 507 an attacker. In order for an attacker to impersonate a respondent, 508 for example, the attacker must be able to capture dialog identifying 509 parameters (which entails inspecting SIP signaling in transit), 510 create plausible responses on the fly, insert this responses back 511 into the signaling stream (or make it appear so to the originator 512 through various forms of spoofing), and possibly squelch legitimate 513 responses that might alert the originator to malfeasance. This 514 essentially requires the attacker to be a man-in-the-middle. The use 515 of judicious channel security, such as TLS, between proxy servers can 516 prevent eavesdropping and many forms of signaling insertion or 517 squelching. 519 Unfortunately, in order to police the behavior of proxy servers 520 themselves, however, one must guard against precisely that: a 521 man-in-the-middle. The primary attacker envisioned by this draft is 522 an intermediary which is legitimately within the path of SIP 523 signaling. 525 In summary, the threats that have been discussed in this section 526 include: 527 Service hijacking: Unscrupulous domains can retarget requests, 528 disobeying the rules of RFC3261, without significant risk of 529 detection. 530 Insecure responses: When retargeting has occurred, traditional 531 signatures cannot be applied to SIP responses because the identity 532 of the sender is not reflected in the response. Modifying 533 responses in order to communicate the identity of the sender does 534 not seem to fix the problem. 535 Confidentiality problems: It is easy to bid-down attempts to use 536 confidentiality in SIP message bodies, and when SIP responses are 537 used as a key distribution mechanism, retargeting makes the 538 intended scope of those keys ambiguous. 539 Circumvention of blacklists: Retargeting can cause a SIP user 540 agent to come into contact with an entity that has been 541 blacklisted. 542 Rampant transitivity: Retargeting increases the amount of 543 indirection between the originating user agent and various 544 intermediaries and endpoints with which it might need to establish 545 a security relationship. 547 4. Benefits of Retargeting 549 Given that an intermediary has two different ways that it can choose 550 to change the target of a request - redirection and retargeting - 551 what are the advantages of retargeting over redirection? 552 Messaging Efficiency: Instead sending a response back to the UAC 553 whenever the target needs to change, intermediaries just forward 554 the request. This can be significant in environments where UACs 555 are constrained in terms of computational power or bandwidth. 556 However, it can significantly increase the amount of signaling and 557 state that an intermediary needs to manage, especially in forking 558 cases. 559 Target set privacy: If an intermediary discovers more than one 560 potential target for a request, then the policy of the original 561 target user may favor concealment of the whole target set from the 562 UAC. In retargeting cases, a certain amount of information about 563 the new target would be revealed in successful responses (the 564 Contact header and so on), but unresponding targets would be 565 totally hidden from the UAC. Redirection of course discloses the 566 target set to the UAC. 567 Target set ordering policy: If there is more than one possible 568 target for a request, an intermediary can guarantee strict 569 ordering of the target set by performing sequential forking 570 itself. If the intermediary redirects to the UAC, it may use 571 qvalues to suggest and ordering, but it has no guarantee that the 572 ordering will be followed. 573 Dialog control: By redirecting a dialog-forming request, an 574 intermediary may put itself out of the loop of future signaling in 575 the dialog. When an intermediary retargets a request, it may add 576 a Record-Route header and thus remain in the path of future 577 messages in the dialog. 578 NAT traversal: In some cases, an intermediary that changes the 579 target of a request is, in fact, the one SIP entity that can 580 contact the new target. If, for example, the new target is behind 581 a NAT, and maintains a persistent TLS connection to the 582 retargeting intermediary, any requests heading to the target must 583 go through the intermediary. 585 The most important question about these benefits is the following: 586 are they genuinely achievable only if retargeting transpires, or can 587 they replicated via redirection? For example, the ordering of a 588 target set can be preserved if the targets are shared via redirection 589 one at a time with the UAC (though this will substantially decrease 590 messaging efficiency). Many other effects, including privacy, dialog 591 control, and even NAT traversal can be replicated by redirecting to 592 an synthetic target (like a GRUU or an anonymized URI) which 593 dereferences to an intermediary under the control of the retargeting 594 domain. 596 5. Requirements for Securing Retargeting 598 In an ideal world, it would be possible for a UAC to have a strong 599 assurance that intermediaries were behaving properly, and furthermore 600 to have the capability to differentiate between properly-behaving 601 intermediaries and attackers. 602 It MUST be possible for a UAC to detect when a request has been 603 retargeted. 604 A domain that changes the target of a request MUST be capable of 605 informing the UAC of the new target(s). 606 The mechanism MUST allow simple intradomain retargeting in cases 607 where persistent TLS connections are used as a NAT traversal 608 mechanism. 609 It must be possible for a domain that changes the target of a 610 request to inform the UAC of the new target(s) prior to contacting 611 any of the new target(s). There MUST furthermore be a way for 612 intermediaries to determine when UACs require prior information 613 about new targets. 614 It MUST be possible to preserve the privacy of targets and 615 potential targets of requests. 616 It MUST be possible to preserve the ordering of a target set 617 desired by the domain that changes the target of a request. 619 6. Security Considerations 621 This document provides a framework and requirements for addressing an 622 important gap in SIP's existing security practices. 624 7. IANA Considerations 626 This document contains no considerations for the IANA. 628 8. References 630 8.1 Normative References 632 [1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 633 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 634 Session Initiation Protocol", RFC 3261, May 2002. 636 [2] Bradner, S., "Key words for use in RFCs to indicate requirement 637 levels", RFC 2119, March 1997. 639 [3] Peterson, J., "A Privacy Mechanism for the Session Initiation 640 Protocol (SIP)", RFC 3323, November 2002. 642 [4] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol 643 (SIP): Locating SIP Servers", RFC 3263, June 2002. 645 [5] Peterson, J., "Session Initiation Protocol (SIP) Authenticated 646 Identity Body (AIB) Format", RFC 3893, September 2004. 648 [6] Peterson, J., "Enhancements for Authenticated Identity 649 Management in the Session Initiation Protocol (SIP)", 650 draft-ietf-sip-identity-04 (work in progress), February 2005. 652 [7] Peterson, J. and C. Jennings, "Certificate Management Service 653 for SIP", draft-ietf-sip-certs-01 (work in progress), February 654 2005. 656 8.2 Informative References 658 Author's Address 660 Jon Peterson 661 NeuStar, Inc. 662 1800 Sutter St 663 Suite 570 664 Concord, CA 94520 665 US 667 Phone: +1 925/363-8720 668 EMail: jon.peterson@neustar.biz 669 URI: http://www.neustar.biz/ 671 Appendix A. Acknowledgments 672 Intellectual Property Statement 674 The IETF takes no position regarding the validity or scope of any 675 Intellectual Property Rights or other rights that might be claimed to 676 pertain to the implementation or use of the technology described in 677 this document or the extent to which any license under such rights 678 might or might not be available; nor does it represent that it has 679 made any independent effort to identify any such rights. Information 680 on the procedures with respect to rights in RFC documents can be 681 found in BCP 78 and BCP 79. 683 Copies of IPR disclosures made to the IETF Secretariat and any 684 assurances of licenses to be made available, or the result of an 685 attempt made to obtain a general license or permission for the use of 686 such proprietary rights by implementers or users of this 687 specification can be obtained from the IETF on-line IPR repository at 688 http://www.ietf.org/ipr. 690 The IETF invites any interested party to bring to its attention any 691 copyrights, patents or patent applications, or other proprietary 692 rights that may cover technology that may be required to implement 693 this standard. Please address the information to the IETF at 694 ietf-ipr@ietf.org. 696 Disclaimer of Validity 698 This document and the information contained herein are provided on an 699 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 700 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 701 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 702 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 703 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 704 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 706 Copyright Statement 708 Copyright (C) The Internet Society (2005). This document is subject 709 to the rights, licenses and restrictions contained in BCP 78, and 710 except as set forth therein, the authors retain all their rights. 712 Acknowledgment 714 Funding for the RFC Editor function is currently provided by the 715 Internet Society.