SIP H. Tschofenig
Internet-Draft Siemens
Expires: September 6, 2006 J. Peterson
NeuStar, Inc.
J. Polk
Cisco
D. Sicker
CU Boulder
J. Hodges
NeuStar, Inc.
March 5, 2006
SIP SAML Profile and Binding
draft-tschofenig-sip-saml-05.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 6, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document specifies a Session Initiation Protocol (SIP) profile
Tschofenig, et al. Expires September 6, 2006 [Page 1]
Internet-Draft SIP SAML March 2006
of Security Assertion Markup Language (SAML) as well as a SAML SIP
binding. The defined SIP SAML Profile composes with the mechanisms
defined in the SIP Identity specification and satisfy requirements
presented in "Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)".
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Specification Scope . . . . . . . . . . . . . . . . . . . . . 5
4. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7
4.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8
4.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9
5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 10
6. Use-case Scenarios . . . . . . . . . . . . . . . . . . . . . . 12
6.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 12
6.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 13
6.3. Compensation using SIP and SAML . . . . . . . . . . . . . 15
7. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 17
7.1. AS-driven SIP SAML URI-based Attribute Assertion
Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 17
7.1.1. Required Information . . . . . . . . . . . . . . . . . 17
7.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 17
7.1.3. Profile Description . . . . . . . . . . . . . . . . . 21
7.1.4. Assertion Profile Description . . . . . . . . . . . . 24
7.1.5. Assertion Verification . . . . . . . . . . . . . . . . 27
8. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 29
9. Example Signed SAML Assertion . . . . . . . . . . . . . . . . 30
10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
10.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 32
10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 33
10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 33
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 34
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 35
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
15. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 38
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
16.1. Normative References . . . . . . . . . . . . . . . . . . . 39
16.2. Informative References . . . . . . . . . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42
Intellectual Property and Copyright Statements . . . . . . . . . . 43
Tschofenig, et al. Expires September 6, 2006 [Page 2]
Internet-Draft SIP SAML March 2006
1. Introduction
This document specifies composition of the Security Assertion Markup
Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate
richer authorization mechanisms and enable "trait-based
authorization." Trait-based authorization is where one is authorized
to make use of some resource based on roles or traits rather than
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) v2.0, "SAMLv2", is an XML-
based framework for creating and exchanging security information.
[OASIS.sstc-saml-exec-overview-2.0-cd-01] and [OASIS.sstc-saml-tech-
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].
Various means of providing trait-based authorization exist:
authorization certificates, SPKI or extensions to the authenticated
identity body [RFC3893]. The authors selected SAML due to its
increasing use in environments such as the Liberty Alliance, and the
Internet2 project, areas where the applicability to SIP is widely
desired.
Tschofenig, et al. Expires September 6, 2006 [Page 3]
Internet-Draft SIP SAML March 2006
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
The SIP network element "Authentication Service" is introduced in
[I-D.ietf-sip-identity]. We reuse this term to refer to a network
element that authenticates and authorizes a user and creates a "SIP
identity assertion". This system entity is the moral equivalent of a
"SAML Authority" in the SAML terminology.
For overall SIP terminology, see [RFC3261].
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].
The below list maps other various SIP terms to their SAML
(rough-)equivalents:
Element, Network Element: System Entity, Entity
Authentication Service: SAML Authority
Invitee, Invited User, Called Party, Callee - Relying Party
Server, User Agent Server (UAS): SAML Responder
User Agent Client (UAC), client: SAML Requester
Additional terms concocted in the context of this specification:
profile attribute(s):
one or more attributes of a "user profile".
user profile, subject profile:
the set of various attributes accompanying (i.e., mapped to) a
user account in many environments.
Tschofenig, et al. Expires September 6, 2006 [Page 4]
Internet-Draft SIP SAML March 2006
3. Specification Scope
The scope of this specification is:
o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
that a subject's profile attributes, and their domain's
certificate, can be conveyed to a relying party using SAML. In
doing so, satisfy the requirements outlined in [I-D.ietf-sipping-
trait-authz], and compose with [I-D.ietf-sip-identity].
The following are outside the scope of this specification:
o Defining a means for configuring the runtime behavior, or
deployment characteristics, of the Authentication Service.
Discussion:
For example, a SIP Authentication Service could be implemented
such that its SAML-based features are employed, or not, on a
subject-by-subject basis, and/or on a domain-by-domain basis.
o The definition of specific conveyed subject profile attributes
(aka traits).
Discussion:
This specification defines a facility enabling "trait-based
authorization" as discussed in [I-D.ietf-sipping-trait-authz].
The attributes of interest in trait-based authorization will be
ones akin to, for example: roles, organizational membership,
access rights, or authentication event context. Definition of
such attributes is application- and/or deployment-context-
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].
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.
Note that SAMLv2 specifies a "metadata" facility that may be
Tschofenig, et al. Expires September 6, 2006 [Page 5]
Internet-Draft SIP SAML March 2006
useful in addressing this need.
Tschofenig, et al. Expires September 6, 2006 [Page 6]
Internet-Draft SIP SAML March 2006
4. SAML Introduction
SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] [OASIS.sstc-saml-tech-
overview-2.0-draft-08] defines an XML-based framework for exchanging
"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.
Thus one can employ SAML to make and encode statements such as "Alice
has these profile attributes and her domain's certificate is
available over there, and I'm making this statement, and here's who I
am." Then one can cause such an assertion to be conveyed to some
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.
The specification of how SAML is employed in a particular context of
use is known as a "SAML profile". The specification of how SAML
assertions and/or protocol messages are conveyed in, or over, another
protocol is known as a "SAML Binding". Typically, a SAML profile
specifies the SAML bindings that may be used in its context. Both
SAML profiles and SAML bindings reference other SAML specifications,
especially the SAML Assertions and Protocols, aka "SAML Core",
specification [OASIS.saml-core-2.0-os].
There is an additional subtle aspect of SAML profiles that is worth
highlighting -- the notion of a "SAML assertion profile". A SAML
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:
o The SAML assertion must contain at least one authentication
statement and no other statements. The relying party must be
represented in the <AudienceRestriction> element. The
SubjectConfirmation Method must be Foo. etc.
o The SAML assertion must contain at least one attribute statement
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:
Tschofenig, et al. Expires September 6, 2006 [Page 7]
Internet-Draft SIP SAML March 2006
o Assertions
o Abstract Request/Response protocol
We describe each in turn below:
4.1. SAML Assertions
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:
Issuing information:
Who issued the assertion, when was it issued and the assertion
identifier.
Subject information:
The name of the subject, the security domain and optional subject
information, like public key.
Conditions under which the assertion is valid:
Special kind of conditions like assertion validity period,
audience restriction and target restriction.
Additional advice:
Explaining how the assertion was made, for example.
In terms of SAML assertions containing SAML attribute statements or
SAML authentication statements, here are explanatory examples:
With a SAML assertion containing a SAML attribute statement, an
issuing authority is asserting that the subject is associated with
certain attributes with certain subject profile attribute values.
For example, user jon@cs.example.com is associated with the
attribute "Department", which has the value "Computer Science".
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.
Tschofenig, et al. Expires September 6, 2006 [Page 8]
Internet-Draft SIP SAML March 2006
With a SAML assertion containing both a SAML attribute statement
and a SAML authentication statement, an issuing authority is
asserting the union of the above.
4.2. Abstract Request/Response Protocol
SAML defines an abstract request/response protocol for obtaining
assertions. See Section 3 "SAML Protocols" of
[OASIS.saml-core-2.0-os]. A request asks for an assertion. A
response returns the requested assertion or an error. This abstract
protocol may then be cast into particular contexts of use by binding
it to specific underlying protocols, e.g., HTTP or SIP, and
"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.
Tschofenig, et al. Expires September 6, 2006 [Page 9]
Internet-Draft SIP SAML March 2006
5. Employing SAML in SIP
Employing SAML in SIP necessitates devising a new SAML profile or
profiles because the those already specified in the SAMLv2
specification set are specific to other use contexts, e.g., HTTP-
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.
The "Authenticated Identity Management in SIP" specification
[I-D.ietf-sip-identity] (aka "SIP Identity") facilitates the
composition of SAML and SIP in that it defines a "mediated
authentication architecture" where verifying endpoints verify SIP
identity assertions -- i.e., the "Identity" header value -- signed by
an Authentication Service (AS). The semantic being that the AS is
vouching that it did indeed authenticate the calling party.
Such an Authentication Service, which likely has access to various
pieces of information concerning the calling party, could also act as
a SAML Authority, and make such information available to the callee
via SAML.
Since [I-D.ietf-sip-identity] stipulates that the AS must make its
certificate available for retrieval and convey the availability and
access mechanism via a URI, in the Identity-Info header, we have an
opportunity to compose SIP Identity and SAML.
Such composition can be accomplished by having the resource referred
to by the URI in the Identity-Info be a SAML assertion conveying both
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.
Tschofenig, et al. Expires September 6, 2006 [Page 10]
Internet-Draft SIP SAML March 2006
+--------+ +--------------+ +--------+
|Alice@ | |Authentication| | Bob@ |
|example | |Service | |example2|
|.com | |@example.com | |com |
| | | | | |
+---+----+ +------+-------+ +---+----+
| | |
| INVITE | |
|---------------------->| |
| From:alice@foo.com | |
| | |
| 407 Proxy auth. req. | |
|<----------------------| |
| Challenge | |
| | |
| ACK | |
|---------------------->| |
| | |
| INVITE w/authn creds | |
|---------------------->| |
| | INVITE |
| | w/Identity header |
| |--------------------->|
| | and Identity-Info |
| | |
| | HTTP GET SAML assn |
| |<==================== |
| | and domain cert |
| | |
| | HTTP 200 OK + assn |
| |=====================>|
| | and domain cert |
| 200 OK | |
|<----------------------+----------------------|
| | |
Figure 1: SIP-SAML-based Network Asserted Identity
Since the AS already being trusted to create and add the Identity
header containing the SIP Identity Assertion, and to supply a pointer
to its domain certificate, having it point instead to a SAML
assertion conveying the domain certificate and possibly some user
profile attributes, does not significantly alter the first-order
security considerations examined in [I-D.ietf-sip-identity]. This
specification provides some additional security considerations
analysis below in Section 10.
Tschofenig, et al. Expires September 6, 2006 [Page 11]
Internet-Draft SIP SAML March 2006
6. Use-case Scenarios
This section shows message flows based on scenarios in [I-D.ietf-
sipping-trait-authz] enriched with a SAML based solution.
Section 6.2 shows a SIP conferencing scenario with role-based access
control using SAML. A future version of this document will cover
more scenarios from [I-D.ietf-sipping-trait-authz].
6.1. PSTN-to-SIP Phone Call
Alice, using a phone connected to the PSTN, wants to make a call to
Bob, which resides in a SIP network. Her call is switched through
the PSTN by means of PSTN signaling (outside the scope of this
document) to the PSTN/SIP gateway. At the gateway, the call is
converted from SS7 signaling to SIP signaling. Since Alice'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.
+-----------+
+----------------------+ | |
| | 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 |
+---------------------+
Tschofenig, et al. Expires September 6, 2006 [Page 12]
Internet-Draft SIP SAML March 2006
Figure 2: PSTN to SIP call
Note that the INVITE emitted by the PSTN/SIP gateway could
alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone,
and Bob's phone could take on the SIP Identity "verifier" role, which
is being played by Bob's SIP proxy in the figure.
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
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, via [I-D.ietf-
sip-identity] mechanisms, and/or,
o the SAML assertion could provide additional user profile
information such as group membership (belongs to the students,
staff, faculty group of university X). This could, for non-
identity-based authorization systems, imply certain rights.
The corresponding SIP message flow (in high level detail) could have
the following shape:
Tschofenig, et al. Expires September 6, 2006 [Page 13]
Internet-Draft SIP SAML March 2006
+-----+ +-----------+ +-----------+
| | | SIP Proxy | | Focus |
|User | |(Asserting | | (Relying |
| | | party) | | party) |
+--+--+ +-----+-----+ +-----+-----+
| INVITE | |
|sip:conf-factory | INVITE |
|------------------>| w/Identity hdr |
| |------------------>|
| | |
| | HTTP GET SAML assn|
| |<==================|
| | and domain cert |
| | |
| | HTTP 200 OK + assn|
| |==================>|
| | and domain cert |
| | |
| | |
| | Ringing |
| Ringing |<------------------|
|<------------------| |
| | |
| | OK |
| OK |<------------------|
|<------------------| |
| | |
| ACK | |
|------------------>| ACK |
| |------------------>|
| | |
| | |
... many more msgs...
Figure 3: SIP Conferencing and SAML
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.
This could be addressed by creating another SIP SAML Profile where
the caller obtains the necessary information, e.g., SAML assertions,
and places them into its SIP request message prior to sending it.
This would obviate the need for the callee relying party to make
requests in order to obtain said information. This is a topic for
future work, and possibly future revisions of this specification.
Tschofenig, et al. Expires September 6, 2006 [Page 14]
Internet-Draft SIP SAML March 2006
6.3. Compensation using SIP and SAML
This section describes a scenario where SAML is used in SIP to
realize compensation functionality as described in [I-D.jennings-
sipping-pay].
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.
+--------+ +--------+ +--------+
|Payment | | User | |Merchant|
|Provider| | Alice | |Bob |
| | | | | |
| | | | | |
+---+----+ +---+----+ +---+----+
| | |
| | 1) Call |
| |------------------------>|
| | |
| | 2) 402 + Payment Offer |
| 3) Request for |<------------------------|
| a Payment | |
|<----------------------| |
| | |
| 4) SAML Assertion | |
| (=Receipt) | |
|---------------------->| |
| | 5) Call + Receipt |
| |------------------------>|
| | |
| | 6) 200 OK |
| |<------------------------|
| | |
Figure 4: Message flow for SIP payment
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
Tschofenig, et al. Expires September 6, 2006 [Page 15]
Internet-Draft SIP SAML March 2006
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.
The Offer contains information about the three parties, the Payment
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.
Tschofenig, et al. Expires September 6, 2006 [Page 16]
Internet-Draft SIP SAML March 2006
7. SIP SAML Profiles
This section defines one SIP SAML profile:
The "AS-driven SIP SAML URI-based Attribute Assertion Fetch
Profile"
7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile
7.1.1. Required Information
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].
Identification:
urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0
@@ NOTE: This URN must be agreed upon, and then registered with
IANA per [RFC3553].
Contact Information:
@@ someone's or something's contact info goes here
SAML Confirmation Method Identifiers:
The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is
used in this profile.
Description:
Given below.
Updates:
None.
7.1.2. Profile Overview
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.
Tschofenig, et al. Expires September 6, 2006 [Page 17]
Internet-Draft SIP SAML March 2006
Although this profile is overview is cast in terms of a SIP INVITE
transaction, the reader should note that the mechanism specified
herein, and in [I-D.ietf-sip-identity], may be applied to any SIP
request message.
Figure 5 begins on the next page.
Tschofenig, et al. Expires September 6, 2006 [Page 18]
Internet-Draft SIP SAML March 2006
+------------------+ +------------------+ +-----------------+
| 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 |
Tschofenig, et al. Expires September 6, 2006 [Page 19]
Internet-Draft SIP SAML March 2006
| | | 200 OK | |
| V |<----------------------+----------------------| (6)
. - | | |
V
Figure 5: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE
Transaction
Step 1. Initial SIP Transaction between Caller and AS
This optional initial step is comprised of substeps 1a, 1b,
and 1c in Figure 5. In this step, the caller, Alice, sends a
SIP request message, illustrated as an INVITE, indicating Bob
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).
Step 2. Caller sends SIP Request Message with Authorization
Credentials to the AS
Alice then sends an INVITE message in response to the
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.
Step 3. AS Authorizes the SIP Request and Forwards it to Callee
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.
Tschofenig, et al. Expires September 6, 2006 [Page 20]
Internet-Draft SIP SAML March 2006
The AS determines which profile attributes (if any) to assert
in the <AttributeStatement> via local configuration and/or
obtaining example2.com's metadata
[OASIS.saml-metadata-2.0-os]. The AS then sends the updated
INVITE message to Bob.
Step 4. Callee Dereferences HTTP-based SAML URI Reference
Bob's UAC or SIP Proxy receives the message and begins
verifying it per the "Verifier Behavior" specified in
[I-D.ietf-sip-identity]. In order to accomplish this task,
it needs to obtain Alice's domain certificate. It obtains
the HTTP-based SAML URI Reference from the message's
Identity-Info header and dereferences it per Section 8.1.
Note that this is not a SIP message, but an HTTP message
[RFC2616].
Step 5. AS Returns SAML Assertion
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.
Upon receipt of Alice's SAML Assertion, the AS continues its
verification of the INVITE message. If successful, it
returns a 200 OK message directly to Alice. Otherwise it
returns an appropriate SIP error response.
Step 6. Callee Returns SIP 200 OK to Caller
If Bob determines, based upon Alice's identity as asserted by
the AS, and as further substantiated by the information in
the SAML assertion, to accept the INVITE, he returns a SIP
200 OK message directly to Alice.
7.1.3. Profile Description
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.
Tschofenig, et al. Expires September 6, 2006 [Page 21]
Internet-Draft SIP SAML March 2006
+------------------+ +------------------+ +------------------+
| Sender | |Authn Service (AS)| | Verifier |
| (UAC) | | (Sender's) | |(UAS or Proxy Svr)|
+--------+---------+ +--------+---------+ +--------+---------+
| | | (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)
| | |
Figure 6: AS-driven SIP SAML Attribute Fetch Profile: Message Flow
7.1.3.1. Initial SIP Transaction between Sender and AS
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
Tschofenig, et al. Expires September 6, 2006 [Page 22]
Internet-Draft SIP SAML March 2006
[I-D.ietf-sip-identity]. Substeps 1b and 1c as shown in Figure 6 are
non-normative and illustrative only.
7.1.3.2. Sender sends SIP Request Message with Authorization
Credentials to the AS
This step maps to Steps 1 and 2 of Section 5 "Authentication Service
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.
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.
7.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier
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:
The AS MUST construct a SAML assertion according to the "Assertion
Profile Description" specified in Section 7.1.4 of this
specification.
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].
The AS MUST use the URI constructed in the immediately preceding
substep as the value of the Identity-Info header that is added to
the SIP request message per Step 4 of Section 5 of [I-D.ietf-sip-
identity].
Upon successful completion of all of the above, the AS forwards the
request message.
At this point in this step, after perhaps traversing some number of
intermediaries, the SIP request message arrives at a SIP network
entity performing the "verifier" role. This role and its behavior
are specified in Section 6 "Verifier Behavior" of [I-D.ietf-sip-
identity]. The verifier MUST perform the steps enumerated in the
aforementioned section, with the following modifications:
Step 1 of [I-D.ietf-sip-identity] Section 6 maps to and is updated
by, the following two steps in this procedure.
Tschofenig, et al. Expires September 6, 2006 [Page 23]
Internet-Draft SIP SAML March 2006
Steps 2, 3, and 4 of [I-D.ietf-sip-identity] Section 6 may be
mapped across this latter portion of this step, and/or the
following two steps, as appropriate.
7.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference
The verifier SHOULD ascertain whether it has a current cached copy of
the SIP message sender's SAML assertion and domain certificate. If
not, or if the verifier chooses to (e.g., due to local policy), it
MUST dereference the the HTTP-based SAML URI Reference found in the
SIP message's Identity-Info header. To do so, the verifier MUST
employ the "SAML HTTP-URI-based SIP Binding" specified in
Section 8.1.
7.1.3.5. AS Returns SAML Assertion
This step also employs Section 8.1 "SAML HTTP-URI-based SIP Binding".
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.
Otherwise, the HTTP response message will contain a SAML assertion
and be denoted as such via the MIME media type of "application/
samlassertion+xml" [IANA.application.samlassertion-xml]. The
verifier MUST perform the verification steps specified in
Section 7.1.5 "Assertion Verification", below. If successful, then
this procedure continues with the next step.
7.1.3.6. Verifier performs Next Step
The SIP request was successfully processed. The verifier now
performs its next step, which depends at least in part on the type of
SIP request it received.
7.1.4. Assertion Profile Description
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].
An example SAML assertion, formulated according to this profile is
given in Section 9.
Overall SAML assertion profile requirements:
Tschofenig, et al. Expires September 6, 2006 [Page 24]
Internet-Draft SIP SAML March 2006
The SAML assertion MUST be signed by the same key as used to sign
the contents of the Identity header field. Signing of SAML
assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].
In the following subsections, the SAML assertion profile is specified
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].
7.1.4.1. Element: <Assertion>
Attribute: ID
The value for the ID XML attribute SHOULD be allocated randomly
such that the value meets the randomness requirments specified in
Section 1.3.4 of [OASIS.saml-core-2.0-os].
Attribute: IssueInstant
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.
7.1.4.1.1. Element: <Issuer>
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:
<Assertion
<ds:Signature
<ds:KeyInfo
<ds:X509Data
<ds:X509Certificate
7.1.4.1.2. Element: <Subject>
The <Subject> element SHOULD contain both a <NameID> element and a
<SubjectConfirmation> element.
Tschofenig, et al. Expires September 6, 2006 [Page 25]
Internet-Draft SIP SAML March 2006
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].
The <SubjectConfirmation> element attribute Method SHOULD be set to
the value:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
Although it MAY be set to some other implementation- and/or
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.
Tschofenig, et al. Expires September 6, 2006 [Page 26]
Internet-Draft SIP SAML March 2006
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.
Tschofenig, et al. Expires September 6, 2006 [Page 27]
Internet-Draft SIP SAML March 2006
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.
Tschofenig, et al. Expires September 6, 2006 [Page 28]
Internet-Draft SIP SAML March 2006
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.
Tschofenig, et al. Expires September 6, 2006 [Page 29]
Internet-Draft SIP SAML March 2006
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>
Tschofenig, et al. Expires September 6, 2006 [Page 30]
Internet-Draft SIP SAML March 2006
</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>
Tschofenig, et al. Expires September 6, 2006 [Page 31]
Internet-Draft SIP SAML March 2006
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.
Tschofenig, et al. Expires September 6, 2006 [Page 32]
Internet-Draft SIP SAML March 2006
* 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.
Tschofenig, et al. Expires September 6, 2006 [Page 33]
Internet-Draft SIP SAML March 2006
11. Contributors
The authors would like to thank Marcus Tegnander and Henning
Schulzrinne for his contributions to earlier versions of this
document.
Tschofenig, et al. Expires September 6, 2006 [Page 34]
Internet-Draft SIP SAML March 2006
12. Acknowledgments
We would like to thank RL 'Bob' Morgan and Stefan Goeman for their
comments to this draft.
Tschofenig, et al. Expires September 6, 2006 [Page 35]
Internet-Draft SIP SAML March 2006
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
Tschofenig, et al. Expires September 6, 2006 [Page 36]
Internet-Draft SIP SAML March 2006
14. IANA Considerations
This document contains a number of IANA considerations. A future
version of this document will list them in this section.
Tschofenig, et al. Expires September 6, 2006 [Page 37]
Internet-Draft SIP SAML March 2006
15. Open Issues
A list of open issues can be found at:
http://www.tschofenig.com:8080/saml-sip/
Tschofenig, et al. Expires September 6, 2006 [Page 38]
Internet-Draft SIP SAML March 2006
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]
Peterson, J., "Trait-based Authorization Requirements for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-02 (work in progress),
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
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2392] Levinson, E., "Content-ID and Message-ID Uniform Resource
Locators", RFC 2392, August 1998.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Tschofenig, et al. Expires September 6, 2006 [Page 39]
Internet-Draft SIP SAML March 2006
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[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]
Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-05 (work in
progress), October 2004.
[I-D.ietf-sipping-certs]
Jennings, C. and J. Peterson, "Certificate Management
Service for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-02 (work in progress), July 2005.
[I-D.jennings-sipping-pay]
Jennings, C., "Payment for Services in Session Initiation
Protocol (SIP)", draft-jennings-sipping-pay-03 (work in
progress), October 2005.
[I-D.peterson-message-identity]
Peterson, J., "Security Considerations for Impersonation
Tschofenig, et al. Expires September 6, 2006 [Page 40]
Internet-Draft SIP SAML March 2006
and Identity in Messaging Systems",
draft-peterson-message-identity-00 (work in progress),
October 2004.
[IANA.application.samlassertion-xml]
OASIS Security Services Technical Committee (SSTC),
"application/samlassertion+xml MIME Media Type
Registration", IANA MIME Media Types Registry application/
samlassertion+xml, December 2004.
[OASIS.draft-saml-protocol-ext-02]
Cantor, S., "SAML Protocol Extensions", OASIS SSTC Working
Draft draft-saml-protocol-ext-02, Februrary 2006.
[OASIS.saml-conformance-2.0-os]
Mishra, P., Philpott, R., and E. Maler, "Conformance
Requirements for the Security Assertion Markup Language
(SAML) V2.0", OASIS Standard saml-conformance-2.0-os,
March 2005.
[OASIS.saml-glossary-2.0-os]
Hodges, J., Philpott, R., and E. Maler, "Glossary for the
Security Assertion Markup Language (SAML) V2.0", OASIS
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.
Rosenberg, "SIP: Session Initiation Protocol", RFC 2543,
March 1999.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002.
Tschofenig, et al. Expires September 6, 2006 [Page 41]
Internet-Draft SIP SAML March 2006
Authors' Addresses
Hannes Tschofenig
Siemens
Otto-Hahn-Ring 6
Munich, Bavaria 81739
Germany
Email: Hannes.Tschofenig@siemens.com
Jon Peterson
NeuStar, Inc.
1800 Sutter St Suite 570
Concord, CA 94520
US
Email: jon.peterson@neustar.biz
James Polk
Cisco
2200 East President George Bush Turnpike
Richardson, Texas 75082
US
Email: jmpolk@cisco.com
Douglas C. Sicker
University of Colorado at Boulder
ECOT 430
Boulder, CO 80309
US
Email: douglas.sicker@colorado.edu
Jeff Hodges
NeuStar, Inc.
2000 Broadway Street
Redwood City, CA 94063
US
Email: Jeff.Hodges@neustar.biz
Tschofenig, et al. Expires September 6, 2006 [Page 42]
Internet-Draft SIP SAML March 2006
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Tschofenig, et al. Expires September 6, 2006 [Page 43]