SIPPING H. Tschofenig, Ed. Internet-Draft Nokia Siemens Networks Intended status: Informational G. Dawirs Expires: August 28, 2008 University of Namur T. Froment Alcatel-Lucent D. Wing Cisco H. Schulzrinne Columbia University February 25, 2008 Requirements for Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony draft-froment-sipping-spit-requirements-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/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 August 28, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Tschofenig, et al. Expires August 28, 2008 [Page 1] Internet-Draft SPIT Authorization Policy Requirements February 2008 Abstract Spam over Internet Telephony (SPIT) is one of the foreseen future forms of spamming that SIP open-wide networks may have to handle. SPIT also has more impact on users than email spam since it is more intrusive. Email as a store-and-forward communication mechanism allows for several filtering mechanisms to be applied to the full content before being presented to the user. Session Initiation Protocol (SIP) interaction is, in contrast, real-time communication and therefore does not provide much information prior to the transmission of the content, making it both harder to filter and more annoying to users. The responsibility for filtering, blocking calls, or taking any other preventive action can belong to different elements in the call flow and may depend on various factors. This document discusses the requirements to define authorization policies that should allow end users or other parties to setup anti-SPIT policies for triggering these actions. These policies typically match a particular SIP communication pattern based on a number of attributes. The range of attributes includes information provided, for example, by the SIP protocol itself, by the SIP identity mechanism, by information carried within SAML assertions, reputation systems of social networks or other extensions. Tschofenig, et al. Expires August 28, 2008 [Page 2] Internet-Draft SPIT Authorization Policy Requirements February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Transformations . . . . . . . . . . . . . . . . . . . . . 8 3.4. Generic Requirements . . . . . . . . . . . . . . . . . . . 8 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . . 12 7.2. References . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 15 Tschofenig, et al. Expires August 28, 2008 [Page 3] Internet-Draft SPIT Authorization Policy Requirements February 2008 1. Introduction The problem of SPIT is an important challenge and it is to expect that a combination of several techniques is desirable to provide a framework to deal with it. The goal of SPIT-policies is not to discuss these techniques, or to propose new ones. It just suggest to provide a way to define these policies using a standardized XML format. One important building block is to provide a mechanism to instruct a trusted SIP proxy or any other SIP element to influence message handling of incoming requests according to policies. Different entities, such as end users, parents on behalf of their kids or system administrators, might create, modify or delete authorization policies. Some attributes in an incoming message play a more important role than others. For example, applying authorization policies based on the authenticated identity, see [RFC4474], is an effective way to make decisions regarding unwanted traffic in many cases. This document identifies requirements for authorization policies when used to influence message handling for unwanted communication attempts. Tschofenig, et al. Expires August 28, 2008 [Page 4] Internet-Draft SPIT Authorization Policy Requirements February 2008 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], with the important qualification that, unless otherwise stated, these terms apply to the design of the authorization policies, not its implementation or application. Tschofenig, et al. Expires August 28, 2008 [Page 5] Internet-Draft SPIT Authorization Policy Requirements February 2008 3. Requirements This section lists the requirements categorized according to their applicability for the "conditions", "actions" and "transformation" parts typically found in authorization policies. 3.1. Conditions The first set of requirements refer to identity related information. Req-C 1: Policies MUST allow conditions to express single authenticated identities. Req-C 2: Policies MUST allow filtering based on the domain part of the identity. Req-C 3: Policies MUST support the differentiation between authenticated and unauthenticated identities. Req-C 4: Policies MUST be able to express exceptions within a group of users or a domain. Req-C 5: Policies SHOULD allow an anonymous identity as a condition. Message handling might be different depending on the content of the SIP message header fields. Req-C 6: Policies SHOULD allow conditions to refer to the "destination" (which corresponds to the "Request-URI") and "original-destination" (which corresponds to the "To" header). Req-C 7: Policies SHOULD allow conditions to refer to the method invoked by the caller (e.g., INVITE, REFER, MESSAGE, SUBSCRIBE). Motivation: Some SIP methods are more intrusive than others (the default applicative behaviour when SIP MESSAGEs are received is often to pop-up the message on the UAS side), adopting a different filtering policy depending of the method invoked will enhance the user's protection. Req-C 8: Policies SHOULD allow the entity that writes the rules to take actions on messages that are marked as Spam. Note that such a condition element should be seen in context of the authenticated domain or, otherwise, of a protected information to avoid security vulnerabilities. Tschofenig, et al. Expires August 28, 2008 [Page 6] Internet-Draft SPIT Authorization Policy Requirements February 2008 Req-C 9: Policies MAY allow to make decisions based on the current state of the user. E.g., based on a user who selected an active profile, or sphere or another presence information. Req-C 10: Policies SHOULD support consitions based on the content type and/or offered (or used) media of a message. Message handling might be different based on time/date. Req-C 11: Policies SHOULD allow conditions that refer to the reception date, time, timezone or period of time of the incoming request. Message handling might be different based on the language. Req-C 12: Policies SHOULD allow to make decisions based on the languages in which the originator of the call wishes to communicate. 3.2. Actions Req-A 1: Policies SHOULD allow messages to get "blocked", i.e., to stop forwarding the request and to return an answer with a "403 Forbidden'' Req-A 2: Policies SHOULD allow messages to get "politely blocked", i.e., to drop the request without returning any answer. Req-A 3: Policies SHOULD allow messages to get "marked", i.e., to forward the request and mark it as "potential Spam" for filtering at the end point or at subsequent entities along the signaling path. Req-A 4: Policies SHOULD allow messages to be "allowed", i.e., to forward this message. Req-A 5: Policies MUST allow messages to be "redirected" to, for example, voicemail or to a different device in the possession of the user. Req-A 6: Policies MUST allow executing other SPIT prevention procedures, such as computational puzzles [I-D.jennings-sip-hashcash] or the consent framework" [I-D.ietf-sip-consent-framework]. A specification developing a SPIT prevention mechanism should provide information on how they can be incorporated into the authorization policy framework. Tschofenig, et al. Expires August 28, 2008 [Page 7] Internet-Draft SPIT Authorization Policy Requirements February 2008 Req-A 7: Policies MAY allow an e-mail (or SMS, MMS) or other notifications to be sent to the user about the actions taken due to a specific call attempt. R8: Policies MAY allow the usage of one or many feedback mechanisms. 3.3. Transformations Req-T 1: Policies SHOULD allow SIP messages to be marked with a certain SPIT probability in case SPIT detection and policy enforcement is excecuted on different entities. For example, a network element might run a statistical SPIT detection tool but the authorization policies are executed on a different entity, such as the end host. Note that it needs to be ensured that an adversary is not able to set the SPIT probabity values since otherwise the authorization policies that rely on such information are misguided. 3.4. Generic Requirements Req-G 1: It SHOULD be possible to allow a hierarchy of authorization policies to be used. It is quite likely that a rules from different rule writing entities are provided. For example, in a company environment policies from the system administrator are provided in addition to the end users policies. The former might reflect the overall company policy. The impact for the policy is mainly on the definition of an appropriate conflict resolution mechanism. Req-G 2: It MUST be possible for a client to learn the supported authorization policy capabilities implemented by the server. Req-G 3: Policies MUST be extensible and these extensions MUST exist within a different namespace. Furthermore, a published schema and the namespace for elements defined within it MUST NOT be altered by future specifications. Req-G 4: The policies MUST provide a mandatory-to-implement conflict resolution mechanism. Tschofenig, et al. Expires August 28, 2008 [Page 8] Internet-Draft SPIT Authorization Policy Requirements February 2008 4. IANA Considerations This document does not require actions by IANA. Tschofenig, et al. Expires August 28, 2008 [Page 9] Internet-Draft SPIT Authorization Policy Requirements February 2008 5. Security Considerations This document describes the requirements for elements contained in the authorization policies that allow communication attempts to be treated differently based on the content of the message, time-of-day, context of the user, reputation of the sending party, and many other factors. The security concerns are related to the ability of certain entities to create, update and delete authorization policies. If an unauthorized entity is allowed to modify policies (and to distribute them to other domains) then a denial of service attack is the consequence with impact for more than a single end point. These security aspects are, however, not subject of this document. Tschofenig, et al. Expires August 28, 2008 [Page 10] Internet-Draft SPIT Authorization Policy Requirements February 2008 6. Acknowledgements The content of this document is inspired by the work of CPL [RFC3880], SIEVE [I-D.ietf-sieve-3028bis], Common Policy [RFC4745] and Presence Authorization Policy [I-D.ietf-simple-presence-rules]. We would like to thank the authors of these documents for their work. Furthermore, we would like to thank Eva Leppanen for the detailed review provided in June 2006. Tschofenig, et al. Expires August 28, 2008 [Page 11] Internet-Draft SPIT Authorization Policy Requirements February 2008 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 7.2. References [I-D.ietf-sieve-3028bis] Showalter, T. and P. Guenther, "Sieve: An Email Filtering Language", draft-ietf-sieve-3028bis-13 (work in progress), October 2007. [I-D.ietf-simple-presence-rules] Rosenberg, J., "Presence Authorization Rules", draft-ietf-simple-presence-rules-10 (work in progress), July 2007. [I-D.ietf-sip-consent-framework] Rosenberg, J., Camarillo, G., and D. Willis, "A Framework for Consent-based Communications in the Session Initiation Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work in progress), January 2008. [I-D.jennings-sip-hashcash] Jennings, C., "Computational Puzzles for SPAM Reduction in SIP", draft-jennings-sip-hashcash-06 (work in progress), July 2007. [RFC3880] Lennox, J., Wu, X., and H. Schulzrinne, "Call Processing Language (CPL): A Language for User Control of Internet Telephony Services", RFC 3880, October 2004. [RFC4474] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Initiation Protocol (SIP)", RFC 4474, August 2006. [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007. Tschofenig, et al. Expires August 28, 2008 [Page 12] Internet-Draft SPIT Authorization Policy Requirements February 2008 Authors' Addresses Hannes Tschofenig (editor) Nokia Siemens Networks Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany Email: Hannes.Tschofenig@nsn.com URI: http://www.tschofenig.com Geoffrey Dawirs University of Namur 21, rue Grandgagnage Namur B-5000 Belgique Email: gdawirs@gdawirs.be Thomas Froment Alcatel-Lucent Route de Villejust Nozay, Paris 91620 France Email: Thomas.Froment@alcatel-lucent.fr Dan Wing Cisco 170 West Tasman Drive San Jose, CA 95134 USA Email: dwing@cisco.com Tschofenig, et al. Expires August 28, 2008 [Page 13] Internet-Draft SPIT Authorization Policy Requirements February 2008 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu Tschofenig, et al. Expires August 28, 2008 [Page 14] Internet-Draft SPIT Authorization Policy Requirements February 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Tschofenig, et al. Expires August 28, 2008 [Page 15]