Network Working Group                                         Pars Mutaf
Internet-Draft                                            March 17, 2008
Expires: September 18, 2008



          IKEv2 extensions for combating SPIT on mobile hosts
                       draft-mutaf-spikev2-01.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 18, 2008.

Abstract

   This document describes IKEv2 extensions for combating SPIT on mobile
   hosts.













Mutaf                  Expires September 18, 2008               [Page 1]


Internet-Draft                   Spikev2                      March 2008


Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.1.  Weak  . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     2.2.  Strong  . . . . . . . . . . . . . . . . . . . . . . . . . . 4
   3.  Off-line protection . . . . . . . . . . . . . . . . . . . . . . 5
   4.  IKEv2 extensions  . . . . . . . . . . . . . . . . . . . . . . . 5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 6
   7.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 6
   9.  Normative References  . . . . . . . . . . . . . . . . . . . . . 6
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8




































Mutaf                  Expires September 18, 2008               [Page 2]


Internet-Draft                   Spikev2                      March 2008


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
   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 spam over IP telephony.

   SPIT is likely to be very annoying on cell phones carried in one's
   pocket during the day.  Each time SPIT arrives the user will be
   notified for a useless, annoying and potentially harmful message or
   call.  This document describes IPsec solutions and IKEv2 extensions
   for combating SPIT on cellular hosts.


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.




Mutaf                  Expires September 18, 2008               [Page 3]


Internet-Draft                   Spikev2                      March 2008


   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].
   The popularity of CAPTCHAs does not seem to be affected, 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 accepted, 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 human name 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



Mutaf                  Expires September 18, 2008               [Page 4]


Internet-Draft                   Spikev2                      March 2008


   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
   the weak defense (above) where an attacker can send SPIT by solving a
   CAPTCHA.


3.  Off-line protection

   In current cellular systems, when the target device is off-line or
   busy, the calling party can leave a voice message in a message box.
   The message is forwarded to its destination when the target phone is
   up and available again.  Similarly, text messages are buffered in the
   system, and delivered later when the target phone is ready.  The
   message box may be filled with spam voice messages and text messages.

   In the Internet, e-mail can be used for voice and text messages.
   When an initiator host successfully established an IPsec SA with a
   target host, the target host can return an e-mail address.  The
   target host should also sign and return a public key certificate of
   the initiator.  This will prove that the initiator is authorized to
   leave messages to the indicated mailbox.  When the target host is
   off-line or busy, the initiator can detect it and send a locally
   recorded voice file to the indicated e-mail address.  When the target
   host is up and available, it will fetch the e-mails found in the
   mailbox, or the e-mails will be pushed to the mobile host.

   The certificate issued by the target host proves authorization to
   send e-mail to the target host's mailbox.  If the initiator turns bad
   and sends SPIT to the target host's mailbox, its certificate should
   be revoked until it expires.  The certificate lifetimes should not be
   too long.  They should be prediodically updated by the target host.
   For example, each time a legitimate communication takes place, the
   target host can issue a new and fresh certificate replacing the old
   one.


4.  IKEv2 extensions

   In its current form IKEv2 does not support CAPTCHA challenges, nor
   asking responder user's permission to proceed.  TBD.




Mutaf                  Expires September 18, 2008               [Page 5]


Internet-Draft                   Spikev2                      March 2008


5.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


6.  Security Considerations

   TBD.


7.  Conclusion

   This document decribed IKEv2 (Internet Key Exchange version 2),
   extensions for combating SPIT (SPam over Internet Telephony).

   The described defense forces an initiator user to solve a CAPTCHA for
   establishing an IPsec Security Association (SA).  Legitimate users
   will solve only one CAPTCHA and continue to profit from the same SA
   during future sessions.  The attacker will need to solve a different
   CAPTCHA for each SPIT that s(he) sends to the target host.  When SPIT
   arrives from a source address, the corresponding SA will be dropped
   upon the target user's command.  This defense (although weak) puts
   the legitimate users in a much more advantageous position than
   malicious ones.

   With the strong defense, 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.


8.  Acknowledgements

   TBD.


9.  Normative References

   [CAPTCHA]  Ahn, L., Blum, M., and J. Langford, "Telling Humans and
              Computers Apart Automatically", In Communications of the
              ACM, February 2004.




Mutaf                  Expires September 18, 2008               [Page 6]


Internet-Draft                   Spikev2                      March 2008


   [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

   Email: pars.mutaf@gmail.com



































Mutaf                  Expires September 18, 2008               [Page 7]


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 18, 2008               [Page 8]