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

Versions: 00

SIP WG                                                          R. State
Internet-Draft                                  University of Luxembourg
Intended status: Informational                                 O. Festor
Expires: September 3, 2009                                   H. Abdelnur
                                        INRIA, Centre de recherche Grand
                                                                     Est
                                                              V. Pascual
                                                               J. Kuthan
                                                         R. Coeffic, Ed.
                                                                J. Janak
                                                              J. Floroiu
                                                     Tekelec / iptel.org
                                                           March 2, 2009


                 SIP digest authentication relay attack
                    draft-state-sip-relay-attack-00

Status of This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   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.



State, et al.           Expires September 3, 2009               [Page 1]

Internet-Draft   SIP digest authentication relay attack       March 2009


   This Internet-Draft will expire on September 3, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism
   for creating, modifying, and terminating sessions with one or more
   participants.  This document describes a vulnerability of SIP
   combined with HTTP Digest Access Authentication [RFC2617] through
   which an attacker can leverage the victim's credentials to send
   authenticated requests on his behalf.  This attack is different from
   the man-in-the-middle (MITM) attack and does not require any
   eavesdropping, DNS or IP spoofing.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Mode of operation  . . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  The basic relay attack . . . . . . . . . . . . . . . . . .  4
     3.2.  Pre-conditions . . . . . . . . . . . . . . . . . . . . . . 11
   4.  Possible mitigations . . . . . . . . . . . . . . . . . . . . . 14
   5.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     6.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     6.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 16
   Appendix B.  Open Issues . . . . . . . . . . . . . . . . . . . . . 16













State, et al.           Expires September 3, 2009               [Page 2]

Internet-Draft   SIP digest authentication relay attack       March 2009


1.  Introduction

   The Session Initiation Protocol (SIP [RFC3261]) provides a mechanism
   for creating, modifying, and terminating sessions with one or more
   participants.  The route used for messages within an established
   session is determined by the route-set, which is recorded during
   session initiation using the record-routing mechanism.  Additionally,
   the participants provide a contact address, the address at which they
   whish to be contacted for further requests within a given session.

   This document describes a vulnerability of SIP combined with HTTP
   Digest Access Authentication [RFC2617] through which an attacker can
   leverage the victim's credentials to send authenticated requests.
   This attack is different from the man-in-the-middle (MITM) attack and
   does not require any eavesdropping, DNS or IP spoofing.  In most
   cases, the session can be initiated by the attacker and only requires
   the victim to send a re-INVITE or any other in-dialog request that
   can also be used out-of-dialog at some point in time, which can be
   triggered by the attacker as well.

   Digest Access Authentication is the authentication mechanism which is
   used by SIP proxies and UAs to authenticate any type of request sent
   by a UA (apart from CANCEL and ACK).  It is mostly used by proxies to
   authenticate registrations and session setup.  It is based on the
   exchange of a challenge, generated by the UAS, and a response, which
   is generated by the UAC.  Challenge and response are based on
   digesting and hashing a secret and certain parts of the messages.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

   The other concepts and terminology used in this document are
   compatible with RFC3261 [RFC3261] and [RFC2617].

3.  Mode of operation

   This attack creates a man-in-the-middle situation by SIP means to
   start a more classical attack on Digest Access Authentication
   ([RFC2617]).  This allows the attacker to send SIP requests on behalf
   on the victim, while using credentials generated by the victim.  In
   particular, it allows the attacker to start the MITM attack on Digest
   Access Authentication without the need for eavesdropping, DNS or IP
   spoofing.

   This is done by establishing a session with the victim, in which the



State, et al.           Expires September 3, 2009               [Page 3]

Internet-Draft   SIP digest authentication relay attack       March 2009


   attacker is placed between the victim and the authenticating proxy on
   the signaling path.  Then, an in-dialog request sent by the victim is
   recycled and turned into an out-of-dialog request that can be sent to
   a target chosen by the attacker.

