SIP H. Tschofenig
Internet-Draft Siemens
Expires: April 25, 2005 J. Peterson
NeuStar, Inc.
J. Polk
Cisco
D. Sicker
CU Boulder
M. Tegnander
Siemens
October 25, 2004
Using SAML for SIP
draft-tschofenig-sip-saml-01.txt
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. 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 become aware will be disclosed, in accordance with
RFC 3668.
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 25, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
Tschofenig, et al. Expires April 25, 2005 [Page 1]
Internet-Draft Using SAML for SIP October 2004
This document describes how to use the Security Assertion Markup
Language (SAML) to offer trait-based authorization. As such, it
provides an alternative to existing authorization mechanisms for SIP.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 5
4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . 6
4.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 6
4.2 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.3 Request/Response Protocol . . . . . . . . . . . . . . . . 7
4.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 8
5. Assertion Handling Models . . . . . . . . . . . . . . . . . 9
6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1 Network Asserted Identities . . . . . . . . . . . . . . . 14
6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 16
6.3 PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 17
6.4 Compensation using SIP and SAML . . . . . . . . . . . . . 18
7. SIP-SAML Extension . . . . . . . . . . . . . . . . . . . . . 20
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 21
9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 23
10. Security Considerations . . . . . . . . . . . . . . . . . . 24
10.1 Stolen Assertion . . . . . . . . . . . . . . . . . . . . 24
10.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . 24
10.3 Forged Assertion . . . . . . . . . . . . . . . . . . . . 24
10.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . 25
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28
14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
15.1 Normative References . . . . . . . . . . . . . . . . . . . 32
15.2 Informative References . . . . . . . . . . . . . . . . . . 32
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . 36
Tschofenig, et al. Expires April 25, 2005 [Page 2]
Internet-Draft Using SAML for SIP October 2004
1. Introduction
This document proposes a method for using the Security Assertion
Markup Language (SAML) in collaboration with SIP to acommodate richer
authorization mechanisms and enable trait- based authorization where
you are authenticated using roles or traits instead of identity. A
motivation for trait based authorization and some scenarios are
presented in [I-D.ietf-sipping-trait-authz].
Security Assertion Markup Language
(SAML)[I-D.saml-tech-overview-1.1-03] is an XML extension for
security information exchange that is being developed by OASIS. SAML
enables users to gain access to multiple website resources without
having to re-authenticate every time the domain changes. The first
authentication would be transferred to subsequent domains using SAML.
To provide trait-based authorization a few solutions are possible:
authorization certificates, SPKI or extensions to the authenticated
identity body [I-D.ietf-sip-authid-body]. The authors selected SAML
due to the amount of work done in the area of SAML which provides
some assurance that this technology is mature enough.
Tschofenig, et al. Expires April 25, 2005 [Page 3]
Internet-Draft Using SAML for SIP October 2004
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 SIP entity 'Authentication Service' was introduced with
[I-D.ietf-sip-identity].
The Authentication Service is the entity that authenticates and
authorizes a user and creates an Assertion. This entity is the
equivalent of the asserting party in the SAML terminology.
For terminology related to SAML the reader is referred to
[I-D.saml-tech-overview-1.1-03].
Tschofenig, et al. Expires April 25, 2005 [Page 4]
Internet-Draft Using SAML for SIP October 2004
3. Goals and Non-Goals
This document tries to accomplish the following goals:
o This document defines how SAML assertions are carried in the SIP.
As such, the usage of SAML Assertions within SIP can be seen as a
SAML profile.
o The requirements and scenarios defined in
[I-D.ietf-sipping-trait-authz] are compared to the solution
described in this document by utilizing SAML assertions.
The following issues are outside the scope of this document:
o The configuration of the Authentication Service in order to attach
certain assertions is outside the scope of this specification and
might depend on the environment where SIP is used. To avoid
restricting the functionality of SIP either as an in-band or an
out-of-band mechanism, it can be defined to trigger the inclusion
of SAML assertions. SAML itself provides mechanisms for this
purpose.
o The attributes stored in Assertions are, for example, roles,
membership to a certain organization, specific access rights or
information about the authentication. A definition of most of
these attributes is application dependent and not defined in this
document. The SAML specification itself provides a number of
common attributes and provides extension points for future
enhancements. A brief overview of the available attributes within
an Assertion is given in Section 4.1.
o SIP is not used as a request/response protocol between the Relying
Party and the Asserting Party to fetch an Assertion based on a
received Artifact.
Tschofenig, et al. Expires April 25, 2005 [Page 5]
Internet-Draft Using SAML for SIP October 2004
4. SAML Introduction
In SAML there are three main entities: the user, the asserting party
and the relying party. A user requests and Assertions and receives
them after a successful authentication and authorization protocol
execution. The asserting party provides assurance that a particular
user has been given proper authorization. The relying party has to
trust the asserting party with regard to the provided information and
then decides whether or not to accept the assertions provided, giving
different levels of privileges.
The components of SAML are:
o Assertions/Artifact
o Request/Response protocols
o Bindings
o Profiles
We describe each in turn below
4.1 Assertions
An Assertion is a package of information including authentication
statements, attribute statements and authorization decision
statements. All kinds of statements do not have to be present, but
at least one. An Assertion contains several elements:
Issuing information:
Who issued the assertion, when was it issued and the assertion
identifier.
Subject information:
The name of the subject, the security domain and optional subject
information, like public key.
Conditions under which the assertion is valid:
Special kind of conditions like assertion validity period,
audience restriction and target restriction.
Tschofenig, et al. Expires April 25, 2005 [Page 6]
Internet-Draft Using SAML for SIP October 2004
Additional advice:
Explaining how the assertion was made, for example.
In an authentication statement, an issuing authority asserts that a
certain subject was authenticated by certain means at a certain time.
In an attribute statement, an issuing authority asserts that a
certain subject is associated with certain attributes which has
certain values. For example, user jon@cs.example.com is associated
with the attribute 'Department', which has the value 'Computer
Science'.
In an authorization decision statement, a certain subject with a
certain access type to a certain resource has given certain evidence
that the identity is correct. Based on this, the relying party then
makes the decision on giving access or not. The subject could be a
human or a program, the resource could be a webpage or a web service,
for example.
4.2 Artifact
The artifact used in the Browser/Artifact profile, is a base-64
encoded string which is 40 bytes long. 20 bytes consists of the
typecode, which is the source id. The remaining 20 bytes consists of
a 20-byte random number that servers use to look up an assertion.
The source server stores the assertion temporarily. The destination
server receives the artifact and pulls the assertion from the source
site. The purpose of the artifact is to act as a token who
references an assertion for the subject who holds the artifact.
4.3 Request/Response Protocol
SAML defines a request/response protocol for obtaining Assertions.
The request asks for an Assertion or makes queries for
authentication, attribute and authorization decisions. The response
is carrying back the requested Assertion.
4.4 Bindings
The bindings in SAML maps between the SAML protocol and a transport
and messaging protocol. With SAML Version 1.1 there is only one
binding specified, which is SAML embedded in SOAP-over-HTTP. In a
binding, a transport and messaging protocol is used only for
transporting the request/response mechanism.
Tschofenig, et al. Expires April 25, 2005 [Page 7]
Internet-Draft Using SAML for SIP October 2004
4.5 Profiles
When using a profile, SAML is used to provide assertions about a
resource in the body of the message itself. In Version 1.1 of SAML,
there are two profiles specified, the Browser/Artifact profile and
the Browser/POST profile. The Browser/Artifact profile represents a
"pull" model, where a special reference to the assertion called an
artifact, is sent to the relying party from the asserting party. The
artifact is then used to "pull" the assertion from the asserting
party. The Browser/POST profile represents a "push" model, where an
assertion is posted (using the HTTP POST command) directly to the
relying party. These two models are described in Figure 1 and Figure
2.
Tschofenig, et al. Expires April 25, 2005 [Page 8]
Internet-Draft Using SAML for SIP October 2004
5. Assertion Handling Models
As mentioned in Section 4.5, two main models can be used in SAML and
therefore also with the SIP-SAML extension defined in this document:
The Push and the Pull model.
In the Pull model the end host requests an assertion from the
Asserting Party and receives, after successful authentication and
authorization, an Artifact. The Artifact is a special form of an
Assertion. This Artifact can be compared with the call-by reference
approach where a reference to the Assertion is stored at the
Asserting Party and can later be dereferenced into the real assertion
on a request by a replying party. The Relying Party later fetches
the SAML Assertion after receiving a request by the user which
includes the Artifact. For communicating the SAML request and
response messages, a separate message exchange is needed with a
protocol such as SOAP or HTTP. This is outside the scope of this
document.
Tschofenig, et al. Expires April 25, 2005 [Page 9]
Internet-Draft Using SAML for SIP October 2004
+----------+ +--------------+ +--------------+
| User | | Asserting | | Relying |
| | | Party | | Party |
+----+-----+ +------+-------+ +------+-------+
| | |
| Request Assertion | |
|--------------------->| |
| | |
| User Authentication | |
| and Authorization | |
|<---------------------| |
|--------------------->| |
| | |
| Artifact | |
|<---------------------| |
| | |
| Request + Artifact |
|----------------------+------------------------->|
| | |
| | SAML request |
| |<-------------------------|
| | |
| |SAML response + Assertion |
| |------------------------->|
| | |
| Accept/Reject |
|<---------------------+--------------------------|
| | |
Figure 1: SAML Pull model
With the Push model, the user requests an Assertion from the
Asserting Party. The user can also trigger the Asserting Party to
attach an Assertion to the request. The Assertion, which is added to
the service request, can be verified by the Relying Party without
additional protocol interactions with the Asserting Party. The
Assertion therefore contains enough information to authorize the
service request. This model realizes a call-by value style of
communication.
Tschofenig, et al. Expires April 25, 2005 [Page 10]
Internet-Draft Using SAML for SIP October 2004
+----------+ +--------------+ +--------------+
| User | | Asserting | | Relying |
| | | Party | | Party |
+----+-----+ +------+-------+ +------+-------+
| | |
| Request Assertion | |
|--------------------->| |
| | |
| | |
| User Authentication | |
| and Authorization | |
|<---------------------| |
|--------------------->| |
| | |
| | |
| Assertion | |
|<---------------------| |
| | |
| Request + Assertion |
|----------------------+------------------------->|
| | |
| | |
| Accept/Reject |
|<---------------------+--------------------------|
| | |
Figure 2: SAML Push model
The usage of SAML in HTTP-based environments and in SIP is, however,
affected by some architectural differences.
The function of the entities in the Push and the Pull model are shown
in Figure 1 and in Figure 2.
The user has to request an Assertion at the Asserting Party and both
entities mutually authenticate each other. The requested Assertion
is sent to the user in a confidential manner to prevent eavesdroppers
from obtaining this Assertion. The Relying Party trusts the
Asserting Party. It is assumed that the accessed resource is located
at the Relying Party and that this entity does not become malicious
or act on behalf of the user to impersonate him or her to other
parties with regard to access to his resources. To prevent some
degree of misuse, attributes in the Assertion limit its applicability
for certain applications, servers or time frame.
Signaling in SIP can, however, involve a number of entities in more
complex scenarios. As an example, the scenario addressed in
[I-D.ietf-sip-identity] aims to replace end-to-end authentication via
Tschofenig, et al. Expires April 25, 2005 [Page 11]
Internet-Draft Using SAML for SIP October 2004
S/MIME by a "mediated authentication architecture". The end hosts
only need to be able to verify Assertions signed by an Authentication
Service which guarantees that the sender was authenticated.
Directly applying SAML to such a scenario, however, causes a problem:
a SIP proxy, which securely receives a SAML Assertion (such as
confidentially protected to prevent eavesdroppers between the SIP UA
and the SIP proxy to learn the Assertion), can store this Assertion
to impersonate the user in future requests towards other SIP end
users. The fact that multiple parties see the Assertion along the
path (i.e., SIP proxies) make the situation worse. The Assertion
might include some attributes which restrict its usage (such as
recipient(s), unique identifier for the message or a time-based
constraint) but they cannot fully prevent impersonation.
This problem appears if SAML Assertions are not bound to a particular
protocol run. Binding the Assertion to a particular protocol session
is not useful if the property of single-sign on is required.
To provide referential integrity, a solution as mentioned in
[I-D.ietf-sip-authid-body] can be used. which allows a party in a
SIP transaction to cryptographically sign the headers that assert the
identity of the originator of a message, and provide some other
headers necessary for reference integrity. An authenticated identity
body (AIB) is a MIME body of type 'message/sipfrag'. This MIME body
has a Content-Disposition type of 'aib'. The MIME body is optional.
The header fields From, Contact, Date and Call-ID must be used for
providing identity. Contact and Date header fields are required for
providing reference integrity. AIBs may contain other headers that
help to uniquely identify the transaction or that provides related
reference integrity.
The requirements for a non-INVITE AIB is very much the same as for an
INVITE: From, Call-ID, Date and Contact header fields are required.
The same that goes for requests also goes for responses with some
small differences. The From header field of the AIB in the response
to an INVITE must correspond to the address-of-record of the
responder and not the From header field in the received request. The
To header field of the request must not be included. A new Date
header field has to be generated for the response while the Call-ID
and CSeq are copied from the request.
Following is an example of the format of an AIB for an INVITE:
Tschofenig, et al. Expires April 25, 2005 [Page 12]
Internet-Draft Using SAML for SIP October 2004
Content-Type: message/sipfrag
Content-Disposition: aib; handling=optional
From: Alice <sip:alice@example.com>
To: Bob <sip:bob@example2.com>
Contact: <sip:alice@pc33.example.com>
Date: Thu, 26 Aug 2004 13:51:34 GMT
Call-ID: b76m5l94s90835
CSeq: 435431 INVITE
Figure 3: AIB Format for an INVITE
The same concept is applicable to this document as well with regard
to reference integrity. For a further discussion on this topic see
Section 14 and [I-D.peterson-message-identity].
Tschofenig, et al. Expires April 25, 2005 [Page 13]
Internet-Draft Using SAML for SIP October 2004
6. Scenarios
This section shows message flows based on scenarios in
[I-D.ietf-sipping-trait-authz] enriched with a SAML based solution.
Section 6.1 provides an example of enhanced network asserted
identities and Section 6.2 shows a SIP conferencing scenario with
role-based access control using SAML. A future version of this
document will cover more scenarios from
[I-D.ietf-sipping-trait-authz].
6.1 Network Asserted Identities
Figure 4 shows an enhanced network asserted identity scenario based
on [I-D.ietf-sip-identity] which again utilizes extensions proposed
with [I-D.ietf-sip-authid-body]. The enhancement is based on the
attributes asserted by the Authentication Service.
Figure 4 shows three entities, Alice@example.com, AS@example.com and
Bob@example2.com. If Alice wants to communicate with Bob, she sends
a SIP INVITE to her preferred AS. Depending on the chosen SIP
security mechanism either digest authentication, S/MIME or Transport
Layer Security is used to provide the AS with a strong assurance
about the identity of Alice. During this step authorization
attributes for inclusion into the SAML Assertion can be selected.
After Alice is authenticated and authorized, a SAML assertion is
attached to the SIP message. The Authentication Service can be
configured to attach a number of assertions, not limited to the
authenticated identity.
To bind the SAML assertion to a specific SIP session, it is necessary
for the AS to compute a hash of some fields of the message. A list
of the fields to hash is described in [I-D.ietf-sip-identity] and
particularly in [I-D.ietf-sip-authid-body]. The hash is digitally
signed and inserted into the SAML assertion and placed into the SAML
header. The SAML header also contains information about the entity
which created the digital signature. Upon reception of the message,
Bob verifies the signature of the SAML Assertion and verifies the
binding to the SIP message in order to prevent cut-and-paste attacks.
The provided SAML assertion can then be used to assist during the
authorization procedure. If Bob does not understand the extension
defined in this document, he silently ignores it. When the 200 OK
message arrives at Bob's AS, the same procedure as when Alice sent
her INVITE to her AS can be performed, if desired. This exchange is
not shown in Figure 4.
Note that this scenario does not imply that the SAML assertions are
solely used by SIP UAs. Assertions can also be helpful for SIP
Tschofenig, et al. Expires April 25, 2005 [Page 14]
Internet-Draft Using SAML for SIP October 2004
proxies or B2B UAs. Additionally, a push model is shown in this
section but it is reasonable to use a pull as well. For simplicity
reasons a push model should be prefered since an additional message
exchange between the Authentication Service and the UA can be
omitted.
+--------+ +--------------+ +--------+
|Alice@ | |Authentication| | Bob@ |
|example | |Service | |example2|
|.com | |@example.com | |com |
| | | | | |
+---+----+ +------+-------+ +---+----+
| | |
| INVITE | |
|---------------------->| |
| From:alice@foo.com | |
| | |
| 407 Proxy auth. req. | |
|<----------------------| |
| Challenge | |
| | |
| Challenge response | |
|---------------------->| |
| | |
| INVITE | |
|---------------------->| |
| | INVITE |
| | + SAML assertion |
| |--------------------->|
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
Figure 4: Network Asserted Identities
A variation of the scenario presented in Figure 4 is given in Figure
5 where an end host (Alice@example.com) obtains an Assertion from its
SIP proxy server which acts as an Authentication Service. This
assertion is then attached by the end host to the outgoing INVITE
message. Unlike in case of an Artifact, Bob@example.com does not
need to contact the Proxy Server.
An example of this scenario could be to preempt a lower priority call
if enough assurance for doing so is presented in the attached SAML
assertion. This would also mean that there is a priority value
included in the INVITE (for example in the Resource-Priority Header).
Tschofenig, et al. Expires April 25, 2005 [Page 15]
Internet-Draft Using SAML for SIP October 2004
+--------+ +--------------+ +--------+
| Alice@ | |Proxy Server | | Bob@ |
|example | |(AS | |example |
|.com | |@example.com | |.com |
| | | | | |
+---+----+ +------+-------+ +---+----+
| | |
| INVITE | |
|---------------------->| |
| From:alice@example.com| |
| | |
| 407 Proxy auth. req. | |
|<----------------------| |
| SAML Auth Header | |
| to use | |
| | |
| INVITE + SAML assertion |
|-----------------------+--------------------->|
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
Figure 5: End host attaching SAML Assertion
Note that Bob and Alice do not need to be in the same administrative
domain. It is feasible that Bob is in a domain that is federated
with Alice's domain.
The Assertion obtained by Alice@example.com needs to be associated
with a particular SIP messaging session. How to achieve this binding
is for further consideration.
6.2 SIP Conferencing
This section is meant to raise some discussions about the usage of
SAML in the domain of conferencing. A user who routes its SIP
message through the Authentication Service (Asserting Party) towards
a conferencing server may want SAML Assertions to be included. The
following properties could be provided by this procedure:
o The user identity can be replaced to allow the user to be
anonymous with regard to the Focus
o The user identity could be asserted to the Focus
o The SAML Assertion could provide additional information such as
group membership (belongs to the students, staff, faculty group of
Tschofenig, et al. Expires April 25, 2005 [Page 16]
Internet-Draft Using SAML for SIP October 2004
university X). This could, for non-identity-based authorization
systems, imply certain rights.
The corresponding SIP message flow (in high level detail) could have
the following shape:
+-----+ +-----------+ +-----------+
| | | SIP Proxy | | Focus |
|User | |(Asserting | | (Relying |
| | | party) | | party) |
+--+--+ +-----+-----+ +-----+-----+
| INVITE | |
|sip:conf-factory | |
|------------------>| INVITE+SAML |
| |------------------>|
| | |
| | Ringing |
| Ringing |<------------------|
|<------------------| |
| | |
| | OK |
| OK |<------------------|
|<------------------| |
| | |
| ACK | |
|------------------>| ACK |
| |------------------>|
| | |
| | |
... many more msgs...
Figure 6: SIP Conferencing and SAML
6.3 PSTN-to-SIP Phone Call
Alice, using a phone connected to the PSTN, wants to make a call to
Bob, which resides in a SIP network. Her call is switched through
the PSTN by means of PSTN signaling (outside the scope of this
document) to the PSTN/SIP gateway. At the gateway, the call is
converted from SS7 signaling to SIP signaling. Since Alice was
previously 'authenticated' through PSTN signaling mechanisms, the
gateway can create an assertion based on signaling information from
Alice and digitally sign it with his private key. Alice's call is
forwarded from the SIP/PSTN gateway to Bob's phone. Bob can certify
that the identity of Alice is correct by examining the SAML
Assertion.
Tschofenig, et al. Expires April 25, 2005 [Page 17]
Internet-Draft Using SAML for SIP October 2004
+-----------+
+----------------------+ | |
| | SS7 | SIP/PSTN |
| Public Switched |--------------------->| Gateway |
| | | |
| | | |
| Telephone Network | +--+-----------+----+
| ^ | | | |
+---------+------------+ | | SIP+SAML |
| SS7 | v |
| | +--------+ |
O | | | |
O /|\ <----+----| SIP | |
/|\ / \ SIP+ | Proxy | |
/ \ Bob SAML | | |
Alice | +--------+ |
| SIP based |
| Network |
+-------------------+
Figure 7: PSTN to SIP call
6.4 Compensation using SIP and SAML
This section briefly elaborates a scenario where SAML is used in SIP
to realize compensation functionality as described in
[I-D.jennings-sipping-pay]
In addition to the scenario presented in Section 1 of
[I-D.jennings-sipping-pay] the message exchange shown in Figure 8 is
feasible. Alice initiates a communication with an Authentication
Service which acts as a financial instuituation. Note that Alice
does not necessarily need to use SIP for communication with the
Authentication Service. Instead it might be possible to use HTTP or
other protocols which offer the necessary user credential or offer
additional information (such as a web page). After a successful
authentication and authorization Alice obtains an Assertion (or an
Artifact) which might contain payment relevant information. For a
later service access Alice contacts the merchant Bob which the
Assertion. Bob verifies the Assertion and, might want to contact the
Authentication Service for a credit check. A financial settlement
between the merchant Bob and the Trusted Third Party is assumed.
Depending on the type of service a one-time payment with immediately
amont capturing may take place (e.g., in case of a prepaid account)
or the amount of captured as a batch transaction.
The aspect of lighweight protocol execution is provided by
Tschofenig, et al. Expires April 25, 2005 [Page 18]
Internet-Draft Using SAML for SIP October 2004
o The alternative usage of an Artificat which leads to a lower
bandwidth consumption.
o The ability to use a single Assertion for multiple service access
protocol executions, if desired.
o SAML furthermore allows a cryptographic key to be bound to the
Assertion. A high degree of flexibility is provided with regard
to the possible credentials. For example, it might not be
necessary to use public key cryptography with every service
access. This might be useful if the cost of public key
cryptographic is too expensive for a cheap service or when end
hosts are performance constraint devices. In this case it might
be useful to rely on symmetric cryptographic, such as hash chains.
+--------+ +--------------+ +--------+
|User | |Authentication| |Merchant|
|Alice | |Server | |Bob |
| | |(Trusted Third| | |
| | | Party) | | |
+---+----+ +------+-------+ +---+----+
| | |
| SIP, HTTP, etc. | |
|---------------------->| |
| | |
| Assertion | |
|<----------------------| |
| | |
| | |
| INVITE + SAML assertion |
|-----------------------+--------------------->|
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
Figure 8: Message flow for SIP payment
The message flow of Section 1 of [I-D.jennings-sipping-pay] can also
be realized by defining information about the service cost. The main
advantage between the above-describe mechanism and the one described
in Section 1 is the type of user involvement and protocol
interaction. In both cases it is possible to provide an indication
to the user about the costs of a service access. In fact, the
Assertion might specify these type of constraints directly or
indirectly with the help of recurring service requests/responses.
Tschofenig, et al. Expires April 25, 2005 [Page 19]
Internet-Draft Using SAML for SIP October 2004
7. SIP-SAML Extension
To carry SAML Assertions and Artifacts two mechanisms are defined:
o The SIP header may either carry an Artificat or a CID URI
[RFC2392] pointing to an Assertion in the SIP body. The name of
this new SIP header is SAML-Payload. A SAML Artifact consists of
a TypeCode, SourceID and an AssertionHandle. It is thereby
assumed that the Relying Party will maintain a table of sourceID
values as well as URLs for Asserting Parties to contact. This
information is communicated out-of-band. This document also
allows the Asserting Party to add a URL to point to the Assertion
to prevent this level of indirection.
o The SIP body may carry one or more SAML Assertions. The MIME type
of this SAML Assertion is defined in [I-D.hodges-saml-mediatype].
A SIP user agent may add an Assertion to the body of a SIP message or
may add a reference to the Assertion into the SIP header. SIP
proxies MUST NOT add the Assertion to the boby. The SIP header MUST
be used instead when an Assertion has to be added.
A SAML Assertion SHOULD be protected and when added by a SIP entity
then S/MIME MUST be used rather than XML digital signatures.
To bind a SAML assertion to a SIP message a few selected SIP message
fields are input to a hash function. The digest-string, defined in
Section 10 of [I-D.ietf-sip-identity], is included into the
conditions extension point of the SAML Assertion. Details are for
further study.
Tschofenig, et al. Expires April 25, 2005 [Page 20]
Internet-Draft Using SAML for SIP October 2004
8. Example
This is an example of a SAML assertion and how it is structured in
XML.
<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
MajorVersion="1"
MinorVersion="1"
AssertionID="P1YaAz/tP6U/fsw/xA+jax5TPxQ="
Issuer="www.example.com"
IssueInstant="2004-06-28T17:15:32.753Z">
<saml:Conditions NotBefore="2004-06-28T17:10:32.753Z"
NotOnOrAfter="2004-06-28T17:20:32.753Z" />
<saml:AuthenticationStatement
AuthenticationMethod="urn:ietf:rfc:3075"
AuthenticationInstant="2004-06-28T17:15:12.706Z">
<saml:Subject>
<saml:NameIdentifier>
NameQualifier=alice@example.com
Format="urn:oasis:names:tc:SAML:1.1:nameid-
format:emailAddress">uid=alice
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:
cm:SIP-artifact-01
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
The elements in the Assertion have the following meaning:
+---------------------+-----+-------------------------------+
| Tag name |Req- | Description |
| |uired| |
+---------------------+-----+-------------------------------+
|MajorVersion | X |Major version of the assertion |
+---------------------+-----+-------------------------------+
|MinorVersion | X |Minor version of the assertion |
+---------------------+-----+-------------------------------+
|AssertionID | X |ID of the assertion |
+---------------------+-----+-------------------------------+
|Issuer | X |The name of the SAML authority |
| | |that created the assertion |
Tschofenig, et al. Expires April 25, 2005 [Page 21]
Internet-Draft Using SAML for SIP October 2004
+---------------------+-----+-------------------------------+
|IssuerInstant | X |Issuing time of the assertion |
+---------------------+-----+-------------------------------+
| | |Conditions that MUST be taken |
|Conditions | |into account when assessing |
| | |the validity of the assertion |
+---------------------+-----+-------------------------------+
| | |Specifies |
|AuthenticationMethod | X |what kind of authentication |
| | |took place |
+---------------------+-----+-------------------------------+
|AuthenticationInstant| X |Specifies the time when the |
| | |authentication took place |
+---------------------+-----+-------------------------------+
|Qualifier | |The name by which the subject |
| | |is recognized |
+---------------------+-----+-------------------------------+
| | |A URI reference representing |
|Format | |the format of NameIdentifier |
| | | |
+---------------------+-----+-------------------------------+
| | |Specifies a subject by supply- |
|SubjectConfirmation | |ing data that allows the sub- |
| | |ject to be authenticated |
+---------------------+-----+-------------------------------+
| | |Identifies |
|ConfirmationMethod | |which method to be used for |
| | |authenticating the subject |
+---------------------+-----+-------------------------------+
Figure 10: Tag descriptions
Tschofenig, et al. Expires April 25, 2005 [Page 22]
Internet-Draft Using SAML for SIP October 2004
9. Requirement Comparison
A future version of this document will compare the requirements
listed in [I-D.ietf-sipping-trait-authz] with the solution provided
in this document.
Tschofenig, et al. Expires April 25, 2005 [Page 23]
Internet-Draft Using SAML for SIP October 2004
10. Security Considerations
This section discusses security considerations when using SAML with
SIP.
10.1 Stolen Assertion
Threat:
If an eavesdropper can copy the real user's SAML response and
included assertions and construct a SIP message of his own, then
the eavesdropper could be able to impersonate the user at other
SIP entities.
Countermeasures:
By providing adequate confidentiality, eavesdropping of a SAML
assertion can be stopped.
10.2 MitM Attack
Threat:
Since the SAML assertion is carried within a SIP message, a
malicious site could impersonate the user at some other SIP
entities. These SIP entities would believe the adversary to be
the subject of the assertion.
Countermeasures:
If the adversary is a not-participating in the SIP signaling
itself (i.e., it is not a SIP proxy or a SIP UA), this threat can
be eliminated by employing inherent SIP security mechanisms, such
as TLS. However, if this entity is part of the communication
itself then reference integrity needs to be provided. Assertions
with tight restrictions (e.g., validity of the assertion) can also
limit the possible damage.
10.3 Forged Assertion
Threat:
A malicious user could forge or alter a SAML assertion in order to
communicate with the SIP entities.
Tschofenig, et al. Expires April 25, 2005 [Page 24]
Internet-Draft Using SAML for SIP October 2004
Countermeasures:
To avoid this kind of attack, the entities must assure that proper
mechanisms for protecting the SAML assertion needs to be in place.
It is recommended to protect the Assertion using a digital
signature.
10.4 Replay Attack
Threat:
In the case of using SIP with the SAML pull model, the threat of
replay lies in the fact that the artifact is a one-time-use
subject. The same artifact can be used again to gain access to
resources.
Countermeasures:
Cases where multiple requests are made which references the same
request must be tracked in order to avoid the threat.
Tschofenig, et al. Expires April 25, 2005 [Page 25]
Internet-Draft Using SAML for SIP October 2004
11. Contributors
The authors would like to thank Henning Schulzrinne for his
contributions to this document.
Tschofenig, et al. Expires April 25, 2005 [Page 26]
Internet-Draft Using SAML for SIP October 2004
12. Acknowledgments
We would like to thank RL 'Bob' Morgan and Stefan Goeman for their
comments to this draft.
Tschofenig, et al. Expires April 25, 2005 [Page 27]
Internet-Draft Using SAML for SIP October 2004
13. IANA Considerations
This document contains a number of IANA considerations. A future
version of this document will list them in this section.
Tschofenig, et al. Expires April 25, 2005 [Page 28]
Internet-Draft Using SAML for SIP October 2004
14. Open Issues
This document raises a number of issues with regard to the SIP
protocol interaction. Some of them are raised in this document (such
as reference integrity, who is allowed to add which information,
etc.) but a more detailed treatment of this topic with a focus of
identity management is described in [I-D.peterson-message-identity].
In particular, the following sections are highly relevant for this
document:
Assertion Constraints and Scope:
This aspect deals with the problem of binding a SIP Assertion to a
specific SIP message. The goal is to provide a security property
called reference integrity to prevent replay and impersonation
attacks. As described in Section 5 that a number of fields can be
used for this purpose. This document also considers scenarios
where the SAML Assertion was obtained outside a SIP protocol run.
In these cases SIP fields are not available to provide reference
integrity. The concept of the holder-of-the-key assertion is
described below and relevant for this discussion.
Canonicalization versus Replication:
To provide reference integrity a few selected fields need to be
hashed, signed and placed into the Assertion. Two approaches are
available for this purpose. Hence it needs to be studied how the
interworking between reference integrity and the usage of obtained
SAML assertion can be properly accomplished. For example, who
indicates which fields are included?
Placement of Assertions and Keys in Messages:
This document assumes that the Assertions are added to the SIP
body and Artifacts or references to Assertions located in the SIP
body are added to the SIP header. A central question is therefore
where these Assertions should be attached? Should the SIP user
agent or intermediate SIP proxies add Assertions/Artifacts? In the
scenarios depicted in Section 6, we have both approaches depending
on what kind of scenario it is. In Figure 4, they are added at
the UA and in contrast we have Figure 7, where the assertions are
added at the PSTN/SIP gateway.
MIME bodies can only be attached at the UA. Proxies by definition
do not attach MIME bodies; if an intermediary were to do so, it
would not be playing the proxy server role in the SIP
architecture. The SIP content indirection mechanism
[I-D.ietf-sip-content-indirect-mech] is also relevant in this
Tschofenig, et al. Expires April 25, 2005 [Page 29]
Internet-Draft Using SAML for SIP October 2004
discussion.
To provide reference integrity (by binding a SIP session and a SAML
Assertion together) two alternative approaches exist:
Hashing of SIP message fields:
If a hash is computed over a number of selected SIP fields and
subsequently digitally signed then there is a some degree of
protection that the Assertion cannot be copied to other SIP
messages and reused. The drawback thereby is that the Assertion
has a very limited time period. The hashed fields may vary from
context to context.
Holder-of-the-Key Assertion:
SAML introduces the concept of a holder-of-the-key assertion to
bind the Assertions (authorization information) to a cryptographic
key. As a result, the end host which was quite passive when
dealing with Assertions can be turned into an active protocol
participant. The end host obtained the assertion and attached
them to selected messages but did not provide any cryptographic
computations with regard to the Assertion itself. With the end
host being active in the protocol exchange security is improved a
lot. Furthermore, it is possible to combine the benefits of the
work done with SIPPING-CERT [I-D.ietf-sipping-certs] and this
document by binding a self-signed certificate created by the user
and stored at the credential server to an Assertion. As noted in
Section 9 of [I-D.ietf-sipping-certs] in the context of signing
SIP messages the usage of a self-signed certificate is not very
helpful except used with an Authentication Service. Combined with
a SAML Assertion the signature would protect the SIP message and
the SAML Assertion would provide authorization information.
A number of credentials can be used with the KeyInfo element of the
Holder-of-the-Key Assertion as described in Section 4.4 of
[xmldsig-core].
Further open issues are:
o Some work on option-tags is required. Are there cases when
processing of the assertion would be required by the sender? Or
when a proxy server wants to be able to say that a UA must supply
this header in order to access a particular resource? If so, an
option-tag should be defined for this extension that can be used
in Require, Supported, 420, etc.
o Specific SAML confirmation method identifiers and identifiers for
Tschofenig, et al. Expires April 25, 2005 [Page 30]
Internet-Draft Using SAML for SIP October 2004
the bindings or profiles must be defined and registrered with
OASIS. A confirmation method identifier is a URI that specifies
which method should be used by the target domain to assure that
the identity of the subject is true.
This mechanism seems to be provide the same reference integrity
properties as the hash over the various headers/bodies proposed in
the identity draft.
o Further use cases would be interesting. For example, a mechanism
to provide additional security for the SIP REFER method [RFC3515].
o A few new URIs need to be registered. The proposed URIs for
identification are:
SIP Binding: urn:oasis:names:tc:SAML:1.0:bindings:SIP-binding
Artifact profile:
urn:oasis:names:tc:SAML:1.0:profiles:SIP-artifact-01
Assertion profile:
urn:oasis:names:tc:SAML:1.0:profiles:SIP-assertion-01
o The proposed URIs for Confirmation Method Identifiers are:
Artifact profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-artifact-01
Assertion profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-bearer
o These are based on the URIs already used in the existing SOAP-SAML
binding, specified in Section 3 of [I-D.saml-bindings-1.1].
o An alignment with the work done by Liberty Alliance on Federated
Identities as described in [I-D.liberty-idff-arch-overview] would
be useful.
o The security consideration needs more details.
Tschofenig, et al. Expires April 25, 2005 [Page 31]
Internet-Draft Using SAML for SIP October 2004
15. References
15.1 Normative References
[I-D.hodges-saml-mediatype]
Hodges, J., "application/saml+xml Media Type
Registration", draft-hodges-saml-mediatype-01 (work in
progress), June 2004.
[I-D.ietf-sipping-trait-authz]
Peterson, J., "Trait-based Authorization Requirements for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-00 (work in progress),
February 2004.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
15.2 Informative References
[I-D.ietf-sip-authid-body]
Peterson, J., "SIP Authenticated Identity Body (AIB)
Format", draft-ietf-sip-authid-body-03 (work in progress),
May 2004.
[I-D.ietf-sip-content-indirect-mech]
Olson, S., "A Mechanism for Content Indirection in Session
Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-04 (work in
progress), July 2004.
[I-D.ietf-sip-identity]
Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-03 (work in progress), September
2004.
[I-D.ietf-sipping-certs]
Jennings, C. and J. Peterson, "Certificate Management
Service for SIP", draft-ietf-sipping-certs-00 (work in
progress), October 2004.
[I-D.jennings-sipping-pay]
Jennings, C., "Payment for SIP Services",
draft-jennings-sipping-pay-00 (work in progress), July
Tschofenig, et al. Expires April 25, 2005 [Page 32]
Internet-Draft Using SAML for SIP October 2004
2004.
[I-D.liberty-idff-arch-overview]
Wason, T., "Liberty ID-FF Architecture Overview", 2004.
[I-D.peterson-message-identity]
Peterson, J., "Security Considerations for Impersonation
and Identity in Messaging Systems",
draft-peterson-message-identity-00 (work in progress),
October 2004.
[I-D.saml-bindings-1.1]
Maler, E., Philpott, R. and P. Mishra, "Bindings and
Profiles for the OASIS Security Assertion Markup Language
(SAML) V1.1", September 2003.
[I-D.saml-core-1.1]
Maler, E., Philpott, R. and P. Mishra, "Assertions and
Protocol for the OASIS Security Assertion Markup Language
(SAML) V1.1", September 2003.
[I-D.saml-sec-consider-1.1]
Maler, E. and R. Philpott, "Security and Privacy
Considerations for the OASIS Security Markup Language
(SAML) V1.1", September 2003.
[I-D.saml-tech-overview-1.1-03]
Maler, E. and J. Hughes, "Technical Overview of the OASIS
Security Assertion Markup Language (SAML) V1.1", March
2004.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[xmldsig-core]
Eastlake, D., Reagle, J. and D. Solo, "XML-Signature
Syntax and Processing, W3C Recommendation (available at
http://www.w3.org/TR/xmldsig-core/)", February 2002.
Tschofenig, et al. Expires April 25, 2005 [Page 33]
Internet-Draft Using SAML for SIP October 2004
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
EMail: Hannes.Tschofenig@siemens.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
EMail: jon.peterson@neustar.biz
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
US
EMail: jmpolk@cisco.com
Douglas C. Sicker
University of Colorado at Boulder
ECOT 430
Boulder, CO 80309
US
EMail: douglas.sicker@colorado.edu
Marcus Tegnander
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Tschofenig, et al. Expires April 25, 2005 [Page 34]
Internet-Draft Using SAML for SIP October 2004
Appendix A. Acknowledgments
We would like to thank RL 'Bob' Morgan for his comments to this
draft.
Tschofenig, et al. Expires April 25, 2005 [Page 35]
Internet-Draft Using SAML for SIP October 2004
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 (2004). 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.
Tschofenig, et al. Expires April 25, 2005 [Page 36]