idnits 2.17.1 draft-state-sip-relay-attack-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([RFC2617], [RFC3261]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2009) is 5528 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'Table 2' is mentioned on line 241, but not defined ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RFC 7615, RFC 7616, RFC 7617) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP WG R. State 3 Internet-Draft University of Luxembourg 4 Intended status: Informational O. Festor 5 Expires: September 3, 2009 H. Abdelnur 6 INRIA, Centre de recherche Grand 7 Est 8 V. Pascual 9 J. Kuthan 10 R. Coeffic, Ed. 11 J. Janak 12 J. Floroiu 13 Tekelec / iptel.org 14 March 2, 2009 16 SIP digest authentication relay attack 17 draft-state-sip-relay-attack-00 19 Status of This Memo 21 This Internet-Draft is submitted to IETF in full conformance with the 22 provisions of BCP 78 and BCP 79. This document may contain material 23 from IETF Documents or IETF Contributions published or made publicly 24 available before November 10, 2008. The person(s) controlling the 25 copyright in some of this material may not have granted the IETF 26 Trust the right to allow modifications of such material outside the 27 IETF Standards Process. Without obtaining an adequate license from 28 the person(s) controlling the copyright in such materials, this 29 document may not be modified outside the IETF Standards Process, and 30 derivative works of it may not be created outside the IETF Standards 31 Process, except to format it for publication as an RFC or to 32 translate it into languages other than English. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF), its areas, and its working groups. Note that 36 other groups may also distribute working documents as Internet- 37 Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 The list of current Internet-Drafts can be accessed at 45 http://www.ietf.org/ietf/1id-abstracts.txt. 47 The list of Internet-Draft Shadow Directories can be accessed at 48 http://www.ietf.org/shadow.html. 50 This Internet-Draft will expire on September 3, 2009. 52 Copyright Notice 54 Copyright (c) 2009 IETF Trust and the persons identified as the 55 document authors. All rights reserved. 57 This document is subject to BCP 78 and the IETF Trust's Legal 58 Provisions Relating to IETF Documents in effect on the date of 59 publication of this document (http://trustee.ietf.org/license-info). 60 Please review these documents carefully, as they describe your rights 61 and restrictions with respect to this document. 63 Abstract 65 The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism 66 for creating, modifying, and terminating sessions with one or more 67 participants. This document describes a vulnerability of SIP 68 combined with HTTP Digest Access Authentication [RFC2617] through 69 which an attacker can leverage the victim's credentials to send 70 authenticated requests on his behalf. This attack is different from 71 the man-in-the-middle (MITM) attack and does not require any 72 eavesdropping, DNS or IP spoofing. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 77 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 78 3. Mode of operation . . . . . . . . . . . . . . . . . . . . . . 3 79 3.1. The basic relay attack . . . . . . . . . . . . . . . . . . 4 80 3.2. Pre-conditions . . . . . . . . . . . . . . . . . . . . . . 11 81 4. Possible mitigations . . . . . . . . . . . . . . . . . . . . . 14 82 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6.1. Normative References . . . . . . . . . . . . . . . . . . . 15 85 6.2. Informative References . . . . . . . . . . . . . . . . . . 15 86 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 16 87 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . . 16 89 1. Introduction 91 The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism 92 for creating, modifying, and terminating sessions with one or more 93 participants. The route used for messages within an established 94 session is determined by the route-set, which is recorded during 95 session initiation using the record-routing mechanism. Additionally, 96 the participants provide a contact address, the address at which they 97 whish to be contacted for further requests within a given session. 99 This document describes a vulnerability of SIP combined with HTTP 100 Digest Access Authentication [RFC2617] through which an attacker can 101 leverage the victim's credentials to send authenticated requests. 102 This attack is different from the man-in-the-middle (MITM) attack and 103 does not require any eavesdropping, DNS or IP spoofing. In most 104 cases, the session can be initiated by the attacker and only requires 105 the victim to send a re-INVITE or any other in-dialog request that 106 can also be used out-of-dialog at some point in time, which can be 107 triggered by the attacker as well. 109 Digest Access Authentication is the authentication mechanism which is 110 used by SIP proxies and UAs to authenticate any type of request sent 111 by a UA (apart from CANCEL and ACK). It is mostly used by proxies to 112 authenticate registrations and session setup. It is based on the 113 exchange of a challenge, generated by the UAS, and a response, which 114 is generated by the UAC. Challenge and response are based on 115 digesting and hashing a secret and certain parts of the messages. 117 2. Terminology 119 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 120 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 121 document are to be interpreted as described in RFC 2119 [RFC2119]. 123 The other concepts and terminology used in this document are 124 compatible with RFC3261 [RFC3261] and [RFC2617]. 126 3. Mode of operation 128 This attack creates a man-in-the-middle situation by SIP means to 129 start a more classical attack on Digest Access Authentication 130 ([RFC2617]). This allows the attacker to send SIP requests on behalf 131 on the victim, while using credentials generated by the victim. In 132 particular, it allows the attacker to start the MITM attack on Digest 133 Access Authentication without the need for eavesdropping, DNS or IP 134 spoofing. 136 This is done by establishing a session with the victim, in which the 137 attacker is placed between the victim and the authenticating proxy on 138 the signaling path. Then, an in-dialog request sent by the victim is 139 recycled and turned into an out-of-dialog request that can be sent to 140 a target chosen by the attacker. 142 3.1. The basic relay attack 144 Figure 1 shows the relay attack, which can be executed as-is if the 145 victim accepts requests from any host. Please note that this is the 146 simplest case. However, even if the victim's UA would only accept 147 requests from its outbound proxy, there are still ways to perform 148 this attack (see Section 3.2). 150 The attacker (bob@rogue.com) starts by initiating a session with 151 Alice with an INVITE request (F1) conforming to [RFC3261]. 153 F1 INVITE Bob -> Alice 155 INVITE sip:alice@dhcp12345.home.com SIP/2.0 156 Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds8 157 From: Bob ;tag=9fxced76sl 158 To: Alice 159 Call-ID: 3848276298220188511@rogue.com 160 Contact: 161 Content-Type: application/sdp 162 Content-Length:... 164 [SDP not shown] 166 In F1 above, the request URI is set to alice@dhcp12345.home.com, 167 which is the contact that Alice registered at proxy.com. This 168 contact can be obtained by setting up another session with Alice 169 prior to the attack, this time using alice@proxy.com as a request 170 URI, and remembering the contact address given by Alice's UA in the 171 200 reply. 173 After Alice has sent a successful final reply (F2), Bob sends an ACK 174 (F3) and the session is initiated between Bob and Alice. 176 F2 200 OK Alice -> Bob 178 SIP/2.0 200 OK 179 Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds8 180 From: Bob ;tag=9fxced76sl 181 To: Alice ;tag=6546g5er4g 182 Call-ID: 3848276298220188511@rogue.com 183 Contact: 184 Content-Type: application/sdp 185 Content-Length:... 187 [SDP not shown] 188 bob alice +1-900-xxx 189 proxy.com @rogue.com @proxy.com @proxy.com 190 | | | | 191 | | INVITE F1 | | 192 | |---------------->| | 193 | | 200 OK F2 | | 194 | |<----------------| | 195 | | ACK F3 | | 196 | |---------------->| | 197 | | | | 198 | | media session | | 199 | |.................| | 200 | | | | 201 | | INVITE F4 | | 202 | |<----------------| | 203 | modify | | 204 | the request | | 205 | INVITE F5 | | | 206 |<----------------| | | 207 | 407 F6 | | | 208 |---------------->| | | 209 | ACK F7 | | | 210 |<----------------| | | 211 | reverse | | 212 | the changes | | 213 | | 407 F8 | | 214 | |---------------->| | 215 | | ACK F9 | | 216 | |<----------------| | 217 | modify | | 218 | the request | | 219 | | INVITE(auth) F10| | 220 | INVITE(auth) F11|<----------------| | 221 |<----------------| | | 222 | INVITE F12 | | | 223 |----------------------------------------------->| 224 | | | | 226 Figure 1: Basic relay attack 228 Once the session between Alice and Bob has been initiated, Bob can 229 either use the SIP session timer [RFC4028] or social engineering to 230 trigger Alice's UA send a re-INVITE (F4). The SIP session timer is 231 very appealing because it does not need any special actions from 232 Alice. Bob only has to maintain the session active until the first 233 refresh, which will happen after 45 seconds if the minimum refresh 234 timer duration (90) has been accepted by Alice's UA. 236 It is important that the attacker includes the 'refresher=uas' 237 parameter to the Session-Expires header field to force Alice's UA to 238 be the refresher (see [RFC4028] for more details). This choice 239 cannot be overridden by the UAS as stated in [RFC4028], section 9: 241 "However, as the table indicates [Table 2], the UAS cannot 242 override the UAC's choice of refresher, if it made one." 244 It is also important for success of the attack that INVITE is used to 245 refresh the session. In fact, [RFC4028] also allows the use of 246 UPDATE for this purpose. But, as the attack relies on the 247 possibility to turn an in-dialog request into an out-of-dialog 248 request and UPDATE cannot be sent without a dialog, the attacker will 249 try to prevent the victim from using UPDATE. This is done by simply 250 not announcing any support for the UPDATE method. 252 F4 INVITE Alice -> Bob 254 INVITE sip:bob.rogue.com SIP/2.0 255 Via: SIP/2.0/UDP alice@dhcp12345.home.com;branch=z9hG4bKnashds10 256 To: Bob ;tag=9fxced76sl 257 From: Alice ;tag=6546g5er4g 258 Call-ID: 3848276298220188511@rogue.com 259 Route: 260 Contact: 261 Content-Type: application/sdp 262 Content-Length:... 264 [SDP not shown] 266 Social engineering might be required if the session refresh timer 267 could not be set to a value which is small enough or if Alice does 268 not support the SIP session timer. In this case, an accomplice of 269 Bob could call Alice as well, and both can hope that Bob will be 270 placed on hold, which is usually done by sending a re-INVITE. An 271 alternative might be to ask for a transfer call and thus generate a 272 re-INVITE. 274 F5 INVITE Bob -> proxy.com 276 INVITE sip:+1-900-xxx@proxy.com SIP/2.0 277 Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds12 278 To: "+1-900-xxx" 279 From: Alice ;tag=6546g5er4g 280 Call-ID: 9876543298220145234@rogue.com 281 Contact: 282 Content-Type: application/sdp 283 Content-Length:... 285 [SDP not shown] 287 Then, Bob uses this re-INVITE (F4) with some modifications to 288 initiate a session with 1-900-xxx@proxy.com (F5). The most obvious 289 modification consists of removing the To-tag so that the request 290 looks like an out-of-dialog request. However, Bob could also change 291 almost any other parts of the message not protected by the 292 authentication mechanism, which in fact means everything but the 293 request method. 295 F6 407 proxy.com -> Bob 297 SIP/2.0 407 Proxy Authentication Required 298 Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds12 299 To: "+1-900-xxx" 300 From: Alice ;tag=6546g5er4g 301 Call-ID: 9876543298220145234@rogue.com 302 Proxy-Authenticate: Digest realm="proxy.com", 303 qop="auth, auth-int", nonce="f84f1cec41e6cbe5aea9c8e88d359543", 304 opaque="", stale=FALSE, algorithm=MD5 305 Content-Length: 0 307 As proxy.com uses authentication to verify the identity of its users, 308 this proxy generates a 407 (Proxy Authentication Required) response 309 (F6) containing a challenge. This challenge is passed back to Alice 310 by constructing a valid 407 response (F8) based on the original re- 311 INVITE (F4), thus reversing the modifications made on the way to 312 proxy.com. 314 F8 407 Bob -> Alice 316 SIP/2.0 407 Proxy Authentication Required 317 Via: SIP/2.0/UDP alice@dhcp12345.home.com;branch=z9hG4bKnashds10 318 To: Bob ;tag=9fxced76sl 319 From: Alice ;tag=6546g5er4g 320 Call-ID: 9876543298220145234@rogue.com 321 Proxy-Authenticate: Digest realm="proxy.com", 322 nonce="f84f1cec41e6cbe5aea9c8e88d359543", 323 opaque="", stale=FALSE, algorithm=MD5 324 Content-Length: 0 326 As proxy.com is Alice's proxy, it is most probable that her UA will 327 have the user's credentials and reply this challenge without asking 328 her. While generating the challenge response, some parts of the new 329 INVITE (F10) generated by Alice are hashed into the challenge 330 response, thus protecting those parts from being modified by Bob 331 without proxy.com noticing it. 333 F10 INVITE Alice -> Bob 335 INVITE sip:bob.rogue.com SIP/2.0 336 Via: SIP/2.0/UDP alice@dhcp12345.home.com;branch=z9hG4bKnashds10 337 To: Bob ;tag=9fxced76sl 338 From: Alice ;tag=6546g5er4g 339 Call-ID: 3848276298220188511@rogue.com 340 Route: 341 Contact: 342 Proxy-Authorization: Digest username="alice", realm="proxy.com", 343 uri="sip:bob@rogue.com", nonce="f84f1cec41e6cbe5aea9c8e88d359543", 344 response="3bea678acef9875433487f23a567d876", 345 opaque="", algorithm=MD5 346 Content-Type: application/sdp 347 Content-Length:... 349 [SDP not shown] 351 F11 INVITE Bob -> proxy.com 353 INVITE sip:+1-900-xxx@proxy.com SIP/2.0 354 Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds12 355 To: "+1-900-xxx" 356 From: Alice ;tag=6546g5er4g 357 Call-ID: 9876543298220145234@rogue.com 358 Contact: 359 Proxy-Authorization: Digest username="alice", realm="proxy.com", 360 uri="sip:bob@rogue.com", nonce="f84f1cec41e6cbe5aea9c8e88d359543", 361 response="3bea678acef9875433487f23a567d876", 362 opaque="", algorithm=MD5 363 Content-Type: application/sdp 364 Content-Length:... 366 [SDP not shown] 368 Which parts are included depends on the 'qop' attribute used in the 369 Proxy-Authenticate header field. If the 'qop' attribute has been set 370 to 'auth' or is not present, then only the method and the request URI 371 are hashed. If 'qop=auth-int', the message body is taken into 372 account as well. However, it is very easy for Bob to execute a bid- 373 down attack by simply removing the option 'qop' parameter from the 374 Proxy-Authorize header field (see [RFC2617], section 4.8). 376 After the bid-down attack has been performed, only the method and the 377 request URI are protected. It is worth noting that the protection 378 provided on the request URI is purely theoretical, as [RFC3261] 379 introduces an exception to the request URI checking required by 380 [RFC2617] in section 22.4: 382 "6. RFC 2617 requires that a server check that the URI in the 383 request line and the URI included in the Authorization header 384 field point to the same resource. In a SIP context, these two 385 URIs may refer to different users, due to forwarding at some 386 proxy. Therefore, in SIP, a server MAY check that the 387 Request-URI in the Authorization header field value 388 corresponds to a user for whom the server is willing to accept 389 forwarded or direct requests, but it is not necessarily a 390 failure if the two fields are not equivalent." 392 This implies that only the method is always protected, whereby the 393 request URI (R-URI) can also be changed. This offers multiple 394 opportunities to the attacker such as impersonating Alice, or calling 395 for free on Alice's expenses. 397 3.2. Pre-conditions 399 In the call flow in the previous section, Alice does accept requests 400 from any host on the internet. This allows Bob to call her directly. 401 However, more secure phones are usually configured to only accept 402 requests if they are coming from their outbound proxy. In this case, 403 it might not be as easy as previously to place Bob between Alice and 404 the authenticating proxy, but still possible. 406 If we keep the assumption that Bob calls Alice first, the call flow 407 shown in Figure 2 can be used. The only possible issue we would 408 encounter here would come from proxy.com removing the credentials 409 from the new INVITE request (F17). 411 If proxy.com and p2.com are one and the same, or at least performing 412 authentication with the same realm, it is most probable that this is 413 what would happen. But if they are different, there is no reason why 414 proxy.com would remove those credentials, which means that the attack 415 is still possible. In fact, proxies typically do not touch 416 credentials with a realm which is different from the one they belong 417 to. 419 bob alice 420 p2.com @rogue.com proxy.com @proxy.com 421 | | | | 422 | | INVITE F1 | INVITE F2 | 423 | |--------------->|--------------->| 424 | | 200 OK F4 | 200 OK F3 | 425 | |<---------------|<---------------| 426 | | ACK F5 | ACK F6 | 427 | |--------------->|--------------->| 428 | | | | 429 | | mediasession | 430 | |.................................| 431 | | | | 432 | | INVITE F8 | INVITE F7 | 433 | |<---------------|<---------------| 434 | modify | | 435 | the request | | 436 | INVITE F9 | | | 437 |<---------------| | | 438 | 407 F10 | | | 439 |--------------->| | | 440 | ACK F11 | | | 441 |<---------------| | | 442 | reverse | | 443 | the changes | | 444 | | 407 F12 | 407 F13 | 445 | |--------------->|--------------->| 446 | | ACK F15 | ACK F14 | 447 | |<---------------|<---------------| 448 | | INV w/auth F17| INV w/auth F16 | 449 | |<---------------|<---------------| 450 | modify | | 451 | the request | | 452 | | | | 453 | INV w/auth F18 | | | 454 |<---------------| | | 455 | | | | 457 Figure 2: Relay attack with outbound proxy 459 If the attacker manages to get the victim to call him first, it is 460 even possible to remove the first proxy from the signaling path and 461 attack this proxy's authentication. 463 An example of this is shown in Figure 3. 465 bob alice 466 proxy.com @rogue.com proxy.com @proxy.com 467 | | | | 468 | | INVITE F1 | INVITE F2 | 469 | |<---------------|<---------------| 470 | remove proxy.com | | 471 | from Record-Route | | 472 | and Via headers | | 473 | | 200 OK F3 | 474 | |-------------------------------->| 475 | | ACK F4 | 476 | |<--------------------------------| 477 | | | | 478 | | mediasession | 479 | |.................................| 480 | | | | 481 | | INVITE F6 | INVITE F5 | 482 | |<--------------------------------| 483 | modify | | 484 | the request | | 485 | INVITE F7 | | | 486 |<---------------| | | 487 | 407 F8 | | | 488 |--------------->| | | 489 | ACK F9 | | | 490 |<---------------| | | 491 | reverse | | 492 | the changes | | 493 | | 407 F10 | 494 | |-------------------------------->| 495 | | ACK F11 | 496 | |<--------------------------------| 497 | | INV w/auth F12 | 498 | |<--------------------------------| 499 | modify | | 500 | the request | | 501 | | | | 502 | INV w/auth F13 | | | 503 |<---------------| | | 504 | | | | 506 Figure 3: Alice calls Bob 508 In the call flow above, Alice calls Bob through her outbound proxy 509 (proxy.com). In the 200 reply, Bob removes proxy.com from the 510 Record-Route and Via header fields. After this manipulation has been 511 done, Bob can proceed with the basic relay attack as shown in 512 Section 3.1. 514 If Alice is using a Network Address (and Port) Translator (NAPT; 515 which is most probable if Alice is an average consumer), it is 516 especially easy to execute the attack as shown in Figure 3 with UDP. 517 This assumes that proxy.com has written the IP address of Alice's UA 518 in the 'received' parameter of the Via header field. The first 519 possibility is to remove proxy.com from the Record-Route header 520 field, but not from the Via, and hope that proxy.com will not notice 521 this change. The other possibility is to send F3 with the source IP 522 address set to that of proxy.com. 524 It is worth noting that if Alice sends any other request than INVITE 525 which can also be used out-of-dialog, the same procedures can be 526 applied by the attacker to send such requests with the proper 527 authentication provided by Alice to a destination of his choice. 529 4. Possible mitigations 531 There may be many solutions to the problems stated in this document. 532 This section is an attempt to summarize a couple of suggestions that 533 have been made in the past to initiate a debate about most 534 appropriate solutions. 536 The basic attack as shown in Figure 1 can be prevented successfully 537 with following counter-measures: 539 o Alice could use a strict outbound proxy. This means that her UA 540 shall only accept SIP messages with a source IP address set to the 541 outbound proxy's IP address. 543 o The outbound proxy should remove the credentials related to his 544 administrative domain before forwarding the request anywhere else. 546 The call flows depicted in Figure 2 and Figure 3 show that using an 547 outbound proxy does not solve the problem by itself. It is also very 548 important that this outbound proxy is able to remove the credentials 549 of its users before forwarding the request anywhere else, and shall 550 thus be able to perform the authentication by itself. Or it should 551 at least only forward challenge responses to some well known hosts 552 within the same administrative domain. 554 However, the case shown in Figure 2 cannot be avoided with a strict 555 outbound proxy as described above, as the attacked proxy is not in 556 the same administrative domain as the outbound proxy. In this case, 557 one way for p2.com to mitigate the attack is to refuse authenticated 558 requests coming from another address as the registered contact, thus 559 forcing registration prior to communication through this proxy. 561 A somehow interresting mitigation would be to avoid sending re-INVITE 562 request at all. If a session refresh is needed, UPDATE could be used 563 instead. As shown earlier, it is very simple for the attacker to 564 disable the use of UPDATE anyway. This leads to a situation where 565 Alice would have to refuse to establish sessions with UAs that do not 566 support UPDATE. Whereby this could be reached by deprecating re- 567 INVITE in future version of SIP, this does not really solving the 568 issue with current deployments. On the longer run, the re-INVITE 569 method could be redefined to a dedicated specific method with a 570 distinct set of credentials with respect to the initial INVITE 571 method. 573 5. Acknowledgements 575 The authors gratefully acknowledge the contribution of the members of 576 the team that discovered the relay attack: H. Abdelnur, O. Festor, R. 577 State. 579 6. References 581 6.1. Normative References 583 [RFC2119] Bradner, S., "Key words for use in RFCs to 584 Indicate Requirement Levels", BCP 14, 585 RFC 2119, March 1997. 587 [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., 588 Lawrence, S., Leach, P., Luotonen, A., and 589 L. Stewart, "HTTP Authentication: Basic and 590 Digest Access Authentication", RFC 2617, 591 June 1999. 593 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, 594 G., Johnston, A., Peterson, J., Sparks, R., 595 Handley, M., and E. Schooler, "SIP: Session 596 Initiation Protocol", RFC 3261, June 2002. 598 [RFC4028] Donovan, S. and J. Rosenberg, "Session 599 Timers in the Session Initiation Protocol 600 (SIP)", RFC 4028, April 2005. 602 6.2. Informative References 604 [voipsec-ml] Abdelnur, H., State, R., and O. Festor, 605 "Breaking SIP for fun and toll fraud". 607 [draft-undery-sip-auth] "Enhanced Usage of HTTP Digest 608 Authentication for SIP". 610 Appendix A. Change Log 612 New document 614 Appendix B. Open Issues 616 Section 4 needs to be extended. 618 Authors' Addresses 620 R. State 621 University of Luxembourg 622 6, rue Richard Coudenhove-Kalergi 623 L-1359 Luxembourg 624 Luxembourg 626 Phone: +352 46 66 44 56 47 627 EMail: Radu.State@uni.lu 629 O. Festor 630 INRIA, Centre de recherche Grand Est 631 61, rue du jardin botanique 632 Nancy 633 France 635 Phone: +33 383 59 30 66 636 EMail: olivier.festor@inria.fr 638 H. Abdelnur 639 INRIA, Centre de recherche Grand Est 640 61, rue du jardin botanique 641 Nancy 642 France 644 Phone: +33 383 59 30 66 645 EMail: Humberto.Abdelnur@loria.fr 646 V. Pascual 647 Tekelec / iptel.org 648 Am Borsigturm 11 649 Berlin 650 Germany 652 Phone: +49 30 32 51 32 12 653 EMail: victor@iptel.org 655 J. Kuthan 656 Tekelec / iptel.org 657 Am Borsigturm 11 658 Berlin 659 Germany 661 Phone: +49 30 32 51 32 13 662 EMail: Jiri.Kuthan@tekelec.com 664 R. Coeffic (editor) 665 Tekelec / iptel.org 666 Am Borsigturm 11 667 Berlin 668 Germany 670 Phone: +49 30 32 51 32 18 671 EMail: raphael@iptel.org 673 J. Janak 674 Tekelec / iptel.org 675 Am Borsigturm 11 676 Berlin 677 Germany 679 Phone: +49 30 32 51 32 18 680 EMail: Jan.Janak@tekelec.com 681 J. Floroiu 682 Tekelec / iptel.org 683 Am Borsigturm 11 684 Berlin 685 Germany 687 Phone: +49 30 32 51 32 16 688 EMail: John.Floroiu@tekelec.com