3.1.  The basic relay attack

   Figure 1 shows the relay attack, which can be executed as-is if the
   victim accepts requests from any host.  Please note that this is the
   simplest case.  However, even if the victim's UA would only accept
   requests from its outbound proxy, there are still ways to perform
   this attack (see Section 3.2).

   The attacker (bob@rogue.com) starts by initiating a session with
   Alice with an INVITE request (F1) conforming to [RFC3261].


   F1 INVITE Bob -> Alice

      INVITE sip:alice@dhcp12345.home.com SIP/2.0
      Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds8
      From: Bob <sip:bob@rogue.com>;tag=9fxced76sl
      To: Alice <sip:alice@proxy.com>
      Call-ID: 3848276298220188511@rogue.com
      Contact: <sip:bob.rogue.com>
      Content-Type: application/sdp
      Content-Length:...

      [SDP not shown]


   In F1 above, the request URI is set to alice@dhcp12345.home.com,
   which is the contact that Alice registered at proxy.com.  This
   contact can be obtained by setting up another session with Alice
   prior to the attack, this time using alice@proxy.com as a request
   URI, and remembering the contact address given by Alice's UA in the
   200 reply.

   After Alice has sent a successful final reply (F2), Bob sends an ACK
   (F3) and the session is initiated between Bob and Alice.











State, et al.           Expires September 3, 2009               [Page 4]

Internet-Draft   SIP digest authentication relay attack       March 2009


   F2 200 OK Alice -> Bob

      SIP/2.0 200 OK
      Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds8
      From: Bob <sip:bob@rogue.com>;tag=9fxced76sl
      To: Alice <sip:alice@proxy.com>;tag=6546g5er4g
      Call-ID: 3848276298220188511@rogue.com
      Contact: <sip:alice@dhcp12345.home.com>
      Content-Type: application/sdp
      Content-Length:...

      [SDP not shown]







































State, et al.           Expires September 3, 2009               [Page 5]

Internet-Draft   SIP digest authentication relay attack       March 2009


                             bob              alice     +1-900-xxx
         proxy.com       @rogue.com        @proxy.com   @proxy.com
            |                 |                 |            |
            |                 |  INVITE F1      |            |
            |                 |---------------->|            |
            |                 |  200 OK F2      |            |
            |                 |<----------------|            |
            |                 |     ACK F3      |            |
            |                 |---------------->|            |
            |                 |                 |            |
            |                 |  media session  |            |
            |                 |.................|            |
            |                 |                 |            |
            |                 |  INVITE F4      |            |
            |                 |<----------------|            |
            |              modify               |            |
            |            the request            |            |
            |  INVITE F5      |                 |            |
            |<----------------|                 |            |
            |     407 F6      |                 |            |
            |---------------->|                 |            |
            |     ACK F7      |                 |            |
            |<----------------|                 |            |
            |              reverse              |            |
            |            the changes            |            |
            |                 |     407 F8      |            |
            |                 |---------------->|            |
            |                 |     ACK F9      |            |
            |                 |<----------------|            |
            |              modify               |            |
            |            the request            |            |
            |                 | INVITE(auth) F10|            |
            | INVITE(auth) F11|<----------------|            |
            |<----------------|                 |            |
            |      INVITE F12 |                 |            |
            |----------------------------------------------->|
            |                 |                 |            |

                       Figure 1: Basic relay attack

   Once the session between Alice and Bob has been initiated, Bob can
   either use the SIP session timer [RFC4028] or social engineering to
   trigger Alice's UA send a re-INVITE (F4).  The SIP session timer is
   very appealing because it does not need any special actions from
   Alice.  Bob only has to maintain the session active until the first
   refresh, which will happen after 45 seconds if the minimum refresh
   timer duration (90) has been accepted by Alice's UA.




State, et al.           Expires September 3, 2009               [Page 6]

Internet-Draft   SIP digest authentication relay attack       March 2009


   It is important that the attacker includes the 'refresher=uas'
   parameter to the Session-Expires header field to force Alice's UA to
   be the refresher (see [RFC4028] for more details).  This choice
   cannot be overridden by the UAS as stated in [RFC4028], section 9:


           "However, as the table indicates [Table 2], the UAS cannot
           override the UAC's choice of refresher, if it made one."


   It is also important for success of the attack that INVITE is used to
   refresh the session.  In fact, [RFC4028] also allows the use of
   UPDATE for this purpose.  But, as the attack relies on the
   possibility to turn an in-dialog request into an out-of-dialog
   request and UPDATE cannot be sent without a dialog, the attacker will
   try to prevent the victim from using UPDATE.  This is done by simply
   not announcing any support for the UPDATE method.


   F4 INVITE Alice -> Bob

      INVITE sip:bob.rogue.com SIP/2.0
      Via: SIP/2.0/UDP alice@dhcp12345.home.com;branch=z9hG4bKnashds10
      To: Bob <sip:bob@rogue.com>;tag=9fxced76sl
      From: Alice <sip:alice@proxy.com>;tag=6546g5er4g
      Call-ID: 3848276298220188511@rogue.com
      Route: <sip:bob@bob.rogue.com;lr>
      Contact: <sip:alice@dhcp12345.home.com>
      Content-Type: application/sdp
      Content-Length:...

      [SDP not shown]


   Social engineering might be required if the session refresh timer
   could not be set to a value which is small enough or if Alice does
   not support the SIP session timer.  In this case, an accomplice of
   Bob could call Alice as well, and both can hope that Bob will be
   placed on hold, which is usually done by sending a re-INVITE.  An
   alternative might be to ask for a transfer call and thus generate a
   re-INVITE.










