SIPPING G. Dawirs
Internet-Draft University of Namur
Intended status: Informational T. Froment
Expires: August 30, 2007 Alcatel
H. Tschofenig
Siemens
February 26, 2007
Authorization Policies for Preventing SPIT
draft-froment-sipping-spit-authz-policies-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 30, 2007.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Dawirs, et al. Expires August 30, 2007 [Page 1]
Internet-Draft SPIT Policies February 2007
Abstract
SPAM, defined as sending unsolicited messages to someone in bulk,
might be a problem on SIP open-wide deployed networks. The
responsibility for filtering or blocking calls can belong to
different elements in the call flow and may depend on various
factors. This document discusses mechanisms to establish policies to
react on potentially unwanted communication attempts.
These policies match a particular Session Initiation Protocol (SIP)
communication pattern based on a number of attributes. The range of
attributes includes information provided, for example, by the SIP
itself, by the SIP identity mechanism, by information carried within
SAML assertions (as introduced with SIP-SAML) and by the SPIT-SAML
extensions.
This document raises the question whether it is worth to investigate
the aspect of authorization policy usage for SPIT prevention. If so,
then the choice of a policy language for describing authorization
policies and the details of the authorization policies becomes
important. Mechanisms to create, modify and delete authorization
policies that are stored in XML documents are already available with
XCAP or WEBDAV and they could be reused.
Dawirs, et al. Expires August 30, 2007 [Page 2]
Internet-Draft SPIT Policies February 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Discussion and Open Issues . . . . . . . . . . . . . . . . . . 10
5.1. Extending Geopriv Authorization Policies . . . . . . . . . 10
5.2. Hierarchical Authorization Policy Documents . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
9.2. References . . . . . . . . . . . . . . . . . . . . . . . . 14
Appendix A. Sophisticated SPIT Filtering Scenario . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
Intellectual Property and Copyright Statements . . . . . . . . . . 18
Dawirs, et al. Expires August 30, 2007 [Page 3]
Internet-Draft SPIT Policies February 2007
1. Introduction
The problem of SPAM for VoIP seems to become a very big challenge and
only "the combination of several techniques can provide a framework
for dealing with spam in SIP" (as stated in
[I-D.jennings-sip-hashcash]).
One important building block is to provide a mechanism to instruct
some entities in the network to "filter" incoming requests according
to user or to network-wide policies. Different entities, such as
users or system administrators, might create and modify authorization
policies and might even share these policies between domains.
Some attributes in a SIP communication play a more important role
than others. For example, applying authorization policies based on
the authenticated identity is probably an effective way to accept a
communication attempt in order to compat SPIT. The same is true for
policies that are applied to deployment friendlier SIP security
solutions, such as the SIP identity mechanism
[I-D.ietf-sip-identity].
Dawirs, et al. Expires August 30, 2007 [Page 4]
Internet-Draft SPIT Policies February 2007
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].
Dawirs, et al. Expires August 30, 2007 [Page 5]
Internet-Draft SPIT Policies February 2007
3. Framework
The framework of the discussed anti-SPIT authorization policies can
be shown as follows:
Policies Policies
|| ||
|| ||
|| ||
|| ||
VV VV
+-----------+ +-----------+
|SIP | SIP |SIP |
+---------->|Proxy |<---------->|Proxy |<----------+
| |Server X | |Server Y | |
| +-----------+ +-----------+ |
SIP| domain: example.com domain: otherdomain.com |SIP
| |
| |
| |
| |
v v
+-----------+ SIP +-----------+
|SIP | <-----------------------------------------> |SIP |
|User Agent | RTP |User Agent |
|Alice | <=========================================> |Bob |
+-----------+ +-----------+
^^ ^^
|| ||
|| ||
|| ||
|| ||
Policies Policies
Figure 1: Framework and Scenario
Authorization policies can be applied at the end host and/or by
intermediaries. The rule maker might be an end user that owns the
device, a VoIP service provider, a person with a relationship to the
end user (e.g., the parents of a child using a mobile phone). When
the creation, modification and deletion of authorization policies is
not only a local matter then a standardized policy language is
needed.
The subsequent text lists a few use cases.
The first use case that can be imagined is the case of a user that
Dawirs, et al. Expires August 30, 2007 [Page 6]
Internet-Draft SPIT Policies February 2007
asks its outbound proxy to offer protection of requests from a
particular SIP UA. He can create an authorization policy rule and
upload it to the SIP proxy within its own domain. Requests coming
from this SIP URI will then be blocked or treated differently.
Assuming "B@otherdomain.com" has added an authorization rule blocking
request coming from domain example.com. Here is a potential message
sequence:
A@example.com Proxy Proxy B@otherdomain.com
@example.com @otherdomain.com
| | | |
| | | Reject |
| | | @example.com |
| | |<---------------|
| | | OK |
| | |--------------->|
| | | |
| INVITE | | |
| B@otherdomain.com | |
|---------------->| | |
| | INVITE | |
| | B@otherdomain.com |
| |-------------->| |
| | 403 Forbidden | |
| |<--------------| |
| 403 Forbidden | | |
|<----------------| | |
Filtering at the Receiver's Network
If a solution has to be provided to enable SPIT filtering then the
following two sub-problems have to be solved:
o An authorization policy language that allows to expression the
conditions and actions. An example is
[I-D.ietf-simple-presence-rules].
o A mechanism to create, delete, update, retrieve and upload XML
based authorization policy rules. XCAP [I-D.ietf-simple-xcap] is
a reasonable solution. Another one is WEBDAV
[I-D.ietf-webdav-rfc2518bis].
Dawirs, et al. Expires August 30, 2007 [Page 7]
Internet-Draft SPIT Policies February 2007
4. Requirements
The design of anti-SPIT authorization policies is guided by the
following requirements.
1. The policies SHOULD allow filtering incoming requests depending
on several criteria's:
* Value of any SIP header attribute (e.g., From, To, Contact)
* Presence (or lack) of any SIP header attribute (e.g., From,
To, Contact)
* Method invoked by the caller (e.g., INVITE, MESSAGE)
* Value of parameters specified in
[I-D.schwartz-sipping-spit-saml]
+ IdentityStrength
+ CostOfCall
+ AuthenticationMethod
+ IdentityAssertion
+ ConnectionSecurity
+ SPITSuspected
+ CallCenter
+ AssertionStrength
* Request URI of a request
* Presence of a given expression in the body (subject for
further investigation)
2. The policies SHOULD support wildcards (e.g., entire domains)
3. The policies SHOULD support logical operations (and, or, not)
between individual elements in conditions
4. The policies SHOULD refer to all authenticated and
unauthenticated identities.
Dawirs, et al. Expires August 30, 2007 [Page 8]
Internet-Draft SPIT Policies February 2007
5. The policies SHOULD allow a number of actions to be specified,
such as:
* "block": stop forwarding the request and answer with a ``403
Forbidden''
* "polite-block": drop the request without answering anything
* "mark": forward the request, putting a flag ``SPAM''
* "allow": forward this message without conditions (this
mechanism is described further)
* and trigger other mechanism, such as:
+ "puzzle": trigger the "Computational Puzzles"
[I-D.jennings-sip-hashcash] mechanism.
+ "consent": trigger the "Consent Framework"
[I-D.rosenberg-sipping-consent-framework] mechanism
6. The policies SHOULD allow a default action to be specified.
7. It SHOULD be possible to allow a hierarchy of authorization
policies to be used.
Dawirs, et al. Expires August 30, 2007 [Page 9]
Internet-Draft SPIT Policies February 2007
5. Discussion and Open Issues
5.1. Extending Geopriv Authorization Policies
The work done in the Geopriv working group on authorization policies
seem to be a promising candate for these authorization policies.
To fulfill requirements (1) to (6), it is necessary to decide if
[I-D.ietf-geopriv-common-policy] and [I-D.ietf-simple-presence-rules]
can be extended.
The following open issues have been identified:
o The authorization policies defined by the Geopriv working group
focus on a whitelist approach. This document also raises the
question to what extend backlisting capability can be supported or
is necessary to support.
o The Geopriv Common Policy mechanism does not allow generic "deny"
actions to be defined. This aspect refers to requirements (4)
("all") where (although "all except one" is supported by Common
Policy).
o Requirement 2 (wildcards) is provided by Common Policy in a
limited fashion by referring to the domain part of an identity.
Regular expressions are not supported to keep the policy language
simple.
5.2. Hierarchical Authorization Policy Documents
Requirement (7) might require a conflict resolution mechanism to be
specified. Geopriv Common Policy currently defines a very simple but
powerful conflict resolution mechanism but it is for further
investigation whether it is applicable to this problem domain. Other
policy languages define a more sophisticated set of conflict
resolution mechanisms with preceedence and weights for policies.
Although this might be an obviously solution for usage in the context
of hierarchical authorization policies it causes problems in other
places (such as preserving the order of rules).
Dawirs, et al. Expires August 30, 2007 [Page 10]
Internet-Draft SPIT Policies February 2007
6. IANA Considerations
This document does not require actions by IANA.
Dawirs, et al. Expires August 30, 2007 [Page 11]
Internet-Draft SPIT Policies February 2007
7. Security Considerations
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.
Furthermore, SPIT prevention techniques often cross the border of
what is legally acceptable in certain countries (e.g., filtering SPIT
without the consent of the user). Hence, it is extremely important
to consider privacy laws in this work.
Dawirs, et al. Expires August 30, 2007 [Page 12]
Internet-Draft SPIT Policies February 2007
8. Acknowledgements
Acknowledgements to Yann Lopez for valuable input regarding the usage
of Common Policy in the problem domain of SPIT prevention.
Dawirs, et al. Expires August 30, 2007 [Page 13]
Internet-Draft SPIT Policies February 2007
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
9.2. References
[I-D.ietf-geopriv-common-policy]
Schulzrinne, H., "Common Policy: A Document Format for
Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-11 (work in progress),
August 2006.
[I-D.ietf-simple-presence-rules]
Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-08 (work in progress),
October 2006.
[I-D.ietf-simple-xcap]
Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-12 (work in progress),
October 2006.
[I-D.ietf-sip-identity]
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-06
(work in progress), October 2005.
[I-D.ietf-webdav-rfc2518bis]
Dusseault, L., "HTTP Extensions for Distributed Authoring
- WebDAV", draft-ietf-webdav-rfc2518bis-18 (work in
progress), February 2007.
[I-D.jennings-sip-hashcash]
Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", draft-jennings-sip-hashcash-04 (work in progress),
March 2006.
[I-D.rosenberg-sipping-consent-framework]
Rosenberg, J. and J. Rosenberg, "A Framework for Consent-
Based Communications in the Session Initiation Protocol
(SIP)", draft-rosenberg-sipping-consent-framework-00 (work
in progress), July 2004.
Dawirs, et al. Expires August 30, 2007 [Page 14]
Internet-Draft SPIT Policies February 2007
[I-D.schwartz-sipping-spit-saml]
Schwartz, D., "SPAM for Internet Telephony (SPIT)
Prevention using the Security Assertion Markup Language
(SAML)", draft-schwartz-sipping-spit-saml-01 (work in
progress), June 2006.
Dawirs, et al. Expires August 30, 2007 [Page 15]
Internet-Draft SPIT Policies February 2007
Appendix A. Sophisticated SPIT Filtering Scenario
In a more sophisticated scenario one might even consider the idea of
stopping SPIT as early as possible. Domains may agree to exchange
authorization policies in order to stop SPIT earlier (i.e., closer to
the source of the problem). The subsequent text describes this
scenario.
A@example.com Proxy Proxy B@otherdomain.com
@example.com @otherdomain.com
| | | |
| INVITE | | |
| B@otherdomain.com | |
|---------------->| | |
| 403 Forbidden | | |
|<----------------| | |
Filtering at the Sender's Network
This call flow illustrates the bandwidth-saving interest of this use
case.
Though, two scenarios could happen:
o In the good case, the sender's domain is honest and exchanges
authorization policies in order to apply rules that avoids
forwarding unsollicited requests.
o In the worst case, the sender's domain is not cooperative. It
will refuse to upload such documents. In this case, the presence
of rules in the recipient's domain will suffice to keep the
recipient "SPAM free", even if more traffic has been consumed
(since the request has been relayed at least until the first proxy
of the recipient's domain, exactly like in the first use case).
It might be desirable to use a hierarchy of authorization policy
documents that need to be combined when applying them to the SIP
signaling traffic. This raises the question of a merging algorithm,
particularly when authorization policy rules are conflicting or
contain blacklists.
This scenario is subject for further discussion since it might raise
privacy concerns when privacy policies are shared and potentially
applied to other communication partners traffic.
Dawirs, et al. Expires August 30, 2007 [Page 16]
Internet-Draft SPIT Policies February 2007
Authors' Addresses
Geoffrey Dawirs
University of Namur
21, rue Grandgagnage
Namur B-5000
Belgique
Email: gdawirs@gdawirs.be
Thomas Froment
Alcatel
1, rue Ampere - BP 80056
Massy, Paris 91302
France
Email: Thomas.Froment@alcatel-lucent.fr
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
URI: http://www.tschofenig.com
Dawirs, et al. Expires August 30, 2007 [Page 17]
Internet-Draft SPIT Policies February 2007
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.
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).
Dawirs, et al. Expires August 30, 2007 [Page 18]