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]