State, et al.           Expires September 3, 2009               [Page 7]

Internet-Draft   SIP digest authentication relay attack       March 2009


   F5 INVITE Bob -> proxy.com

      INVITE sip:+1-900-xxx@proxy.com SIP/2.0
      Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds12
      To: "+1-900-xxx" <sip:+1-900-xxx@proxy.com>
      From: Alice <sip:alice@proxy.com>;tag=6546g5er4g
      Call-ID: 9876543298220145234@rogue.com
      Contact: <sip:bob.rogue.com>
      Content-Type: application/sdp
      Content-Length:...

      [SDP not shown]


   Then, Bob uses this re-INVITE (F4) with some modifications to
   initiate a session with 1-900-xxx@proxy.com (F5).  The most obvious
   modification consists of removing the To-tag so that the request
   looks like an out-of-dialog request.  However, Bob could also change
   almost any other parts of the message not protected by the
   authentication mechanism, which in fact means everything but the
   request method.


   F6 407  proxy.com -> Bob

      SIP/2.0 407 Proxy Authentication Required
      Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds12
      To: "+1-900-xxx" <sip:+1-900-xxx@proxy.com>
      From: Alice <sip:alice@proxy.com>;tag=6546g5er4g
      Call-ID: 9876543298220145234@rogue.com
      Proxy-Authenticate: Digest realm="proxy.com",
       qop="auth, auth-int", nonce="f84f1cec41e6cbe5aea9c8e88d359543",
       opaque="", stale=FALSE, algorithm=MD5
      Content-Length: 0


   As proxy.com uses authentication to verify the identity of its users,
   this proxy generates a 407 (Proxy Authentication Required) response
   (F6) containing a challenge.  This challenge is passed back to Alice
   by constructing a valid 407 response (F8) based on the original re-
   INVITE (F4), thus reversing the modifications made on the way to
   proxy.com.









State, et al.           Expires September 3, 2009               [Page 8]

Internet-Draft   SIP digest authentication relay attack       March 2009


   F8 407  Bob -> Alice

      SIP/2.0 407 Proxy Authentication Required
      Via: SIP/2.0/UDP alice@dhcp12345.home.com;branch=z9hG4bKnashds10
      To: Bob <sip:bob@rogue.com>;tag=9fxced76sl
      From: Alice <sip:alice@proxy.com>;tag=6546g5er4g
      Call-ID: 9876543298220145234@rogue.com
      Proxy-Authenticate: Digest realm="proxy.com",
       nonce="f84f1cec41e6cbe5aea9c8e88d359543",
       opaque="", stale=FALSE, algorithm=MD5
      Content-Length: 0


   As proxy.com is Alice's proxy, it is most probable that her UA will
   have the user's credentials and reply this challenge without asking
   her.  While generating the challenge response, some parts of the new
   INVITE (F10) generated by Alice are hashed into the challenge
   response, thus protecting those parts from being modified by Bob
   without proxy.com noticing it.


   F10 INVITE Alice -> Bob

      INVITE sip:bob.rogue.com SIP/2.0
      Via: SIP/2.0/UDP alice@dhcp12345.home.com;branch=z9hG4bKnashds10
      To: Bob <sip:bob@rogue.com>;tag=9fxced76sl
      From: Alice <sip:alice@proxy.com>;tag=6546g5er4g
      Call-ID: 3848276298220188511@rogue.com
      Route: <sip:bob@bob.rogue.com;lr>
      Contact: <sip:alice@dhcp12345.home.com>
      Proxy-Authorization: Digest username="alice", realm="proxy.com",
       uri="sip:bob@rogue.com", nonce="f84f1cec41e6cbe5aea9c8e88d359543",
       response="3bea678acef9875433487f23a567d876",
       opaque="", algorithm=MD5
      Content-Type: application/sdp
      Content-Length:...

      [SDP not shown]













