[Search] [txt|pdf|bibtex] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
SIP Working Group                                             H. Kaplan
Internet Draft                                              Acme Packet
Intended status: Informational                                  D. Wing
                                                          Cisco Systems
Expires: August 22, 2008                              February 22, 2008


                      The SIP Identity Baiting Attack
                    draft-kaplan-sip-baiting-attack-02


Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress".

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html

   This Internet-Draft will expire on August 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).













Kaplan, Wing           Expires August 22, 2008               [Page 1]


                   The SIP Identity Baiting Attack      February 2008


Abstract

   This document identifies a potential SPIT and Phishing attack, which
   subverts the RFC 4474 SIP Identity and RFC 4916 Connected Identity
   mechanisms in a particular way.  The attack is termed "Baiting", as
   it uses a RFC4474-signed call as the bait for malicious use.


Table of Contents

   1.    Introduction................................................2
      1.1.   Background.............................................3
   2.    Terminology.................................................3
   3.    Applicability...............................................4
   4.    Overview of the Attack......................................4
   5.    Harvesting Signed Invites...................................5
   6.    RFC-4474 Cut-Paste Protection...............................6
   7.    Baiting with Offer-less Invites.............................7
   8.    Baiting with ICE............................................7
   9.    Baiting with SRTP...........................................7
   10.   Baiting with non-INVITE Requests............................7
   11.   Attack Success Conditions...................................8
   12.   Possible Solutions?.........................................8
      12.1.  SIP Identity and SIP Connected Identity................8
      12.2.  Secured Media with a Secret............................9
   13.   Security Considerations.....................................9
   14.   IANA Considerations.........................................9
   15.   References..................................................9
      15.1.  Informative References.................................9
   Authors' Addresses...............................................10
   Intellectual Property Statement..................................12
   Full Copyright Statement.........................................12
   Acknowledgment...................................................12


1. Introduction

   SIP Identity, defined in [RFC4474], defines a mechanism for
   originating domains to sign SIP requests with a certificate, in
   order to prove the legitimacy of the From identity and the request's
   body content.  The motivation of the work derived from the need to
   provide a form of cryptographically strong end-to-end (or end-domain
   to end-domain) identity, in order to avoid malicious use of identity
   fraud.

   While not specifically called out, many people consider the
   [RFC4474] mechanism as useful for preventing SPIT and Phishing
   attacks, because strong identity is a basis for many anti-SPIT



Kaplan                  Expires - August 2008                [Page 2]


                   The SIP Identity Baiting Attack      February 2008


   techniques [SIP-SPAM].  This draft describes a form of attack which
   shows that is not the case.

   Furthermore, [RFC4916] defines a way to use the same Identity
   mechanism to perform called party identification, by issuing a re-
   INVITE or UPDATE request from the called party to the caller.  This
   draft describes a way to mis-use that mechanism to aid in the
   attack.

   It should be noted that neither [RFC4474] nor [RFC4916] claim to
   prevent this form of attack, nor in fact is Baiting an attack on the
   mechanisms themselves.  It uses the mechanisms for malicious use,
   and shows that the mechanisms should not be assumed to provide
   benefits they do not.  Lastly, one of the motivations in writing
   this draft was to show that one does not need to truly be a man-in-
   the-middle in order to perform a cut-paste form of attack such as
   Baiting.

1.1. Background

   SIP [RFC3261] has a transitive trust model, whereby SIP requests get
   routed through various intermediaries.  In this model, the
   initiating User Agents (UAs) must generally rely on the
   intermediaries to be secure.  Such a trust model has many security
   issues, one of which is identity proof.  As in email, if the
   identity of the sender of a message cannot be secured, various forms
   of impersonation attacks are possible.

   Two very common issues in email today are SPAM and Phishing attacks,
   which both benefit from impersonation.  For SIP-based applications,
   SPIT (SPAM for Internet Telephony) is not yet a serious problem, due
   mostly to the early stage of SIP deployment, a closed service model,
   and fees for use.  As it grows in popularity and decreases in cost,
   however, its potential for attracting SPIT will grow.

   [RFC4474] follows a similar general model as [DKIM] for source-based
   identity authentication, but the resulting symptoms caused by some
   of DKIM's weaknesses has greater importance for SIP as a real-time
   session-setup protocol than Email does.  SPAM, for example, would be
   far less tolerated for phone calls than they would for email, even
   if the called party ignored the call but the phone rang.

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.  The
   terminology in this document conforms to RFC 2828, "Internet
   Security Glossary".


