Network Working Group Pars Mutaf Internet-Draft All play, no work Expires: September 15, 2008 March 14, 2008 IKEv2 extensions for combating SPIT on mobile hosts draft-mutaf-spikev2-00.txt 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/ietf/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 September 15, 2008. Abstract This document describes IKEv2 extensions for combating SPIT on mobile hosts. 1. Introduction "Voice over IP systems, like e-mail and other Internet applications, are susceptible to abuse by malicious parties who initiate unsolicited and unwanted communications called SPIT (SPam over Internet Telephony). Telemarketers, prank callers, and other telephone system abusers are likely to target VoIP systems increasingly, particularly if VoIP tends to supplant conventional Mutaf Expires September 15, 2008 [Page 1] Internet-Draft Spikev2 March 2008 telephony." -- from Wikipedia entry on VoIP spam, March 2008. [RFC5039] provides a detailed analysis of the SPIT risk, reviews the existing approaches for e-mail spam and provides guidelines for combating SPIT. SPIT is likely to be very annoying on cell phones which are carried in one's pocket. They will interrupt the user for useless and annoying short messages and incoming calls. This document describes solutions that are well adapted to cell phones. 2. Solutions This section describes two solutions: weak and strong. The described solutions are extensions to the Internet Key Exchange (IKEv2) protocol [RFC4306]. 2.1. Weak A solution to SPIT is to require an IPsec SA (Security Association) before a correspondent opens a session with a target SIP URI. If later the correspondent turns bad and sends SPIT, the target cell phone can remove the SA. To prevent an attacker from repeatedly establishing SAs with the target host and sending SPIT, the initiator can be requested to solve a hard challenge. IKEv2 supports cookies which can be used to prevent an attacker from spoofing IP addresses. When fighting against SPIT, one has an important advantage: the sender, if legitimate, is necessarily a human. Consequently, Turing tests known as CAPTCHA can be used [CAPTCHA]. The IKEv2 responder can return a CAPTCHA to check if IKEv2 is initiated by a human. Difficult CAPTCHAs can also be used to challenge a malicious human. If the initiator user does not return the correct solution to the CAPTCHA, IKEv2 will not proceed normally and an SA will not be established. Additional defenses include adaptively increasing the difficulty of the CAPTCHA, and temporarily blacklisting the attacker's IP address. If the SPIT has commercial purposes, the attacker is unlikely to continuously send the same advertisement to the same target user. A commercial attacker would rather target a large number of hosts and send the same advertisement to each of them. The above defense can defeat commercial attacks, since the attacker will need to solve a large number challenges coming from each target host. A September 2006 Slashdot article on CAPTCHA reports how "data entry specialists" solve captchas for $0.60 per hour for 50 hours a week SLASHDOT [SLASHDOT]. The popularity of CAPTCHAs does not seem to be affected, Mutaf Expires September 15, 2008 [Page 2] Internet-Draft Spikev2 March 2008 however. Popular web sites, e.g. Google and Yahoo! still employ this defense to protect their resources. 2.2. Strong This approach extends the above defense with strong identities and target user's approval. The target user may want to receive incoming sessions or short messages from known people only. Or, the initiator user may be unknown but the target user may have an idea who (s)he is. A security association may be established with unknown users as well, however in any case the target user requires a certified identity of the initiator. Along with a CAPTCHA (as described above), the target host sends a human name certificate request. The initiator returns the required certificate along with a solution to the CAPTCHA challenge. If the CAPTCHA solution is correct, the target host displays the initiator's human name and asks for permission to create an SA: "Michael Knight wants to connect. Accept? [YES/NO]" If accepted by the target user, IKEv2 will proceed and an IPsec SA can be established with the target cell phone. Regarding the validity of the initiator's certificate, there are two possible approaches: a) If the certificate is invalid, stop IKEv2. Else continue. b) If the certificate is invalid, notify the target user and wait for user decision. If OK, continue. Else stop IKEv2. The advantage of (a) is that attackers cannot make bogus requests disturbing the target user with messages asking for user permission. On the other hand, valid certificates may not be always available. Some users may choose (b) notifying the target user and wait for user decision. In this case, however, an attacker can send continuous bogus requests forcing the target host frequently display the above message, annoying the target user. This attack can be defeated by requesting the initiator user to solve a CAPTCHA before his request can be displayed at the target host's screen. The difficulty of the CAPTCHA can be adaptively tuned by the target host. An important point to note here is that by solving a CAPTCHA, the attacker will not obtain anything. The target user can always reject the connection attempt, if the initiator is unknown, or a known person is being impersonated. This is an important difference from Mutaf Expires September 15, 2008 [Page 3] Internet-Draft Spikev2 March 2008 the weak defense (above) where an attacker can send SPIT by solving a CAPTCHA. 3. IKEv2 extentions In its current form IKEv2 does not support CAPTCHA challenges, nor asking responder user's permission to proceed. TBD. 4. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 5. Security Considerations TBD. 6. Conclusion This document decribed IKEv2 (Internet Key Exchange version 2), extensions for combating SPIT (SPam over Internet Telephony). In the traditional model of operation, an attacker does not need to solve a challenge nor a CAPTCHA to send SPIT to a victim. With the weak defense described in Section 2.1, the attacker needs to solve a CAPTCHA before sending SPIT. For each SPIT to reach the target user, the attacker needs to solve a different CAPTCHA. The CAPTCHA can be made very hard to solve. Unlike the attacker, a legitimate user will be asked to solve a CAPTCHA only once. This defense (although weak) puts the legitimate users in a much more advantageous position than malicious ones. With the strong defense described in Section 2.2, the attacker needs to solve a CAPTCHA, and even after returning the right anwser the attacker is not certain that the SPIT reached the target user. The target user may reject the request because (s)he has no idea the sender is. Moreover, if the attacker's certificate is valid (otherwise SPIT cannot be sent) the attacker's identity will be revealed and black listed by the target phone. Mutaf Expires September 15, 2008 [Page 4] Internet-Draft Spikev2 March 2008 7. Acknowledgements TBD. 8. References [CAPTCHA] Ahn, L., Blum, M., and J. Langford, "Telling Humans and Computers Apart Automatically", In Communications of the ACM, February 2004. [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", RFC 4306, December 2005. [RFC5039] Rozenberg, J. and C. Jennings, "Session Initiation Protocol (SIP) and SPAM", RFC 5039, January 2008. [SLASHDOT] http://it.slashdot.org/article.pl?sid=06/09/06/1217240, "Will Solve Captcha for Money?", September 2006. Author's Address Pars Mutaf All play, no work Email: pars.mutaf@gmail.com Mutaf Expires September 15, 2008 [Page 5] Internet-Draft Spikev2 March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Intellectual Property 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. Mutaf Expires September 15, 2008 [Page 6]