One document matched: draft-schwartz-sipping-spit-saml-00.txt
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" <sip:alice@mio.com>;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.
<Assertion xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns="urn:oasis:names:tc:SAML:1.0:assertion"
...
<AttributeStatement>
<Subject>
<NameIdentifier>securityAttributes</NameIdentifier>
<SubjectConfirmation>
<ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:bearer
</ConfirmationMethod>
</SubjectConfirmation>
</Subject>
<Attribute
AttributeName="IdentityStrength"
AttributeNamespace="http://mio.com">
Schwartz, et al. Expires April 20, 2006 [Page 7]
Internet-Draft SPIT Prevention using SAML October 2005
<AttributeValue>4</AttributeValue>
</Attribute>
<Attribute
AttributeName="CostOfCall"
AttributeNamespace="http://mio.com">
<AttributeValue>1</AttributeValue>
</Attribute>
<Attribute
AttributeName="ConnectionSecurity"
AttributeNamespace="http://mio.com">
<AttributeValue>3</AttributeValue>
</Attribute>
<Attribute
AttributeName="CallCenter"
AttributeNamespace=http://mio.com>
<AttributeValue>1</AttributeValue>
</Attribute>
<Attribute
AttributeName="SPITSuspect"
AttributeNamespace="http://mio.com">
<AttributeValue>0</AttributeValue>
</Attribute>
<Attribute
AttributeName="IdentityAssertion"
AttributeNamespace="http://mio.com">
<AttributeValue>1</AttributeValue>
</Attribute>
<Attribute
AttributeName="AssertionStrength"
AttributeNamespace="http://mio.com">
<AttributeValue>0</AttributeValue>
</Attribute>
</AttributeStatement>
</Assertion>
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:
<Attribute
AttributeName="IdentityStrength"
AttributeNamespace="http://mio.com">
<AttributeValue>2
</AttributeValue>
</Attribute>
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]
| PAFTECH AB 2003-2026 | 2026-04-22 23:59:46 |