One document matched: draft-tschofenig-sipping-spit-policy-03.xml
<?xml version="1.0"?>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="yes" ?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC4474 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4474.xml'>
<!ENTITY RFC4745 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml'>
<!ENTITY RFC4825 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml'>
<!ENTITY RFC5025 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5025.xml'>
<!ENTITY I-D.jennings-sip-hashcash PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.jennings-sip-hashcash.xml'>
<!ENTITY I-D.ietf-sip-consent-framework PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sip-consent-framework.xml'>
<!ENTITY I-D.froment-sipping-spit-requirements PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.froment-sipping-spit-requirements.xml'>
<!ENTITY RFC5039 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5039.xml'>
<!ENTITY RFC3880 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3880.xml'>
<!ENTITY RFC5228 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5228.xml'>
<!ENTITY I-D.tschofenig-sipping-framework-spit-reduction PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-sipping-framework-spit-reduction.xml'>
<!ENTITY RFC2445 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2445.xml'>
<!ENTITY RFC3987 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3987.xml'>
<!ENTITY RFC3856 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3856.xml'>
<!ENTITY RFC2617 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2617.xml'>
<!ENTITY RFC3261 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3261.xml'>
<!ENTITY RFC3325 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3325.xml'>
<!ENTITY RFC3966 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3966.xml'>
<!ENTITY RFC3323 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3323.xml'>
<!ENTITY I-D.tschofenig-sipping-captcha PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml3/reference.I-D.tschofenig-sipping-captcha.xml'>
<!ENTITY RFC4480 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4480.xml'>
<!ENTITY RFC4479 PUBLIC '' 'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4479.xml'>
]>
<rfc category="std" ipr="full3978" docName="draft-tschofenig-sipping-spit-policy-03.txt">
<front>
<title abbrev="Policies for Internet Telephony Spam">A Document Format for Expressing
Authorization Policies to tackle Spam and Unwanted Communication for Internet Telephony</title>
<author initials="H." surname="Tschofenig" fullname="Hannes Tschofenig">
<organization>Nokia Siemens Networks</organization>
<address>
<postal>
<street>Linnoitustie 6</street>
<city>Espoo</city>
<code>02600</code>
<country>Finland</country>
</postal>
<phone>+358 (50) 4871445</phone>
<email>Hannes.Tschofenig@gmx.net</email>
<uri>http://www.tschofenig.priv.at</uri>
</address>
</author>
<author initials="D" surname="Wing" fullname="Dan Wing">
<organization>Cisco</organization>
<address>
<postal>
<street> </street>
<city> </city>
<region> </region>
<code> </code>
<country> </country>
</postal>
<phone> </phone>
<email>dwing@cisco.com</email>
</address>
</author>
<author initials="H." surname="Schulzrinne" fullname="Henning Schulzrinne">
<organization>Columbia University</organization>
<address>
<postal>
<street>Department of Computer Science</street>
<street>450 Computer Science Building</street>
<city>New York</city>
<region>NY</region>
<code>10027</code>
<country>US</country>
</postal>
<phone>+1 212 939 7004</phone>
<email>hgs@cs.columbia.edu</email>
<uri>http://www.cs.columbia.edu</uri>
</address>
</author>
<author fullname="Thomas Froment" initials="T." surname="Froment">
<organization>Alcatel-Lucent</organization>
<address>
<postal>
<street>1, rue Ampere - BP 80056</street>
<city>Massy</city>
<region>Paris</region>
<code>91302</code>
<country>France</country>
</postal>
<email>Thomas.Froment@alcatel-lucent.fr</email>
</address>
</author>
<author fullname="Geoffrey Dawirs" initials="G." surname="Dawirs">
<organization>University of Namur</organization>
<address>
<postal>
<street>21, rue Grandgagnage</street>
<city>Namur</city>
<code>B-5000</code>
<country>Belgique</country>
</postal>
<email>gdawirs@gdawirs.be</email>
</address>
</author>
<date year="2008"/>
<area>Real-time Applications and Infrastructure Area</area>
<workgroup>SIPPING</workgroup>
<keyword>Internet-Draft</keyword>
<keyword>Authorization Policy</keyword>
<keyword>Spam Prevention</keyword>
<keyword>User-controlled Policy Routing</keyword>
<abstract>
<t>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.</t>
</abstract>
</front>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="introduction" title="Introduction">
<t>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 <xref target="I-D.jennings-sip-hashcash"/>. </t>
<t>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 <xref
target="RFC4474"/>, is one important concept.</t>
<t>The requirements for the authorization policies described in this document are outlined in
<xref target="I-D.froment-sipping-spit-requirements"/>. A framework document is available
at <xref target="I-D.tschofenig-sipping-framework-spit-reduction"/>.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="terminology" title="Terminology">
<t>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 <xref target="RFC2119"/>.</t>
<t>This document reuses the terminology from RFC 4745 <xref target="RFC4745"/>:</t>
<t>
<list style="hanging">
<t hangText="Rule maker:">
<vspace blankLines="1"/> 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.<vspace blankLines="1"/>
</t>
<t hangText="Authorization policy:">
<vspace blankLines="1"/>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. <vspace
blankLines="1"/>
</t>
<t hangText="Permission:">
<vspace blankLines="1"/>The term permission refers to the action and transformation
components of a rule.<vspace blankLines="1"/>
</t>
</list>
</t>
<t>We use the term 'Recipient' for the entity that is target of the communication attempt of a
sender.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Generic Processing">
<section title="Structure of SPIT Authorization Documents">
<t> A SPIT authorization document is an XML document, formatted according to the schema
defined in RFC 4745 <xref target="RFC4745"/>. SPIT authorization documents inherit the
MIME type of common policy documents, application/auth-policy+xml. As described in <xref
target="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. </t>
</section>
<section title="Rule Transport">
<t>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) <xref
target="RFC4825"/>.</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="conditions" title="Condition Elements">
<t>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. </t>
<t> Note that, as discussed in <xref target="RFC4745"/>, a permission document applies to a
translation if all the expressions in its conditions part evaluate to TRUE. </t>
<section anchor="identity" title="Identity">
<t> Although the <identity> element is defined in <xref target="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: </t>
<t>
<list style="symbols">
<t>Define acceptable means of authentication. </t>
<t>Define the procedure for representing the identity as a URI or IRI <xref
target="RFC3987"/>. </t>
</list>
</t>
<t>This sub-section defines those details for systems based on <xref target="RFC3856"/>. </t>
<section title="Acceptable Forms of Authentication">
<t> When used with SIP, a request is considered authenticated if one of the following
techniques is used:</t>
<t>
<list style="hanging">
<t hangText="SIP Digest:"><vspace blankLines="1"/> The proxy has authenticated the
sender using SIP <xref target="RFC3261"/> digest authentication <xref
target="RFC2617"/>. However, if the anonymous authentication described on page 194
of RFC 3261 <xref target="RFC3261"/> was used, the sender is not considered
authenticated.<vspace blankLines="1"/>
</t>
<t hangText="Asserted Identity:"><vspace blankLines="1"/>If a request contains a
P-Asserted-ID header field <xref target="RFC3325"/> and the request is coming from a
trusted element, the sender is considered authenticated.<vspace blankLines="1"/></t>
<t hangText="Cryptographically Verified Identity:">
<vspace blankLines="1"/>If a request contains an Identity header field as defined in
<xref target="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.</t>
</list>
</t>
<t>An anonymous From header field with RFC 4474 <xref target="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. </t>
</section>
<section title="Computing a URI for the Sender">
<t> 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 <xref target="RFC3966"
/>. For example, consider the following "user record" in a database: </t>
<t>
<figure>
<artwork><![CDATA[
SIP AOR: sip:alice@example.com
digest username: ali
digest password: f779ajvvh8a6s6
digest realm: example.com
]]></artwork>
</figure>
</t>
<t> 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". </t>
<t> For messages that are authenticated using RFC 3325 <xref target="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 <xref target="RFC3966"/>), then each of them is used for the comparisons
outlined in <xref target="RFC4745"/>, and if either of them match a <one>
or <except> element, it is considered a match. </t>
<t> For messages that are authenticated using the SIP Identity mechanism <xref
target="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. </t>
<t> 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. </t>
<t> 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 <xref target="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. </t>
<t> It is important to note that SIP frequently uses both SIP URI and tel URI <xref
target="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. </t>
</section>
</section>
<section anchor="sphere" title="Sphere">
<t>The <sphere> element is defined in <xref target="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.</t>
<t> 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 <xref target="RFC4480"/> as part of the person
data component <xref target="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. </t>
</section>
<section anchor="spit-handling" title="SPIT Handling">
<t>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.</t>
<t>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. </t>
<t>The <spit-handling> element MAY contain zero or more
<challenge> elements. The <challenge> elements has an
attribute 'result' that either contains "SUCCESS" or "FAILURE".</t>
</section>
<section anchor="presence-status" title="Presence Status">
<t> 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.</t>
</section>
<section anchor="time-period" title="Time Period Condition">
<t>The <time-period> element allows to make decisions based on the time, date
and timezone. It defines an extended version of the <validity> element.</t>
<t> The <time-period> element may contain the following attributes:</t>
<t>
<list style="hanging">
<t hangText="dtstart:"><vspace blankLines="1"/>Start of interval (RFC 2445 <xref
target="RFC2445"/> DATE-TIME). This attribute is MANDATORY. <vspace blankLines="1"/></t>
<t hangText="dtend:"><vspace blankLines="1"/>End of interval (RFC 2445 <xref
target="RFC2445"/> DATE-TIME). This attribute is MANDATORY.<vspace blankLines="1"/></t>
<t hangText="timestart:"><vspace blankLines="1"/>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 <xref
target="RFC2445"/>. This attribute is OPTIONAL. The default value is 000000. <vspace
blankLines="1"/></t>
<t hangText="timeend:"><vspace blankLines="1"/>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 <xref
target="RFC2445"/>. This attribute is OPTIONAL. The default value is 235959. <vspace
blankLines="1"/></t>
<t hangText="byweekday:"> List of days of the week. This attribute is OPTIONAL.<vspace
blankLines="1"/></t>
</list>
</t>
<t> The <time-period> is based on the description in CPL <xref
target="RFC3880"/> but with a reduced feature set. </t>
<t>The "dtstart" and "dtend" attributes are formatted as iCalendar COS DATE-TIME values, as
specified in Section 4.3.5 of RFC 2445 <xref target="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 <xref target="ISO8601"/>. </t>
<t>The "timestart" specifes a time value to indicate the beginning of every day. The default
value is 000000 representing the beginning of the day. </t>
<t>The "timeend" specifes a time value to indicate the end of every day. The default value
is 235959 representing the end of the day. </t>
<t> 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. </t>
<t> Here is an example of the time-period element. </t>
<t>
<figure>
<artwork><![CDATA[
<time dtstart="20070112T083000"
timestart="0800"
timeend="1800"
byweekday="MO,TU,WE,TH,FR"
dtend="20080101T183000"/>
]]></artwork>
</figure>
</t>
<t>The following aspects need to be considered:</t>
<t>
<list style="hanging">
<t hangText="1)">By default, if all the OPTIONAL parameters are missing,
<time-period> element is valid for the whole duration from 'dtstart' to
'dtend'. </t>
<t hangText="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. </t>
<t hangText="3)">If the values of the 'byweekday' attribute values do not correspond to
the expected domain, they are simply ignored. </t>
<t hangText="4)">Only a single 'byweekday' attribute MUST be listed in a
<time> element. </t>
</list>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="actions" title="Actions">
<t>As stated in <xref target="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. </t>
<section anchor="execute" title="Execute Action">
<t>The <handling> element allows a couple of actions to be triggered, namely </t>
<t>
<list style="hanging">
<t hangText="Block Action:"><vspace blankLines="1"/> 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.<vspace blankLines="1"/>
</t>
<t hangText="Allow Action:"><vspace blankLines="1"/> The Allow action states that this
specific connection request MUST be forwarded. </t>
</list>
</t>
<t>Furthermore, a couple of further mechanisms, such as computational puzzles mechanism
(described in <xref target="I-D.jennings-sip-hashcash"/>), the consent framework
(described in <xref target="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.</t>
<t>[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.] </t>
</section>
<section anchor="Forward-to" title="Forward To">
<t>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 <xref target="RFC3261"/>) or TEL URI (RFC 3966 <xref
target="RFC3966"/>). </t>
</section>
<!--
<section anchor="spam-marking" title="Spam Marking">
<t>This document defines the <spam-marking> action that enables the usage of
Spam marking.</t>
</section>
-->
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="examples" title="Examples">
<t> This section provides a few examples for policy rules defined in this document. </t>
<section title="Identity and Time-Based Policy">
<t>The following policy shows a white list with an identity condition and a simple
time-based condition.</t>
<t>
<figure>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
<section title="Extended Time-Based Policy">
<t>The following policy shows the usage of the <time-period> element to
forward calls to an answering machine during the night.</t>
<t>
<figure>
<artwork><![CDATA[
<?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>
]]></artwork>
</figure>
</t>
</section>
<section title="Policy for triggering Captcha and Hashcash Challenges">
<t>The following example policy shows three rules with the rule id r1 - r4. </t>
<t>
<list style="empty">
<t>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. <vspace blankLines="1"/>
</t>
<t>Rule r2 indicates that for SIP messages where the identity has not been verifiable
the hash cash mechanism <xref target="I-D.jennings-sip-hashcash"/> and CAPTCHAs <xref
target="I-D.tschofenig-sipping-captcha"/> are applied (see the 'hashcash' and the
'captcha' token in the <execute> element). </t>
<t>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. </t>
<t>Rule r4 blocks the call if sender provided a wrong hash cash or CAPTCHA result.</t>
</list>
</t>
<t>Rule r1 and r2 are valid only from 2007-01-01T01:00:00+01:00 to
2007-07-01T24:00:00+01:00. </t>
<t>
<figure>
<artwork><![CDATA[
<?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>
<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>
]]></artwork>
</figure>
</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="schema" title="XML Schema">
<t>This section contains the XML schema that defines the policies schema described in this
document. This schema extends the Common Policy schema (see <xref target="RFC4474"/>) by
introducing new members of the <condition> and <action>
elements.</t>
<t>
<figure>
<artwork><![CDATA[
<?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 -->
<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>
<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>
</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>
]]></artwork>
</figure>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="XCAP" title="XCAP USAGE">
<t> The following section defines the details necessary for clients to manipulate SPIT
authorization documents from a server using XCAP. </t>
<section anchor="ID" title="Application Unique ID">
<t> 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 <xref target="iana"/>. </t>
</section>
<section anchor="Schema" title="XML Schema">
<t>XCAP requires application usages to define a schema for their documents. The schema for
Anti-SPIT authorization documents is described in <xref target="schema"/>. </t>
</section>
<section anchor="namespace" title=" Default Namespace">
<t> XCAP requires application usages to define the default namespace for their documents.
The default namespace is urn:ietf:params:xml:ns:spit-policy.</t>
</section>
<section anchor="MIME" title=" MIME Type ">
<t>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.</t>
</section>
<section anchor="validation" title="Validation Constraints">
<t>This specification does not define additional constraints. </t>
</section>
<section anchor="Data" title="Data Semantics">
<t> This document discusses the semantics of Anti-SPIT authorization. </t>
</section>
<section anchor="Naming" title=" Naming Conventions">
<t> 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. </t>
</section>
<section anchor="Resource" title="Resource Interdependencies">
<t> This application usage does not define additional resource interdependencies. </t>
</section>
<section anchor="Auth" title="Authorization Policies">
<t> 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. </t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section anchor="iana" title="IANA Considerations">
<t>There are several IANA considerations associated with this specification. </t>
<section title="Anti-SPIT Policy XML Schema Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:schema:spit-policy</t>
<t hangText="Registrant Contact:">Hannes Tschofenig (hannes.tschofenig@nsn.com).</t>
<t hangText="XML:">The XML schema to be registered is contained in <xref target="schema"
/>. Its first line is <figure>
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
]]></artwork>
</figure> and its last line is<figure>
<artwork><![CDATA[
</xs:schema>
]]></artwork>
</figure></t>
</list>
</t>
</section>
<section title="Anti-SPIT Policy Namespace Registration">
<t>
<list style="hanging">
<t hangText="URI:">urn:ietf:params:xml:ns:spit-policy</t>
<t hangText="Registrant Contact:">Hannes Tschofenig (hannes.tschofenig@nsn.com).</t>
<t hangText="XML:">
<figure>
<artwork> </artwork>
</figure>
</t>
</list>
</t>
</section>
<section title="XCAP Application Usage ID">
<t>This section registers an XCAP Application Usage ID (AUID) according to the IANA
procedures defined in <xref target="RFC4825"/>. </t>
<t> Name of the AUID: spit-policy </t>
<t> Description: The rules defined in this documents describe ways to react on unwanted and
unsolicted communication (including Spam).</t>
</section>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Security Considerations">
<t>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. </t>
<t>A couple of requirements are described in <xref
target="I-D.froment-sipping-spit-requirements"/> and a general discussion about the
available solution mechanisms is available with <xref target="RFC5039"/>. This
document offers the ability to glue the different solution pieces together. </t>
<t>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 user's Anti-SPIT rules must be prevented to avoid the
introduction of security vulnerabilities. </t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Contributors">
<t>We would like to thank Mayutan Arumaithurai (mayutan.arumaithurai@gmail.com) for his work
on this document.</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<section title="Acknowledgments">
<t>We would like to thank <list style="symbols">
<t>Jonathan Rosenberg, David Schwartz and Dan York for sharing their thoughts with us
before the first version of this document was written.</t>
<t>Miguel Garcia and Rémi Denis-Courmont for their review comments to the -00 version.</t>
<t>Mayutan Arumaithurai for his editing help with the -00 version.</t>
<t>Poikselka Miikka, Isomaki Markus, Jari Mutikainen, Jean-Marie Stupka, and Antti Laurila
for their comments and for pointing us to specifications outside the IETF.</t>
</list>
</t>
<t>This document intentionally re-uses concept from existing documents. In particular, we
reused <list style="symbols">
<t>ideas from SIEVE <xref target="RFC5228"/>, a mail filtering language.</t>
<t>the text in <xref target="time-period"/> is based on the description in the Call
Processing Language (CPL) <xref target="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.</t>
<t>text in <xref target="identity"/> from <xref target="RFC5025"/>.</t>
<t>content of <xref target="Forward-to"/>, and <xref target="presence-status"/> is reused
from <xref target="ETSI-TS-183-004"/>.</t>
<!-- <t>text of <xref target="media-list"/> from <xref target="OMA-TS-XDM_Shared_Policy"/></t>
-->
</list>
</t>
</section>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
</middle>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
<back>
<references title="Normative References">
<reference anchor="RFC2119">
<front>
<title abbrev="RFC Key Words">Key words for use in RFCs to Indicate Requirement Levels</title>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
</author>
<date month="March" year="1997"/>
</front>
<format type="TXT" octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"/>
</reference> &RFC4745; &RFC4825; &RFC3987;
&RFC3856; &RFC2617; &RFC3261; &RFC4474; &RFC3966;
&RFC4479; &RFC3323; &RFC4480; </references>
<references title="Informative References">
&RFC3325;
&I-D.froment-sipping-spit-requirements;
&RFC5039; &RFC5025;
&I-D.jennings-sip-hashcash; &I-D.ietf-sip-consent-framework; &RFC5228;
&RFC3880; &I-D.tschofenig-sipping-framework-spit-reduction;
&RFC2445;
&I-D.tschofenig-sipping-captcha;
<reference anchor="ETSI-TS-183-004">
<front>
<title>TS 183 004, Telecommunications and Internet converged Services and Protocols for
Advanced Networking (TISPAN); PSTN/ISDN simulation services: Communication Diversion
(CDIV); Protocol specification </title>
<author fullname="ETSI">
<organization>ETSI</organization>
</author>
<date year="2007"/>
</front>
<format type="html" target="24173-710-ETSI-TS-183-004"/>
</reference>
<reference anchor="OMA-TS-XDM_Shared_Policy">
<front>
<title>Shared Policy XDM Specification</title>
<author fullname="Open Mobile Alliance">
<organization>Open Mobile Alliance</organization>
</author>
<date year="2007"/>
</front>
<format type="doc" target="OMA-TS-XDM_Shared_Policy-V1_0-20070614-D"/>
</reference>
<reference anchor="ISO8601">
<front>
<title>"Data elements and interchange formats -- Information interchange -- Representation
of dates and times", ISO Standard ISO 8601:2000(E), International Organization for
Standardization, Geneva, Switzerland,</title>
<author fullname="ISO (International Organization for Standardization)">
<organization>ISO (International Organization for Standardization)</organization>
</author>
<date month="December" year="2000"/>
</front>
<format type="html" target="http://www.twinsun.com/tz/tz-link.htm"/>
</reference>
</references>
<!-- ////////////////////////////////////////////////////////////////////////////////// -->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-22 16:42:39 |