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: 1 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" To: Receiver From: 330 ; tag=330 Call-ID: 0@BHOME2 CSeq: 1 INVITE Expires: 1200 Assertion: g@G.com ... ASR=xxx Assertion: | e@Z.com ... 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 SPIT IdentityStrength Namespace

Namespace for SPIT IdentityStrength

urn:ietf:params:xml:ns:spit:IdentityStrength

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

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 SPIT CostOfCall Namespace

Namespace for SPIT CostOfCall

urn:ietf:params:xml:ns:spit:CostOfCall

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

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 SPIT CallRate Namespace

Namespace for SPIT CallRate

urn:ietf:params:xml:ns:spit:CallRate

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

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 SPIT CallCompletionSuccessRate Namespace

Namespace for SPIT CallCompletionSuccessRate

urn:ietf:params:xml:ns:spit:CallCompletionSuccessRate

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

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 SPIT CallDurationConsistancy Namespace

Namespace for SPIT CallDurationConsistancy

urn:ietf:params:xml:ns:spit:CallDurationConsistancy

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

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 SPIT SpitSuspect Namespace

Namespace for SPIT SpitSuspect

urn:ietf:params:xml:ns:spit:SpitSuspect

See RFCXXXX [NOTE TO IANA/RFC-EDITOR: Please replace XXXX with the RFC number of this specification.].

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]