State, et al.           Expires September 3, 2009               [Page 9]

Internet-Draft   SIP digest authentication relay attack       March 2009


   F11 INVITE Bob -> proxy.com

      INVITE sip:+1-900-xxx@proxy.com SIP/2.0
      Via: SIP/2.0/UDP bob.rogue.com;branch=z9hG4bKnashds12
      To: "+1-900-xxx" <sip:+1-900-xxx@proxy.com>
      From: Alice <sip:alice@proxy.com>;tag=6546g5er4g
      Call-ID: 9876543298220145234@rogue.com
      Contact: <sip:bob@bob.rogue.com>
      Proxy-Authorization: Digest username="alice", realm="proxy.com",
       uri="sip:bob@rogue.com", nonce="f84f1cec41e6cbe5aea9c8e88d359543",
       response="3bea678acef9875433487f23a567d876",
       opaque="", algorithm=MD5
      Content-Type: application/sdp
      Content-Length:...

      [SDP not shown]


   Which parts are included depends on the 'qop' attribute used in the
   Proxy-Authenticate header field.  If the 'qop' attribute has been set
   to 'auth' or is not present, then only the method and the request URI
   are hashed.  If 'qop=auth-int', the message body is taken into
   account as well.  However, it is very easy for Bob to execute a bid-
   down attack by simply removing the option 'qop' parameter from the
   Proxy-Authorize header field (see [RFC2617], section 4.8).

   After the bid-down attack has been performed, only the method and the
   request URI are protected.  It is worth noting that the protection
   provided on the request URI is purely theoretical, as [RFC3261]
   introduces an exception to the request URI checking required by
   [RFC2617] in section 22.4:


     "6.  RFC 2617 requires that a server check that the URI in the
          request line and the URI included in the Authorization header
          field point to the same resource.  In a SIP context, these two
          URIs may refer to different users, due to forwarding at some
          proxy.  Therefore, in SIP, a server MAY check that the
          Request-URI in the Authorization header field value
          corresponds to a user for whom the server is willing to accept
          forwarded or direct requests, but it is not necessarily a
          failure if the two fields are not equivalent."


   This implies that only the method is always protected, whereby the
   request URI (R-URI) can also be changed.  This offers multiple
   opportunities to the attacker such as impersonating Alice, or calling
   for free on Alice's expenses.



State, et al.           Expires September 3, 2009              [Page 10]

Internet-Draft   SIP digest authentication relay attack       March 2009


3.2.  Pre-conditions

   In the call flow in the previous section, Alice does accept requests
   from any host on the internet.  This allows Bob to call her directly.
   However, more secure phones are usually configured to only accept
   requests if they are coming from their outbound proxy.  In this case,
   it might not be as easy as previously to place Bob between Alice and
   the authenticating proxy, but still possible.

   If we keep the assumption that Bob calls Alice first, the call flow
   shown in Figure 2 can be used.  The only possible issue we would
   encounter here would come from proxy.com removing the credentials
   from the new INVITE request (F17).

   If proxy.com and p2.com are one and the same, or at least performing
   authentication with the same realm, it is most probable that this is
   what would happen.  But if they are different, there is no reason why
   proxy.com would remove those credentials, which means that the attack
   is still possible.  In fact, proxies typically do not touch
   credentials with a realm which is different from the one they belong
   to.






























State, et al.           Expires September 3, 2009              [Page 11]

Internet-Draft   SIP digest authentication relay attack       March 2009


                            bob                            alice
         p2.com        @rogue.com        proxy.com      @proxy.com
           |                |                |                |
           |                |  INVITE F1     |   INVITE F2    |
           |                |--------------->|--------------->|
           |                |  200 OK F4     |   200 OK F3    |
           |                |<---------------|<---------------|
           |                |     ACK F5     |      ACK F6    |
           |                |--------------->|--------------->|
           |                |                |                |
           |                |          mediasession           |
           |                |.................................|
           |                |                |                |
           |                |  INVITE F8     |   INVITE F7    |
           |                |<---------------|<---------------|
           |             modify              |                |
           |           the request           |                |
           | INVITE F9      |                |                |
           |<---------------|                |                |
           |    407 F10     |                |                |
           |--------------->|                |                |
           |    ACK F11     |                |                |
           |<---------------|                |                |
           |             reverse             |                |
           |           the changes           |                |
           |                |     407 F12    |     407 F13    |
           |                |--------------->|--------------->|
           |                |     ACK F15    |     ACK F14    |
           |                |<---------------|<---------------|
           |                | INV w/auth  F17| INV w/auth F16 |
           |                |<---------------|<---------------|
           |             modify              |                |
           |           the request           |                |
           |                |                |                |
           | INV w/auth F18 |                |                |
           |<---------------|                |                |
           |                |                |                |

                Figure 2: Relay attack with outbound proxy

   If the attacker manages to get the victim to call him first, it is
   even possible to remove the first proxy from the signaling path and
   attack this proxy's authentication.

   An example of this is shown in Figure 3.