Kaplan                  Expires - August 2008                [Page 3]


                   The SIP Identity Baiting Attack      February 2008




3. Applicability

   This draft applies to the [RFC4474] SIP Identity and [RFC4916]
   Connected Identity mechanisms.


4. Overview of the Attack

   The general form of the attack is as follows:

      1. An attacker, Bob, is registered at a typical [RFC3261]
          compliant domain: example.net.  Bob wishes to attack
          alice@example.com.
      2. Bob "harvests" an [RFC4474] signed request from a legitimate
          party, such as Bank.  This can be done through various means,
          such as filling out a web form for the Bank to call him,
          leaving a voicemail, or whatever - or possibly using the
          [RFC4916] connected-identity mechanism, as described later in
          this document.
      3. Bank sends a [RFC4474] signed Invite with SDP to Bob.
      4. Bob terminates the call attempt from Bank with a failure
          response.
      5. Bob takes the received SIP Invite request from Bank, inserts
          a Via and Record-Route header of his UA's address, and
          changes the request-URI with a new target of
          sip:alice@example.com, the ultimate victim of the attack.
          Bob may also change the From tag, delete the received Via's,
          and/or possibly insert a History-Info header.
      6. Bob sends the Invite through his domain example.net, or
          directly to example.com, or through another domain.
      7. The signed request is routed based on the request-URI,
          eventually leading to Alice's Identity verifier.
      8. Alice's domain receives the request, and verifies the
          [RFC4474] identity signature.  In the previous steps, Bob has
          not changed anything which was signed by [RFC4474], so the
          validation succeeds.  Note that the To URI will most likely
          be sip:bob@example.net, but per [RFC3261] Alice's domain does
          not verify that the To domain is the same as Alice's domain -
          nor could it, because the request may have simply been
          forwarded through re-targeting, which is legitimate.
      9. Alice's phone rings, with Bank appearing as the source
          caller.  At this point, Bob has already succeeded in annoying
          Alice, because her phone rang, and she thought it was Bank.
      10. Alice picks up the phone, which sends a 200 ok response to
          Bob.
      11. Bob receives the SDP answer in the 200 ok, which tells him
          where to send media to Alice.  Bob sends an ACK to Alice.


Kaplan                  Expires - August 2008                [Page 4]


                   The SIP Identity Baiting Attack      February 2008


      12. Bob then sends his SPIT audio RTP to Alice, possibly spoofing
          the IP Address and port in the SDP offer sent by Bank.  Bank
          will not be sending RTP itself, because it does not get the
          200 ok, and (in step 4) Bob terminated the call from Bank.
      13. At this point Bob is successfully SPAM-ing Alice.  Alice may
          send media to Bank, but since Bob terminated the call from
          Bank (in step 4), Bank discards/ignores the media from Alice.
      14. Alternatively, Bob may attempt Phishing by inserting a Call-
          Info header with a HTTP URL or even a DATA URL, and the audio
          may tell Alice to click on the link or view the DATA URL
          content.  Alice receives a cryptographic assertion that the
          call is from Bank, and thus the phishing attack has a higher
          chance of success.

   Note that this form of the attack creates one-way media, from Bob to
   Alice, which Alice believes is from Bank.  Bob can use the one-way
   media to announce an advertisement, such as:

      "Your Bank urges you to vote for <candidate> during the upcoming
       election.  Thank you and have a nice day."

   Or Bob might use the one-way audio for phishing, such as:

      "This is a recording from your Bank.  Your account has been
      compromised.  Please call us, at <attacker's phone number>, to
      restore service to your bank account.  Thank you and have a
      nice day."

   When Alice calls the attacker's phone number, the attacker will now
   have bi-directional audio with the victim.

