SIP Working Group H. Kaplan Internet Draft Acme Packet Intended status: Informational D. Wing Cisco Systems Expires: August 18, 2008 February 18, 2008 The SIP Identity Baiting Attack draft-kaplan-sip-baiting-attack-01 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 18, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Kaplan, Wing Expires August 1, 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....................................10 14. IANA Considerations........................................10 15. References.................................................10 15.1. Informative References.................................10 Authors' Addresses...............................................11 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 2007 [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 2007 [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 2007 [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 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 , 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 2007 [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 2007 [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 2007 [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 2007 [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, we can only think of one solution: re-target signing. The general idea is, for requests not inside a dialog, to make the Verification require the To-URI domain to either match the domain of the verifier (or one it is acting as a verifier for), or if the To-URI domain does not match then to perform a check based on the following new mechanism: if a request is re-targeted, require each re-targeting domain to insert a History-Info-type header and add an additional, new, Identity-type header set that covers the [RFC4474] Identity header and whose certificate matches the domain in the History-Info header's URI. For example a "History-Identity" header, which can be a multiple instance header. Each time a request gets re-targeted, additional History-Identity headers get added (none get removed). Thus if a verifier gets a request where the To-URI domain does not match its own, it needs to verify the signature of each re-targeting domain matched, which should work in a reverse-chain of certificates-to-domain-names backwards to the same one as that in the To-URI. So for example, the Invite has a To-URI of sip:bob@example.com. It gets routed to example.com, which sees the To-URI is itself, but is retargeting to bob@example.net. So example.com adds a History- Identity header of "sip:bob@example.net" and its signature using example.com's certificate. The Invite gets to example.net, which tries to verify it - it sees a To-URI of example.com (not its domain), so it looks in History-Identity, sees example.net, and verifies example.com signed it. Then suppose example.net re-targets to example.org. So it adds another History-Identity header with "sip:bob@example.org", and signs it with example.net's cert. The Invite gets to example.org, which performs the same type of verification: the To-URI domain does not match itself, so it sees the last History-Identity header, verifies the previous History- Identity domain signed it, and so on. Such a mechanism is not pretty. It is very processing intensive, prone to failure, and does not provide a smooth transition fro non- Identity to Identity support. We are not convinced it is truly viable, but it's just a straw-man idea. The main goal of this draft is to document the issue, not the solution, and indeed a solution may not be possible. 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]. Kaplan Expires - August 2007 [Page 9] The SIP Identity Baiting Attack February 2008 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. [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. Kaplan Expires - August 2007 [Page 10] The SIP Identity Baiting Attack February 2008 [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 Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 Email: dwing@cisco.com Kaplan Expires - August 2007 [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 2007 [Page 12]