SIPPING D. Schwartz Internet-Draft B. Sterman Expires: April 20, 2006 Kayote Networks E. Katz XConnect Global Networks H. Tschofenig Siemens October 17, 2005 SPAM for Internet Telephony (SPIT) Prevention using the Security Assertion Markup Language (SAML) draft-schwartz-sipping-spit-saml-00.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 April 20, 2006. Copyright Notice Copyright (C) The Internet Society (2005). 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 April 20, 2006 [Page 1] Internet-Draft SPIT Prevention using SAML October 2005 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Federation of Member Islands . . . . . . . . . . . . . . . 4 3.3. Security Attributes . . . . . . . . . . . . . . . . . . . 5 4. Example Message Flow . . . . . . . . . . . . . . . . . . . . . 5 4.1. Preliminary Considerations . . . . . . . . . . . . . . . . 5 4.2. Call Flow . . . . . . . . . . . . . . . . . . . . . . . . 6 5. Details of Security Information . . . . . . . . . . . . . . . 9 5.1. Security Attributes . . . . . . . . . . . . . . . . . . . 9 5.1.1. IdentityStrength (s) . . . . . . . . . . . . . . . . . 10 5.1.2. CostOfCall (d) . . . . . . . . . . . . . . . . . . . . 10 5.1.3. IdentityAssertion (d) (optional) . . . . . . . . . . . 11 5.1.4. AuthenticationOfAccountOpening (s) . . . . . . . . . . 11 5.1.5. SPITSuspect (d) . . . . . . . . . . . . . . . . . . . 12 5.1.6. CallCenter (d) . . . . . . . . . . . . . . . . . . . . 12 5.1.7. AssertionStrength (d) . . . . . . . . . . . . . . . . 12 5.2. Using SAML to Embed Security Attributes . . . . . . . . . 13 6. Filtering and Call Blocking . . . . . . . . . . . . . . . . . 13 7. Additional Impacts . . . . . . . . . . . . . . . . . . . . . . 14 7.1. Additional Network Elements in Flow . . . . . . . . . . . 14 7.2. Encryption/Decryption Delay . . . . . . . . . . . . . . . 14 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.1. Security Header . . . . . . . . . . . . . . . . . . . . . 15 11.2. Call Rejection Response Code . . . . . . . . . . . . . . . 15 11.3. Future Evolving Parameters . . . . . . . . . . . . . . . . 15 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . . 16 12.2. Informative References . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19 Schwartz, et al. Expires April 20, 2006 [Page 2] Internet-Draft SPIT Prevention using SAML October 2005 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 generally not verified by 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.tschofenig-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 intentially only addresses a small subset of the entire solution space, i.e., issues related to the authenticity of the caller, the authenticity of the trusted party making security assertions, and of the integrity of the signaling (including security information). 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: End Users (EU): SIP User Agents or other SIP based edge devices managed by callers' domain or MI Schwartz, et al. Expires April 20, 2006 [Page 3] Internet-Draft SPIT Prevention using SAML October 2005 Member Islands (MI): Aggregating organization responsible for a set of EUs such as VoIP service provider or enterprises. MI's consist of a SIP proxy and an Authentication Service Authentication Service (AS): Entity responsible for the encoding/decoding of security information verified by SIP proxy and other security attributes associated with a given call. Trust Anchor (TA): Entity serving as certificate agency as well as propegator of security attribute information to localized Authenticcation Services. 3. Overview 3.1. Goals The three goals of this document are to: 1. Introduce an authenticated identity mechanism for the transmission of identity information as a first measure of protection against SPIT. 2. Present an 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/ parties to determine the relative likelihood of each call with respect to SPIT. 3. Identify a suitable method of passing the above-mentioned information within a SIP message. 3.2. Federation of Member Islands The underlying assumption behind this proposal is that there be a federation of which the member islands wishing to communicate are members. Without this constraint, there is no way to 'trust' any information being exchanged between members. Note that there is no requirement for actual SIP traffic to pass via any centralized point. The centralized point or TA, is needed only for the following two functions: o To serve as the Certificate service or agency for local MI Authentication Services Schwartz, et al. Expires April 20, 2006 [Page 4] Internet-Draft SPIT Prevention using SAML October 2005 o To keep static security profile information originating at localized Authentication Servers honest. Static information is defined as information about the MI that applies to all calls from the MI (such as that this is a free provider). The goal is for the originating MI to pass information to terminating MI about the nature of the call to the in a manner that the authenticity of this information can be trusted. 3.3. Security Attributes There is other information pertaining to a given call, identity information notwithstanding, that is available to the originating Authentication Service that can and should be passed to a termination MI for a given call. This information consists to a large part of parameters or attributes that give additional indications of potential SPIT calls. An initial set of these attributes is given in Section 5 and includes parameters such as 'IdentityStrength' indicating the level of difficulty in obtaining this identity or 'CostOfCall' indicating whether or not there is a charge associated with this call and so forth. These security attributes are combined with the identity and asserted by a third party and aim to improve the probability of SPIT detection. The attributes can be broken down to o static, which applies to characteristics of the MI in general and o dynamic, which applies on a call by call basis. The combination of static and dynamic attributes make up the security profile, which will be presented to the terminating MI on a call by call basis. The static attributes will be given as an input to the local Authentication Service by the MI. Since the Authentication Service makes statements about itself it is necessary to contact a Trust Anchor each time when new credentials are obtained. 4. Example Message Flow 4.1. Preliminary Considerations Security and identity information relating to a call is transferred between the caller's provider (originating MI, henceforth MI(O)) and the callee's provider (terminating MI, henceforth MI(T)). MI(O) consists of a SIP proxy responsible for authenticating the caller, for authorizing it, for routing the call to the desired Schwartz, et al. Expires April 20, 2006 [Page 5] Internet-Draft SPIT Prevention using SAML October 2005 communication endpoint, and an Authentication Service Element (AS) responsible for crafting an assertion with security related information into the outgoing message. 4.2. Call Flow To illustrate the core idea presented in this document an example SIP call flow is described in Figure 2. Please note the following points: o Only the initial call signaling is shown o Assumption is that the call is accepted on the terminating side (by the SIP proxy of the receiving party) o Only relevant SIP headers are shown (for editorial reasons) o The SIP proxy and the Authentication Service are logical entities that might be co-located at a single physical entity The Authentication Service adding an assertion to a SIP call relies on some amount of static information to generate the security profile to add to the call. The protocol used for accumulating this information is not shown in the message flow below. The protocol interaction starts with the SIP User Agent to outbound SIP proxy MI(O) communication. The SIP User Agent 'Alice', acts as an Originator of the call, places a call via its VoIP service provider MI(O) to another SIP User Agent of a different VoIP service provider MI(T). As per [I-D.ietf-sip-identity] the first hop between the end user and MI(O) MUST be over TLS in order to completely eliminate identity theft. Via: SIP/2.0/TLS 1.1.1.1;branch=z9hG4bK-123 // note the TLS From: "Alice" ;tag=9802748 The SIP proxy at the MI(O) authenticates the user (for example, using Digest Authentication) and further verifies (based on information available at MI(O)) that the Identity passed in the 'From' header is associated with this username. Typically, this step will assert that the Caller ID being presented is actually registered to the authenticating user, thus eliminating the possibility of identity theft, i.e., one user presenting another user's Caller ID. Schwartz, et al. Expires April 20, 2006 [Page 6] Internet-Draft SPIT Prevention using SAML October 2005 MI(O) MI(T) +---------------------+ +---------------------+ SIP | +-----+ +-------+ | SIP | +-------+ +-----+ | SIP | | SIP | | Auth | | | | Auth | | SIP | | +----->|Proxy|-->|Service|-------->|Service|-->|Proxy|------+ | | | X | | X | | | | Y | | Y | | | | | +-----+ +-------+ | | +-------+ +-----+ | | | +---------------------+ +---------------------+ | | | | TLS and TLS and | | SIP Digest SIP Digest | | | | | v v +-----------+ SIP and RTCP +-----------+ |SIP | <--------------------------------------> |SIP | |User Agent | RTP |User Agent | |Alice | <======================================> |Bob | +-----------+ +-----------+ Legend: <--->: Signaling Traffic <===>: Data Traffic Figure 2: Call Flow Once authenticated, MI(O) AS creates a SAML assertion using both static information about the MI and dynamic information about the call and encodes these security attributes as well as the identity into this assertion. The code snippets below show only part of the SAML assertion that was created. securityAttributes urn:oasis:names:tc:SAML:1.0:cm:bearer Schwartz, et al. Expires April 20, 2006 [Page 7] Internet-Draft SPIT Prevention using SAML October 2005 4 1 3 1 0 1 0 Next, the SAML assertion MUST be associated with this specific SIP message exchange by computing a hash over the canonical form of several headers and all the bodies. This hash is included in the SAML assertion and finally the SAML assertion is digitally signed. The details of this computation are described in [I-D.tschofenig-sip- saml] and borrowed from [I-D.ietf-sip-identity]. A reference to the SAML assertion, called SAML artifact, is then added to the SIP header, as described in [I-D.tschofenig-sip-saml]. MI(O) sends the INVITE to the terminating MI (MI(T)). Since the assertion is bound to this specific SIP message exchange and signed by MI(O), it is not necessary to establish a secure connection between the communicating SIP proxies although this is likely to be Schwartz, et al. Expires April 20, 2006 [Page 8] Internet-Draft SPIT Prevention using SAML October 2005 available. When MI(T) receives the SIP message it needs to fetch the assertion from MI(0) using the attached artifact. Subsequently, the AS makes a decision whether to accept, reject or divert the SIP message based on the embedded security information. Since standard User Agents, Proxies, or other SIP entities may not (and currently do not) provide support of the extension described in this document, the AS at MI(T) may strip off that information before passing on to MI(T) SIP proxy. As more devices and applications support this security standard, information can be pushed further out to the edge and the decision making process, likewise, can be implemented further along the call path. It may be the ultimate goal to allow each user to set his/her own device to accept, reject, or divert calls according to the information provided. 5. Details of Security Information The security attributes proposed here are embedded within a SAML body. A SAML artifact that is a reference of the SAML assertion is added to the SIP header of the message, as described in [I-D.tschofenig-sip-saml]. 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. 5.1. Security Attributes As discussed in the previous section, in addition to identity information, the AS must also add a security profile to each call. This profile is comprised of other security related information that the AS knows about the call or the caller (dynamic), or the MI(O) (dynamic). This information can be obtained offline in researching the Member Island's policies (based on its own analysis and/or submission from the MI), or it may be determined by inspecting call patterns or other methods. The following is an initial list of attributes which may help determine the likelihood of a call being SPIT. 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 Schwartz, et al. Expires April 20, 2006 [Page 9] Internet-Draft SPIT Prevention using SAML October 2005 list of security attributes will likewise be dynamic and follow the trends in SPIT and fraud detection. The method of passing the information as presented in this paper is open and flexible, and therefore should be able to accommodate new parameters and modifications of existing ones. Some of this information is retrieved from an MI profile filled in at MI signup. Other information is either calculated on the fly, by the localized AS, or part of an additional profile that the TA may keep on each MI that may be dynamically downloaded to Authentication Service. 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. Next to each attribute a designation of (s) for static or (d) for dynamic is added to designate the type of attribute. 5.1.1. IdentityStrength (s) This parameter relates to the relative difficulty customers or users have in obtaining identities or user accounts at MI(O) - in other words the amount of trust that can be placed in the user's identity. In the case of an 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 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 parameter are: 0 - Unknown 1 - Free service 2 - Paying service (e.g. Billing Address or Payment method verified) 3 - Physical premises verified / Enterprise / PSTN based 4 - User had to present a passport 5.1.2. CostOfCall (d) This parameter indicates the charges associated with a call. It is assumed that paying calls are less likely to be SPIT. The values for this parameter are: Schwartz, et al. Expires April 20, 2006 [Page 10] Internet-Draft SPIT Prevention using SAML October 2005 0 - Unknown 1 - Free 2 - Flat rate (subscription for unmetered dialing) 3 - Per minute (or included in a finite bucket of minutes) [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.] 5.1.3. IdentityAssertion (d) (optional) This parameter describes the method which is used to assert the Identity. In architectures where the TA is responsible for routing calls between MIs (such as business cases requiring complete call demarcation thereby transforming TA into B2BUA), the TA may have information that will allow verification that a given user does in fact belong to the MI(O) domain. (For example, if the Identity of a user is the Caller ID, and that is also the DID by which calls are routed to the user's MI.) In that case, there can be some level of assertion regarding the Identity even if the originating MI does not enforce any policy of cross checking the Identity with the secure username obtained from Digest Authentication. Furthermore, the TA may determine that a call coming from an MI does not belong to the set of users in that MI's domain. It is assumed that calls with higher values are less likely to be SPIT calls. The values for this parameter are: 0 - Violation of user space detected. 1 - Unknown - that is if a call is presented without any Identity information (e.g. an anonymous call originating at on the PSTN). 2 - Identity asserted by the TA based on its belonging to an originating MI's domain. 3 - Identity asserted by the MI(O) as uniquely associated with and authenticated user. 5.1.4. AuthenticationOfAccountOpening (s) This parameter indicates the existence of a mechanism that verifies new accounts being opened at the MI. The values for this parameter are: Schwartz, et al. Expires April 20, 2006 [Page 11] Internet-Draft SPIT Prevention using SAML October 2005 0 - No validation of new account (could be machine opened) 1 - Turing Test (human needed to open new account) 2 - Credit card or other form of verifiable identification 3 - Passport was presented for verification 5.1.5. SPITSuspect (d) This parameter is an a score assigned to the call by the MI(O) AS, based on examining the call records associated with this user to determine the likelihood of it being SPIT. There are a number of examples of tests that can be applied to calls or to end users that may raise flags regarding that user's calls. A sample list of might be: (using a combination of tests below) o Some number n of calls per minute from one user o Small percentage of dialed/answered calls by user o Small percentage of repeat/distinct numbers dialed by user o n calls of the same length o Calls to sequential destination numbers The values for this parameter are 0-9 with 9 being the most likely that the call is SPIT. 5.1.6. CallCenter (d) In the case where the SPITSuspect value is a high number (e.g., due to a large number of outbound calls), this could still be a legitimate user. The MI responsible to verify that the particular EU is in fact a commercial outbound call center (which would account for the high SPITSuspect value). To facilitate this identification, the MI(O) can register the user and the call can be identified accordingly. The values for this parameter are: 0 - Unknown 1 - Known to be a call center, but not trusted, (e.g. call center may make unsolicited calls and/or may not respect Do-Not-Call databases). 2 - Known to be a fully trusted call center, (e.g. no unsolicited calls and either the EU or the MI filters calls on all available DNC databases). 5.1.7. AssertionStrength (d) This parameter is an overall objective weighted score that MI(O) AS assigns to the call based on all the above values. In this way, less sophisticated decisions can be made based solely on the value of this Schwartz, et al. Expires April 20, 2006 [Page 12] Internet-Draft SPIT Prevention using SAML October 2005 parameter, whereas more detailed information is also available. The values for this parameter are: 0 - Low security level 1 - Medium security level 2 - High level of security Note: Since this value is an overall rating of the call, it may be the most useful for determining whether to reroute or block a call. That determination may be made by the termination IP-PBX, Proxy, or even User Agent. These elements may not be SAML aware, or may sit behind a firewall that strips out the SAML structure. There may be a need to pass this value in the SIP header (possibly Warning header), instead of embedded within a SAML message. Please refer to Section 11 for a discussion on open issues. 5.2. Using SAML to Embed Security Attributes Security attributes are formatted as descriptor=value pairs and passed to the terminating MI using the Security Markup Language - SAML. The actual descriptor=value pairs are flexible and can adapt as security requirements evolve or circumstances change. Integration of SAML and SIP is described in [RFC3261]. While attributes can be passed either as a SAML-Payload header or as a SAML body, this proposal will assume that the SAML body approach is used. Following is a code snippet for one such attribute: 2 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. Schwartz, et al. Expires April 20, 2006 [Page 13] Internet-Draft SPIT Prevention using SAML October 2005 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 AuthenticationMethod < n o Reject call if IdentityAssertion < n o Reject call if ConnectionSecurity < n o Reject call if SPITSuspected > n o Reject call if CallCenter <> 0 o Reject call if AssertionStrength < n 7. Additional Impacts 7.1. Additional Network Elements in Flow As can be seen by the flow presented in section 3, there are now two AS elements participating in each call. While this may seem inhibiting, the main issue will be the delay associated with encoding and decoding of information associated with Authentication Service in general and not the mere presence of two additional hops in the flow. 7.2. Encryption/Decryption Delay Encryption/Decryption is the main performance issue. [I-D.ietf-sip- identity] Provides specific performance metrics in terms of key size and resultant encryptions/second. Clearly this issue needs to be carefully addressed using various load balancing techniques in order to mitigate the problem. 8. 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.tschofenig-sip-saml] are applicable for this document as well. Since, SAML-SIP borrows ideas from SIP Identity [I-D.ietf-sip-identity] with respect to the idea of binding a SIP signaling exchange to an assertion the security considerations of [I-D.ietf-sip-identity] are applicable to this document. [Editor's Note: A comparison with other SPAM prevention techniques from a security point of view will be provided in a future version of this document.] Schwartz, et al. Expires April 20, 2006 [Page 14] Internet-Draft SPIT Prevention using SAML October 2005 9. IANA Considerations A future version of this document will provide IANA considerations. 10. Acknowledgments The authors would like to thank Jon Peterson, Douglas Sicker, Yariv Trabelsi and Brocha Straus for their comments and suggestions. 11. Open Issues During our work the following open issues have been identified. 11.1. Security Header It is likely that SIP-based firewalls understand SAML, but the Proxy/ IP-PBX/SUA does not. The ability to block or reroute calls based on SPIT likeliness, however, may be something that can (and should) be implemented by those elements (that are already responsible for decisions like call forwarding, filtering, etc.). In order to make the AssertionStrength variable available to those downstream elements, it will have to be placed in the SIP header. That extension will have to be defined. Adding this summary information as a header, and having the detailed SAML information available via a referenced URL, will also shorten the message and allow for UDP transmission. 11.2. Call Rejection Response Code In the event that a SIP-based firewall (or TA in the case where demarcation is used in conjunction with hosted SPIT filtering) decides to reject the call based on the security information available, what error code should be returned? The 428 'Use Authenticated Identity' is probably not applicable in this case. Perhaps another code, e.g. 438 'Rejected for Security Reasons' can be defined. 11.3. Future Evolving Parameters As SPIT generators and IP telemarketers increase their technological savvy, the protectors of privacy and VoIP service providers will have to improve their own arsenal of defensive applications. There are already a number of suggestions including Turing Tests and other clever means of weeding out legitimate calls. In the ongoing battle, there will most likely be a number of methods employed and they will evolve and change. The method described here for transmitting Schwartz, et al. Expires April 20, 2006 [Page 15] Internet-Draft SPIT Prevention using SAML October 2005 security related information on a call by call basis is flexible and can accommodate new tests or data by adding different parameters. As described in the main part of the document the relationship between the TA and the MIs is subject for further discussion. The fact that a SIP proxy MUST NOT add an assertion to the body of the SIP message leaves the protocol designers with two choices: o Add a SAML artifact to the SIP header. This requires the verifying party to fetch the SAML assertion from the asserting party first. This introduces call setup delays. o The Asserting party returns an error message with the SAML assertion to the end host and the end host initiates the call again (with the SAML assertion in the SIP body). This mechanism requires that the SIP User Agent understands the SIP-SAML extensions in order to perform this protocol exchange. A call setup delay is introduced with this approach as well. The authors have decided to use SAML artifacts. 12. References 12.1. Normative References [I-D.ietf-sipping-spam] Rosenberg, J., "The Session Initiation Protocol (SIP) and Spam", draft-ietf-sipping-spam-01 (work in progress), July 2005. [I-D.tschofenig-sip-saml] Tschofenig, H., "Using SAML for SIP", draft-tschofenig-sip-saml-04 (work in progress), July 2005. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [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. 12.2. Informative References [I-D.ietf-sip-identity] Peterson, J. and C. Jennings, "Enhancements for Authenticated Identity Management in the Session Schwartz, et al. Expires April 20, 2006 [Page 16] Internet-Draft SPIT Prevention using SAML October 2005 Initiation Protocol (SIP)", draft-ietf-sip-identity-05 (work in progress), May 2005. Schwartz, et al. Expires April 20, 2006 [Page 17] Internet-Draft SPIT Prevention using SAML October 2005 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 April 20, 2006 [Page 18] Internet-Draft SPIT Prevention using SAML October 2005 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 (2005). 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 April 20, 2006 [Page 19]