5. Harvesting Signed Invites

   There are several ways in which an attacker, Bob, can try to harvest
   multiple [RFC4474] signed Invite requests for malicious use:

     1. Bob can have Bank call him, by submitting web contact forms,
        leaving voicemail, etc.
     2. If Bank calls Bob, Bob can issue 3xx redirect responses to
        redirect the call request to another alias account, or even to
        himself again.  This may even yield new Call-Id's for each
        redirected request, and minimally new CSeq values - each of
        these will have a valid [RFC4474] signature.
     3. If Bank calls Bob, and Bank supports [RFC4028] Session Timers,
        Bob can respond with a low Session-Expires header duration
        (e.g., 90 seconds), with a refresher=uac parameter, and an
        Allow header which does not include UPDATE as an allowed
        Method, in an attempt to get Bank to issue signed re-INVITEs
        continuously and often.


Kaplan                  Expires - August 2008                [Page 5]


                   The SIP Identity Baiting Attack      February 2008


     4. Bob can make a SIP call to Bank, such as Bank's 800-number IVR
        system, expecting Bank to support [RFC4916] Connected Identity.
        Bob can send an Allow header which does not include UPDATE as
        an allowed Method, in an attempt to get Bank to issue a re-
        INVITE to prove its identity.
     5. For calls initiated by Bob, Bob could include the [RFC4028]
        'timer' Supported option tag and Session-Expires header of
        short duration (e.g., 90 seconds), with a refresher=uas
        parameter, in order to get Bank to issue re-INVITE's
        continuously and often.
     6. Bob could try to passively monitor legitimate, unencrypted, SIP
        traffic.
     7. Bob could try to become a "Man-in-the-Middle", for example by
        compromising a legitimate Proxy.

   Note that any signed INVITE, whether within a dialog or not, is
   potentially useful for performing a Baiting attack.  [RFC4474] does
   not sign the To-tag, and thus it can simply be removed for re-use as
   a "new" INVITE.  Stateful verifiers may or may not detect such re-
   use.  And Bob can simply send them to different target domains, to
   avoid hitting the same verifier.

   Even if Bob sends multiple such INVITEs, with the same Call-Id, to
   the same target domain, [RFC4474] is not explicit about how a
   Verifier should behave.  Each harvested request would have a unique
   CSeq value, and thus unique signature, and not be detected as a
   strict replay attack per [RFC4474].  It is not clear how it really
   could be detected as a replay, either, given the need to support
   legitimate signed re-INVITEs within a dialog, and dialog matching
   based on Call-Id and tags (not Call-Id alone).


6. RFC-4474 Cut-Paste Protection

   It is important to note that [RFC4474] signs the Call-Id in an
   attempt to prevent such cut-paste attacks.  The assumption is that
   the verifying domain keeps track of the call-id's for the duration
   of the Date interval (typically 1 hour), and does not allow a
   duplicate request using the same Call-Id.  This Baiting attack sends
   the request to a domain other than the one in the To-URI, and thus
   one harvested [RFC4474]-signed INVITE can be sent to numerous target
   domains.

   Interestingly, Bob can use one of the listed harvesting techniques
   within a dialog or through 3xx redirects, to get additional signed
   requests to use against different users of the *same* target domain.
   Thus Bob could attack multiple users in the same target domain from
   one [RFC4474] call from or to Bank.  Furthermore, if verification is
   performed by the end UA's and not by a centralized verifier system


Kaplan                  Expires - August 2008                [Page 6]


                   The SIP Identity Baiting Attack      February 2008


   for the end-domain, this attack would succeed against *all* users of
   that domain from one harvested INVITE (because the end UAs would not
   be able to protect each other from cut-and-pasted Call-IDs).

7. Baiting with Offer-less Invites

   If Bank were to generate an Invite without SDP, the attack is still
   possible, but even more severe because the attacker (Bob) can end up
   with a bi-directional media call.  Bob would be able to send media
   on Alice's SDP offer in her response, and Bob could create his own
   ACK with his SDP answer.  If Alice expects an identity-signed ACK,
   Bob could even answer Bank's call and use Bank's signed ACK in the
   same way as the Invite.  Note that [RFC4474] provides no mechanism
   to determine when ACKs need to be signed, and since an ACK cannot be
   responded to, Alice cannot really reject it either - it would be
   silently ignored.

