SIP H. Tschofenig
Internet-Draft Siemens
Expires: January 10, 2005 J. Peterson
NeuStar, Inc.
J. Polk
Cisco
D. Sicker
CU Boulder
M. Tegnander
Siemens
July 12, 2004
Using SAML for SIP
draft-tschofenig-sip-saml-00
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I 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 January 10, 2005.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document describes how to use the Security Assertion Markup
Language (SAML) to offer trait-based authorization. As such, it
Tschofenig, et al. Expires January 10, 2005 [Page 1]
Internet-Draft Using SAML for SIP July 2004
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 . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Network Asserted Identities . . . . . . . . . . . . . . . 13
6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 15
6.3 PSTN-to-SIP phone call . . . . . . . . . . . . . . . . . . 17
7. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . 19
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 22
10. Security considerations . . . . . . . . . . . . . . . . . . 23
10.1 Stolen Assertion . . . . . . . . . . . . . . . . . . . . 23
10.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . 23
10.3 Forged Assertion . . . . . . . . . . . . . . . . . . . . 23
10.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . 23
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 25
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 26
13. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 27
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
14.1 Normative References . . . . . . . . . . . . . . . . . . . 29
14.2 Informative References . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
A. SAML Artifact format . . . . . . . . . . . . . . . . . . . . 32
Intellectual Property and Copyright Statements . . . . . . . 33
Tschofenig, et al. Expires January 10, 2005 [Page 2]
Internet-Draft Using SAML for SIP July 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. It 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 January 10, 2005 [Page 3]
Internet-Draft Using SAML for SIP July 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 January 10, 2005 [Page 4]
Internet-Draft Using SAML for SIP July 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
header. 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. XCAP[I-D.draft-ietf-simple-xcap-02] is a
possible mechanism to configure the behavior of the Authentication
Service in an out-of-band fashion.
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. Since the attributes need to be understood by the
entity verifying the assertions it might be necessary to describe
common attributes in a future version of this document. Note that
some attribute definitions are already available with SAML (such
as attributes providing information about the authentication
procedure).
o SIP is not used as a request/response protocol for obtaining
Assertions (although possible). Such a protocol is, for example,
required between the Relying Party and the Asserting Party to
fetch an Assertion based on a received Artifact. Note, however,
that SIP is still implicitly used to request Assertions.
Tschofenig, et al. Expires January 10, 2005 [Page 5]
Internet-Draft Using SAML for SIP July 2004
4. SAML Introduction
In SAML there are three main entities: the user, the asserting party
and the relying party. The asserting party is asserting 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 January 10, 2005 [Page 6]
Internet-Draft Using SAML for SIP July 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 assertion and pulls the data from the artifact on
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. The XML format for
protocol messages are defined within an XML schema in TBD.
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 January 10, 2005 [Page 7]
Internet-Draft Using SAML for SIP July 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 respresents 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 in
Figure 2.
Tschofenig, et al. Expires January 10, 2005 [Page 8]
Internet-Draft Using SAML for SIP July 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 referenced. 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. That is outside the scope of this
document.
Note that this exchange also allows the Artifact to be bound to a
particular signaling session by attaching the assertion to the
service request. This requires the Asserting Party to participate in
the signaling message exchange and provides stronger security
properties but removes the property of "single sign-on".
+----------+ +--------------+ +--------------+
| User | | Asserting | | Relying |
| | | Party | | Party |
+----+-----+ +------+-------+ +------+-------+
| | |
| Request Assertion | |
|--------------------->| |
| | |
| | |
| User Authentication | |
| and Authorization | |
|<---------------------| |
|--------------------->| |
| | |
| | |
| Artifact | |
|<---------------------| |
| | |
| Request + Artifact |
|----------------------+------------------------->|
| | |
| | |
| | SAML request |
Tschofenig, et al. Expires January 10, 2005 [Page 9]
Internet-Draft Using SAML for SIP July 2004
| |<-------------------------|
| | |
| | |
| |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. Using programming languages, a call-by value is
implemented.
Tschofenig, et al. Expires January 10, 2005 [Page 10]
Internet-Draft Using SAML for SIP July 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 main goal of
realizing single-sign-on (SSO) functionality in HTTP is not the goal
of this extension to SIP.
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
to obtain 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 that
it does not act on behalf of the user to impersonate him or her to
other parties with regard to access to this resource. 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
Tschofenig, et al. Expires January 10, 2005 [Page 11]
Internet-Draft Using SAML for SIP July 2004
complex scenarios. As an example, the scenario addressed in
[I-D.ietf-sip-identity] aims to replace end-to-end authentication via
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
lifetime or indication of a particular resource) but they cannot
fully prevent impersonation. If intermediate SIP proxies should also
be able to process the Assertion then it cannot be bound to a
particular receiver - the intermediate SIP proxies might not even be
known to the SIP end host.
This problem appears if SAML Assertions are not bound to a particular
protocol run. Binding the Assertion to a particular session is not
useful in the context of SSO but in many SIP scenarios there seems to
be a problem if such a binding is not provided. There is little
usage in requesting Assertions from a separate Authentication Service
for every SIP message exchange since the additional latency and
performance impact could potentially be large.
Tschofenig, et al. Expires January 10, 2005 [Page 12]
Internet-Draft Using SAML for SIP July 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 3 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 3 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 Header 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 identity
which created the digital signature. Upon reception of the message,
Bob learns the signature in the SAML header 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 3.
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 January 10, 2005 [Page 13]
Internet-Draft Using SAML for SIP July 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 3: Network Asserted Identities
A variation of the scenario presented in Figure 3 is given in Figure
4 where an end host (Alice@example.com) obtains an Assertion from its
SIP proxy server. 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.
Tschofenig, et al. Expires January 10, 2005 [Page 14]
Internet-Draft Using SAML for SIP July 2004
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).
+--------+ +--------------+ +--------+
| Alice@ | |Proxy Server | | Bob@ |
|example | | | |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 4: End host attaching SAML Assertion
Note that Bob and Alice can 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 SIP conferencing.
Tschofenig, et al. Expires January 10, 2005 [Page 15]
Internet-Draft Using SAML for SIP July 2004
Two possible usage cases are described. The first use case describes
a user who routes its SIP message through the Authentication Service
(Asserting Party) to allow SAML Assertions to be included. The
following goals could be achieved by this procedure:
o The user identity can be replaced to have 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
university X). This could, for non-identity-based authorization
system 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 5: SIP Conferencing and SAML
In the second use case, a SIP Proxy (which acts as an Asserting
Party) stores authorization policies for usage with SIP conferencing.
These authorization policies could be attached by the Asserting Party
Tschofenig, et al. Expires January 10, 2005 [Page 16]
Internet-Draft Using SAML for SIP July 2004
for this particular session. The Focus does not need to store this
type of information.
These policies might not be configured by the user itself. One could
think of a model similar to the Geopriv model where the rule maker
does not need to be the same entity as the conferencing participant.
The authorization policies defined in [I-D.niemi-xcon-cpcp-rules]
could be reused. If we think of virtual 3GPP/IEEE meeting scenario
then certain members have more rights than others and it must be
asserted that a particular person is the member of a company and
possibly some other restrictions.
The SAML assertion could, for example, include (among other things):
<rule="a1234">
<conditions/>
<actions>
<join-handling>accept</join-handling>
</actions>
<transformations>
<is-key-participant>true</is-key-participant>
</transformations>
</rule>
Figure 6: Carrying authz. policies for SIP Conferering in SAML
The identity section of the conditions part is left empty since the
Assertion is attached to a request which originates from a particular
entity. The identity to whom the Assertion was granted is already
included in other SAML specific attributes.
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 properly authenticated through PSTN signaling mechanisms,
the gateway can create an assertion based on signaling information
from Alice and digitally sign it with it's 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 January 10, 2005 [Page 17]
Internet-Draft Using SAML for SIP July 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
Tschofenig, et al. Expires January 10, 2005 [Page 18]
Internet-Draft Using SAML for SIP July 2004
7. Header Syntax
This document specifies a new SIP header: SAML-Payload
This header MUST NOT appear more than once in a SIP message.
SAML-Payload = "SAML-Payload" HCOLON saml-assertion
The saml-assertion field either contains a base64 encoded SAML
Assertion which SHOULD be S/MIME protected or an Artifcat. An
example of an Assertion is shown in Section 8 and its protection is
highly recommended but not mandated by the SAML specification.
If an SAML assertions is protected 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 TBD
element of the SAML Assertion.
Tschofenig, et al. Expires January 10, 2005 [Page 19]
Internet-Draft Using SAML for SIP July 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 January 10, 2005 [Page 20]
Internet-Draft Using SAML for SIP July 2004
+---------------------+-----+-------------------------------+
|IssuerInstant | X |Issuing time of the assertion |
+---------------------+-----+-------------------------------+
| | |Conditions that MUST be taken |
|Conditions | |into account when assessing |
| | |the validity of the assertion |
+---------------------+-----+-------------------------------+
| | |A URI reference that 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 |
+---------------------+-----+-------------------------------+
| | |A URI reference who identifies |
|ConfirmationMethod | |which method to be used for |
| | |authenticating the subject |
+---------------------+-----+-------------------------------+
Figure 9: Tag descriptions
Tschofenig, et al. Expires January 10, 2005 [Page 21]
Internet-Draft Using SAML for SIP July 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 January 10, 2005 [Page 22]
Internet-Draft Using SAML for SIP July 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 it's own SIP message, 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.
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
Tschofenig, et al. Expires January 10, 2005 [Page 23]
Internet-Draft Using SAML for SIP July 2004
references the same request must be tracked in order to avoid the
threat.
Tschofenig, et al. Expires January 10, 2005 [Page 24]
Internet-Draft Using SAML for SIP July 2004
11. Contributors
The authors would like to thank Henning Schulzrinne for their input
to this document.
Tschofenig, et al. Expires January 10, 2005 [Page 25]
Internet-Draft Using SAML for SIP July 2004
12. 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 January 10, 2005 [Page 26]
Internet-Draft Using SAML for SIP July 2004
13. Open issues
During the work on this document a number of open issues have been
discovered:
o It needs to be studied how the interworking between reference
integrity and the usage of obtained SAML assertion can be properly
accomplished.
o In Section 7, it suggests that an S/MIME protected SAML assertion
could appear by-value in a SIP header. This issue deserves
further investigations. If by-value inclusion is required, then
at best, this header might contain a "cid:" URL. This allows you
to point to a particular MIME body in the body of a SIP message.
However, proxy servers cannot add bodies to SIP requests, and so
this would be a UA-only approach.
o Where should the Assertions be attached? At the UA or at the
proxy? In the scenarios depicted in Section 6, we have both
approaches depending on what kind of scenario it is. In Figure 3,
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. If an assertion needs to be added by-value,
something like the redirection-based mechanism originally in the
identity draft would be appropriate. This issue is for further
study.
o The usage of the SAML artifact from HTTP to provide by-reference
carriage of the assertion needs further study. The HTTP artifact
assumes that the recipient will know how to dereference the
artifact, which for various reasons in the HTTP binding makes
sense, but in SIP might not. The authors think that it would be
good to provide a URL associated with the asserting party, one
which might also contain the artifact (i.e.
http://asserting-party.com/artifact), or parts of the artifact,
that are necessary to index to a particular assertion being held
by the asserted party. Hence, an HTTPS URL has to be used for
this purpose. Otherwise, given the very peer-to-peer nature of
SIP it is possible that the artifact will not give you enough
information to be able to figure out how to contact the asserting
party.
o Some work on option-tags is required. Are there cases when
processing of the assertion would be required by the sender? Or
Tschofenig, et al. Expires January 10, 2005 [Page 27]
Internet-Draft Using SAML for SIP July 2004
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 (and I
think 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
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 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 January 10, 2005 [Page 28]
Internet-Draft Using SAML for SIP July 2004
14. References
14.1 Normative References
[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,
<reference.I-D.ietf-sipping-trait-authz.xml>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
14.2 Informative References
[I-D.draft-ietf-simple-xcap-02]
Rosenberg, J., "Extensible Markup Language (XML)
Configuration Access Protocol (XCAP)",
draft-ietf-simple-xcap-02 (work in progress), February
2004, <reference.I-D.draft-ietf-simple-xcap-02.xml>.
[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, <reference.I-D.ietf-sip-authid-body.xml>.
[I-D.ietf-sip-identity]
Peterson, J., "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)",
draft-ietf-sip-identity-02 (work in progress), May 2004,
<reference.I-D.ietf-sip-identity.xml>.
[I-D.liberty-idff-arch-overview]
Wason, T., "Liberty ID-FF Architecture Overview", 2004,
<reference.I-D.liberty-idff-arch-overview.xml>.
[I-D.niemi-xcon-cpcp-rules]
Niemi, A., "Conference Policy Authorization Rules",
draft-niemi-xcon-cpcp-rules-00 (work in progress), May
2004, <reference.I-D.niemi-xcon-cpcp-rules.xml>.
[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,
<reference.I-D.saml-bindings-1.1.xml>.
Tschofenig, et al. Expires January 10, 2005 [Page 29]
Internet-Draft Using SAML for SIP July 2004
[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,
<reference.I-D.saml-core-1.1.xml>.
[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,
<reference.I-D.saml-sec-consider-1.1.xml>.
[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, <reference.I-D.saml-tech-overview-1.1-03.xml>.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E. and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999, <reference.RFC.2543.xml>.
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
Tschofenig, et al. Expires January 10, 2005 [Page 30]
Internet-Draft Using SAML for SIP July 2004
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 531
Boulder, CO 80309
US
EMail: douglas.sicker@colorado.edu
Marcus Tegnander
Siemens
Otto-Hahn-Ring 6
Munich, Bayern 81739
Germany
Tschofenig, et al. Expires January 10, 2005 [Page 31]
Internet-Draft Using SAML for SIP July 2004
Appendix A. SAML Artifact format
TypeCode := 0x0001
RemainingArtifact := SourceID AssertionHandle
SourceID := 20-byte_sequence
AssertionHandle := 20-byte_sequence
The sourceID is a 20-byte sequence which is used by the destination
domain to determine the identity and location of the source domain.
It is assumed that the destination domain will maintain a table of
sourceID values as well as URLs for the domains it is having SAML
sessions with and this information is communicated out-of-band. When
the destination receives the SAML artifact, it determines if the
source domain belongs to a known source domain and obtains the
location before sending a SAML request.
If two source domains communicating with the same target domain MUST
be distinguished by unique SourceIDs. The AssertionHandle is
constructed on the basis that they SHOULD not have any predictable
relationship to the contents of the assertion and that it MUST be not
worth the effort to reconstruct or guess the value of the
AssertionHandle.
In [I-D.saml-bindings-1.1] section 4.1.1.8, some RECOMMENDED
practices for creation of SAML artifacts are listed.
Tschofenig, et al. Expires January 10, 2005 [Page 32]
Internet-Draft Using SAML for SIP July 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 January 10, 2005 [Page 33]