Internet DRAFT - draft-schwartz-sipping-spit-saml
draft-schwartz-sipping-spit-saml
SIPPING D. Schwartz
Internet-Draft B. Sterman
Expires: December 28, 2006 Kayote Networks
E. Katz
XConnect Global Networks
H. Tschofenig
Siemens
June 26, 2006
SPAM for Internet Telephony (SPIT) Prevention using the Security
Assertion Markup Language (SAML)
draft-schwartz-sipping-spit-saml-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 28, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
Limiting and preventing SPAM for Internet Telephony (SPIT) is seen as
an important task for future security work in the Voice over IP
environment. This document addresses the problem by utilizing the
Schwartz, et al. Expires December 28, 2006 [Page 1]
Internet-Draft SPIT Prevention using SAML June 2006
concept introduced by the SIP Identity Framework in combination with
the Security Assertion Markup Language (SAML) to warrant certain
security relevant attributes from one administrative domain to
another. This approach allows the destination domain to make
intelligent filtering decisions when receiving voice calls.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1. Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2. Trust Models . . . . . . . . . . . . . . . . . . . . . . . 5
3.2.1. Attributes . . . . . . . . . . . . . . . . . . . . . . 5
4. Details of Security Information . . . . . . . . . . . . . . . 5
4.1. Type attributes . . . . . . . . . . . . . . . . . . . . . 6
4.1.1. IdentityStrength . . . . . . . . . . . . . . . . . . . 6
4.1.2. CostOfCall . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Flow Attributes . . . . . . . . . . . . . . . . . . . . . 7
4.2.1. CallRate . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2. CallCompletionSuccessRate . . . . . . . . . . . . . . 7
4.2.3. CallDurationConsistancy . . . . . . . . . . . . . . . 8
4.2.4. SpitSuspect . . . . . . . . . . . . . . . . . . . . . 8
4.3. Using SAML to Embed Security Attributes . . . . . . . . . 8
5. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 8
6. Filtering and Call Blocking . . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8.1. SPIT IdentityStrength Namespace Registration . . . . . . . 14
8.2. SPIT CostOfCall Namespace Registration . . . . . . . . . . 15
8.3. SPIT CallRate Namespace Registration . . . . . . . . . . . 16
8.4. SPIT CallCompletionSuccessRate Namespace Registration . . 17
8.5. CallDurationConsistancy Namespace Registration . . . . . . 18
8.6. SPIT SpitSuspect Namespace Registration . . . . . . . . . 19
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
Intellectual Property and Copyright Statements . . . . . . . . . . 23
Schwartz, et al. Expires December 28, 2006 [Page 2]
Internet-Draft SPIT Prevention using SAML June 2006
1. Introduction
Security concerns are of primary importance to the widespread
adoption of VoIP, particularly in full IP to IP communication
scenarios. Caller-ID information is easily manipulated and is not
always verified by domain administrator or a trusted third-party,
leaving a caller's identity suspect. With the ever growing
popularity of VoIP offerings worldwide providing an attractive user
base at the disposal of malicious parties, the threat of SPIT (Spam
for Internet Telephony) looms just over the horizon. All that is
needed using SIP is a User Agent Client (UAC) that initiates, in
parallel, a large number of calls.
While there are many discussions underway as to the best approach to
preventing SPIT [I-D.ietf-sipping-spam], this document outlines an
initial SPIT prevention approach that may help to form a basis for a
comprehensive solution. To develop a solution that can be deployed
soon we build on existing work, namely the SIP Identity Framework
approach suggested here makes use of Authenticated Identity in SIP
[I-D.ietf-sip-identity] and the Security Attributes Markup Language
(SAML) as it pertains to SIP [I-D.ietf-sip-saml].
A complete Voice over IP security solution requires a number of
building blocks, including mechanisms to secure the signaling and
data communication between the participating parties, authorization
of the caller and many more aspects. This document intentionally
focuses on a small subset of the entire solution space, specifically
the issues of the authenticity of an authentication service creating
assertions and the content of these assertions.
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 [RFC2119].
The following definitions are used throughout this document:
SIP User Agent (UA):
SIP User Agents or other SIP based edge devices managed by
callers' Administrative Domain (AD). We will adopt here the plain
SIP terminology as follows: The UA sending the request will be the
User Agent Client or UAC and the User Agent receiving (or not) the
request all the way downstream and generating the response will be
the User Agent Server or UAS.
Schwartz, et al. Expires December 28, 2006 [Page 3]
Internet-Draft SPIT Prevention using SAML June 2006
Authentication Service (AS):
Entity that possesses the private key of a domain certificate, and
is capable of authenticating one or more SIP users that can
register in that domain.
Administrative Domain (AD):
Aggregating domain responsible for a set of EUs such as VoIP
service provider or enterprise PBX. AD's minimally consist of a
SIP proxy and an Authentication Service.
Peering Domain (PD):
Domain maintaining a trust relationship with another domain. Note
that all domains are also peering domains.
Security Attributes (SA):
ASecurity information pertaining to a given call that is
transferred between PD's. There are two kinds of SA's Type
Attributes (TA) and Flow Attributes (FA).
Type Attributes (TA):
Type attributes are characteristics of a call that define static
indicators of SPAM.
Flow Attributes (FA):
Flow attributes are characteristics of a call that when compared
with all other calls passing through a PD can provide dynamic
indicators of SPAM.
Policy:
A set of actions or rules that are taken in response to the
receipt Security attributes. As stated above, this discussion is
out of scope for this document. For a discussion of this topic
see [I-D.froment-sipping-spit-authz-policies].
Client Administrative Domain (CAD):
AD responsible for UAC.
3. Overview
Schwartz, et al. Expires December 28, 2006 [Page 4]
Internet-Draft SPIT Prevention using SAML June 2006
3.1. Goals
The two goals of this document are to:
1. 1. Present initial set of security attributes intended to
complement the authenticated identity mechanism with additional
information about the call in order to help the called party/ies
determine the relative likelihood of each call with respect to
SPIT.
2. Identify a suitable method of passing the above-mentioned
information within a SIP message.
3.2. Trust Models
There is no point in discussing exchange of authenticated identity or
security attributes without first describing the underlying trust
models. The approach described in this document works in a number of
different environments, including
o Centralized Trust Model: Everyone trusts a centralized third party
to authenticate and authorize all participants in the network.
This third party creates all the assertions and in essence there
is no transitive trust.
o Federated Trust Model: Different centralized trust models are
combined and transitive trust is applied along the communication
between these networks. This topic is subject for discussion in
the SPEERMINT working group.
o P2P trust model: This trust model is very much subject for ongoing
work in the research community and in the P2P SIP interest group.
Furthermore work is necessary to verify the applicability of the
approach described in this document to the P2P environment.
3.2.1. Attributes
Statements containing both type and flow information about a call
that is exchanged between peers. The assertions are additive and may
be chained with the downstream call flow to provide a more complete
picture. Each peer can use these assertions to assist in enforcement
of its policy.
4. Details of Security Information
As discussed above, the assertions can be broken down to
(a) type - static characteristics of specific call, and
(b) flow - dynamic characteristics of call (relative to other
calls).
The SIP Proxy at the CAD adds type attributes and proxies at each PD
along the downstream path (including SAD) add any relevant flow
attributes. At each domain the local AS binds these attributes to
Schwartz, et al. Expires December 28, 2006 [Page 5]
Internet-Draft SPIT Prevention using SAML June 2006
the message together with its own identity.
Since this model attempts to cover many different architectures,
including transit networks, it is imperative that the attributes are
passed in the SIP header (as opposed to the body) so that transit PD
proxies along the way can add information as well. Note also, that
the actual attributes need to be passed by value [I-D.ietf-sip-saml]
to speed up their processing by proxies along the downstream path.
Please note the security attribute list provided in the subsequent
section does not list authentication related information as
additional attributes since this information is already provided by
SAML as part of the authentication statements.
It is our hope that this list will be refined and expanded as the
initiative described here becomes more widely discussed and
implemented. Furthermore, as can be seen from the parallels to
combating SPAM, worms, and viruses, the battle against misuse of VoIP
will be ongoing and methods will evolve to counter new threats. The
list of security attributes will likewise continue to grow and follow
trends in SPIT and fraud detection. The method of passing the
information as presented in this draft is open and flexible, and
therefore should be able to accommodate new parameters and
modifications of existing ones.
The attributes are formatted as descriptor-value pairs and presented
here with a description of their meaning and utility, along with
suggested values representing varying levels of security or fraud
potential. First we describe type attributes added by CAD SIP proxy
and then we describe flow attributes added by each peer along the
downstream signaling path.
4.1. Type attributes
4.1.1. IdentityStrength
This attribute relates to the relative difficulty customers or users
have in obtaining identities or user accounts at CAD - in other words
the amount of trust that can be placed in the user's identity. In
the case of a VoIP service provider, for example, a free service
where users download software based on an email address would have a
lower value than one where product is shipped to a postal address.
Calls originating on the PSTN will also have high values since the
Caller ID associated with a call on the PSTN has a perceived high
degree of trust. It is assumed that callers with a higher value will
be less likely to generate SPIT calls.
The values for this attribute are:
Schwartz, et al. Expires December 28, 2006 [Page 6]
Internet-Draft SPIT Prevention using SAML June 2006
o 0 - Unknown
o 1 - Free service
o 2 - Paying service (e.g., Billing Address or Payment method
verified)
o 3 - Physical premises verified / Enterprise / PSTN based
o 4 - User had to present a passport
The key issue is a "degree of confidence" that this account is not
robot created [ 0 .. 3 ], and is human (not identity) verified by
either turing test, or address, or c/c etc...
4.1.2. CostOfCall
This attribute indicates the charges associated with a call. It is
assumed that paying calls are less likely to be SPIT.
The values for this attribute are:
1. 0 - Unknown
2. 1 - Free
3. 2 - Flat rate (subscription for unmetered dialing)
4. 3 - Per minute (or included in a finite bucket of minutes)
5. 4 - Charged individually per call (event based charging)
[Editor's Note: The mechanism for the transfer of dynamic information
from the SIP proxy to the AS on a call by call basis is subject for
further discussion and should be seen as a tentative proposal.]
4.2. Flow Attributes
As opposed to the call centric nature of the static attributes, the
dynamic ones are more a measure of the previous peer. Each PD (this
includes the OAD) can, using heuristics and viewing all its call
detail, identity, authentication etc information, create additional
information, in relation to spit. Please note that to the best of
our knowledge, these attributes do not violate any of the known
privacy laws. Information is stateless and anonymous. Following is
a sample list of three such attributes.
4.2.1. CallRate
A number representing the amount of INVITES that have come from this
Peer per a predefined time period relative to the monthly average.
4.2.2. CallCompletionSuccessRate
A number representing the number of successful call completions from
this peer per a predefined time period relative to the number of
failed ones.
Schwartz, et al. Expires December 28, 2006 [Page 7]
Internet-Draft SPIT Prevention using SAML June 2006
4.2.3. CallDurationConsistancy
A number representing the spread of duration of successful calls per
a predefined time period relative to the monthly average.
4.2.4. SpitSuspect
This parameter is an overall objective weighted score that each PD
assigns based on its interpretation of received attributes, its own
information, and its heuristics. In this way, less sophisticated
decisions can be made based solely on the value of this parameter,
whereas more detailed information is also available. The values for
this parameter are:
1. 0 - Low SPIT level
2. 1 - Medium SPIT level
3. 2 - High SPIT level
4.3. Using SAML to Embed Security Attributes
Security attributes are formatted as descriptor=value pairs and
passed to the terminating TAD using the Security Markup Language
(SAML).
Integration of SAML and SIP is described in [I-D.ietf-sip-saml].
Theoretically, SAML assertions can be conveyed in SIP per-value or by
reference (i.e., as a URI reference described in [I-D.ietf-sip-
saml]). Furthermore, the reference or the assertion can
theoretically be conveyed in the SIP header or in the SIP body.
[I-D.ietf-sip-saml] describes how a HTTP URI reference to a SAML
assertion is carried inside the SIP header.
The SPIT related information defined in this document are XML encoded
in the following structure:
<Attribute
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:ietf:params:xml:ns:spit:IdentityStrength">
<AttributeValue xsi:type="xs:integer">1</AttributeValue>
</Attribute>
Figure 1: SAML encoding
5. Example Message Flow
As mentioned above, in an attempt to cover as many real world
Schwartz, et al. Expires December 28, 2006 [Page 8]
Internet-Draft SPIT Prevention using SAML June 2006
scenarios as possible the trust model assumed in this draft is a
distributed one. This encompasses direct bilateral trust [A trusts
B], transitive trust models - such as through a trust service [A
trusts C, C trusts B, therefore A trusts B], federations and P2P
chains of trusted pairs. The SIP security model deals with
expressing trust relationships both in an end-to-end model and a hop-
by-hop model.
For the sake of this discussion, therefore, we will be referring to
the diagram below depicting this general distributed trust model.
The nodes in this diagram represent SIP entities (UA, Proxy, B2B) and
the edges represent trust relationships. Borrowing from DNS
terminology, any node containing static information (e.g.,
CostOfCall) about an upstream node will be said to be authoritative
with respect to this node. Any node containing ONLY dynamic
information (e.g., ASR) about an upstream node will be said to be a
transit node for the upstream node.
_____
| |
| C |
_____ /| |\ _____ _____
| | / |_____| \ | | | |
| B |/ \| E | | H |
_____ /| |\ _____ /| |\ _____ /| |
| | / |_____| \ | | / |_____| \ | | / |_____|
| A |/ \| D |/ \| G |/
| | | |\ _____ | |
|_____| |_____| \ | | |_____|
\| F |
| |
|_____|
Figure 2: Distributed Trust Based Network
The flow under discussion will be that of a call originating at A
destined for H (A and H are User Agents). The example flow will
traverse proxies B, C, E and G where following the discussion above,
node B is authoritative (with respect to A) and nodes C, E and G are
transit proxies in the flow. The flexibility of the distributed
approach is readily apparent as this flow may represent a peer to
peer network, a circle of trust network or a centralized provider
network.
The advantage of a decentralized network is that nodes can see from
where the signaling arrives; as well communicate their opinions on
both the signaling data they have acquired, and the peers who are the
Schwartz, et al. Expires December 28, 2006 [Page 9]
Internet-Draft SPIT Prevention using SAML June 2006
source of this data.
The purpose of this flow is to show the security attributes that can
be asserted by the authoritative node B, and those that can be
asserted by all transit nodes including B, C, E and G. For this
reason, SIP flow items such as challenges or responses have been
omitted.
Note that this flow does not address the issue of policy, namely,
what action any node may take in response to receiving of these
attributes. Policy and schema are negotiated out-of-band.
Assertions are made along the flow. Each node is responsible for
enforcement of the policy. All that is addressed is what can
potentially be passed downstream. For this reason, the receiving
domain administrator (G) is shown forwarding the attributes to the
receiving UA (H) for its policy based decision as to whether or not
to accept the incoming INVITE
Schwartz, et al. Expires December 28, 2006 [Page 10]
Internet-Draft SPIT Prevention using SAML June 2006
+---+ +---+ +---+ +---+ +---+ +---+
| A | | B | | C | | E | | G | | H |
+---+ +---+ +---+ +---+ +---+ +---+
| | | | | |(step)
| INVITE | | | | |
|---------->| | | | | (1)
| | | | | |
| | INVITE | | | |
| |---------->| | | |
| | IStrength | | | |
| | CostOCall | | | | (2a)
| | | | | |
| | callsPMin | | | |
| | ASR | | | | (2b)
| | sameLngth | | | |
| | | | | |
| | SSuspect | | | | (2c)
| | | | | |
| | | INVITE | | |
| | |---------->| | |
| | | callsPMin | | |
| | | ASR | | |
| | | sameLngth | | |
| | | | | |
| | | SSuspect | | |
| | | | | |
| | | | INVITE | |
| | | |---------->| |
| | | | callsPMin | |
| | | | ASR | |
| | | | sameLngth | |
| | | | | |
| | | | SSuspect | |
| | | | | |
| | | | | INVITE |
| | | | |---------->|
| | | | | callsPMin |
| | | | | ASR |
| | | | | sameLngth |
| | | | | |
| | | | | SSuspect |
Figure 3: Example flow
The flow starts (1) by the sending UA (A) sending an INVITE to its
domain administrator or service provider (B). Note that in the case
of peer to peer network this communication can be to a Super Node
responsible for the sending UA. As discussed above, node B is both
Schwartz, et al. Expires December 28, 2006 [Page 11]
Internet-Draft SPIT Prevention using SAML June 2006
"authoritative" in that it has a lot of "type" information about A,
and "flow" in that it knows previous flow or dynamic information
about this peer. B adds the two kinds of information: "type" info
(2a) and "flow" info (2b) coupled with an overall indication of SPIT
(3c). Note that C, E and G add only the "flow" and overall
information in their messages.
This is what would be received by H
INVITE sip:jeremyb@192.168.0.101 SIP/2.0
Via:SIP/2.0/UDP10.10.10.1:5060;branch=z9hG4bK00003300;received=192.
168.0.106
Max-Forwards: 70
Contact: "330"<sip:user@BHOME2>
To: Receiver <sip:jeremyb@192.168.0.101> From: 330 <sip:user@BHOME2>;
tag=330 Call-ID: 0@BHOME2 CSeq: 1 INVITE Expires: 1200
Assertion:
<saml:Assertion>
<saml:Subject>
<saml:NameID>
g@G.com
<saml:SubjConf>
<saml:SubjConfData>
<ds:KeyInfo>...
<saml:AttrStatement>
ASR=xxx
Assertion:
<saml:Assertion>
<saml:Subject>|
<saml:NameID>
e@Z.com
<saml:SubjConf>
<saml:SubjConfData>
<ds:KeyInfo>...
<saml:AttrStatement>
ASR=xxx
Content-Type: application/sdp Content-Length: 126
v=0 o=330 330 330 IN IP4 BHOME2 s=Session
SDP c=IN IP4 192.168.0.106 t=0 0 m=audio 9876 RTP/AVP 0
a=rtpmap:0 PCMU/8000
Figure 4: INVITE example
Schwartz, et al. Expires December 28, 2006 [Page 12]
Internet-Draft SPIT Prevention using SAML June 2006
6. Filtering and Call Blocking
The responsibility for filtering or blocking calls can belong to
different elements in the call flow and may depend on various
factors. To one extreme, the terminating end user may have a device
configured to reject calls with certain characteristics, forward
other calls to voice mail, and only pass through the most secure
calls. More likely, however, is as discussed above for MI(T) AS to
contain the policy information to make this decision and strip the
information out of the message.
A typical implementation would have the Security Profile settings as
follows (or combination thereof):
o Strip SAML message (if yes then the SAML would be stripped)
o Reject call if IdentityStrength < n
o Reject call if CostOfCall < n
o Reject call if SPITSuspected > n
o Reject call if CallCenter is not 0
The ability to specify a language to describe these authorization
rules are described in [I-D.froment-sipping-spit-authz-policies].
7. Security Considerations
This document extends the functionality of SAML usage in SIP for a
specific scenario, namely SPAM for IP As such, the security
considerations discussed in [I-D.ietf-sip-saml] are applicable for
this document.
8. IANA Considerations
IANA is requested to register seven URNs, to create seven registries
and to register a number of tokens for each registry.
This document instructs IANA to create a registry named SPIT-
Attributes with seven sub-registries. The sub-registries are:
o IdentityStrength
o CostOfCall
o CallRate
o CallCompletionSuccessRate
o CallDurationConsistancy
o SpitSuspect
IANA is requested to register tokens for each of these sub-
registries. The respective tokens are listed in Section 5.1 for the
seven sub-registries listed above.
Schwartz, et al. Expires December 28, 2006 [Page 13]
Internet-Draft SPIT Prevention using SAML June 2006
Following the policies outline in RFC 2434 [RFC2434], new tokens are
assigned after Expert Review by the Expert Reviewer appointed by the
IESG. The same procedure applies to updates of tokens within the
registry and to deleting tokens from the registry.
The Expert's support of IANA will include providing IANA with the new
token(s) when the update is provided only in the form of a schema,
and providing IANA with the new schema element(s) when the update is
provided only in the form of a token.
Each registration must include the name of the token and a brief
description similar to the ones offered in for the initial
registrations contained this document:
Token Identifier: Identifier of the token.
Description: Brief description indicating the meaning of the token,
including one or more examples where the term encompasses several
more precise terms.
8.1. SPIT IdentityStrength Namespace Registration
URI: urn:ietf:params:xml:ns:spit:IdentityStrength
Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Schwartz, et al. Expires December 28, 2006 [Page 14]
Internet-Draft SPIT Prevention using SAML June 2006
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>SPIT IdentityStrength Namespace</title>
</head>
<body>
<h1>Namespace for SPIT IdentityStrength</h1>
<h2>urn:ietf:params:xml:ns:spit:IdentityStrength</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
Figure 5: XML example
8.2. SPIT CostOfCall Namespace Registration
URI: urn:ietf:params:xml:ns:spit:CostOfCall
Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Schwartz, et al. Expires December 28, 2006 [Page 15]
Internet-Draft SPIT Prevention using SAML June 2006
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>SPIT CostOfCall Namespace</title>
</head>
<body>
<h1>Namespace for SPIT CostOfCall</h1>
<h2>urn:ietf:params:xml:ns:spit:CostOfCall</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
Figure 6: XML example
8.3. SPIT CallRate Namespace Registration
URI: urn:ietf:params:xml:ns:spit:CallRate
Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Schwartz, et al. Expires December 28, 2006 [Page 16]
Internet-Draft SPIT Prevention using SAML June 2006
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>SPIT CallRate Namespace</title>
</head>
<body>
<h1>Namespace for SPIT CallRate</h1>
<h2>urn:ietf:params:xml:ns:spit:CallRate</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
Figure 7: XML example
8.4. SPIT CallCompletionSuccessRate Namespace Registration
URI: urn:ietf:params:xml:ns:spit:CallCompletionSuccessRate
Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Schwartz, et al. Expires December 28, 2006 [Page 17]
Internet-Draft SPIT Prevention using SAML June 2006
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>SPIT CallCompletionSuccessRate Namespace</title>
</head>
<body>
<h1>Namespace for SPIT CallCompletionSuccessRate</h1>
<h2>urn:ietf:params:xml:ns:spit:CallCompletionSuccessRate</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
Figure 8: XML example
8.5. CallDurationConsistancy Namespace Registration
URI: urn:ietf:params:xml:ns:spit:CallDurationConsistancy
Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Schwartz, et al. Expires December 28, 2006 [Page 18]
Internet-Draft SPIT Prevention using SAML June 2006
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>SPIT CallDurationConsistancy Namespace</title>
</head>
<body>
<h1>Namespace for SPIT CallDurationConsistancy</h1>
<h2>urn:ietf:params:xml:ns:spit:CallDurationConsistancy</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
Figure 9: XML example
8.6. SPIT SpitSuspect Namespace Registration
URI: urn:ietf:params:xml:ns:spit:SpitSuspect
Registrant Contact: IETF SIPPING Working Group, Hannes Tschofenig
(Hannes.Tschofenig@siemens.com).
Schwartz, et al. Expires December 28, 2006 [Page 19]
Internet-Draft SPIT Prevention using SAML June 2006
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>SPIT SpitSuspect Namespace</title>
</head>
<body>
<h1>Namespace for SPIT SpitSuspect</h1>
<h2>urn:ietf:params:xml:ns:spit:SpitSuspect</h2>
<p>See <a href="[URL of published RFC]">RFCXXXX
[NOTE TO IANA/RFC-EDITOR:
Please replace XXXX with the RFC number of this
specification.]</a>.</p>
</body>
</html>
END
Figure 10: XML example
9. Acknowledgments
The authors would like to thank Jon Peterson, Douglas Sicker, Yariv
Trabelsi ,Brocha Straus and Jeremy Barkan for their comments and
suggestions.
10. References
10.1. Normative References
[I-D.ietf-sip-saml]
Tschofenig, H., "SIP SAML Profile and Binding",
draft-ietf-sip-saml-00 (work in progress), June 2006.
[I-D.ietf-sipping-spam]
Rosenberg, J., "The Session Initiation Protocol (SIP) and
Spam", draft-ietf-sipping-spam-02 (work in progress),
March 2006.
Schwartz, et al. Expires December 28, 2006 [Page 20]
Internet-Draft SPIT Prevention using SAML June 2006
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[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.
10.2. Informative References
[I-D.froment-sipping-spit-authz-policies]
Froment, T., "Authorization Policies for Preventing SPIT",
draft-froment-sipping-spit-authz-policies-00 (work in
progress), February 2006.
[I-D.ietf-sip-identity]
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-06
(work in progress), October 2005.
Schwartz, et al. Expires December 28, 2006 [Page 21]
Internet-Draft SPIT Prevention using SAML June 2006
Authors' Addresses
David Schwartz
Kayote Networks
Malcha Technology Park
Jerusalem, 96951
Israel
Email: david.schwartz@kayote.com
Baruch Sterman
Kayote Networks
Malcha Technology Park
Jerusalem, 96951
Israel
Email: baruch.sterman@kayote.com
Eli Katz
XConnect Global Networks
12 York Gate
London, London NW1
UK
Email: eli.katz@xconnect.net
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Schwartz, et al. Expires December 28, 2006 [Page 22]
Internet-Draft SPIT Prevention using SAML June 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Schwartz, et al. Expires December 28, 2006 [Page 23]