8. Baiting with ICE

   The NAT traversal mechanism defined in [ICE] would seem to aid the
   attacker.  The password and username fragment are signed by
   [RFC4474], but they will be clearly viewable to the attacker, and
   thus the attacker should be able to generate STUN connectivity
   checks using them, impersonating the legitimate caller.  We believe
   this would mean ICE would actually enable the attacker to achieve
   bi-directional media, for the malicious call.  [This is TBD, pending
   review by an ICE expert (a glaciologist?)]

9. Baiting with SRTP

   The Baiting attack is just as successful with the [RFC4568]
   security-descriptions key exchange mechanism, because the keys are
   in cleartext for the attacker.  The attacker can thus generate the
   SRTP packets to the victim.  For [DTLS-SRTP], coupled with [DTLS-
   SRTP-FRAMEWORK], the fingerprint being signed prevents a Baiting
   attack from succeeding, because the attacker cannot successfully
   modify the fingerprint in the [RFC4474]-signed SDP.

10.  Baiting with non-INVITE Requests

   It should be clear that the main focus of the Baiting attack
   outlined in this draft is the INVITE request, however one can apply
   Baiting to other requests.  All SIP requests outside of a dialog are
   routed based on the request-URI or Route headers, and thus any
   harvested request can be cut-paste to a new target.  However it is
   harder to harvest such requests in general, and to do so in such a
   way that it provides any real gain to cut-paste them, other than for
   annoyance purposes.



Kaplan                  Expires - August 2008                [Page 7]


                   The SIP Identity Baiting Attack      February 2008



11.  Attack Success Conditions

   What makes the attack successful are the following issues with the
   [RFC4474] mechanism:

          1) Requests in SIP are routed based on the Request-URI and/or
             Route headers, not the To-URI.  The To-URI is signed, but
             it doesn't prevent the request being sent elsewhere and
             accepted by parties other than that indicated in the To-
             URI.  Email-based [DKIM] has a similar issue, but at least
             with email the To information is displayed, whereas it
             rarely is with SIP.
          2) Unlike Email, where all of the sensitive content is
             contained in the body of the request, SIP is used as a
             rendezvous and session setup protocol for the sensitive
             content: the media.  That is why [RFC4474] signs the SDP:
             in order to provide some protection for the ultimate
             content.  But as this attack shows, it cannot truly do so
             alone.
          3) [RFC4474] does not sign the Call-Info header.
          4) [RFC4474] does not sign the tags of the request.  While it
             provides no clear use to do so for initial requests (which
             have no To-tag), it would protect requests within a
             dialog.  [RFC4916] simply re-uses the [RFC4474] mechanism,
             and thus would benefit from this as well.


12.  Possible Solutions?

12.1.     SIP Identity and SIP Connected Identity

   The purpose of this draft is to outline a security issue with
   [RFC4474] and [RFC4916], not to fix it.  However, we outline a few
   possible corrections to [RFC4474] to address parts of the attack:

     1. Sign the Call-Info header.  It is "sensitive" in a similar way
        as SDP or bodies.
     2. Include the tags, or at least the To-tag, in the signed headers
        list.  This would prevent harvested in-dialog requests from
        being re-used outside the dialog.
     3. Clearly specify how Verifiers should act with respect to two
        signed requests of the same Call-Id+CSeq but different tags,
        vs. same Call-Id but different tags+CSeq should behave.
     4. Possibly specify that UPDATE requests without bodies are not
        signed?  Seems like a massive overhead for session-timers to
        sign such requests.




Kaplan                  Expires - August 2008                [Page 8]


                   The SIP Identity Baiting Attack      February 2008


   To address the general issue of request routing having nothing to do
   with the signed To-URI, one possible solution is to have the UAS or
   Verifier have a list of AoR's/To-URI's they are willing to accept
   requests for.  In other words, if Alice's UAS or Verifier knew that
   only requests with a To-URI of "sip:alice@example.com", and whatever
   other aliases and lists/groups she is a member of, were allowed,
   then the UAS or verifier could simply reject baited requests.  [in
   fact, such a thing is probably generally useful regardless of
   Identity signatures]  This "access list" could be provisioned by
   Alice into her UAS, or her UAS could publish such information into
   the Verifier, or her UAS or Verifier could learn it from her
   Registrar through a subscribe package or config-framework, etc.

   Such an access list mechanism would only work for native SIP users,
   however.  One could not, for example, be able to create an access
   list for a SIP-PSTN gateway, since such gateways handle calls to any
   PSTN destination user.  This may or may not be a good property to
   have for Identity verification, but it severely limits the
   usefulness of [RFC4474].


