< draft-tschofenig-sip-saml-04.txt   draft-tschofenig-sip-saml-05.txt >
SIP H. Tschofenig SIP H. Tschofenig
Internet-Draft Siemens Internet-Draft Siemens
Expires: January 19, 2006 J. Peterson Expires: September 6, 2006 J. Peterson
NeuStar, Inc. NeuStar, Inc.
J. Polk J. Polk
Cisco Cisco
D. Sicker D. Sicker
CU Boulder CU Boulder
M. Tegnander J. Hodges
LYIT NeuStar, Inc.
July 18, 2005 March 5, 2006
Using SAML for SIP SIP SAML Profile and Binding
draft-tschofenig-sip-saml-04.txt draft-tschofenig-sip-saml-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 41 skipping to change at page 1, line 41
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 19, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document defines a mechanism for using the Security Assertion This document specifies a Session Initiation Protocol (SIP) profile
Markup Language (SAML) in concert with the Session Initiation of Security Assertion Markup Language (SAML) as well as a SAML SIP
Protocol (SIP). In particular, it provides a way for SIP to refer to binding. The defined SIP SAML Profile composes with the mechanisms
SAML objects, and for recipients of SIP messages to use SAML in order defined in the SIP Identity specification and satisfy requirements
to make more informed authorization decisions. presented in "Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)".
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Goals and Non-Goals . . . . . . . . . . . . . . . . . . . . 5 3. Specification Scope . . . . . . . . . . . . . . . . . . . . . 5
4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . 6 4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7
4.1 Assertions . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8
4.2 Artifact . . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9
4.3 Request/Response Protocol . . . . . . . . . . . . . . . . 7 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 10
4.4 Bindings . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Use-case Scenarios . . . . . . . . . . . . . . . . . . . . . . 12
4.5 Profiles . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 12
5. Assertion Handling Models . . . . . . . . . . . . . . . . . 9 6.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 13
6. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . 14 6.3. Compensation using SIP and SAML . . . . . . . . . . . . . 15
6.1 Network Asserted Identities . . . . . . . . . . . . . . . 14 7. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 17
6.2 SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 16 7.1. AS-driven SIP SAML URI-based Attribute Assertion
6.3 PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 17 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 17
6.4 Compensation using SIP and SAML . . . . . . . . . . . . . 18 7.1.1. Required Information . . . . . . . . . . . . . . . . . 17
7. SIP-SAML Extension . . . . . . . . . . . . . . . . . . . . . 20 7.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 17
8. Example . . . . . . . . . . . . . . . . . . . . . . . . . . 21 7.1.3. Profile Description . . . . . . . . . . . . . . . . . 21
9. Requirement Comparison . . . . . . . . . . . . . . . . . . . 23 7.1.4. Assertion Profile Description . . . . . . . . . . . . 24
10. Security Considerations . . . . . . . . . . . . . . . . . . 24 7.1.5. Assertion Verification . . . . . . . . . . . . . . . . 27
10.1 Stolen Assertion . . . . . . . . . . . . . . . . . . . . 24 8. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 29
10.2 MitM Attack . . . . . . . . . . . . . . . . . . . . . . 24 8.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 29
10.3 Forged Assertion . . . . . . . . . . . . . . . . . . . . 24 9. Example Signed SAML Assertion . . . . . . . . . . . . . . . . 30
10.4 Replay Attack . . . . . . . . . . . . . . . . . . . . . 25 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 26 10.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 32
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 27 10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 33
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 28 10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 33
14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . 29 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
15.1 Normative References . . . . . . . . . . . . . . . . . . 32 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
15.2 Informative References . . . . . . . . . . . . . . . . . 32 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 34 15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 38
Intellectual Property and Copyright Statements . . . . . . . 35 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Normative References . . . . . . . . . . . . . . . . . . . 39
16.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 43
1. Introduction 1. Introduction
This document proposes a method for using the Security Assertion This document specifies composition of the Security Assertion Markup
Markup Language (SAML) in collaboration with SIP to accommodate Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate
richer authorization mechanisms and enable trait- based authorization richer authorization mechanisms and enable "trait-based
where you are authenticated using roles or traits instead of authorization." Trait-based authorization is where one is authorized
identity. A motivation for trait based authorization and some to make use of some resource based on roles or traits rather than
scenarios are presented in [I-D.ietf-sipping-trait-authz]. ones identifier(s). Motivations for trait-based authorization, along
with use-case scenarios, are presented in [I-D.ietf-sipping-trait-
authz].
Security Assertion Markup Language (SAML) [I-D.saml-tech-overview- Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML-
1.1-03] is an XML extension for security information exchange that is based framework for creating and exchanging security information.
being developed by OASIS. SAML is a XML-based framework for creating [OASIS.sstc-saml-exec-overview-2.0-cd-01] and [OASIS.sstc-saml-tech-
and exchanging security information. overview-2.0-draft-08] provide non-normative overviews of SAMLv2.
The SAMLv2 specification set is normatively defined by [OASIS.saml-
conformance-2.0-os].
To provide trait-based authorization a few solutions are possible: Various means of providing trait-based authorization exist:
authorization certificates, SPKI or extensions to the authenticated authorization certificates, SPKI or extensions to the authenticated
identity body [I-D.ietf-sip-authid-body]. The authors selected SAML identity body [RFC3893]. The authors selected SAML due to its
due to its increasing use in environments such as the Liberty increasing use in environments such as the Liberty Alliance, and the
Alliance and the Internet2 project, areas where the applicability to Internet2 project, areas where the applicability to SIP is widely
SIP is widely desired. desired.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The SIP entity 'Authentication Service' was introduced with The SIP network element "Authentication Service" is introduced in
[I-D.ietf-sip-identity]. We reuse this term to refer to an entity [I-D.ietf-sip-identity]. We reuse this term to refer to a network
that authenticates and authorizes a user and creates an assertion. element that authenticates and authorizes a user and creates a "SIP
This entity is the equivalent of the asserting party in the SAML identity assertion". This system entity is the moral equivalent of a
terminology. "SAML Authority" in the SAML terminology.
For terminology related to SAML the reader is referred to [I-D.saml-
tech-overview-1.1-03].
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.
In order for SAML to be used in a practical system, participating
entities must agree on attributes and traits that will be used.
Without this pre-existing agreement, SAML cannot be usefully
deployed. This document does not discuss the manner in which
participating entites might discover one another or agree on the
syntax and semantics of attributes and traits.
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.
4. SAML Introduction
In SAML there are three main entities: the user, the asserting party
and the relying party. A user requests 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 For overall SIP terminology, see [RFC3261].
o Bindings In this specification, the term, or term component, "SAML" refers to
SAML V2.0 in all cases. For example, the term "SAML assertion"
implicitly means "SAMLv2 assertion". For overall SAML terminology,
see [OASIS.saml-glossary-2.0-os].
o Profiles The below list maps other various SIP terms to their SAML
(rough-)equivalents:
We describe each in turn below Element, Network Element: System Entity, Entity
4.1 Assertions Authentication Service: SAML Authority
An assertion is a package of information including authentication Invitee, Invited User, Called Party, Callee - Relying Party
statements, attribute statements and authorization decision
statements. All of statements do not have to be present, but at
least one does. An assertion contains several elements:
Issuing information: Server, User Agent Server (UAS): SAML Responder
Who issued the assertion, when was it issued and the assertion User Agent Client (UAC), client: SAML Requester
identifier.
Subject information: Additional terms concocted in the context of this specification:
The name of the subject, the security domain and optional subject profile attribute(s):
information, like public key.
Conditions under which the assertion is valid: one or more attributes of a "user profile".
Special kind of conditions like assertion validity period, user profile, subject profile:
audience restriction and target restriction.
Additional advice: the set of various attributes accompanying (i.e., mapped to) a
user account in many environments.
Explaining how the assertion was made, for example. 3. Specification Scope
In an authentication statement, an issuing authority asserts that a The scope of this specification is:
certain subject was authenticated by certain means at a certain time.
In an attribute statement, an issuing authority asserts that a o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
certain subject is associated with certain attributes which has that a subject's profile attributes, and their domain's
certain values. For example, user jon@cs.example.com is associated certificate, can be conveyed to a relying party using SAML. In
with the attribute 'Department', which has the value 'Computer doing so, satisfy the requirements outlined in [I-D.ietf-sipping-
Science'. trait-authz], and compose with [I-D.ietf-sip-identity].
In an authorization decision statement, a certain subject with a The following are outside the scope of this specification:
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 o Defining a means for configuring the runtime behavior, or
deployment characteristics, of the Authentication Service.
The artifact used in the Browser/Artifact profile, is a base-64 Discussion:
encoded string that is 40 bytes long. 20 bytes consists of the
typecode, which is the source id. The remaining 20 bytes consists of
a 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 that references an
assertion for the subject who holds the artifact.
Note that artifacts were designed to be used specifically in a web For example, a SIP Authentication Service could be implemented
context where the asserting party is clear due to the client/server such that its SAML-based features are employed, or not, on a
nature of the protocol. Artifacts are not globally-derefenceable; subject-by-subject basis, and/or on a domain-by-domain basis.
one cannot tell simply be inspecting an artifact out of context which
server generated the artifact. For the more peer-to-peer
architecture of SIP, enhancements are required to make the context of
artifact generation known to relying parties.
4.3 Request/Response Protocol o The definition of specific conveyed subject profile attributes
(aka traits).
SAML defines a request/response protocol for obtaining assertions. Discussion:
The request asks for an assertion or makes queries for
authentication, attribute and authorization decisions. The response
carries back the requested assertion.
4.4 Bindings This specification defines a facility enabling "trait-based
authorization" as discussed in [I-D.ietf-sipping-trait-authz].
The bindings in SAML maps between the SAML protocol and a transport The attributes of interest in trait-based authorization will be
and messaging protocol. With SAML Version 1.1 there is only one ones akin to, for example: roles, organizational membership,
binding specified, which is SAML embedded in SOAP-over-HTTP. In a access rights, or authentication event context. Definition of
binding, a transport and messaging protocol is used only for such attributes is application- and/or deployment-context-
transporting the request/response mechanism. dependent and are not defined in this specification. However, The
SAMLv2 specification defines several "SAML Attribute Profiles" for
encoding attributes from various application domains, e.g., LDAP,
UUID/GUID, DCE PAC, and XACML, in SAML assertions [OASIS.saml-
profiles-2.0-os].
4.5 Profiles In order for any trait-based system to be practical, participating
entities must agree on attributes and traits that will be conveyed
and subsequently relied upon. Without such agreements, a trait-
based system cannot be usefully deployed. This specification does
not discuss the manner in which participating entites might
discover one another or agree on the syntax and semantics of
attributes and traits.
When using a profile, SAML is used to provide assertions about a Note that SAMLv2 specifies a "metadata" facility that may be
resource in the body of the message itself. In Version 1.1 of SAML, useful in addressing this need.
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 2 and
Figure 1.
5. Assertion Handling Models 4. SAML Introduction
As mentioned in Section 4.5, two main models can be used in SAML and SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] [OASIS.sstc-saml-tech-
therefore also with the SIP-SAML extension defined in this document: overview-2.0-draft-08] defines an XML-based framework for exchanging
The Push and the Pull model. "security assertions" between entities. In the course of making, or
relying upon such assertions, SAML system entities may use SAML
protocols, or other protocols, to communicate regarding an assertion
itself, or the subject of an assertion.
A 'Push' model (or mode) means to transmit information towards Thus one can employ SAML to make and encode statements such as "Alice
another entity. Here we call that transmitting the information 'by- has these profile attributes and her domain's certificate is
value'. An example of this model (or mode) is an email attachment available over there, and I'm making this statement, and here's who I
(file). That attachment is included in the original transmission, as am." Then one can cause such an assertion to be conveyed to some
is 'by-value'. party who can then rely on it in some fashion for some purpose, for
example input it into some local policy evaluation for access to some
resource. This is done in a particular "context of use". Such a
context of use could be, for example, deciding whether to accept and
act upon a SIP-based invitation to initiate a communication session.
Whereas, a 'Pull' model (or mode) means to transmit an identifier for The specification of how SAML is employed in a particular context of
where a piece of information is (located somewhere else). This use is known as a "SAML profile". The specification of how SAML
piece of information still requires retrieval by the receiver of this assertions and/or protocol messages are conveyed in, or over, another
transmission. Here we call that transmitting the information 'by- protocol is known as a "SAML Binding". Typically, a SAML profile
reference'. An example of this model (or mode) is including a URI in specifies the SAML bindings that may be used in its context. Both
that email, to be accessed directly by the receiver of the email in a SAML profiles and SAML bindings reference other SAML specifications,
subsequent operation. especially the SAML Assertions and Protocols, aka "SAML Core",
specification [OASIS.saml-core-2.0-os].
Either the end host or an intermediate proxy might request an There is an additional subtle aspect of SAML profiles that is worth
assertion or an artifact. The Push and the Pull model used for HTTP highlighting -- the notion of a "SAML assertion profile". A SAML
does not match with its usage in SIP. assertion profile is the specification of the assertion contents in
the context of a particular SAML profile. It is possibly further
qualified by a particular implementation and/or deployment context.
Condensed examples of SAML assertion profiles are:
With the 'per-value' model either a user requests an assertion from o The SAML assertion must contain at least one authentication
the Asserting Party or the user triggers the Asserting Party to statement and no other statements. The relying party must be
attach an assertion to the outgoing request. The assertion, which is represented in the <AudienceRestriction> element. The
added to the service request, can be verified by the Relying Party SubjectConfirmation Method must be Foo. etc.
without additional protocol interactions with the Asserting Party.
The assertion therefore contains enough information to authorize the
service request.
Figure 1 shows the protocol exchange where the user fetches the o The SAML assertion must contain at least one attribute statement
assertion. and may contain more than one. The values for the subject's
profile attributes named "Foo" and "Bar" must be present. An
authentication statement may be present. etc.
+----------+ +--------------+ +--------------+ The primary facets of SAML itself are:
| User | | Asserting | | Relying |
| | | Party | | Party |
+----+-----+ +------+-------+ +------+-------+
| | |
| Request Assertion | |
|--------------------->| |
| | |
| User Authentication | |
| and Authorization | |
|<---------------------| |
|--------------------->| |
| | |
| Assertion | |
|<---------------------| |
| | |
| Request + Assertion |
|----------------------+------------------------->|
| | |
| | |
| Accept/Reject |
|<---------------------+--------------------------|
| | |
Figure 1: Example for a 'Per-value' Interaction o Assertions
With the 'per-reference' model either the user contacts the Asserting o Abstract Request/Response protocol
Party to obtain an artifact or the user triggers the Asserting Party
to attach the artifact to the outgoing request. The artifact is a
reference to an assertion is stored at the Asserting Party and can
later be dereferenced into the assertion on a request. The Relying
Party later fetches the SAML assertion after receiving the artifact
by the user. For communicating the SAML request and response
messages, a separate message exchange is needed with a protocol, such
as SOAP. A description of this protocol interaction is outside the
scope of this document.
Figure 2 shows an example protocol interaction where the user fetches We describe each in turn below:
the artifact.
+----------+ +--------------+ +--------------+ 4.1. SAML Assertions
| User | | Asserting | | Relying |
| | | Party | | Party |
+----+-----+ +------+-------+ +------+-------+
| | |
| Request Assertion | |
|--------------------->| |
| | |
| User Authentication | |
| and Authorization | |
|<---------------------| |
|--------------------->| |
| | |
| Artifact | |
|<---------------------| |
| | |
| Request + Artifact |
|----------------------+------------------------->|
| | |
| | SAML request |
| |<-------------------------|
| | |
| |SAML response + Assertion |
| |------------------------->|
| | |
| Accept/Reject |
|<---------------------+--------------------------|
| | |
Figure 2: Example for a 'Per-reference' Interaction A SAML assertion is a package of information including issuer and
subject, conditions and advice, and/or attribute statements, and/or
authentication statements and/or other statements. Statements may or
may not be present. The SAML assertion "container" itself contains
the following information:
The usage of SAML in HTTP-based environments and in SIP is, however, Issuing information:
affected by some architectural differences.
The user has to request an assertion at the Asserting Party and both Who issued the assertion, when was it issued and the assertion
entities mutually authenticate each other. The requested assertion identifier.
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 Subject information:
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: The name of the subject, the security domain and optional subject
a SIP proxy, which securely receives a SAML assertion (such as information, like public key.
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 Conditions under which the assertion is valid:
SIP transaction or dialog. Binding the assertion to a particular
protocol session is not useful if the property of single-sign on is
required.
To provide referential integrity the solution described in [I-D.ietf- Special kind of conditions like assertion validity period,
sip-authid-body] can be reused. Such an approach allows a party in a audience restriction and target restriction.
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 Additional advice:
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: Explaining how the assertion was made, for example.
Content-Type: message/sipfrag In terms of SAML assertions containing SAML attribute statements or
Content-Disposition: aib; handling=optional SAML authentication statements, here are explanatory examples:
From: Alice <sip:alice@example.com> With a SAML assertion containing a SAML attribute statement, an
To: Bob <sip:bob@example2.com> issuing authority is asserting that the subject is associated with
Contact: <sip:alice@pc33.example.com> certain attributes with certain subject profile attribute values.
Date: Thu, 26 Aug 2004 13:51:34 GMT For example, user jon@cs.example.com is associated with the
Call-ID: b76m5l94s90835 attribute "Department", which has the value "Computer Science".
CSeq: 435431 INVITE
Figure 3: AIB Format for an INVITE With a SAML assertion containing a SAML authentication statement,
an issuing authority is asserting that the subject was
authenticated by certain means at a certain time.
The same concept is applicable to this document as well with regard With a SAML assertion containing both a SAML attribute statement
to reference integrity. For a further discussion on this topic see and a SAML authentication statement, an issuing authority is
Section 14 and [I-D.peterson-message-identity]. asserting the union of the above.
6. Scenarios 4.2. Abstract Request/Response Protocol
This section shows message flows based on scenarios in [I-D.ietf- SAML defines an abstract request/response protocol for obtaining
sipping-trait-authz] enriched with a SAML based solution. assertions. See Section 3 "SAML Protocols" of
Section 6.1 provides an example of enhanced network asserted [OASIS.saml-core-2.0-os]. A request asks for an assertion. A
identities and Section 6.2 shows a SIP conferencing scenario with response returns the requested assertion or an error. This abstract
role-based access control using SAML. A future version of this protocol may then be cast into particular contexts of use by binding
document will cover more scenarios from [I-D.ietf-sipping-trait- it to specific underlying protocols, e.g., HTTP or SIP, and
authz]. "profiling" it for the specific use case at hand. The SAML HTTP-
based web single sign-on profile is one such example (see Section 4.1
Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait-
based SIP communication session establishment, the topic of this
specification, is another.
6.1 Network Asserted Identities 5. Employing SAML in SIP
Figure 4 shows an enhanced network asserted identity scenario based Employing SAML in SIP necessitates devising a new SAML profile or
on [I-D.ietf-sip-identity] which again utilizes extensions proposed profiles because the those already specified in the SAMLv2
with [I-D.ietf-sip-authid-body]. The enhancement is based on the specification set are specific to other use contexts, e.g., HTTP-
attributes asserted by the Authentication Service. based web browsing. Although SIP bears some similarity to HTTP, it
is a seperately distinct protocol, thus SAML profile specificity is
warranted. However, this should not present any untoward
difficulties due to SAML's inherent and explicit extensibility, and
also because SIP is similarly extensible.
Figure 4 shows three entities, Alice@example.com, AS@example.com and The "Authenticated Identity Management in SIP" specification
Bob@example2.com. If Alice wants to communicate with Bob, she sends [I-D.ietf-sip-identity] (aka "SIP Identity") facilitates the
a SIP INVITE to her preferred AS. Depending on the chosen SIP composition of SAML and SIP in that it defines a "mediated
security mechanism either digest authentication, S/MIME or Transport authentication architecture" where verifying endpoints verify SIP
Layer Security is used to provide the AS with a strong assurance identity assertions -- i.e., the "Identity" header value -- signed by
about the identity of Alice. During this step authorization an Authentication Service (AS). The semantic being that the AS is
attributes for inclusion into the SAML assertion can be selected. vouching that it did indeed authenticate the calling party.
After Alice is authenticated and authorized, a SAML assertion is Such an Authentication Service, which likely has access to various
attached to the SIP message. The Authentication Service can be pieces of information concerning the calling party, could also act as
configured to attach a number of assertions, not limited to the a SAML Authority, and make such information available to the callee
authenticated identity. via SAML.
To bind the SAML assertion to a specific SIP session, it is necessary Since [I-D.ietf-sip-identity] stipulates that the AS must make its
for the AS to compute a hash of some fields of the message. A list certificate available for retrieval and convey the availability and
of the fields to hash is described in [I-D.ietf-sip-identity] and access mechanism via a URI, in the Identity-Info header, we have an
particularly in [I-D.ietf-sip-authid-body]. The hash is digitally opportunity to compose SIP Identity and SAML.
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 Such composition can be accomplished by having the resource referred
solely used by SIP UAs. Assertions can also be helpful for SIP to by the URI in the Identity-Info be a SAML assertion conveying both
proxies or B2B UAs. the AS's certificate and user profile attributes. This is the
approach defined in this specification. Figure 1 illustrates this
approach in a high-level summary fashion. Figure 5, further below,
illustrates additional details.
+--------+ +--------------+ +--------+ +--------+ +--------------+ +--------+
|Alice@ | |Authentication| | Bob@ | |Alice@ | |Authentication| | Bob@ |
|example | |Service | |example2| |example | |Service | |example2|
|.com | |@example.com | |com | |.com | |@example.com | |com |
| | | | | | | | | | | |
+---+----+ +------+-------+ +---+----+ +---+----+ +------+-------+ +---+----+
| | | | | |
| INVITE | | | INVITE | |
|---------------------->| | |---------------------->| |
| From:alice@foo.com | | | From:alice@foo.com | |
| | | | | |
| 407 Proxy auth. req. | | | 407 Proxy auth. req. | |
|<----------------------| | |<----------------------| |
| Challenge | | | Challenge | |
| | | | | |
| Challenge response | | | ACK | |
|---------------------->| | |---------------------->| |
| | | | | |
| INVITE | | | INVITE w/authn creds | |
|---------------------->| | |---------------------->| |
| | INVITE | | | INVITE |
| | + SAML assertion | | | w/Identity header |
| |--------------------->| | |--------------------->|
| | and Identity-Info |
| | |
| | HTTP GET SAML assn |
| |<==================== |
| | and domain cert |
| | | | | |
| | HTTP 200 OK + assn |
| |=====================>|
| | and domain cert |
| 200 OK | | | 200 OK | |
|<----------------------+----------------------| |<----------------------+----------------------|
| | | | | |
Figure 4: Network Asserted Identities Figure 1: SIP-SAML-based Network Asserted Identity
A variation of the scenario presented in Figure 4 is given in Since the AS already being trusted to create and add the Identity
Figure 5 where an end host (Alice@example.com) obtains an assertion header containing the SIP Identity Assertion, and to supply a pointer
from its SIP proxy server which acts as an Authentication Service. to its domain certificate, having it point instead to a SAML
This assertion is then attached by the end host to the outgoing assertion conveying the domain certificate and possibly some user
INVITE message. Unlike in case of an artifact, Bob@example.com does profile attributes, does not significantly alter the first-order
not need to contact the Proxy Server. security considerations examined in [I-D.ietf-sip-identity]. This
specification provides some additional security considerations
analysis below in Section 10.
An example of this scenario could be to preempt a lower priority call 6. Use-case Scenarios
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).
+--------+ +--------------+ +--------+ This section shows message flows based on scenarios in [I-D.ietf-
| Alice@ | |Proxy Server | | Bob@ | sipping-trait-authz] enriched with a SAML based solution.
|example | |(AS | |example | Section 6.2 shows a SIP conferencing scenario with role-based access
|.com | |@example.com | |.com | control using SAML. A future version of this document will cover
| | | | | | more scenarios from [I-D.ietf-sipping-trait-authz].
+---+----+ +------+-------+ +---+----+
| | |
| 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 6.1. PSTN-to-SIP Phone Call
Note that Bob and Alice do not need to be in the same administrative Alice, using a phone connected to the PSTN, wants to make a call to
domain. It is feasible that Bob is in a domain that is federated Bob, which resides in a SIP network. Her call is switched through
with Alice's domain. 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's PSTN
phone was previously "authenticated" via PSTN signaling mechanisms,
the gateway is able to assert her phone's identity (e.g., her
telephone number) via SIP Identity and SAML-based mechanisms (e.g.,
in order to convey profile attributes) to Bob's SIP proxy, which also
dereferences the URI in the Identity-Info header in order to obtain
the SAML assertion and the PSTN/SIP Gateway's domain certificate.
Alice's INVITE is then forwarded from the SIP/PSTN gateway to Bob's
phone, and is secured via whatever means is locally established in
Bob's administrative 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. | | SS7 | PSTN/SIP |
| Public Switched |--------------------->| Gateway |
| | | |
| | | |
| Telephone Network | +--+-----------+------+
| ^ | | | ^ V |
+---------+------------+ | | ^ V SIP-Ident |
| SS7 | v ^ V +SAML |
| | +--------+ |
O | | Bob's | |
O /|\ <----+----| SIP | |
/|\ / \ SIP | | Proxy | |
/ \ Bob | | | |
Alice | +--------+ |
| SIP based |
| Network |
+---------------------+
6.2 SIP Conferencing Figure 2: PSTN to SIP call
This section is meant to raise some discussions about the usage of Note that the INVITE emitted by the PSTN/SIP gateway could
SAML in the domain of conferencing. A user who routes its SIP alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone,
message through the Authentication Service (Asserting Party) towards and Bob's phone could take on the SIP Identity "verifier" role, which
a conferencing server may want SAML assertions to be included. The is being played by Bob's SIP proxy in the figure.
following properties could be provided by this procedure:
Whichever approach is employed is a decision local to Bob's
administrative domain and can be made independently.
6.2. SIP Conferencing
This section is meant to foster discussion 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 or need various of her profile
attributes included and may also need to be authenticated by the
conference server. The following properties could be provided by
this procedure:
o The user identity can be replaced to allow the user to be o The user identity can be replaced to allow the user to be
anonymous with regard to the Focus anonymous with regard to the Focus. This can be accomplished via
[RFC3323] in combination with [I-D.ietf-sip-identity], per the
latter, or,
o The user identity could be asserted to the Focus o The user identity could be asserted to the Focus, via [I-D.ietf-
sip-identity] mechanisms, and/or,
o The SAML assertion could provide additional information such as o the SAML assertion could provide additional user profile
group membership (belongs to the students, staff, faculty group of information such as group membership (belongs to the students,
university X). This could, for non-identity-based authorization staff, faculty group of university X). This could, for non-
systems, imply certain rights. identity-based authorization systems, imply certain rights.
The corresponding SIP message flow (in high level detail) could have The corresponding SIP message flow (in high level detail) could have
the following shape: the following shape:
+-----+ +-----------+ +-----------+ +-----+ +-----------+ +-----------+
| | | SIP Proxy | | Focus | | | | SIP Proxy | | Focus |
|User | |(Asserting | | (Relying | |User | |(Asserting | | (Relying |
| | | party) | | party) | | | | party) | | party) |
+--+--+ +-----+-----+ +-----+-----+ +--+--+ +-----+-----+ +-----+-----+
| INVITE | | | INVITE | |
|sip:conf-factory | | |sip:conf-factory | INVITE |
|------------------>| INVITE+SAML | |------------------>| w/Identity hdr |
| |------------------>| | |------------------>|
| | | | | |
| | HTTP GET SAML assn|
| |<==================|
| | and domain cert |
| | |
| | HTTP 200 OK + assn|
| |==================>|
| | and domain cert |
| | |
| | |
| | Ringing | | | Ringing |
| Ringing |<------------------| | Ringing |<------------------|
|<------------------| | |<------------------| |
| | | | | |
| | OK | | | OK |
| OK |<------------------| | OK |<------------------|
|<------------------| | |<------------------| |
| | | | | |
| ACK | | | ACK | |
|------------------>| ACK | |------------------>| ACK |
| |------------------>| | |------------------>|
| | | | | |
| | | | | |
... many more msgs... ... many more msgs...
Figure 6: SIP Conferencing and SAML Figure 3: SIP Conferencing and SAML
6.3 PSTN-to-SIP Phone Call However, there are obvious scaling issues with the conference server
having to do the outbound requests in order to obtain SAML assertions
and certificates for conference participants.
Alice, using a phone connected to the PSTN, wants to make a call to This could be addressed by creating another SIP SAML Profile where
Bob, which resides in a SIP network. Her call is switched through the caller obtains the necessary information, e.g., SAML assertions,
the PSTN by means of PSTN signaling (outside the scope of this and places them into its SIP request message prior to sending it.
document) to the PSTN/SIP gateway. At the gateway, the call is This would obviate the need for the callee relying party to make
converted from SS7 signaling to SIP signaling. Since Alice was requests in order to obtain said information. This is a topic for
previously 'authenticated' through PSTN signaling mechanisms, the future work, and possibly future revisions of this specification.
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.
+-----------+ 6.3. Compensation using SIP and SAML
+----------------------+ | |
| | 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 This section describes a scenario where SAML is used in SIP to
realize compensation functionality as described in [I-D.jennings-
sipping-pay].
6.4 Compensation using SIP and SAML Note that this scenario is not directly addressed by the SIP SAML
Profile and SAML SIP Binding presently defined in this specification.
Rather, this use case calls for additional such profiles and bindings
to be developed.
This section briefly elaborates a scenario where SAML is used in SIP +--------+ +--------+ +--------+
to realize compensation functionality as described in [I-D.jennings- |Payment | | User | |Merchant|
sipping-pay] |Provider| | Alice | |Bob |
| | | | | |
| | | | | |
+---+----+ +---+----+ +---+----+
| | |
| | 1) Call |
| |------------------------>|
| | |
| | 2) 402 + Payment Offer |
| 3) Request for |<------------------------|
| a Payment | |
|<----------------------| |
| | |
| 4) SAML Assertion | |
| (=Receipt) | |
|---------------------->| |
| | 5) Call + Receipt |
| |------------------------>|
| | |
| | 6) 200 OK |
| |<------------------------|
| | |
Section 1 of [I-D.jennings-sipping-pay] shows a message exchange Figure 4: Message flow for SIP payment
which is used by a number of payment protocols and hence can also be
used by a SAML specified protocol. To avoid repetition in this
document a second alternative is provided in Figure 8. Alice
initiates a communication with an Authentication Service which acts
as a financial institution. 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 with the assertion. Bob verifies the
assertion and, it 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 immediate amount deduction may take
place (e.g., in case of a prepaid account) or the amount is captured
as a batch transaction.
The aspect of lightweight protocol execution is provided by User Alice and the Merchant Bob interacts with each other using SIP
and the Alice uses HTTP to exchange messages with a Payment Provider.
Initially, Alice makes a call to Bob (1). Bob determines that a
payment is required and includes information about the payment in an
Offer body of a 402 (Payment Required) response to Alice (2). Alice
looks at this Offer and decides to make a payment. Alice therefore
instructs her Payment Provider to make a transfer from the Alice's
account to the Merchants's account (3) using a request for a SAML
assertion with the extensions defined in this document. The Payment
Provider returns a receipt for this transfer (4). This receipt is a
SAML Assertion (or a SAML Artifact, if the exchange is triggered by a
proxy or if desired by the Customer). Alice resubmits the call to
Bob but this time provides the Receipt for the transaction (5). Bob
determines whether the Receipt is valid (by checking the digital
signature and the content of the assertion) and continues with the
call processing, if the authorization was succesful.
o The alternative usage of an artifact which leads to a lower The Offer contains information about the three parties, the Payment
bandwidth consumption. Provider, that are acceptable to the Merchant Bob, the amount of
transaction, the account identifier for Bob at the Payment Provider,
and a replay protection indicator to make it easier for the Merchant
Bob to avoid replay attacks. User Alice includes this information
when making the Request for Payment to the Payment Provider; adds its
own account information and authorization password; and sends this to
the Payment Provider, which produces a Receipt for the transaction if
it is successful. This transfer from Alice to the Payment Provider
is made across an encrypted, integrity protected channel. The
Receipt includes a timestamp when the Payment Provider made the
transaction and protects the Receipt with a digital signature. Alice
resubmits the call to the Merchant Bob with the Receipt from the
Payment Provier. Merchant Bob can check for replay attacks using the
timestamp and a replay protection indiciator initially provided with
the Offer. Bob can then check the signature is valid using the
Payment Provider's public key.
o The ability to use a single assertion for multiple service access 7. SIP SAML Profiles
protocol executions, if desired.
o SAML, furthermore allows a cryptographic key to be bound to an This section defines one SIP SAML profile:
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 devices
have performance limitations. In this case, it might be useful to
rely on symmetric cryptographic, such as hash chains.
+--------+ +--------------+ +--------+ The "AS-driven SIP SAML URI-based Attribute Assertion Fetch
|User | |Authentication| |Merchant| Profile"
|Alice | |Server | |Bob |
| | |(Trusted Third| | |
| | | Party) | | |
+---+----+ +------+-------+ +---+----+
| | |
| SIP, HTTP, etc. | |
|---------------------->| |
| | |
| Assertion | |
|<----------------------| |
| | |
| | |
| INVITE + SAML assertion |
|-----------------------+--------------------->|
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
Figure 8: Message flow for SIP payment 7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile
The main difference between the above-described mechanism and the one 7.1.1. Required Information
described in Section 1 of [I-D.jennings-sipping-pay] is the degree of
user involvement and the type of 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.
7. SIP-SAML Extension The information given in this section is similar to the info provided
when registering something, a MIME Media Type, say, with IANA. In
this case, it is for registering this profile with the OASIS SSTC.
See Section 2 "Specification of Additional Profiles" in [OASIS.saml-
profiles-2.0-os].
To carry SAML assertions and artifacts two mechanisms are defined: Identification:
o The SIP header may either carry an Artifcat or a CID URI [RFC2392] urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0
pointing to an assertion in the SIP body. The name of this new
SIP header is SAML-Assertion. 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 @@ NOTE: This URN must be agreed upon, and then registered with
of this SAML assertion is defined in [I-D.hodges-saml-mediatype]. IANA per [RFC3553].
A SIP user agent may add an assertion to the body of a SIP message or Contact Information:
may add a reference to the assertion into the SIP header. SIP
proxies MUST NOT add the assertion to the body. 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 @@ someone's or something's contact info goes here
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 SAML Confirmation Method Identifiers:
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.
8. Example The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is
used in this profile.
This is an example of a SAML assertion and how it is structured in Description:
XML.
<saml:Assertion Given below.
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: Updates:
+---------------------+-----+-------------------------------+ None.
| 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 |
+---------------------+-----+-------------------------------+
|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 7.1.2. Profile Overview
9. Requirement Comparison Figure 5 illustrates this profile's overall protocol flow. The
following steps correspond to the labeled interactions in the figure.
Within an individual step, there may be one or more actual message
exchanges depending upon the protocol binding employed for that
particular step and other implementation-dependent behavior.
A future version of this document will compare the requirements Although this profile is overview is cast in terms of a SIP INVITE
listed in [I-D.ietf-sipping-trait-authz] with the solution provided transaction, the reader should note that the mechanism specified
in this document. herein, and in [I-D.ietf-sip-identity], may be applied to any SIP
request message.
10. Security Considerations Figure 5 begins on the next page.
This section discusses security considerations when using SAML with +------------------+ +------------------+ +-----------------+
SIP. | Caller | |Authn Service (AS)| | Callee |
|Alice@example.com | | @example.com | | Bob@example2.com|
+--------+---------+ +--------+---------+ +--------+--------+
- - | | | (steps)
^ ^ | INVITE | |
| | |---------------------->| | (1a)
| | From:alice@foo.com | |
| C | To:sip:bob@example.com| |
| S | | |
| e | 407 Proxy auth. req. | |
| q |<----------------------| | (1b)
| = | Challenge | |
| N | | |
| | ACK | |
| | |---------------------->| | (1c)
| V | | |
| - | | |
^ | INVITE + authorization| |
D | | header w/ creds | |
| |---------------------->| | (2)
I | | From:alice@foo.com | |
| | To:sip:bob@example.com| |
A | Proxy-Authorization:..| |
C | | INVITE |
L S | |--------------------->| (3)
e | | From:alice@foo.com |
O q | | To:sip:bob@example2.com
| | Identity: ..... |
G = | | Identity-Info: |
| | https://example.com|
| N | | /assns/?ID=abcde |
| | | |
| + | |URI resolution (eg. HTTP)
| | |<=====================| (4)
| 1 | | GET /assns/?ID=abcde |
| | | |
| | | | HTTP/1.1 200 OK |
| | | |=====================>| (5)
| | | | <saml:Assertion> |
| | | | <saml:Subject> |
| | | | <saml:NameID> |
| | | | Alice@example.com
| | | | <saml:SubjConf>
| | | | <saml:SubjConfData>
| | | | <ds:KeyInfo>...
| | | | <saml:AttrStatement>
| | | | foo=bar |
| | | 200 OK | |
| V |<----------------------+----------------------| (6)
. - | | |
V
10.1 Stolen Assertion Figure 5: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE
Transaction
Threat: Step 1. Initial SIP Transaction between Caller and AS
If an eavesdropper can copy the real user's SAML response and This optional initial step is comprised of substeps 1a, 1b,
included assertions and construct a SIP message of his own, then and 1c in Figure 5. In this step, the caller, Alice, sends a
the eavesdropper could be able to impersonate the user at other SIP request message, illustrated as an INVITE, indicating Bob
SIP entities. as the callee (1a), is subsequently challenged by the AS
(1b), and sends an ACK in response to the challenge (1c).
The latter message signals the completion of this SIP
transaction (which is an optional substep of this profile).
Countermeasures: Step 2. Caller sends SIP Request Message with Authorization
Credentials to the AS
By providing adequate confidentiality, eavesdropping of a SAML Alice then sends an INVITE message in response to the
assertion can be stopped. challenge, or uses cached credentials for the domain if step
1 was skipped, as specified in [I-D.ietf-sip-identity] and
[RFC3261]. 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.
10.2 MitM Attack Step 3. AS Authorizes the SIP Request and Forwards it to Callee
Threat: First, the AS authorizes the received INVITE message as
specified in [I-D.ietf-sip-identity] and [RFC3261]. If the
authorization is successful, the AS will form the "identity
signature" for the message and add Identity and Identity-Info
headers to the message. The AS also at this time constructs
and caches a SAML assertion asserting Alice's profile
attributes required by Bob's domain (example2.com), and also
containing a the domain's (example.com) public key
certificate, or a reference to it. This certificate MUST
contain the public key corresponding to the private key used
to construct the signature whose value was placed in the
Identity header. The AS constructs a HTTP-based SAML URI
Reference incorporating the assertion's Assertion ID (see
section 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this
URI as the value for the Identity-Info header it adds to the
INVITE message.
Since the SAML assertion is carried within a SIP message, a The AS determines which profile attributes (if any) to assert
malicious site could impersonate the user at some other SIP in the <AttributeStatement> via local configuration and/or
entities. These SIP entities would believe the adversary to be obtaining example2.com's metadata
the subject of the assertion. [OASIS.saml-metadata-2.0-os]. The AS then sends the updated
INVITE message to Bob.
Countermeasures: Step 4. Callee Dereferences HTTP-based SAML URI Reference
If the adversary is a not-participating in the SIP signaling Bob's UAC or SIP Proxy receives the message and begins
itself (i.e., it is not a SIP proxy or a SIP UA), this threat can verifying it per the "Verifier Behavior" specified in
be eliminated by employing inherent SIP security mechanisms, such [I-D.ietf-sip-identity]. In order to accomplish this task,
as TLS. However, if this entity is part of the communication it needs to obtain Alice's domain certificate. It obtains
itself then reference integrity needs to be provided. Assertions the HTTP-based SAML URI Reference from the message's
with tight restrictions (e.g., validity of the assertion) can also Identity-Info header and dereferences it per Section 8.1.
limit the possible damage. Note that this is not a SIP message, but an HTTP message
[RFC2616].
10.3 Forged Assertion Step 5. AS Returns SAML Assertion
Threat: Upon receipt of the above HTTP request, which contains an
embedded reference to Alice's SAML Assertion, Alice's AS
returns her assertion in an HTTP response message.
A malicious user could forge or alter a SAML assertion in order to Upon receipt of Alice's SAML Assertion, the AS continues its
communicate with the SIP entities. verification of the INVITE message. If successful, it
returns a 200 OK message directly to Alice. Otherwise it
returns an appropriate SIP error response.
Countermeasures: Step 6. Callee Returns SIP 200 OK to Caller
To avoid this kind of attack, the entities must assure that proper If Bob determines, based upon Alice's identity as asserted by
mechanisms for protecting the SAML assertion needs to be in place. the AS, and as further substantiated by the information in
It is recommended to protect the assertion using a digital the SAML assertion, to accept the INVITE, he returns a SIP
signature. 200 OK message directly to Alice.
10.4 Replay Attack 7.1.3. Profile Description
Threat: The following sections provide detailed definitions of the individual
profile steps. The relevant illustration is Figure 6, below. Note
that this profile is agnostic to the specific SIP request, and also
that the Sender and Authentication Service (AS) may be seperate or
co-located in actuality.
In the case of using SIP with a 'by-reference' model, the threat +------------------+ +------------------+ +------------------+
of replay lies in the fact that the artifact is a one-time-use | Sender | |Authn Service (AS)| | Verifier |
subject. The same artifact can be used again to gain access to | (UAC) | | (Sender's) | |(UAS or Proxy Svr)|
resources. +--------+---------+ +--------+---------+ +--------+---------+
| | | (steps)
| SIP Request | |
|---------------------->| | (1a)
| | |
| 407 Proxy auth. req. | |
|<----------------------| | (1b)
| Challenge | |
| | |
| ACK | |
|---------------------->| | (1c)
| | |
| | |
|SIP Req + authorization| |
| header w/ creds | |
|---------------------->| | (2)
| | |
| | |
| | SIP Req + Ident & |
| | authz headers |
| |--------------------->| (3)
| | |
| | URI resolution |
| |<=====================| (4)
| | (via HTTP) |
| | |
| | HTTP/1.1 200 OK |
| |=====================>| (5)
| | |
| | |
| | ? | (6)
| | |
Countermeasures: Figure 6: AS-driven SIP SAML Attribute Fetch Profile: Message Flow
Cases where multiple requests are made which references the same 7.1.3.1. Initial SIP Transaction between Sender and AS
request must be tracked in order to avoid the threat.
11. Contributors This OPTIONAL step maps to Steps 1 and 2 of Section 5 "Authentication
Service Behavior" of [I-D.ietf-sip-identity]. If the SIP request
sent by the caller in substep 1a is deemed insufficiently
authenticated by the AS per the rules stipulated by [I-D.ietf-sip-
identity] Steps 1 and 2, then the AS MUST authenticate the sender of
the message. The particulars of how this is accomplished depend upon
implementation and/or deployment instantiation as discussed in
The authors would like to thank Henning Schulzrinne for his [I-D.ietf-sip-identity]. Substeps 1b and 1c as shown in Figure 6 are
contributions to this document. non-normative and illustrative only.
12. Acknowledgments 7.1.3.2. Sender sends SIP Request Message with Authorization
Credentials to the AS
We would like to thank RL 'Bob' Morgan and Stefan Goeman for their This step maps to Steps 1 and 2 of Section 5 "Authentication Service
comments to this draft. Behavior" of [I-D.ietf-sip-identity]. This request is presumed to be
made in a context such that the AS will not challenge it -- i.e., the
AS will consider the sender of the message to be authenticated. If
this is not true, then this procedure reverts back to Step 1, above.
13. IANA Considerations Otherwise, the AS carries out all other processing of the message as
stipulated in [I-D.ietf-sip-identity] Steps 1 and 2, and if
successful, this procedure procedes to the next step below.
This document contains a number of IANA considerations. A future 7.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier
version of this document will list them in this section.
14. Open Issues This first portion of this step maps to Steps 3 and 4 of Section 5
"Authentication Service Behavior" of [I-D.ietf-sip-identity], which
the AS MUST perform, although with the following additional substeps:
This document raises a number of issues with regard to the SIP The AS MUST construct a SAML assertion according to the "Assertion
protocol interaction. Some of them are raised in this document (such Profile Description" specified in Section 7.1.4 of this
as reference integrity, who is allowed to add which information, specification.
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: The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI
per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os].
This aspect deals with the problem of binding a SIP assertion to a The AS MUST use the URI constructed in the immediately preceding
specific SIP message. The goal is to provide a security property substep as the value of the Identity-Info header that is added to
called reference integrity to prevent replay and impersonation the SIP request message per Step 4 of Section 5 of [I-D.ietf-sip-
attacks. As described in Section 5 that a number of fields can be identity].
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: Upon successful completion of all of the above, the AS forwards the
request message.
To provide reference integrity a few selected fields need to be At this point in this step, after perhaps traversing some number of
hashed, signed and placed into the assertion. Two approaches are intermediaries, the SIP request message arrives at a SIP network
available for this purpose. Hence it needs to be studied how the entity performing the "verifier" role. This role and its behavior
interworking between reference integrity and the usage of obtained are specified in Section 6 "Verifier Behavior" of [I-D.ietf-sip-
SAML assertion can be properly accomplished. For example, who identity]. The verifier MUST perform the steps enumerated in the
indicates which fields are included? aforementioned section, with the following modifications:
Alignment with SIP Identity: Step 1 of [I-D.ietf-sip-identity] Section 6 maps to and is updated
by, the following two steps in this procedure.
It might be good to avoid the definition of a second set of Steps 2, 3, and 4 of [I-D.ietf-sip-identity] Section 6 may be
response codes for SAML conditions which will overlap with the mapped across this latter portion of this step, and/or the
response codes defined for SIP Identity draft. following two steps, as appropriate.
Placement of Assertions and Keys in Messages: 7.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference
This document assumes that the assertions are added to the SIP The verifier SHOULD ascertain whether it has a current cached copy of
body and artifacts or references to assertions located in the SIP the SIP message sender's SAML assertion and domain certificate. If
body are added to the SIP header. A central question is therefore not, or if the verifier chooses to (e.g., due to local policy), it
where these assertions should be attached? Should the SIP user MUST dereference the the HTTP-based SAML URI Reference found in the
agent or intermediate SIP proxies add assertions/artifacts? In SIP message's Identity-Info header. To do so, the verifier MUST
the scenarios depicted in Section 6, we have both approaches employ the "SAML HTTP-URI-based SIP Binding" specified in
depending on what kind of scenario it is. In Figure 4, they are Section 8.1.
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 7.1.3.5. AS Returns SAML Assertion
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 discussion.
To provide reference integrity (by binding a SIP session and a SAML This step also employs Section 8.1 "SAML HTTP-URI-based SIP Binding".
assertion together) two alternative approaches exist:
Hashing of SIP message fields: If the prior step returns an HTTP error (e.g., 4xx series), then this
procedure terminates and the verifier returns (upstream) a SIP 436
'Bad Identity-Info' Response code.
If a hash is computed over a number of selected SIP fields and Otherwise, the HTTP response message will contain a SAML assertion
subsequently digitally signed then there is a some degree of and be denoted as such via the MIME media type of "application/
protection that the assertion cannot be copied to other SIP samlassertion+xml" [IANA.application.samlassertion-xml]. The
messages and reused. The drawback thereby is that the assertion verifier MUST perform the verification steps specified in
has a very limited time period. The hashed fields may vary from Section 7.1.5 "Assertion Verification", below. If successful, then
context to context. this procedure continues with the next step.
Holder-of-the-Key Assertion: 7.1.3.6. Verifier performs Next Step
SAML introduces the concept of a holder-of-the-key assertion to The SIP request was successfully processed. The verifier now
bind the assertions (authorization information) to a cryptographic performs its next step, which depends at least in part on the type of
key. As a result, the end host which was quite passive when SIP request it received.
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 7.1.4. Assertion Profile Description
Holder-of-the-Key assertion as described in Section 4.4 of [xmldsig-
core].
Further open issues are: This section defines the particulars of how the sender, i.e., the
SAML Authority, MUST construct certain portions of the SAML
assertions it issues. The schema for SAML assertions themselves is
defined in Section 2.3 of [OASIS.saml-core-2.0-os].
o Some work on option-tags is required. Are there cases when An example SAML assertion, formulated according to this profile is
processing of the assertion would be required by the sender? Or given in Section 9.
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 Overall SAML assertion profile requirements:
the bindings or profiles must be defined and registered 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 The SAML assertion MUST be signed by the same key as used to sign
properties as the hash over the various headers/bodies proposed in the contents of the Identity header field. Signing of SAML
the identity draft. assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].
o Further use cases would be interesting. For example, a mechanism In the following subsections, the SAML assertion profile is specified
to provide additional security for the SIP REFER method [RFC3515]. element-by-element, in a top-down, depth-first manner, beginning with
the outermost element, "<Assertion>". Where applicable, the
requirements for an element's XML attributes are also stated, as a
part of the element's description. Requirements for any given
element or XML attribute are only stated when, in the context of use
of this profile, they are not already sufficiently defined by
[OASIS.saml-core-2.0-os].
o A few new URIs need to be registered. The proposed URIs for 7.1.4.1. Element: <Assertion>
identification are:
SIP Binding: urn:oasis:names:tc:SAML:1.0:bindings:SIP-binding Attribute: ID
Artifact The value for the ID XML attribute SHOULD be allocated randomly
profile: urn:oasis:names:tc:SAML:1.0:profiles:SIP-artifact-01 such that the value meets the randomness requirments specified in
Section 1.3.4 of [OASIS.saml-core-2.0-os].
Assertion Attribute: IssueInstant
profile: urn:oasis:names:tc:SAML:1.0:profiles:SIP-assertion-01
o The proposed URIs for Confirmation Method Identifiers are: The value for the IssueInstant XML attribute SHOULD be set at the
time the SAML assertion is created (and cached for subsequent
retrieval). This time instant value MAY be temporally the same as
that encoded in the SIP message's Date header, and MUST be at
least temporally later, although it is RECOMMENDED that it not be
10 minutes or more later.
Artifact profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-artifact-01 7.1.4.1.1. Element: <Issuer>
Assertion profile: urn:oasis:names:tc:SAML:1.0:cm:SIP-bearer The value for the Issuer XML element MUST be a value that matches
either the Issuer or the Issuer Alternative Name fields [RFC3280] in
the certificate conveyed by the SAML assertion in the ds:
X509Certificate element located on this path within the SAML
assertion:
o These are based on the URIs already used in the existing SOAP-SAML <Assertion
binding, specified in Section 3 of [I-D.saml-bindings-1.1]. <ds:Signature
<ds:KeyInfo
<ds:X509Data
<ds:X509Certificate
o An alignment with the work done by Liberty Alliance on Federated 7.1.4.1.2. Element: <Subject>
Identities as described in [I-D.liberty-idff-arch-overview] would
be useful.
o The security consideration needs more details. The <Subject> element SHOULD contain both a <NameID> element and a
<SubjectConfirmation> element.
15. References The value of the <NameID> element MUST be the same as the Address of
Record (AoR) value used in computing the "signed-identity-digest"
which forms the value of the Identity header. See Section 9 of
[I-D.ietf-sip-identity].
15.1 Normative References The <SubjectConfirmation> element attribute Method SHOULD be set to
the value:
[I-D.hodges-saml-mediatype] urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
Hodges, J., "application/saml+xml Media Type
Registration", draft-hodges-saml-mediatype-01 (work in Although it MAY be set to some other implementation- and/or
progress), June 2004. deployment-specific value. The <SubjectConfirmation> element itself
SHOULD be empty.
7.1.4.1.3. Element: <Conditions>
The <Conditions> element SHOULD contain an <AudienceRestriction>
element, which itself SHOULD contain an <Audience> element. The
value of the <Audience> element SHOULD be the same as the addr-spec
of the SIP request's To header field.
The following XML attributes of the <Conditions> element MUST be set
as follows:
Attribute: NotBefore
The value of the NotBefore XML attribute MUST be set to a time
instant the same as the value for the IssueInstant XML attribute
discussed above, or to a later time.
Attribute: NotOnOrAfter
The value of the NotOnOrAfter XML attribute MUST be set to a time
instant later than the value for NotBefore.
7.1.4.1.4. Element: <AttributeStatement>
The SAML assertion MAY contain an <AttributeStatement> element. If
so, the <AttributeStatement> element will contain attribute-value
pairs, e.g., of a user profile nature, encoded according to either
one of the "SAML Attribute Profiles" as specified in [OASIS.saml-
profiles-2.0-os], or encoded in some implementation- and/or
deployment-specific attribute profile.
The attribute-value pairs SHOULD in fact pertain to the entity
identified in the SIP From header field, since a SAML assertion
formulated per this overall section is stating that they do.
7.1.5. Assertion Verification
This section specifies the steps that a verifier participating in
this profile MUST perform in addition to the "Verifier Behavior"
specified in Section 6 of [I-D.ietf-sip-identity].
The steps are:
1. Before Step 1 in Section 6 of [I-D.ietf-sip-identity], the
verifier MUST extract the AS's domain certificate from the <ds:
X509Certificate> XML element at the end of the element path
given in Section 7.1.4.1.1.
2. Perform Step 1 in Section 6 of [I-D.ietf-sip-identity].
3. After Step 1 in Section 6 of [I-D.ietf-sip-identity], but before
Step 2 of that section, the verifier MUST verify the SAML
assertion's signature via the procedures specified in Section
5.4 of [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core].
@@ TODO: do we need to define a new SIP error response code for
when a SAML assn signature is bad? e.g., '4xx Invalid SAML
asssertion'.
4. Perform Step 2 in Section 6 of [I-D.ietf-sip-identity].
5. Verify that the signer of the SIP message's Identity header
field is the same as the signer of the SAML assertion.
6. Perform Steps 3 and 4 in Section 6 of [I-D.ietf-sip-identity].
7. Verify that the SAML assertion's <Issuer> element value matches
the Issuer or the Issuer Alternative Name fields [RFC3280] in
the AS's domain certificate.
8. Verify that the SAML assertion's <NameID> element value is the
same as the Address of Record (AoR) value in the "signed-
identity-digest". See Section 9 of [I-D.ietf-sip-identity].
9. Verify that the SAML assertion's <SubjectConfirmation> element
value is set to whichever value was configured at
implementation- or deployment-time. The default value is:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
10. Verify that the SAML assertion contains an <Audience> element,
and that its value matches the value of the addr-spec of the SIP
To header field.
11. Verify that the validity period denoted by the NotBefore and
NotOnOrAfter attributes of the <Conditions> element meets the
requirements given in Section 7.1.4.1.3.
8. SAML SIP Binding
This section specifies one SAML SIP Binding at this time. Additional
bindings may be specified in future revisions of this specification.
8.1. SAML HTTP-URI-based SIP Binding
This section specifies the "SAML HTTP-URI-based SIP Binding",
(SHUSB).
The SHUSB is a profile of the "SAML URI Binding" specified in Section
3.7 of [OASIS.saml-bindings-2.0-os]. The SAML URI Binding specifies
a means by which SAML assertions can be referenced by URIs and thus
be obtained through resolution of such URIs.
This profile of the SAML URI Binding is congruent with the SAML URI
Binding -- including support for HTTP-based URIs being mandatory to
implement -- except for the following further restrictions which are
specified in the interest of interoperability (section numbers refer
to [OASIS.saml-bindings-2.0-os]):
Section 3.7.5.3 Security Considerations:
Support for TLS 1.0 or SSL 3.0 is mandatory to implement.
Section 3.7.5.4 Error Reporting:
All SHOULDs in this section are to be interpreted as MUSTs.
9. Example Signed SAML Assertion
Below is an example of a signed SAML assertion:
<Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
<Issuer>
example.com
</Issuer>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
<ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<ds:Reference URI="#_a75adf55-01d7-40cc-929f-dbd8372ebdfc">
<ds:Transforms>
<ds:Transform
Algorithm=
"http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform
Algorithm=
"http://www.w3.org/2001/10/xml-exc-c14n#">
<InclusiveNamespaces
PrefixList="#default saml ds xs xsi"
xmlns=
"http://www.w3.org/2001/10/xml-exc-c14n#"/>
</ds:Transform>
</ds:Transforms>
<ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<ds:DigestValue>
Kclet6XcaOgOWXM4gty6/UNdviI=
</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>
hq4zk+ZknjggCQgZm7ea8fI7...Hr7wHxvCCRwubnmIfZ6RqVL+wNmeWI4=
</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>
MIICyjCCAjOgAwIBAgICAnUwDQYJKoZIhvcNAQEEBQAwgakxCzAJBgNVBAYTAlVT
MRIwEAYDVQQIEwlXaXNjb ..... dnP6Hr7wHxvCCRwubnmIfZ6QZAv2FU78pLX
8I3bsbmRAUg4UP9hH6ABVq4KQKMknxu1xQxLhpR1ylGPdiowMNTrEG8cCx3w/w==
</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
<Subject>
<NameID
Format=
"urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">
Alice@example.com
</NameID>
<SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:sender-vouches"/>
</Subject>
<Conditions NotBefore="2003-04-17T00:46:02Z"
NotOnOrAfter="2003-04-17T00:51:02Z">
<AudienceRestriction>
</AudienceRestriction>
</Conditions>
<AttributeStatement>
...
</AttributeStatement>
</Assertion>
10. Security Considerations
This section discusses security considerations when using SAML with
SIP.
10.1. Man-in-the-middle Attacks and Stolen Assertions
Threat:
By making SAML assertions available via HTTP-based requests by a
potentially unbounded set of requesters, it is conceivably
possible that anyone would be able to simply request one and
obtain it. SIP intermediaries on the signaling path for example.
Or, an HTTP intermediary/proxy could intercept the assertion as it
is being returned to a requester.
The attacker could then conceivably attempt to impersonate the
subject (the putative caller) to some SIP-based target entity.
Countermeasures:
Such an attack is implausible for several reasons. The primary
reason is that a message constructed by an imposter using a stolen
assertion that conveys the public key certificate of some domain
will not verify per [I-D.ietf-sip-identity] because the imposter
will not have the corresponding private key with which to generate
the signed Identity header value.
Also, the SIP SAML assertion profile specified herein that the
subject's SAML assertion must adhere to causes it to be not useful
to arbitrary parties. The subject's assertion:
* should be signed, thus causing any alterations to break its
integrity and make such alterations detectable.
* does not contain an authentication statement. Thus no parties
implementing this specification should be relying on SAML
assertions specified herein as sufficient in and of themselves
to allow access to resources.
* relying party is represented in the SAML assertion's Audience
Restriction.
* Issuer is represented in the SAML assertion.
* validity period for assertion is restricted.
* etc.
10.2. 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 are employed, e.g.,
signing the SAML assertion itself. Section 5.1 of [OASIS.saml-
core-2.0-os] specifies the signing of SAML assertions.
Additionally, the assertion content dictated by the SAML assertion
profile herein ensures ample evidence for a relying party to
verify the assertion and its relationship with the received SIP
request.
10.3. Replay Attack
Threat:
Theft of SIP message protected by the mechanisms described herein
and replay of it at a later time.
Countermeasures:
There are various provisions within [I-D.ietf-sip-identity] that
prevent a replay attack.
11. Contributors
The authors would like to thank Marcus Tegnander and Henning
Schulzrinne for his contributions to earlier versions of this
document.
12. Acknowledgments
We would like to thank RL 'Bob' Morgan and Stefan Goeman for their
comments to this draft.
13. Acknowledgments
We thank RL 'Bob' Morgan for his inputs to this work. The "AS-driven
SIP SAML URI-based Attribute Assertion Fetch Profile" is based on an
idea by Jon Peterson.
Addtionally, the following persons provided input to this work:
Stefan Goeman, Shida Schubert, Jason Fischl
14. IANA Considerations
This document contains a number of IANA considerations. A future
version of this document will list them in this section.
15. Open Issues
A list of open issues can be found at:
http://www.tschofenig.com:8080/saml-sip/
16. References
16.1. Normative References
[I-D.ietf-sip-identity]
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-06
(work in progress), October 2005.
[I-D.ietf-sipping-trait-authz] [I-D.ietf-sipping-trait-authz]
Peterson, J., "Trait-based Authorization Requirements for Peterson, J., "Trait-based Authorization Requirements for
the Session Initiation Protocol (SIP)", the Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-01 (work in progress), draft-ietf-sipping-trait-authz-02 (work in progress),
February 2005. January 2006.
[OASIS.saml-bindings-2.0-os]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS
Standard saml-bindings-2.0-os, March 2005.
[OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion
Markup Language (SAML) V2.0", OASIS Standard saml-core-
2.0-os, March 2005.
[OASIS.saml-metadata-2.0-os]
Cantor, S., Moreh, J., Philpott, R., and E. Maler,
"Metadata for the Security Assertion Markup Language
(SAML) V2.0", OASIS Standard saml-metadata-2.0-os,
March 2005.
[OASIS.saml-profiles-2.0-os]
Hughes, J., Cantor, S., Hodges, J., Hirsch, F., Mishra,
P., Philpott, R., and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource [RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998. Locators", RFC 2392, August 1998.
15.2 Informative References [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[I-D.ietf-sip-authid-body] [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
Peterson, J., "SIP Authenticated Identity Body (AIB) A., Peterson, J., Sparks, R., Handley, M., and E.
Format", draft-ietf-sip-authid-body-03 (work in progress), Schooler, "SIP: Session Initiation Protocol", RFC 3261,
May 2004. June 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004.
[W3C.xmldsig-core]
Eastlake, D., Reagle , J., and D. Solo, "XML-Signature
Syntax and Processing", W3C Recommendation xmldsig-core,
October 2000, <http://www.w3.org/TR/xmldsig-core/>.
16.2. Informative References
[I-D.ietf-sip-content-indirect-mech] [I-D.ietf-sip-content-indirect-mech]
Burger, E., "A Mechanism for Content Indirection in Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", Session Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-05 (work in draft-ietf-sip-content-indirect-mech-05 (work in
progress), October 2004. progress), October 2004.
[I-D.ietf-sip-identity]
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-05
(work in progress), May 2005.
[I-D.ietf-sipping-certs] [I-D.ietf-sipping-certs]
Jennings, C. and J. Peterson, "Certificate Management Jennings, C. and J. Peterson, "Certificate Management
Service for The Session Initiation Protocol (SIP)", Service for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-01 (work in progress), draft-ietf-sipping-certs-02 (work in progress), July 2005.
February 2005.
[I-D.jennings-sipping-pay] [I-D.jennings-sipping-pay]
Jennings, C., "Payment for Services in Session Initiation Jennings, C., "Payment for Services in Session Initiation
Protocol (SIP)", draft-jennings-sipping-pay-01 (work in Protocol (SIP)", draft-jennings-sipping-pay-03 (work in
progress), February 2005. progress), October 2005.
[I-D.liberty-idff-arch-overview]
Wason, T., "Liberty ID-FF Architecture Overview", 2004.
[I-D.peterson-message-identity] [I-D.peterson-message-identity]
Peterson, J., "Security Considerations for Impersonation Peterson, J., "Security Considerations for Impersonation
and Identity in Messaging Systems", and Identity in Messaging Systems",
draft-peterson-message-identity-00 (work in progress), draft-peterson-message-identity-00 (work in progress),
October 2004. October 2004.
[I-D.saml-bindings-1.1] [IANA.application.samlassertion-xml]
Maler, E., Philpott, R., and P. Mishra, "Bindings and OASIS Security Services Technical Committee (SSTC),
Profiles for the OASIS Security Assertion Markup Language "application/samlassertion+xml MIME Media Type
(SAML) V1.1", September 2003. Registration", IANA MIME Media Types Registry application/
samlassertion+xml, December 2004.
[I-D.saml-core-1.1] [OASIS.draft-saml-protocol-ext-02]
Maler, E., Philpott, R., and P. Mishra, "Assertions and Cantor, S., "SAML Protocol Extensions", OASIS SSTC Working
Protocol for the OASIS Security Assertion Markup Language Draft draft-saml-protocol-ext-02, Februrary 2006.
(SAML) V1.1", September 2003.
[I-D.saml-sec-consider-1.1] [OASIS.saml-conformance-2.0-os]
Maler, E. and R. Philpott, "Security and Privacy Mishra, P., Philpott, R., and E. Maler, "Conformance
Considerations for the OASIS Security Markup Language Requirements for the Security Assertion Markup Language
(SAML) V1.1", September 2003. (SAML) V2.0", OASIS Standard saml-conformance-2.0-os,
March 2005.
[I-D.saml-tech-overview-1.1-03] [OASIS.saml-glossary-2.0-os]
Maler, E. and J. Hughes, "Technical Overview of the OASIS Hodges, J., Philpott, R., and E. Maler, "Glossary for the
Security Assertion Markup Language (SAML) V1.1", Security Assertion Markup Language (SAML) V2.0", OASIS
March 2004. Standard saml-glossary-2.0-os, March 2005.
[OASIS.saml-sec-consider-2.0-os]
Hirsch, F., Philpott, R., and E. Maler, "Security and
Privacy Considerations for the OASIS Security Markup
Language (SAML) V2.0", OASIS Standard saml-sec-consider-
2.0-os, March 2005.
[OASIS.sstc-saml-exec-overview-2.0-cd-01]
Madsen, P. and E. Maler, "SAML V2.0 Executive Overview",
OASIS SSTC Committee
Draft sstc-saml-exec-overview-2.0-cd-01, April 2005.
[OASIS.sstc-saml-tech-overview-2.0-draft-08]
Hughes, J. and E. Maler, "Security Assertion Markup
Language (SAML) V2.0 Technical Overview", OASIS SSTC
Working Draft sstc-saml-tech-overview-2.0-draft-08,
September 2005.
[RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J. [RFC2543] Handley, M., Schulzrinne, H., Schooler, E., and J.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999. March 1999.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Method", RFC 3515, April 2003. Initiation Protocol (SIP)", RFC 3323, November 2002.
[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.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Siemens
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
skipping to change at page 34, line 39 skipping to change at page 42, line 39
Email: jmpolk@cisco.com Email: jmpolk@cisco.com
Douglas C. Sicker Douglas C. Sicker
University of Colorado at Boulder University of Colorado at Boulder
ECOT 430 ECOT 430
Boulder, CO 80309 Boulder, CO 80309
US US
Email: douglas.sicker@colorado.edu Email: douglas.sicker@colorado.edu
Marcus Tegnander Jeff Hodges
Letterkenny Institute of Technology NeuStar, Inc.
Port Road 2000 Broadway Street
Letterkenny, Donegal Redwood City, CA 94063
Ireland US
Email: schwed@gmail.com Email: Jeff.Hodges@neustar.biz
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
skipping to change at page 35, line 41 skipping to change at page 43, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 198 change blocks. 
870 lines changed or deleted 1143 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/