State, et al.           Expires September 3, 2009              [Page 12]

Internet-Draft   SIP digest authentication relay attack       March 2009


                           bob                             alice
         proxy.com     @rogue.com        proxy.com      @proxy.com
           |                |                |                |
           |                |  INVITE F1     |   INVITE F2    |
           |                |<---------------|<---------------|
           |         remove proxy.com        |                |
           |         from Record-Route       |                |
           |          and Via headers        |                |
           |                |            200 OK F3            |
           |                |-------------------------------->|
           |                |               ACK F4            |
           |                |<--------------------------------|
           |                |                |                |
           |                |          mediasession           |
           |                |.................................|
           |                |                |                |
           |                |  INVITE F6     |   INVITE F5    |
           |                |<--------------------------------|
           |             modify              |                |
           |           the request           |                |
           | INVITE F7      |                |                |
           |<---------------|                |                |
           |    407 F8      |                |                |
           |--------------->|                |                |
           |    ACK F9      |                |                |
           |<---------------|                |                |
           |             reverse             |                |
           |           the changes           |                |
           |                |             407 F10             |
           |                |-------------------------------->|
           |                |             ACK F11             |
           |                |<--------------------------------|
           |                |     INV w/auth  F12             |
           |                |<--------------------------------|
           |             modify              |                |
           |           the request           |                |
           |                |                |                |
           | INV w/auth F13 |                |                |
           |<---------------|                |                |
           |                |                |                |

                         Figure 3: Alice calls Bob

   In the call flow above, Alice calls Bob through her outbound proxy
   (proxy.com).  In the 200 reply, Bob removes proxy.com from the
   Record-Route and Via header fields.  After this manipulation has been
   done, Bob can proceed with the basic relay attack as shown in
   Section 3.1.



State, et al.           Expires September 3, 2009              [Page 13]

Internet-Draft   SIP digest authentication relay attack       March 2009


   If Alice is using a Network Address (and Port) Translator (NAPT;
   which is most probable if Alice is an average consumer), it is
   especially easy to execute the attack as shown in Figure 3 with UDP.
   This assumes that proxy.com has written the IP address of Alice's UA
   in the 'received' parameter of the Via header field.  The first
   possibility is to remove proxy.com from the Record-Route header
   field, but not from the Via, and hope that proxy.com will not notice
   this change.  The other possibility is to send F3 with the source IP
   address set to that of proxy.com.

   It is worth noting that if Alice sends any other request than INVITE
   which can also be used out-of-dialog, the same procedures can be
   applied by the attacker to send such requests with the proper
   authentication provided by Alice to a destination of his choice.

4.  Possible mitigations

   There may be many solutions to the problems stated in this document.
   This section is an attempt to summarize a couple of suggestions that
   have been made in the past to initiate a debate about most
   appropriate solutions.

   The basic attack as shown in Figure 1 can be prevented successfully
   with following counter-measures:

   o  Alice could use a strict outbound proxy.  This means that her UA
      shall only accept SIP messages with a source IP address set to the
      outbound proxy's IP address.

   o  The outbound proxy should remove the credentials related to his
      administrative domain before forwarding the request anywhere else.

   The call flows depicted in Figure 2 and Figure 3 show that using an
   outbound proxy does not solve the problem by itself.  It is also very
   important that this outbound proxy is able to remove the credentials
   of its users before forwarding the request anywhere else, and shall
   thus be able to perform the authentication by itself.  Or it should
   at least only forward challenge responses to some well known hosts
   within the same administrative domain.

   However, the case shown in Figure 2 cannot be avoided with a strict
   outbound proxy as described above, as the attacked proxy is not in
   the same administrative domain as the outbound proxy.  In this case,
   one way for p2.com to mitigate the attack is to refuse authenticated
   requests coming from another address as the registered contact, thus
   forcing registration prior to communication through this proxy.

   A somehow interresting mitigation would be to avoid sending re-INVITE