12.2.     Secured Media with a Secret

   For SIP methods involving media, such as an INVITE, the use of
   secure media with proof of possession of a secret (such as a private
   key) can prevent the Baiting attack.  Examples of this include
   comedia-tls [RFC4572], [IDENTITY-MEDIA], and [E2E-SEC-MEDIA].

13.  Security Considerations

   The purpose of this draft is to identify a security issue.


14.  IANA Considerations

   None; this document is informational.

15.  References

15.1.     Informative References

   [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., "Session Timers in the Session Initiation
   Protocol (SIP)", RFC 4028, April 2005.




Kaplan                  Expires - August 2008                [Page 9]


                   The SIP Identity Baiting Attack      February 2008


   [RFC4474] Peterson, J., Jennings, C., "Enhancements for
   Authenticated Identity Management in the Session Initiation Protocol
   (SIP)", RFC 4474, August 2006.

   [RFC4568]  Andreasen, F., Baugher, M., Wing, D., "Session
   Description Protocol (SDP) Security Descriptions for Media Streams",
   RFC 4568, July 2006.

   [RFC4572] Lennox, J., "Connection-Oriented Media Transport over the
   Transport Layer Security (TLS) Protocol in the Session Description
   Protocol (SDP)", RFC4572, July 2006.

   [DKIM] Allman, E., et al, "DomainKeys Identified Mail (DKIM)
   Signatures", RFC 4871, May 2007.

   [RFC4916] Elwell, J., "Connected Identity in the Session Initiation
   Protocol (SIP)", RFC 4916, June 2007.

   [SIP-SPAM] Rosenberg, J., Jennings, C., "The Session Initiation
   Protocol (SIP) and Spam", RFC 5039, January 2008.

   [DTLS-SRTP] McGrew, D., Rescorla, E., "Datagram Transport Layer
   Security (DTLS) Extension to Establish Keys for Secure Real-time
   Transport Protocol (SRTP)", draft-ietf-avt-dtls-srtp-01.txt,
   November 2007.

   [DTLS-SRTP-FRAMEWORK] Fischl, J., Tschofenig, H., Rescorla, E.,
   "Framework for Establishing an SRTP Security Context using DTLS"
   draft-ietf-sip-dtls-srtp-framework-00.txt, November 2007.

   [E2E-SEC-MEDIA] Fischer, K., "End-to-End Security for DTLS-SRTP",
   draft-fischer-sip-e2e-sec-media-00.txt, January 2008.

   [ICE] Rosenberg, J., "Interactive Connectivity Establishment (ICE):
   A Protocol for Network Address Translator (NAT) Traversal for
   Offer/Answer Protocols", draft-ietf-mmusic-ice-19.txt, October 2007.

   [IDENTITY-MEDIA] Wing, D., Kaplan, H., "SIP Identity using Media
   Path", draft-wing-sip-identity-media-01, November 2007.


Authors' Addresses

   Hadriel Kaplan
   Acme Packet
   71 Third Ave.
   Burlington, MA 01803, USA
   Email: hkaplan@acmepacket.com



Kaplan                  Expires - August 2008               [Page 10]


                   The SIP Identity Baiting Attack      February 2008



   Dan Wing
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134
   Email: dwing@cisco.com













































Kaplan                  Expires - August 2008               [Page 11]


                   The SIP Identity Baiting Attack      February 2008


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed
   to pertain to the implementation or use of the technology described
   in this document or the extent to which any license under such
   rights might or might not be available; nor does it represent that
   it has made any independent effort to identify any such rights.
   Information on the procedures with respect to rights in RFC
   documents can be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use
   of such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository
   at http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Kaplan                  Expires - August 2008               [Page 12]