SIPPING G. Dawirs
Internet-Draft University of Namur
Expires: December 27, 2006 T. Froment
Alcatel
H. Tschofenig
Siemens
June 25, 2006
Authorization Policies for Preventing SPIT
draft-froment-sipping-spit-authz-policies-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 December 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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
Dawirs, et al. Expires December 27, 2006 [Page 1]
Internet-Draft Anti-SPIT Policies June 2006
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 and WEBDAV and can be reused.
Dawirs, et al. Expires December 27, 2006 [Page 2]
Internet-Draft Anti-SPIT Policies June 2006
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 December 27, 2006 [Page 3]
Internet-Draft Anti-SPIT Policies June 2006
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 have a mechanism to offer 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, there is reason to believe that applying
authorization policies based on the authenticated identity is 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 December 27, 2006 [Page 4]
Internet-Draft Anti-SPIT Policies June 2006
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 December 27, 2006 [Page 5]
Internet-Draft Anti-SPIT Policies June 2006
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 December 27, 2006 [Page 6]
Internet-Draft Anti-SPIT Policies June 2006
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.
Supposing "B@otherdomain.com" has added an authorization rule
blocking request coming from domain example.com. Here is a potential
message sequence:
@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 | | |
|<----------------| | |
If a solution has to be provided to enable SPIT filtering then the
following two sub-problems have to be solved:
o A 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 December 27, 2006 [Page 7]
Internet-Draft Anti-SPIT Policies June 2006
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)
* 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.
5. The policies SHOULD allow a number of actions to be specified,
such as:
Dawirs, et al. Expires December 27, 2006 [Page 8]
Internet-Draft Anti-SPIT Policies June 2006
* "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 December 27, 2006 [Page 9]
Internet-Draft Anti-SPIT Policies June 2006
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 December 27, 2006 [Page 10]
Internet-Draft Anti-SPIT Policies June 2006
6. IANA Considerations
This document does not require actions by IANA.
Dawirs, et al. Expires December 27, 2006 [Page 11]
Internet-Draft Anti-SPIT Policies June 2006
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 December 27, 2006 [Page 12]
Internet-Draft Anti-SPIT Policies June 2006
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 December 27, 2006 [Page 13]
Internet-Draft Anti-SPIT Policies June 2006
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: An XML Document Format
for Expressing Privacy Preferences",
draft-ietf-geopriv-common-policy-10 (work in progress),
May 2006.
[I-D.ietf-simple-presence-rules]
Rosenberg, J., "Presence Authorization Rules",
draft-ietf-simple-presence-rules-07 (work in progress),
June 2006.
[I-D.ietf-simple-xcap]
Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-11 (work in progress), May 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-sip-saml]
Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-00 (work in progress), June 2006.
[I-D.ietf-sipping-spam]
Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", draft-ietf-sipping-spam-02 (work in progress),
March 2006.
[I-D.ietf-webdav-rfc2518bis]
Dusseault, L., "HTTP Extensions for Distributed Authoring
- WebDAV", draft-ietf-webdav-rfc2518bis-15 (work in
progress), May 2006.
[I-D.jennings-sip-hashcash]
Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", draft-jennings-sip-hashcash-04 (work in progress),
Dawirs, et al. Expires December 27, 2006 [Page 14]
Internet-Draft Anti-SPIT Policies June 2006
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.
[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-00 (work in
progress), October 2005.
Dawirs, et al. Expires December 27, 2006 [Page 15]
Internet-Draft Anti-SPIT Policies June 2006
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 | | |
|<----------------| | |
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 December 27, 2006 [Page 16]
Internet-Draft Anti-SPIT Policies June 2006
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.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 December 27, 2006 [Page 17]
Internet-Draft Anti-SPIT Policies June 2006
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.
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Dawirs, et al. Expires December 27, 2006 [Page 18]