State, et al.           Expires September 3, 2009              [Page 14]

Internet-Draft   SIP digest authentication relay attack       March 2009


   request at all.  If a session refresh is needed, UPDATE could be used
   instead.  As shown earlier, it is very simple for the attacker to
   disable the use of UPDATE anyway.  This leads to a situation where
   Alice would have to refuse to establish sessions with UAs that do not
   support UPDATE.  Whereby this could be reached by deprecating re-
   INVITE in future version of SIP, this does not really solving the
   issue with current deployments.  On the longer run, the re-INVITE
   method could be redefined to a dedicated specific method with a
   distinct set of credentials with respect to the initial INVITE
   method.

5.  Acknowledgements

   The authors gratefully acknowledge the contribution of the members of
   the team that discovered the relay attack: H. Abdelnur, O. Festor, R.
   State.

6.  References

6.1.  Normative References

   [RFC2119]                Bradner, S., "Key words for use in RFCs to
                            Indicate Requirement Levels", BCP 14,
                            RFC 2119, March 1997.

   [RFC2617]                Franks, J., Hallam-Baker, P., Hostetler, J.,
                            Lawrence, S., Leach, P., Luotonen, A., and
                            L. Stewart, "HTTP Authentication: Basic and
                            Digest Access Authentication", RFC 2617,
                            June 1999.

   [RFC3261]                Rosenberg, J., Schulzrinne, H., Camarillo,
                            G., Johnston, A., Peterson, J., Sparks, R.,
                            Handley, M., and E. Schooler, "SIP: Session
                            Initiation Protocol", RFC 3261, June 2002.

   [RFC4028]                Donovan, S. and J. Rosenberg, "Session
                            Timers in the Session Initiation Protocol
                            (SIP)", RFC 4028, April 2005.

6.2.  Informative References

   [voipsec-ml]             Abdelnur, H., State, R., and O. Festor,
                            "Breaking SIP for fun and toll fraud".

   [draft-undery-sip-auth]  "Enhanced Usage of HTTP Digest
                            Authentication for SIP".




State, et al.           Expires September 3, 2009              [Page 15]

Internet-Draft   SIP digest authentication relay attack       March 2009


Appendix A.  Change Log

   New document

Appendix B.  Open Issues

   Section 4 needs to be extended.

Authors' Addresses

   R. State
   University of Luxembourg
   6, rue Richard Coudenhove-Kalergi
   L-1359 Luxembourg
   Luxembourg

   Phone: +352 46 66 44 56 47
   EMail: Radu.State@uni.lu


   O. Festor
   INRIA, Centre de recherche Grand Est
   61, rue du jardin botanique
   Nancy
   France

   Phone: +33 383 59 30 66
   EMail: olivier.festor@inria.fr


   H. Abdelnur
   INRIA, Centre de recherche Grand Est
   61, rue du jardin botanique
   Nancy
   France

   Phone: +33 383 59 30 66
   EMail: Humberto.Abdelnur@loria.fr













State, et al.           Expires September 3, 2009              [Page 16]

Internet-Draft   SIP digest authentication relay attack       March 2009


   V. Pascual
   Tekelec / iptel.org
   Am Borsigturm 11
   Berlin
   Germany

   Phone: +49 30 32 51 32 12
   EMail: victor@iptel.org


   J. Kuthan
   Tekelec / iptel.org
   Am Borsigturm 11
   Berlin
   Germany

   Phone: +49 30 32 51 32 13
   EMail: Jiri.Kuthan@tekelec.com


   R. Coeffic (editor)
   Tekelec / iptel.org
   Am Borsigturm 11
   Berlin
   Germany

   Phone: +49 30 32 51 32 18
   EMail: raphael@iptel.org


   J. Janak
   Tekelec / iptel.org
   Am Borsigturm 11
   Berlin
   Germany

   Phone: +49 30 32 51 32 18
   EMail: Jan.Janak@tekelec.com













State, et al.           Expires September 3, 2009              [Page 17]

Internet-Draft   SIP digest authentication relay attack       March 2009


   J. Floroiu
   Tekelec / iptel.org
   Am Borsigturm 11
   Berlin
   Germany

   Phone: +49 30 32 51 32 16
   EMail: John.Floroiu@tekelec.com











































State, et al.           Expires September 3, 2009              [Page 18]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/