SIPPING H. Tschofenig
Internet-Draft Nokia Siemens Networks
Intended status: Standards Track D. Wing
Expires: May 22, 2008 Cisco
H. Schulzrinne
Columbia University
T. Froment
Alcatel-Lucent
G. Dawirs
University of Namur
November 19, 2007
A Document Format for Expressing Authorization Policies to tackle Spam
and Unwanted Communication for Internet Telephony
draft-tschofenig-sipping-spit-policy-02.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 May 22, 2008.
Copyright Notice
Copyright (C) The IETF Trust (2007).
Tschofenig, et al. Expires May 22, 2008 [Page 1]
Internet-Draft Policies for Internet Telephony Spam November 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 defines an authorization based policy
language that allows end users to upload anti-SPIT policies to
intermediaries, such as SIP proxies. These policies mitigate
unwanted SIP communications. It extends the Common Policy
authorization framework with additional conditions and actions. The
new conditions 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 SIP itself,
by the SIP identity mechanism, by information carried within SAML
assertions.
Tschofenig, et al. Expires May 22, 2008 [Page 2]
Internet-Draft Policies for Internet Telephony Spam November 2007
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Generic Processing . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Structure of SPIT Authorization Documents . . . . . . . . 5
3.2. Rule Transport . . . . . . . . . . . . . . . . . . . . . . 5
4. Condition Elements . . . . . . . . . . . . . . . . . . . . . . 6
4.1. Identity . . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. Acceptable Forms of Authentication . . . . . . . . . . 6
4.1.2. Computing a URI for the Sender . . . . . . . . . . . . 7
4.2. Sphere . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.3. SPIT Handling . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Presence Status . . . . . . . . . . . . . . . . . . . . . 9
4.5. Time Period Condition . . . . . . . . . . . . . . . . . . 9
5. Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Execute Action . . . . . . . . . . . . . . . . . . . . . . 11
5.2. Forward To . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Identity and Time-Based Policy . . . . . . . . . . . . . . 12
6.2. Extended Time-Based Policy . . . . . . . . . . . . . . . . 13
6.3. Policy for triggering Captcha and Hashcash Challenges . . 14
7. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8. XCAP USAGE . . . . . . . . . . . . . . . . . . . . . . . . . . 19
8.1. Application Unique ID . . . . . . . . . . . . . . . . . . 19
8.2. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . 19
8.3. Default Namespace . . . . . . . . . . . . . . . . . . . . 20
8.4. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 20
8.5. Validation Constraints . . . . . . . . . . . . . . . . . . 20
8.6. Data Semantics . . . . . . . . . . . . . . . . . . . . . . 20
8.7. Naming Conventions . . . . . . . . . . . . . . . . . . . . 20
8.8. Resource Interdependencies . . . . . . . . . . . . . . . . 20
8.9. Authorization Policies . . . . . . . . . . . . . . . . . . 20
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
9.1. Anti-SPIT Policy XML Schema Registration . . . . . . . . . 21
9.2. Anti-SPIT Policy Namespace Registration . . . . . . . . . 21
9.3. XCAP Application Usage ID . . . . . . . . . . . . . . . . 21
10. Security Considerations . . . . . . . . . . . . . . . . . . . 21
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
13.1. Normative References . . . . . . . . . . . . . . . . . . . 22
13.2. Informative References . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
Intellectual Property and Copyright Statements . . . . . . . . . . 28
Tschofenig, et al. Expires May 22, 2008 [Page 3]
Internet-Draft Policies for Internet Telephony Spam November 2007
1. Introduction
The problem of SPAM for Internet Telephony (SPIT) is an imminent
challenge and only the combination of several techniques can provide
a framework for dealing with unwanted communication, as stated in
[I-D.jennings-sip-hashcash].
One important building block is to have a mechanism that can instruct
SIP intermediaries to react differently on incoming requests based on
policies. Different entities, such as end users, parents on behalf
of their children, system administrators in enterprise networks,
etc., might create and modify authorization policies. The conditions
in these policies can be created from many sources but some
information elements are more important 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 to deal with unsolicited communication.
Authentication based on the SIP identity mechanism, see [RFC4474], is
one important concept.
The requirements for the authorization policies described in this
document are outlined in [I-D.froment-sipping-spit-requirements]. A
framework document is available at
[I-D.tschofenig-sipping-framework-spit-reduction].
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].
This document reuses the terminology from RFC 4745 [RFC4745]:
Rule maker:
The RM is an entity that creates the authorization policies that
react to unwanted connection attempts. 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). A standardized policy language is needed
when the creation, modification and deletion of authorization
policies are not only a local matter.
Tschofenig, et al. Expires May 22, 2008 [Page 4]
Internet-Draft Policies for Internet Telephony Spam November 2007
Authorization policy:
An authorization policy is given by a rule set. A rule set
contains an unordered list of rules. Each rule has a condition,
an action and a transformation component. The terms
'authorization policy', 'policy', 'rule set', 'authorization
policy rule', 'policy rule' and 'rule' are used interchangeably.
Authorization policies can be applied at the end host and/or by
intermediaries.
Permission:
The term permission refers to the action and transformation
components of a rule.
We use the term 'Recipient' for the entity that is target of the
communication attempt of a sender.
3. Generic Processing
3.1. Structure of SPIT Authorization Documents
A SPIT authorization document is an XML document, formatted according
to the schema defined in RFC 4745 [RFC4745]. SPIT authorization
documents inherit the MIME type of common policy documents,
application/auth-policy+xml. As described in [RFC4745], this
document is composed of rules which contain three parts - conditions,
actions, and transformations. Each action or transformation, which
is also called a permission, has the property of being a positive
grant to the authorization server to perform the resulting actions,
be it allow, block etc . As a result, there is a well-defined
mechanism for combining actions and transformations obtained from
several sources. This mechanism therefore can be used to filter
connection attempts thus leading to effective SPIT prevention.
3.2. Rule Transport
Policies are XML documents that are stored at a Proxy Server or a
dedicated device. The Rule Maker therefore needs to use a protocol
to create, modify and delete the authorization policies defined in
this document. Such a protocol is available with the Extensible
Markup Language (XML) Configuration Access Protocol (XCAP) [RFC4825].
Tschofenig, et al. Expires May 22, 2008 [Page 5]
Internet-Draft Policies for Internet Telephony Spam November 2007
4. Condition Elements
This section describes the additional enhancements of the conditions-
part of the rule. This document inherits the Common Policy
functionality, including <identity>, <validity>, and <sphere>
conditions.
Note that, as discussed in [RFC4745], a permission document applies
to a translation if all the expressions in its conditions part
evaluate to TRUE.
4.1. Identity
Although the <identity> element is defined in [RFC4745], that
specification indicates that the specific usages of the framework
document need to define details that are protocol and usage specific.
In particular, it is necessary for a usage of the common policy
framework to:
o Define acceptable means of authentication.
o Define the procedure for representing the identity as a URI or IRI
[RFC3987].
This sub-section defines those details for systems based on
[RFC3856].
4.1.1. Acceptable Forms of Authentication
When used with SIP, a request is considered authenticated if one of
the following techniques is used:
SIP Digest:
The proxy has authenticated the sender using SIP [RFC3261] digest
authentication [RFC2617]. However, if the anonymous
authentication described on page 194 of RFC 3261 [RFC3261] was
used, the sender is not considered authenticated.
Asserted Identity:
If a request contains a P-Asserted-ID header field [RFC3325] and
the request is coming from a trusted element, the sender is
considered authenticated.
Tschofenig, et al. Expires May 22, 2008 [Page 6]
Internet-Draft Policies for Internet Telephony Spam November 2007
Cryptographically Verified Identity:
If a request contains an Identity header field as defined in
[RFC4474], and it validates the From header field of the request,
the request is considered to be authenticated. Note that this is
true even if the request contained a From header field of the form
sip:anonymous@example.com. As long as the signature verifies that
the request legitimately came from this identity, it is considered
authenticated.
An anonymous From header field with RFC 4474 [RFC4474] is considered
authenticated, while anonymous digest is not considered
authenticated, because the former still involves the usage of an
actual username and credential as part of an authentication operation
in the originating domain.
4.1.2. Computing a URI for the Sender
For messages that are authenticated using SIP Digest, the identity of
the sender is set equal to the address of record (AoR) for the user
that has authenticated themselves. The AoR is always a URI, and can
be either a SIP URI or tel URI [RFC3966]. For example, consider the
following "user record" in a database:
SIP AOR: sip:alice@example.com
digest username: ali
digest password: f779ajvvh8a6s6
digest realm: example.com
If the proxy server receives an INVITE, challenges it with the realm
set to "example.com", and the subsequent INVITE contains an
Authorization header field with a username of "ali" and a digest
response generated with the password "f779ajvvh8a6s6", the identity
used in matching operations is "sip:alice@example.com".
For messages that are authenticated using RFC 3325 [RFC3325], the
identity of the sender is equal to the URI in the P-Asserted-ID
header field. If there are multiple values for the P-Asserted-ID
header field (there can be one sip URI and one tel URI [RFC3966]),
then each of them is used for the comparisons outlined in [RFC4745],
and if either of them match a <one> or <except> element, it is
considered a match.
For messages that are authenticated using the SIP Identity mechanism
[RFC4474], identity of the sender is equal to the SIP URI in the From
header field of the request, assuming that the signature in the
Identity header field has been validated.
Tschofenig, et al. Expires May 22, 2008 [Page 7]
Internet-Draft Policies for Internet Telephony Spam November 2007
In SIP systems, it is possible for a user to have aliases - that is,
there are multiple SIP AoRs "assigned" to a single user. In terms of
this specification, there is no relationship between those aliases.
Each would look like a different user. This will be the consequence
for systems where the sender is in a different domain than the
recipient. However, even if the sender and recipient are in the same
domain, and the proxy server knows that there are aliases for the
sender, these aliases are not mapped to each other or used in any
way.
SIP also allows for anonymous identities. If a message is anonymous
because the digest challenge/response used the "anonymous" username,
the message is considered unauthenticated and will match only an
empty <identity> element. If a message is anonymous because it
contains a Privacy header field [RFC3323], but still contains a
P-Asserted-ID header field, the identity in the P-Asserted-ID header
field is still used in the authorization computations; the fact that
the message was anonymous has no impact on the identity processing.
However, if the message had traversed a trust boundary and the
P-Asserted-ID header field and the Privacy header field had been
removed, the message will be considered unauthenticated when it
arrives at the proxy server. Finally, if a message contained an
Identity header field that was validated, and the From header field
contained a URI of the form sip:anonymous@example.com, then the
sender is considered authenticated, and it will have an identity
equal to sip:anonymous@example.com. Had such an identity been placed
into a <one> or <except> element, there will be a match.
It is important to note that SIP frequently uses both SIP URI and tel
URI [RFC3966] as identifiers, and to make matters more confusing, a
SIP URI can contain a phone number in its user part, in the same
format used in a tel URI. The sender's identity that is a SIP URI
with a phone number will not match the <one> and <except> conditions
whose 'id' is a tel URI with the same number. The same is true in
the reverse. If the sender's identity is a tel URI, this will not
match a SIP URI in the <one> or <except> conditions whose user part
is a phone number. URIs of different schemes are never equivalent.
4.2. Sphere
The <sphere> element is defined in [RFC4745]. However, each
application making use of the common policy specification needs to
determine how the policy server computes the value of the sphere to
be used in the evaluation of the condition.
To compute the value of <sphere>, the proxy server interacts with a
presence server who knows whether at least one of the published
presence documents includes the <sphere> element [RFC4480] as part of
Tschofenig, et al. Expires May 22, 2008 [Page 8]
Internet-Draft Policies for Internet Telephony Spam November 2007
the person data component [RFC4479], and all of those containing the
element have the same value for it, that is the value used for the
sphere in policy policy processing. If, however, the <sphere>
element was not available to the presence server (and hence not for
the proxy server), or it was present but had inconsistent values, its
value is considered undefined in terms of policy processing.
4.3. SPIT Handling
The <spit-handling> element is a way to react on the execution of
certain SPIT handling mechanisms. For example, a rule might indicate
that a CAPTCHA has to be sent to the sender and the sender
subsequently has to return the result. Depending on the outcome of
the robot test the rules might enforce different actions. This
element provides such a condition capability.
The <spit-handling> condition evaluates to TRUE if any of its child
elements evaluate to TRUE, i.e., the results of the individual child
element are combined using a logical OR.
The <spit-handling> element MAY contain zero or more <challenge>
elements. The <challenge> elements has an attribute 'result' that
either contains "SUCCESS" or "FAILURE".
4.4. Presence Status
This condition evaluates to TRUE when the called user's current
presence activity status is equal to the value in the <presence-
status> element. Otherwise the condition evaluates to FALSE.
4.5. Time Period Condition
The <time-period> element allows to make decisions based on the time,
date and timezone. It defines an extended version of the <validity>
element.
The <time-period> element may contain the following attributes:
dtstart:
Start of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute
is MANDATORY.
dtend:
End of interval (RFC 2445 [RFC2445] DATE-TIME). This attribute is
MANDATORY.
Tschofenig, et al. Expires May 22, 2008 [Page 9]
Internet-Draft Policies for Internet Telephony Spam November 2007
timestart:
Start of time interval in a particular day. It is of the TIME
data type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445].
This attribute is OPTIONAL. The default value is 000000.
timeend:
End of time interval in a particular day. It is of the TIME data
type as mentioned in Section 4.3.12 of RFC 2445 [RFC2445]. This
attribute is OPTIONAL. The default value is 235959.
byweekday: List of days of the week. This attribute is OPTIONAL.
The <time-period> is based on the description in CPL [RFC3880] but
with a reduced feature set.
The "dtstart" and "dtend" attributes are formatted as iCalendar COS
DATE-TIME values, as specified in Section 4.3.5 of RFC 2445
[RFC2445]. Only floating or UTC times can be used with time zones.
The DATE-TIME is a subset of the corresponding syntaxes from ISO 8601
[ISO8601].
The "timestart" specifes a time value to indicate the beginning of
every day. The default value is 000000 representing the beginning of
the day.
The "timeend" specifes a time value to indicate the end of every day.
The default value is 235959 representing the end of the day.
The "byweekday" attribute specifies a comma-separated list of days of
the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE"
indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday,
"SA" indicates Saturday, and "SU" indicates Sunday. These values are
not case-sensitive.
Here is an example of the time-period element.
<time dtstart="20070112T083000"
timestart="0800"
timeend="1800"
byweekday="MO,TU,WE,TH,FR"
dtend="20080101T183000"/>
The following aspects need to be considered:
Tschofenig, et al. Expires May 22, 2008 [Page 10]
Internet-Draft Policies for Internet Telephony Spam November 2007
1) By default, if all the OPTIONAL parameters are missing, <time-
period> element is valid for the whole duration from 'dtstart' to
'dtend'.
2) The 'byweekday' attribute comes into effect only if the period
from 'dtstart' till 'dtstart' is long enough to accommodate the
specified values, else they are just neglected.
3) If the values of the 'byweekday' attribute values do not
correspond to the expected domain, they are simply ignored.
4) Only a single 'byweekday' attribute MUST be listed in a <time>
element.
5. Actions
As stated in [RFC4474], conditions are the 'if'-part of rules,
whereas actions and transformations form their 'then'-part. The
actions and transformations parts of a rule determine which
operations the proxy server MUST execute on receiving a connection
request attempt that matches all conditions of this rule. Actions
and transformations permit certain operations to be executed.
5.1. Execute Action
The <handling> element allows a couple of actions to be triggered,
namely
Block Action:
The block action states that this specific connection request MUST
NOT be forwarded and a "403" forbidden message MUST be sent to the
sender of the message.
Allow Action:
The Allow action states that this specific connection request MUST
be forwarded.
Furthermore, a couple of further mechanisms, such as computational
puzzles mechanism (described in [I-D.jennings-sip-hashcash]), the
consent framework (described in [I-D.ietf-sip-consent-framework])
etc. can be executed. Each mechanism needs to register a URI and the
value of URI is placed in this field.
[Editior's Note: For editorial purposes the schema currently lists a
few examples but in a non-URI format. When solution documents define
these URIs then they can be used with this document.]
Tschofenig, et al. Expires May 22, 2008 [Page 11]
Internet-Draft Policies for Internet Telephony Spam November 2007
5.2. Forward To
The action supported in this section is forwarding of calls with the
<forward-to> element that contains the following child element
<target> that specifies the address of the forwarding rule. It
should be a valid SIP URI (RFC 3261 [RFC3261]) or TEL URI (RFC 3966
[RFC3966]).
6. Examples
This section provides a few examples for policy rules defined in this
document.
6.1. Identity and Time-Based Policy
The following policy shows a white list with an identity condition
and a simple time-based condition.
Tschofenig, et al. Expires May 22, 2008 [Page 12]
Internet-Draft Policies for Internet Telephony Spam November 2007
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="AA56i09">
<conditions>
<identity>
<one id="sip:bob@example.com"/>
<many>
<except domain="example.com"/>
<except domain="example.org"/>
<except id="sip:alice@bad.example.net"/>
<except id="sip:bob@good.example.net"/>
<except id="tel:+1-212-555-1234" />
<except id="sip:alice@example.com"/>
</many>
</identity>
<sphere value="work"/>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions>
<spit:handling>allow</spit:handling>
</actions>
<transformations/>
</rule>
</ruleset>
6.2. Extended Time-Based Policy
The following policy shows the usage of the <time-period> element to
forward calls to an answering machine during the night.
Tschofenig, et al. Expires May 22, 2008 [Page 13]
Internet-Draft Policies for Internet Telephony Spam November 2007
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="AA56i10">
<conditions>
<spit:time-period>
<time dtstart="19970105T083000"
timestart="2200"
timeend="0800"
byweekday="MO,TU,WE,TH,FR"
dtend="19991230T183000"/>
</spit:time-period>
</conditions>
<actions>
<spit:forward-to>
<target>sip:answering-machine@home.foo-bar.com
</target>
</spit:forward-to>
</actions>
<transformations/>
</rule>
</ruleset>
6.3. Policy for triggering Captcha and Hashcash Challenges
The following example policy shows three rules with the rule id r1 -
r4.
Rule r1 matches for authenticated identities from the domain
"example.com", "example.org" and the single identity
"sip:bob@good.example.net". For these conditions SIP messages are
forwarded to the SIP UA as indicated with the <handling> element.
Rule r2 indicates that for SIP messages where the identity has not
been verifiable the hash cash mechanism
[I-D.jennings-sip-hashcash] and CAPTCHAs
[I-D.tschofenig-sipping-captcha] are applied (see the 'hashcash'
and the 'captcha' token in the <execute> element).
Rule r3 contains the <spit-handling> element with the <challenge>
child element. This rule evaluates to TRUE if the sender returned
a valid hash cash or a valid CAPTCHA result. The action part of
the rule indicates that the call is then forwarded to the
answering machine, namely sip:answering-machine@home.foo-bar.com.
Rule r4 blocks the call if sender provided a wrong hash cash or
CAPTCHA result.
Tschofenig, et al. Expires May 22, 2008 [Page 14]
Internet-Draft Policies for Internet Telephony Spam November 2007
Rule r1 and r2 are valid only from 2007-01-01T01:00:00+01:00 to 2007-
07-01T24:00:00+01:00.
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<rule id="r1">
<conditions>
<identity>
<one id="sip:bob@good.example.net"/>
<many domain="example.com"/>
<many domain="example.org"/>
</identity>
<validity>
<from>2007-01-01T01:00:00+01:00</from>
<until>2007-07-01T24:00:00+01:00</until>
</validity>
</conditions>
<actions>
<spit:execute>allow</spit:execute>
</actions>
<transformations/>
</rule>
<rule id="r2">
<conditions>
<validity>
<from>2007-01-01T01:00:00+01:00</from>
<until>2007-07-01T24:00:00+01:00</until>
</validity>
</conditions>
<actions>
<spit:execute>hashcash</spit:execute>
<spit:execute>captcha</spit:execute>
</actions>
<transformations/>
</rule>
<rule id="r3">
<conditions>
<spit:spit-handling>
<challenge result="SUCCESS">hashcash</challenge>
<challenge result="SUCCESS">captcha</challenge>
</spit:spit-handling>
</conditions>
Tschofenig, et al. Expires May 22, 2008 [Page 15]
Internet-Draft Policies for Internet Telephony Spam November 2007
<actions>
<spit:forward-to>
<target>sip:answering-machine@home.foo-bar.com
</target>
</spit:forward-to>
</actions>
<transformations/>
</rule>
<rule id="r4">
<conditions>
<spit:spit-handling>
<challenge result="FAILURE">hashcash</challenge>
<challenge result="FAILURE">captcha</challenge>
</spit:spit-handling>
</conditions>
<actions>
<spit:execute>block</spit:execute>
</actions>
<transformations/>
</rule>
</ruleset>
7. XML Schema
This section contains the XML schema that defines the policies schema
described in this document. This schema extends the Common Policy
schema (see [RFC4474]) by introducing new members of the <condition>
and <action> elements.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:spit-policy"
xmlns:spit="urn:ietf:params:xml:ns:spit-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<!-- This import brings in the XML language attribute xml:lang-->
<xs:import namespace="http://www.w3.org/XML/1998/namespace"
schemaLocation="http://www.w3.org/2001/xml.xsd"/>
<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
<!-- Conditions -->
Tschofenig, et al. Expires May 22, 2008 [Page 16]
Internet-Draft Policies for Internet Telephony Spam November 2007
<xs:element name="spit-handling">
<xs:complexType>
<xs:sequence>
<xs:element name="challenge" type="spit:challenge-type"
minOccurs="0" maxOccurs="unbounded"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="result" use="required">
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:enumeration value="SUCCESS"/>
<xs:enumeration value="FAILURE"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name="presence-status"
type="spit:presence-status-activity-type"/>
<xs:simpleType name="presence-status-activity-type">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="challenge-type">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:element name="time-period" type="spit:TimeSwitchType"/>
<xs:complexType name="TimeType">
<xs:annotation>
<xs:documentation>Exactly one of the two attributes
"dtend" and "duration" must occur. None of
the attributes following freq are meaningful
unless freq appears. </xs:documentation>
</xs:annotation>
<xs:attribute name="dtstart" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="dtend" type="xs:string" use="required">
<xs:annotation>
Tschofenig, et al. Expires May 22, 2008 [Page 17]
Internet-Draft Policies for Internet Telephony Spam November 2007
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="timestart" type="xs:string" use="optional"
default="000000">
<xs:annotation>
<xs:documentation>RFC 2445 TIME. It represents time in hours,
minutes and seconds and denotes the beginning of the day
time. The default value is 000000, denoting the
beginning of the day. </xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="timeend" type="xs:string" use="optional"
default="235959">
<xs:annotation>
<xs:documentation>RFC 2445 TIME. It represents time in
hours, minutes and seconds and denotes the
end of the day time. The default value is 235959,
denoting the end of the day. </xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byweekday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the week.
Valid values are "MO", "TU",
"WE", "TH", "FR", "SA" and "SU". These values are
not case-sensitive. Each can be preceded
by a positive (+n) or negative (-n) integer.
</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="TimeSwitchType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="time" type="spit:TimeType"
minOccurs="1" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
Tschofenig, et al. Expires May 22, 2008 [Page 18]
Internet-Draft Policies for Internet Telephony Spam November 2007
</xs:complexContent>
</xs:complexType>
<!-- Action -->
<xs:element name="execute">
<xs:simpleType>
<xs:restriction base="xs:string">
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name="forward-to" type="spit:forward-to-type"/>
<xs:complexType name="forward-to-type">
<xs:sequence>
<xs:element name="target" type="spit:target-type"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:complexType>
<xs:simpleType name="target-type">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
</xs:schema>
8. XCAP USAGE
The following section defines the details necessary for clients to
manipulate SPIT authorization documents from a server using XCAP.
8.1. Application Unique ID
XCAP requires application usages to define a unique application usage
ID (AUID) in either the IETF tree or a vendor tree. This
specification defines the "Spit-policy" AUID within the IETF tree,
via the IANA registration in Section 9.
8.2. XML Schema
XCAP requires application usages to define a schema for their
documents. The schema for Anti-SPIT authorization documents is
described in Section 7.
Tschofenig, et al. Expires May 22, 2008 [Page 19]
Internet-Draft Policies for Internet Telephony Spam November 2007
8.3. Default Namespace
XCAP requires application usages to define the default namespace for
their documents. The default namespace is
urn:ietf:params:xml:ns:spit-policy.
8.4. MIME Type
XCAP requires application usages to defined the MIME type for
documents they carry. Anti-SPIT privacy authorization documents
inherit the MIME type of Common Policy documents, application/
auth-policy+xml.
8.5. Validation Constraints
This specification does not define additional constraints.
8.6. Data Semantics
This document discusses the semantics of Anti-SPIT authorization.
8.7. Naming Conventions
When a SIP Proxy receives a SIP message to route it towards to a
specific user foo, it will look for all documents within
http://[xcaproot]/spit-policy/users/foo, and use all documents found
beneath that point to guide authorization policy.
8.8. Resource Interdependencies
This application usage does not define additional resource
interdependencies.
8.9. Authorization Policies
This application usage does not modify the default XCAP authorization
policy, which is that only a user can read, write or modify his/her
own documents. A server can allow privileged users to modify
documents that they do not own, but the establishment and indication
of such policies is outside the scope of this document.
9. IANA Considerations
There are several IANA considerations associated with this
specification.
Tschofenig, et al. Expires May 22, 2008 [Page 20]
Internet-Draft Policies for Internet Telephony Spam November 2007
9.1. Anti-SPIT Policy XML Schema Registration
URI: urn:ietf:params:xml:schema:spit-policy
Registrant Contact: Hannes Tschofenig (hannes.tschofenig@nsn.com).
XML: The XML schema to be registered is contained in Section 7. Its
first line is
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
</xs:schema>
9.2. Anti-SPIT Policy Namespace Registration
URI: urn:ietf:params:xml:ns:spit-policy
Registrant Contact: Hannes Tschofenig (hannes.tschofenig@nsn.com).
XML:
9.3. XCAP Application Usage ID
This section registers an XCAP Application Usage ID (AUID) according
to the IANA procedures defined in [RFC4825].
Name of the AUID: spit-policy
Description: The rules defined in this documents describe ways to
react on unwanted and unsolicted communication (including Spam).
10. Security Considerations
This document aims to make it simple for users to influence the
behavior of SIP message routing with an emphasis on SPIT prevention.
This document proposes a strawman proposal for conditions and actions
that might be useful when it comes to allowing a UA to tell its
proxies which messages it wants to receive and what tasks it wants
those proxies to perform before sending a SIP request to the UA.
A couple of requirements are described in
[I-D.froment-sipping-spit-requirements] and a general discussion
about the available solution mechanisms is available with
[I-D.ietf-sipping-spam]. This document offers the ability to glue
the different solution pieces together.
Since this document uses the Common Policy framework it also inherits
its capabilities, including the combining permission algorithm that
is applied when multiple rules fire. Unauthorized access to the
Tschofenig, et al. Expires May 22, 2008 [Page 21]
Internet-Draft Policies for Internet Telephony Spam November 2007
user's Anti-SPIT rules must be prevented to avoid the introduction of
security vulnerabilities.
11. Contributors
We would like to thank Mayutan Arumaithurai
(mayutan.arumaithurai@gmail.com) for his work on this document.
12. Acknowledgments
We would like to thank
o Jonathan Rosenberg, David Schwartz and Dan York for sharing their
thoughts with us before the first version of this document was
written.
o Miguel Garcia and Remi Denis-Courmont for their review comments to
the -00 version.
o Mayutan Arumaithurai for his editing help with the -00 version.
o Poikselka Miikka, Isomaki Markus, Jari Mutikainen, Jean-Marie
Stupka, and Antti Laurila for their comments and for pointing us
to specifications outside the IETF.
This document intentionally re-uses concept from existing documents.
In particular, we reused
o ideas from SIEVE [RFC3028], a mail filtering language.
o the text in Section 4.5 is based on the description in the Call
Processing Language (CPL) [RFC3880]. In general, the difference
between CPL and this document is that CPL has a more procedural
approach, while this proposal is matching-based. It is obviously
possible to enhance CPL as well to provide the functionality
offered in this document.
o text in Section 4.1 from [I-D.ietf-simple-presence-rules].
o content of Section 5.2, and Section 4.4 is reused from
[ETSI-TS-183-004].
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999.
Tschofenig, et al. Expires May 22, 2008 [Page 22]
Internet-Draft Policies for Internet Telephony Spam November 2007
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325,
November 2002.
[RFC3428] Campbell, B., Rosenberg, J., Schulzrinne, H., Huitema, C.,
and D. Gurle, "Session Initiation Protocol (SIP) Extension
for Instant Messaging", RFC 3428, December 2002.
[RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat,
"Indicating User Agent Capabilities in the Session
Initiation Protocol (SIP)", RFC 3840, August 2004.
[RFC3856] Rosenberg, J., "A Presence Event Package for the Session
Initiation Protocol (SIP)", RFC 3856, August 2004.
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
Priority for the Session Initiation Protocol (SIP)",
RFC 4412, February 2006.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4479] Rosenberg, J., "A Data Model for Presence", RFC 4479,
July 2006.
[RFC4480] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J.
Rosenberg, "RPID: Rich Presence Extensions to the Presence
Information Data Format (PIDF)", RFC 4480, July 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,
Tschofenig, et al. Expires May 22, 2008 [Page 23]
Internet-Draft Policies for Internet Telephony Spam November 2007
February 2007.
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
13.2. Informative References
[ETSI-TS-183-004]
ETSI, "TS 183 004, Telecommunications and Internet
converged Services and Protocols for Advanced Networking
(TISPAN); PSTN/ISDN simulation services: Communication
Diversion (CDIV); Protocol specification", 2007.
[I-D.froment-sipping-spit-requirements]
Froment, T., "Requirements for Authorization Policies to
tackle Spam and Unwanted Communication for Internet
Telephony", draft-froment-sipping-spit-requirements-01
(work in progress), July 2007.
[I-D.ietf-ecrit-service-urn]
Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services",
draft-ietf-ecrit-service-urn-07 (work in progress),
August 2007.
[I-D.ietf-mmusic-file-transfer-mech]
Garcia-Martin, M., Isomaki, M., Camarillo, G., and S.
Loreto, "A Session Description Protocol (SDP) Offer/Answer
Mechanism to Enable File Transfer",
draft-ietf-mmusic-file-transfer-mech-04 (work in
progress), October 2007.
[I-D.ietf-simple-message-sessions]
Campbell, B., "The Message Session Relay Protocol",
draft-ietf-simple-message-sessions-19 (work in progress),
February 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-03 (work
in progress), November 2007.
Tschofenig, et al. Expires May 22, 2008 [Page 24]
Internet-Draft Policies for Internet Telephony Spam November 2007
[I-D.ietf-sipping-spam]
Rosenberg, J. and C. Jennings, "The Session Initiation
Protocol (SIP) and Spam", draft-ietf-sipping-spam-05 (work
in progress), July 2007.
[I-D.jennings-sip-hashcash]
Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", draft-jennings-sip-hashcash-06 (work in progress),
July 2007.
[I-D.mahy-iptel-cpc]
Mahy, R., "The Calling Party's Category tel URI
Parameter", draft-mahy-iptel-cpc-06 (work in progress),
March 2007.
[I-D.rosenberg-sipping-service-identification]
Rosenberg, J., "Identification of Communications Services
in the Session Initiation Protocol (SIP)",
draft-rosenberg-sipping-service-identification-03 (work in
progress), July 2007.
[I-D.schubert-sipping-saml-cpc]
Schubert, S., "Conveying CPC using the SAML",
draft-schubert-sipping-saml-cpc-02 (work in progress),
July 2006.
[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.
[I-D.tschofenig-sipping-captcha]
Tschofenig, H. and E. Leppanen, "Completely Automated
Public Turing Test to Tell Computers and Humans Apart
(CAPTCHA) based Robot Challenges for the Session
Initiation Protocol (SIP)",
draft-tschofenig-sipping-captcha-00 (work in progress),
July 2007.
[I-D.tschofenig-sipping-framework-spit-reduction]
Tschofenig, H., "A Framework to tackle Spam and Unwanted
Communication for Internet Telephony",
draft-tschofenig-sipping-framework-spit-reduction-01 (work
in progress), July 2007.
[ISO8601] ISO (International Organization for Standardization),
""Data elements and interchange formats -- Information
Tschofenig, et al. Expires May 22, 2008 [Page 25]
Internet-Draft Policies for Internet Telephony Spam November 2007
interchange -- Representation of dates and times", ISO
Standard ISO 8601:2000(E), International Organization for
Standardization, Geneva, Switzerland,", December 2000.
[OMA-TS-XDM_Shared_Policy]
Open Mobile Alliance, "Shared Policy XDM Specification",
2007.
[OTZ] Eggert, P., "Sources for Time Zone and Daylight Saving
Time Data, available at
http://www.twinsun.com/tz/tz-link.htm", 2007.
[RFC2445] Dawson, F. and Stenerson, D., "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)",
RFC 2445, November 1998.
[RFC3028] Showalter, T., "Sieve: A Mail Filtering Language",
RFC 3028, January 2001.
[RFC3266] Olson, S., Camarillo, G., and A. Roach, "Support for IPv6
in Session Description Protocol (SDP)", RFC 3266,
June 2002.
[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.
Authors' Addresses
Hannes Tschofenig
Nokia Siemens Networks
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@nsn.com
URI: http://www.tschofenig.com
Dan Wing
Cisco
Phone:
Email: dwing@cisco.com
Tschofenig, et al. Expires May 22, 2008 [Page 26]
Internet-Draft Policies for Internet Telephony Spam November 2007
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
Thomas Froment
Alcatel-Lucent
1, rue Ampere - BP 80056
Massy, Paris 91302
France
Email: Thomas.Froment@alcatel-lucent.fr
Geoffrey Dawirs
University of Namur
21, rue Grandgagnage
Namur B-5000
Belgique
Email: gdawirs@gdawirs.be
Tschofenig, et al. Expires May 22, 2008 [Page 27]
Internet-Draft Policies for Internet Telephony Spam November 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).
Tschofenig, et al. Expires May 22, 2008 [Page 28]