One document matched: draft-froment-sipping-spit-authz-policies-00.txt
Network Working Group G. Dawirs
Internet-Draft University of Namur
Expires: August 24, 2006 T. Froment
Alcatel
H. Tschofenig
Siemens
February 20, 2006
Authorization Policies for Preventing SPIT
draft-froment-sipping-spit-authz-policies-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 August 24, 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 August 24, 2006 [Page 1]
Internet-Draft Anti-SPIT Policies February 2006
react on potentially unwanted communication attempts.
These policies match a particular SIP communication pattern based on
a number of attributes. The range of attributes includes information
provided, for example, by the Session Initiation Protocol, SIP
identity mechanism, SIP-SAML and SPIT-SAML.
An important topic for investigation is to decide whether the problem
is worth analyzing, the choice of a policy language for describing
authorization policies and to provide a mechanisms to create and
modify authorization policies that are stored in XML documents.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 5
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. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property and Copyright Statements . . . . . . . . . . 17
Dawirs, et al. Expires August 24, 2006 [Page 2]
Internet-Draft Anti-SPIT Policies February 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 policies 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 August 24, 2006 [Page 3]
Internet-Draft Anti-SPIT Policies February 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 August 24, 2006 [Page 4]
Internet-Draft Anti-SPIT Policies February 2006
3. Framework
The framework of the discussed anti-SPIT authorization policies looks
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
Authorization policies can be applied at the end host and/or by
intermediaries. The rule maker might be an user that owns the end
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). The
subsequent text lists a few use cases.
The first use case that can be imagined is the case of a user that
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.
Dawirs, et al. Expires August 24, 2006 [Page 5]
Internet-Draft Anti-SPIT Policies February 2006
Supposing "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
| | | |
| 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 possible solution.
In a more sophisticated setting one might even consider the following
idea. Ideally, it would be good to stop unsolicited traffic as early
as possible to avoid consuming bandwidth and processing power.
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
Dawirs, et al. Expires August 24, 2006 [Page 6]
Internet-Draft Anti-SPIT Policies February 2006
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).
These two use cases illustrate the advantages of using a standard
mechanisms in this framework.
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.
Dawirs, et al. Expires August 24, 2006 [Page 7]
Internet-Draft Anti-SPIT Policies February 2006
4. Requirements
The design of anti-SPIT authorization policies is guided by the
following requirements. Note that this is a first strawman proposal
that requires further discussions (since some requirements are
potentially controversal).
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., sip:*@example.com)
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 the following actions to be specified:
Dawirs, et al. Expires August 24, 2006 [Page 8]
Internet-Draft Anti-SPIT Policies February 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 August 24, 2006 [Page 9]
Internet-Draft Anti-SPIT Policies February 2006
5. Discussion and Open Issues
5.1. Extending Geopriv 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 of a backlisting capability that might need to be
supported.
o The Geopriv Common Policy mechanism does not allow "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.
5.2. Hierarchical Authorization Policy Documents
If requirement (7) is valid then a conflict resolution mechanism
needs to be evaluated. Geopriv Common Policy currently defines a
very simple mechanism but it is for further investigation whether it
is actually 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.
Dawirs, et al. Expires August 24, 2006 [Page 10]
Internet-Draft Anti-SPIT Policies February 2006
6. IANA Considerations
This document does not require actions by IANA.
Dawirs, et al. Expires August 24, 2006 [Page 11]
Internet-Draft Anti-SPIT Policies February 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.
Dawirs, et al. Expires August 24, 2006 [Page 12]
Internet-Draft Anti-SPIT Policies February 2006
8. Acknowledgements
Dawirs, et al. Expires August 24, 2006 [Page 13]
Internet-Draft Anti-SPIT Policies February 2006
9. References
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
9.2. Informative References
[I-D.ietf-geopriv-common-policy]
Schulzrinne, H., "A Document Format for Expressing Privacy
Preferences",
Internet-Draft ietf-geopriv-common-policy-07,
February 2006.
[I-D.ietf-simple-presence-rules]
Rosenberg, J., "Presence Authorization Rules", Internet-
Draft ietf-simple-presence-rules-04, October 2005.
[I-D.ietf-simple-xcap]
Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-08 (work in progress),
October 2005.
[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-sipping-spam]
Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", draft-ietf-sipping-spam-01 (work in progress),
July 2005.
[I-D.jennings-sip-hashcash]
Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", draft-jennings-sip-hashcash-03 (work in progress),
October 2005.
[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]
Dawirs, et al. Expires August 24, 2006 [Page 14]
Internet-Draft Anti-SPIT Policies February 2006
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.
[I-D.tschofenig-sip-saml]
Tschofenig, H., "Using SAML for SIP",
draft-tschofenig-sip-saml-04 (work in progress),
July 2005.
Dawirs, et al. Expires August 24, 2006 [Page 15]
Internet-Draft Anti-SPIT Policies February 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 August 24, 2006 [Page 16]
Internet-Draft Anti-SPIT Policies February 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 August 24, 2006 [Page 17]
| PAFTECH AB 2003-2026 | 2026-04-23 04:00:51 |