< draft-ietf-sip-saml-04.txt   draft-ietf-sip-saml-05.txt >
SIP H. Tschofenig SIP H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Updates: 4474 (if approved) J. Hodges Intended status: Experimental J. Hodges
Intended status: Standards Track J. Peterson Expires: May 7, 2009 Unaffiliated
Expires: January 15, 2009 NeuStar, Inc. J. Peterson
NeuStar, Inc.
J. Polk J. Polk
Cisco Cisco
D. Sicker D. Sicker
CU Boulder CU Boulder
July 14, 2008 November 3, 2008
SIP SAML Profile and Binding SIP SAML Profile and Binding
draft-ietf-sip-saml-04.txt draft-ietf-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 40 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 15, 2009. This Internet-Draft will expire on May 7, 2009.
Abstract Abstract
This document specifies a Session Initiation Protocol (SIP) profile This document specifies a Session Initiation Protocol (SIP) profile
of Security Assertion Markup Language (SAML) as well as a SAML SIP of Security Assertion Markup Language (SAML) as well as a SAML SIP
binding. The defined SIP SAML Profile composes with the mechanisms binding. The defined SIP SAML Profile composes with the mechanisms
defined in the SIP Identity specification and satisfy requirements defined in the SIP Identity specification and satisfy requirements
presented in "Trait-based Authorization Requirements for the Session presented in "Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)". Initiation Protocol (SIP)".
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7
3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8
3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9
4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10
5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12
6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 14 6. Header Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
6.1. AS-driven SIP SAML URI-based Attribute Assertion 7. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 16
Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 14 7.1. AS-driven SIP SAML URI-based Attribute Assertion
6.1.1. Required Information . . . . . . . . . . . . . . . . . 14 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 16
6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 14 7.1.1. Required Information . . . . . . . . . . . . . . . . . 16
6.1.3. Profile Description . . . . . . . . . . . . . . . . . 18 7.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 16
6.1.4. Assertion Profile Description . . . . . . . . . . . . 21 7.1.3. Profile Description . . . . . . . . . . . . . . . . . 20
6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 23 7.1.4. Assertion Profile Description . . . . . . . . . . . . 23
6.2. The TBD "call-by-value" Profile . . . . . . . . . . . . . 25 7.1.5. Assertion Verification . . . . . . . . . . . . . . . . 25
7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 26 7.2. Caller-driven SIP SAML Conveyed Assertion Profile . . . . 27
7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 26 8. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 28
8. The 'saml-shusb' Option Tag . . . . . . . . . . . . . . . . . 27 8.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 28
9. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 28 9. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 29
10. Security Considerations . . . . . . . . . . . . . . . . . . . 33 10. Security Considerations . . . . . . . . . . . . . . . . . . . 34
10.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 33 10.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 34
10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 33 10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 34
10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 34 10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 35
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 35 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 36 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
13.1. IANA Registration for New SIP Option Tag . . . . . . . . . 37 13.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 38
13.2. 477 'Use Identity Header with SAML Assertion' Response 13.2. 477 'Binding to SIP Message failed' Response Code . . . . 38
Code . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 13.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 38
13.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 37 13.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 38
13.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 37 14. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40
14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 39 14.1. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 40
15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40 14.2. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40
15.1. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40 14.3. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40
15.2. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40 14.4. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 41
15.3. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 40 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 15.1. Normative References . . . . . . . . . . . . . . . . . . . 42
16.1. Normative References . . . . . . . . . . . . . . . . . . . 41 15.2. Informative References . . . . . . . . . . . . . . . . . . 43
16.2. Informative References . . . . . . . . . . . . . . . . . . 42 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 46
Intellectual Property and Copyright Statements . . . . . . . . . . 45
1. Introduction 1. Introduction
This document specifies composition of the Security Assertion Markup This document specifies composition of the Security Assertion Markup
Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate
richer authorization mechanisms and enable "trait-based richer authorization mechanisms and enable "trait-based
authorization." Trait-based authorization is where one is authorized authorization." Trait-based authorization is where one is authorized
to make use of some resource based on roles or traits rather than to make use of some resource based on roles or traits rather than
ones identifier(s). Motivations for trait-based authorization, along ones identifier(s). Motivations for trait-based authorization, along
with use-case scenarios, are presented in [RFC4484]. with use-case scenarios, are presented in [RFC4484].
Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML-
based framework for creating and exchanging security information. based framework for creating and exchanging security information.
[OASIS.sstc-saml-exec-overview-2.0-cd-01] and [OASIS.sstc-saml-exec-overview-2.0-cd-01] and
[OASIS.sstc-saml-tech-overview-2.0-draft-08] provide non-normative [OASIS.sstc-saml-tech-overview-2.0-draft-16] provide non-normative
overviews of SAMLv2. The SAMLv2 specification set is normatively overviews of SAMLv2. The SAMLv2 specification set is normatively
defined by [OASIS.saml-conformance-2.0-os]. defined by [OASIS.saml-conformance-2.0-os].
Various means of providing trait-based authorization exist: Various means of providing trait-based authorization exist:
authorization certificates [RFC3281], SPKI [RFC2693], or extensions authorization certificates [RFC3281], SPKI [RFC2693], or extensions
to the authenticated identity body [RFC3893]. The authors selected to the authenticated identity body [RFC3893]. The authors selected
SAML due to its increasing use in environments such as the Liberty SAML due to its increasing use in environments such as the Liberty
Alliance, and the Internet2 project, areas where the applicability to Alliance, and the Internet2 project, areas where the applicability to
SIP is widely desired. SIP is widely desired.
skipping to change at page 7, line 8 skipping to change at page 7, line 8
one or more attributes of a "user profile". one or more attributes of a "user profile".
user profile, subject profile: user profile, subject profile:
the set of various attributes accompanying (i.e., mapped to) a the set of various attributes accompanying (i.e., mapped to) a
user account in many environments. user account in many environments.
3. SAML Introduction 3. SAML Introduction
SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01] SAML [OASIS.sstc-saml-exec-overview-2.0-cd-01]
[OASIS.sstc-saml-tech-overview-2.0-draft-08] defines an XML-based [OASIS.sstc-saml-tech-overview-2.0-draft-16] defines an XML-based
framework for exchanging "security assertions" between entities. In framework for exchanging "security assertions" between entities. In
the course of making, or relying upon such assertions, SAML system the course of making, or relying upon such assertions, SAML system
entities may use SAML protocols, or other protocols, to communicate entities may use SAML protocols, or other protocols, to communicate
an assertion itself, or the subject of an assertion. an assertion itself, or the subject of an assertion.
Thus one can employ SAML to make and encode statements such as "Alice Thus one can employ SAML to make and encode statements such as "Alice
has these profile attributes and her domain's certificate is has these profile attributes and her domain's certificate is
available over there, and I'm making this statement, and here's who I 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 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 party who can then rely on it in some fashion for some purpose, for
skipping to change at page 10, line 9 skipping to change at page 10, line 9
"profiling" it for the specific use case at hand. The SAML HTTP- "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 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- Web Browser SSO Profile of [OASIS.saml-profiles-2.0-os]). Trait-
based SIP communication session establishment, the topic of this based SIP communication session establishment, the topic of this
specification, is another. specification, is another.
4. Specification Scope 4. Specification Scope
The scope of this specification is: The scope of this specification is:
o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such o Specify a SIP profile of SAML -- also known as a "SIP SAML
that a subject's profile attributes, and their domain's profile" -- such that a subject's profile attributes, and their
certificate, can be conveyed to a relying party using SAML. In domain's certificate, can be conveyed to a relying party using
doing so, satisfy the requirements outlined in [RFC4484], and SAML. In doing so, satisfy the requirements outlined in
compose with [RFC4474]. [RFC4484], and compose with [RFC4474].
The following are outside the scope of this specification: The following are outside the scope of this specification:
o Defining a means for configuring the runtime behavior, or o Defining a means for configuring the runtime behavior, or
deployment characteristics, of the Authentication Service. deployment characteristics, of the Authentication Service.
Discussion: Discussion:
For example, a SIP Authentication Service could be implemented For example, a SIP Authentication Service could be implemented
such that its SAML-based features are employed, or not, on a such that its SAML-based features are employed, or not, on a
skipping to change at page 12, line 8 skipping to change at page 12, line 8
not discuss the manner in which participating entites might not discuss the manner in which participating entites might
discover one another or agree on the syntax and semantics of discover one another or agree on the syntax and semantics of
attributes and traits. attributes and traits.
Note that SAMLv2 specifies a "metadata" facility that may be Note that SAMLv2 specifies a "metadata" facility that may be
useful in addressing this need. useful in addressing this need.
5. Employing SAML in SIP 5. Employing SAML in SIP
Employing SAML in SIP necessitates devising a new SAML profile(s) and Employing SAML in SIP necessitates devising a new SAML profile(s) and
binding(s) because the those already specified in the SAMLv2 binding(s) because those already specified in the SAMLv2
specification set are specific to other use contexts, e.g., HTTP- specification set are specific to other use contexts, e.g., HTTP-
based web browsing. Although SIP bears some similarity to HTTP, it based web browsing. Although SIP bears some similarity to HTTP, it
is a seperately distinct protocol, thus requiring specification of is a seperately distinct protocol, thus requiring specification of
SIP-specific SAML profile(s) and binding(s). This is technically SIP-specific SAML profile(s) and binding(s). This is technically
straightforward as both SAML and SIP are explicitly extensible. straightforward as both SAML and SIP are explicitly extensible.
The "Authenticated Identity Management in SIP" specification The SIP SAML Profiles defined in this document make use of concepts
[RFC4474] (aka "SIP Identity") facilitates the composition of SAML defined by [RFC4474] "Enhancements for Authenticated Identity
and SIP in that it defines a "mediated authentication architecture" Management in the Session Initiation Protocol (SIP)" -- also known as
where verifying endpoints verify SIP identity assertions -- i.e., the "SIP Identity". In particular, they leverage the "mediated
"Identity" header value -- signed by an Authentication Service (AS). authentication architecture" utilizing the Authentication Service
The semantic being that the AS is vouching that it did indeed (AS). The overall semantic being that the AS is vouching that it did
authenticate the calling party. indeed authenticate the calling party.
Such an Authentication Service, which likely has access to various Such an Authentication Service, which likely has access to various
pieces of information concerning the calling party, could also act as pieces of information concerning the calling party, could also act as
a SAML Authority, and make such information available to the callee a SAML Authority, and make such information available to the callee
via SAML. via SAML.
Since [RFC4474] stipulates that the AS must make its certificate The approach used by this document is similar to the one used for SIP
available for retrieval and convey the availability and access Identity. I.e. the AS creates a SAML assertion and makes it
mechanism via a URI, in the Identity-Info header, we have an available to the verifier via a reference, in the particular case of
opportunity to compose SIP Identity and SAML. the AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile.
Figure 1 illustrates this approach in a high-level summary fashion.
Such composition can be accomplished by having the resource referred Figure 4, further below, illustrates additional details. In case of
to by the URI in the Identity-Info be a SAML assertion conveying both the Assertion-by Value profile the SAML assertion is made available
the AS's certificate and user profile attributes. This is the to the verifying party directly without the additional step of
approach defined in this specification. Figure 1 illustrates this utilizing a reference. This approach is described in Section 7.2.
approach in a high-level summary fashion. Figure 2, 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 | |
|---------------------->| | |---------------------->| |
skipping to change at page 13, line 26 skipping to change at page 13, line 26
| 407 Proxy auth. req. | | | 407 Proxy auth. req. | |
|<----------------------| | |<----------------------| |
| Challenge | | | Challenge | |
| | | | | |
| ACK | | | ACK | |
|---------------------->| | |---------------------->| |
| | | | | |
| INVITE w/authn creds | | | INVITE w/authn creds | |
|---------------------->| | |---------------------->| |
| | INVITE | | | INVITE |
| | w/Identity header | | | w/SAML-Info header |
| |--------------------->| | |--------------------->|
| | and Identity-Info | | | |
| | | | | |
| | HTTP GET SAML assn | | | HTTP GET SAML assn |
| |<==================== | | |<==================== |
| | and domain cert | | | |
| | | | | |
| | HTTP 200 OK + assn | | | HTTP 200 OK + assn |
| |=====================>| | |=====================>|
| | and domain cert | | | |
| 200 OK | | | 200 OK | |
|<----------------------+----------------------| |<----------------------+----------------------|
| | | | | |
Figure 1: SIP-SAML-based Network Asserted Identity Figure 1: SIP-SAML-based Network Asserted Identity
Since the AS already being trusted to create and add the Identity Figure 1 shows an exchange based on the AS-driven SIP SAML URI-based
header containing the SIP Identity Assertion, and to supply a pointer Attribute Assertion Fetch Profile where the AS creates a SAML
to its domain certificate, having it point instead to a SAML assertion, creates a reference to it, and puts that reference into
assertion conveying the domain certificate and possibly some user the SAML-Info header before forwarding the SIP message. Bob in our
profile attributes, does not significantly alter the first-order case acting as the verifier uses the reference to retrieve the SAML
security considerations examined in [RFC4474]. This specification assertion and verifies it.
provides some additional security considerations analysis below in
Section 10.
6. SIP SAML Profiles 6. Header Syntax
This document specifies the new SIP header "SAML-Info". This header
MAY appear in any SIP header and MAY also appear more than once.
The grammar for this header is (following the ABNF [RFC4234] in
section 25 of RFC 3261 [RFC3261]):
SAML-Info =
"SAML-Info" HCOLON ident-info *( SEMI ident-info-params )
ident-info = LAQUOT absoluteURI RAQUOT
ident-info-params = generic-param
Figure 2: SAML-Info ABNF grammar
The "absoluteURI" portion of the SAML-Info header MUST contain a URI
which dereferences to a resource containing a SAML assertion. All
implementations of this specification MUST support the use of HTTP
and HTTPS URIs in the SAML-Info header. Such HTTP and HTTPS URIs
MUST follow the conventions of RFC 2585 [RFC2585], and for those URIs
the indicated resource MUST be of the form 'application/
samlassertion+xml' described in that specification.
No parameters are defined for the SAML-Info header in this document.
Future Experimental RFCS may define additional SAML-Info header
parameters.
This document adds the following entries to Table 2 of RFC 3261
[RFC3261]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
SAML-Info R a o o - o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
Figure 3: New SAML-Info Row for RFC3261 Table 2
The SAML-Info header MUST NOT appear in CANCEL.
7. SIP SAML Profiles
This section defines two "SIP SAML profiles": This section defines two "SIP SAML profiles":
o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch o The "AS-driven SIP SAML URI-based Attribute Assertion Fetch
Profile" Profile"
o The to-be-determined (TBD) "call-by-value" profile o The "Assertion-by-value" Profile
6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 7.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile
6.1.1. Required Information 7.1.1. Required Information
The information given in this section is similar to the info provided The information given in this section is similar to the info provided
when registering something, a MIME Media Type, say, with IANA. In when registering something, a MIME Media Type, say, with IANA. In
this case, it is for registering this profile with the OASIS SSTC. this case, it is for registering this profile with the OASIS SSTC.
See Section 2 "Specification of Additional Profiles" in See Section 2 "Specification of Additional Profiles" in
[OASIS.saml-profiles-2.0-os]. [OASIS.saml-profiles-2.0-os].
Identification: Identification:
urn:ietf:params:sip:sip-saml-profile:as:uri:attr:1.0 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: Contact Information:
@@ someone's or something's contact info goes here Hannes Tschofenig (Hannes.Tschofenig@nsn.com)
SAML Confirmation Method Identifiers: SAML Confirmation Method Identifiers:
The SAML V2.0 "{bearer,hok,?}" confirmation method identifier is The SAML V2.0 confirmation method identifier is used in this
used in this profile. profile.
Description: Description:
Given below. Given below.
Updates: Updates:
None. None.
6.1.2. Profile Overview 7.1.2. Profile Overview
Figure 2 illustrates this profile's overall protocol flow. The Figure 4 illustrates this profile's overall protocol flow. The
following steps correspond to the labeled interactions in the figure. following steps correspond to the labeled interactions in the figure.
Within an individual step, there may be one or more actual message Within an individual step, there may be one or more actual message
exchanges depending upon the protocol binding employed for that exchanges depending upon the protocol binding employed for that
particular step and other implementation-dependent behavior. particular step and other implementation-dependent behavior.
Although this profile is overview is cast in terms of a SIP INVITE Although this profile is overview is cast in terms of a SIP INVITE
transaction, the reader should note that the mechanism specified transaction, the reader should note that the mechanism specified
herein, and in [RFC4474], may be applied to any SIP request message. herein, may be applied to any SIP request message.
Figure 2 begins on the next page. Figure 4 begins on the next page.
+------------------+ +------------------+ +-----------------+ +------------------+ +------------------+ +-----------------+
| Caller | |Authn Service (AS)| | Callee | | Caller | |Authn Service (AS)| | Callee |
|Alice@example.com | | @example.com | | Bob@example2.com| |Alice@example.com | | @example.com | | Bob@example2.com|
+--------+---------+ +--------+---------+ +--------+--------+ +--------+---------+ +--------+---------+ +--------+--------+
- - | | | (steps) - - | | | (steps)
^ ^ | INVITE | | ^ ^ | INVITE | |
| | |---------------------->| | (1a) | | |---------------------->| | (1a)
| | From:alice@foo.com | | | | From:alice@foo.com | |
| C | To:sip:bob@example.com| | | C | To:sip:bob@example.com| |
skipping to change at page 16, line 33 skipping to change at page 18, line 33
^ | INVITE + authorization| | ^ | INVITE + authorization| |
D | | header w/ creds | | D | | header w/ creds | |
| |---------------------->| | (2) | |---------------------->| | (2)
I | | From:alice@foo.com | | I | | From:alice@foo.com | |
| | To:sip:bob@example.com| | | | To:sip:bob@example.com| |
A | Proxy-Authorization:..| | A | Proxy-Authorization:..| |
C | | INVITE | C | | INVITE |
L S | |--------------------->| (3) L S | |--------------------->| (3)
e | | From:alice@foo.com | e | | From:alice@foo.com |
O q | | To:sip:bob@example2.com O q | | To:sip:bob@example2.com
| | Identity: ..... | | | |
G = | | Identity-Info: | G = | | SAML-Info: |
| | https://example.com| | | https://example.com|
| N | | /assns/?ID=abcde | | N | | /assns/?ID=abcde |
| | | | | | | |
| + | |URI resolution (eg. HTTP) | + | |URI resolution (eg. HTTP)
| | |<=====================| (4) | | |<=====================| (4)
| 1 | | GET /assns/?ID=abcde | | 1 | | GET /assns/?ID=abcde |
| | | | | | | |
| | | | HTTP/1.1 200 OK | | | | | HTTP/1.1 200 OK |
| | | |=====================>| (5) | | | |=====================>| (5)
| | | | <saml:Assertion> | | | | | <saml:Assertion> |
skipping to change at page 17, line 9 skipping to change at page 19, line 9
| | | | <saml:SubjConf> | | | | <saml:SubjConf>
| | | | <saml:SubjConfData> | | | | <saml:SubjConfData>
| | | | <ds:KeyInfo>... | | | | <ds:KeyInfo>...
| | | | <saml:AttrStatement> | | | | <saml:AttrStatement>
| | | | foo=bar | | | | | foo=bar |
| | | 200 OK | | | | | 200 OK | |
| V |<----------------------+----------------------| (6) | V |<----------------------+----------------------| (6)
. - | | | . - | | |
V V
Figure 2: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE Figure 4: AS-driven SIP SAML Attribute Fetch Profile: Example INVITE
Transaction Transaction
Step 1. Initial SIP Transaction between Caller and AS Step 1. Initial SIP Transaction between Caller and AS
This optional initial step is comprised of substeps 1a, 1b, This optional initial step is comprised of substeps 1a, 1b,
and 1c in Figure 2. In this step, the caller, Alice, sends and 1c in Figure 4. In this step, the caller, Alice, sends
a SIP request message, illustrated as an INVITE, indicating a SIP request message, illustrated as an INVITE, indicating
Bob as the callee (1a), is subsequently challenged by the AS Bob as the callee (1a), is subsequently challenged by the AS
(1b), and sends an ACK in response to the challenge (1c). (1b), and sends an ACK in response to the challenge (1c).
The latter message signals the completion of this SIP The latter message signals the completion of this SIP
transaction (which is an optional substep of this profile). transaction (which is an optional substep of this profile).
Step 2. Caller sends SIP Request Message with Authorization Step 2. Caller sends SIP Request Message with Authorization
Credentials to the AS Credentials to the AS
Alice then sends an INVITE message in response to the Alice then sends an INVITE message in response to the
skipping to change at page 17, line 38 skipping to change at page 19, line 38
Depending on the chosen SIP security mechanism for client Depending on the chosen SIP security mechanism for client
authentication either digest authentication, client side authentication either digest authentication, client side
authentication of Transport Layer Security, or a combination authentication of Transport Layer Security, or a combination
of both is used to provide the AS with a strong assurance of both is used to provide the AS with a strong assurance
about the identity of Alice. about the identity of Alice.
Step 3. AS Authorizes the SIP Request and Forwards it to Callee Step 3. AS Authorizes the SIP Request and Forwards it to Callee
First, the AS authorizes the received INVITE message as First, the AS authorizes the received INVITE message as
specified in [RFC4474] and [RFC3261]. If the authorization specified in [RFC4474] and [RFC3261]. If the authorization
is successful, the AS will form the "identity signature" for is successful, the AS constructs and caches a SAML assertion
the message and add Identity and Identity-Info header fields asserting Alice's profile attributes required by Bob's
to the message. The AS also at this time constructs and domain (example2.com), and also containing a the domain's
caches a SAML assertion asserting Alice's profile attributes (example.com) public key certificate, or a reference to it.
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 The AS constructs a HTTP-based SAML URI Reference
incorporating the assertion's Assertion ID (see section incorporating the assertion's Assertion ID (see Section
2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI as 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 the value for the SAML-Info header it adds to the INVITE
message. message.
The AS determines which profile attributes (if any) to The AS determines which profile attributes (if any) to
assert in the <AttributeStatement> via local configuration assert in the <AttributeStatement> via local configuration
and/or obtaining example2.com's metadata and/or obtaining example2.com's metadata
[OASIS.saml-metadata-2.0-os]. The AS then sends the updated [OASIS.saml-metadata-2.0-os]. The AS then sends the updated
INVITE message to Bob. INVITE message to Bob.
Step 4. Callee Dereferences HTTP-based SAML URI Reference Step 4. Callee Dereferences HTTP-based SAML URI Reference
Bob's UAC or SIP Proxy receives the message and begins Bob's UAC or SIP Proxy receives the message and begins
verifying it per the "Verifier Behavior" specified in verifying it per the "Verifier Behavior" specified in
[RFC4474]. In order to accomplish this task, it needs to [RFC4474]. In order to accomplish this task, it needs to
obtain Alice's domain certificate. It obtains the HTTP- obtain Alice's domain certificate. It obtains the HTTP-
based SAML URI Reference from the message's Identity-Info based SAML URI Reference from the message's SAML-Info header
header and dereferences it per Section 7.1. Note that this and dereferences it per Section 8.1. Note that this is not
is not a SIP message, but an HTTP message [RFC2616]. a SIP message, but an HTTP message [RFC2616].
Step 5. AS Returns SAML Assertion Step 5. AS Returns SAML Assertion
Upon receipt of the above HTTP request, which contains an Upon receipt of the above HTTP request, which contains an
embedded reference to Alice's SAML Assertion, Alice's AS embedded reference to Alice's SAML Assertion, Alice's AS
returns her assertion in an HTTP response message. returns her assertion in an HTTP response message.
Upon receipt of Alice's SAML Assertion, the AS continues its Upon receipt of Alice's SAML Assertion, the AS continues its
verification of the INVITE message. If successful, it verification of the INVITE message. If successful, it
returns a 200 OK message directly to Alice. Otherwise it returns a 200 OK message directly to Alice. Otherwise it
returns an appropriate SIP error response. returns an appropriate SIP error response.
Step 6. Callee Returns SIP 200 OK to Caller Step 6. Callee Returns SIP 200 OK to Caller
If Bob determines, based upon Alice's identity as asserted If Bob determines, based upon Alice's identity as asserted
by the AS, and as further substantiated by the information by the AS, and as further substantiated by the information
in the SAML assertion, to accept the INVITE, he returns a in the SAML assertion, to accept the INVITE, he returns a
SIP 200 OK message directly to Alice. SIP 200 OK message directly to Alice.
6.1.3. Profile Description 7.1.3. Profile Description
The following sections provide detailed definitions of the individual The following sections provide detailed definitions of the individual
profile steps. The relevant illustration is Figure 3, below. Note profile steps. The relevant illustration is Figure 5, below. Note
that this profile is agnostic to the specific SIP request, and also that this profile is agnostic to the specific SIP request, and also
that the Sender and Authentication Service (AS) may be seperate or that the Sender and Authentication Service (AS) may be seperate or
co-located in actuality. co-located in actuality.
+------------------+ +------------------+ +------------------+ +------------------+ +------------------+ +------------------+
| Sender | |Authn Service (AS)| | Verifier | | Sender | |Authn Service (AS)| | Verifier |
| (UAC) | | (Sender's) | |(UAS or Proxy Svr)| | (UAC) | | (Sender's) | |(UAS or Proxy Svr)|
+--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+ +--------+---------+
| | | (steps) | | | (steps)
| SIP Request | | | SIP Request | |
skipping to change at page 19, line 26 skipping to change at page 21, line 26
| | | | | |
| ACK | | | ACK | |
|---------------------->| | (1c) |---------------------->| | (1c)
| | | | | |
| | | | | |
|SIP Req + authorization| | |SIP Req + authorization| |
| header w/ creds | | | header w/ creds | |
|---------------------->| | (2) |---------------------->| | (2)
| | | | | |
| | | | | |
| | SIP Req + Ident & | | | SIP Req + SAML-Info |
| | authz headers | | | |
| |--------------------->| (3) | |--------------------->| (3)
| | | | | |
| | URI resolution | | | URI resolution |
| |<=====================| (4) | |<=====================| (4)
| | (via HTTP) | | | (via HTTP) |
| | | | | |
| | HTTP/1.1 200 OK | | | HTTP/1.1 200 OK |
| |=====================>| (5) | |=====================>| (5)
| | | | | |
| | | | | |
| | ? | (6) | | ? | (6)
| | | | | |
Figure 3: AS-driven SIP SAML Attribute Fetch Profile: Message Flow Figure 5: AS-driven SIP SAML Attribute Fetch Profile: Message Flow
6.1.3.1. Initial SIP Transaction between Sender and AS 7.1.3.1. Initial SIP Transaction between Sender and AS
This OPTIONAL step maps to Steps 1 and 2 of Section 5 "Authentication This optional step maps to Steps 1 and 2 of Section 5 "Authentication
Service Behavior" of [RFC4474]. If the SIP request sent by the Service Behavior" of [RFC4474]. If the SIP request sent by the
caller in substep 1a is deemed insufficiently authenticated by the AS caller in substep 1a is deemed insufficiently authenticated by the AS
per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST
authenticate the sender of the message. The particulars of how this authenticate the sender of the message. The particulars of how this
is accomplished depend upon implementation and/or deployment is accomplished depend upon implementation and/or deployment
instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown
in Figure 3 are non-normative and illustrative only. in Figure 5 are non-normative and illustrative only.
6.1.3.2. Sender sends SIP Request Message with Authorization 7.1.3.2. Sender sends SIP Request Message with Authorization
Credentials to the AS Credentials to the AS
This step maps to Steps 1 and 2 of Section 5 "Authentication Service This step maps to Steps 1 and 2 of Section 5 "Authentication Service
Behavior" of [RFC4474]. This request is presumed to be made in a Behavior" of [RFC4474]. This request is presumed to be made in a
context such that the AS will not challenge it -- i.e., the AS will 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 consider the sender of the message to be authenticated. If this is
not true, then this procedure reverts back to Step 1, above. not true, then this procedure reverts back to Step 1, above.
Otherwise, the AS carries out all other processing of the message as Otherwise, the AS carries out all other processing of the message as
stipulated in [RFC4474] Steps 1 and 2, and if successful, this stipulated in [RFC4474] Steps 1 and 2, and if successful, this
procedure procedes to the next step below. procedure procedes to the next step below.
6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier 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 This first portion of this step maps to Steps 3 and 4 of Section 5
"Authentication Service Behavior" of [RFC4474], which the AS MUST "Authentication Service Behavior" of [RFC4474], which the AS MUST
perform, although with the following additional substeps: perform, although with the following additional substeps:
The AS MUST construct a SAML assertion according to the "Assertion The AS MUST construct a SAML assertion according to the "Assertion
Profile Description" specified in Section 6.1.4 of this Profile Description" specified in Section 7.1.4 of this
specification. specification.
The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI 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]. 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 The AS MUST use the URI constructed in the immediately preceding
substep as the value of the Identity-Info header that is added to substep as the value of the SAML-Info header that is added to the
the SIP request message per Step 4 of Section 5 of [RFC4474]. SIP request message.
Upon successful completion of all of the above, the AS forwards the Upon successful completion of all of the above, the AS forwards the
request message. request message.
At this point in this step, after perhaps traversing some number of At this point in this step, after perhaps traversing some number of
intermediaries, the SIP request message arrives at a SIP network intermediaries, the SIP request message arrives at a SIP network
entity performing the "verifier" role. This role and its behavior entity performing the "verifier" role. This role and its behavior
are specified in Section 6 "Verifier Behavior" of [RFC4474]. The are specified in Section 6 "Verifier Behavior" of [RFC4474]. The
verifier MUST perform the steps enumerated in the aforementioned verifier MUST perform the steps enumerated in the aforementioned
section, with the following modifications: section, with the following modifications:
Step 1 of [RFC4474] Section 6 maps to and is updated by, the Step 1 of [RFC4474] Section 6 maps to and is updated by, the
following two steps in this procedure. following two steps in this procedure.
Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this
latter portion of this step, and/or the following two steps, as latter portion of this step, and/or the following two steps, as
appropriate. appropriate.
6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 7.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference
The verifier SHOULD ascertain whether it has a current cached copy of The verifier SHOULD ascertain whether it has a current cached copy of
the SIP message sender's SAML assertion and domain certificate. If 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 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 MUST dereference the the HTTP-based SAML URI Reference found in the
SIP message's Identity-Info header. To do so, the verifier MUST SIP message's SAML-Info header. To do so, the verifier MUST employ
employ the "SAML HTTP-URI-based SIP Binding" specified in the "SAML HTTP-URI-based SIP Binding" specified in Section 8.1.
Section 7.1.
6.1.3.5. AS Returns SAML Assertion 7.1.3.5. AS Returns SAML Assertion
This step also employs Section 7.1 "SAML HTTP-URI-based SIP Binding". 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 If the prior step returns an HTTP error (e.g., 4xx series), then this
procedure terminates and the verifier returns (upstream) a SIP 436 procedure terminates and the verifier returns (upstream) a SIP 436
'Bad Identity-Info' Response code. 'Bad SAML-Info' Response code.
Otherwise, the HTTP response message will contain a SAML assertion Otherwise, the HTTP response message will contain a SAML assertion
and be denoted as such via the MIME media type of "application/ and be denoted as such via the MIME media type of "application/
samlassertion+xml" [IANA.application.samlassertion-xml]. The samlassertion+xml" [IANA.application.samlassertion-xml]. The
verifier MUST perform the verification steps specified in verifier MUST perform the verification steps specified in
Section 6.1.5 "Assertion Verification", below. If successful, then Section 7.1.5 "Assertion Verification", below. If successful, then
this procedure continues with the next step. this procedure continues with the next step.
6.1.3.6. Verifier performs Next Step 7.1.3.6. Verifier performs Next Step
The SIP request was successfully processed. The verifier now The SIP request was successfully processed. The verifier now
performs its next step, which depends at least in part on the type of performs its next step, which depends at least in part on the type of
SIP request it received. SIP request it received.
6.1.4. Assertion Profile Description 7.1.4. Assertion Profile Description
This section defines the particulars of how the sender, i.e., the This section defines the particulars of how the sender, i.e., the
SAML Authority, MUST construct certain portions of the SAML SAML Authority, MUST construct certain portions of the SAML
assertions it issues. The schema for SAML assertions themselves is assertions it issues. The schema for SAML assertions themselves is
defined in Section 2.3 of [OASIS.saml-core-2.0-os]. defined in Section 2.3 of [OASIS.saml-core-2.0-os].
An example SAML assertion, formulated according to this profile is An example SAML assertion, formulated according to this profile is
given in Section 9. given in Section 9.
Overall SAML assertion profile requirements: Overall SAML assertion profile requirements:
The SAML assertion MUST be signed by the same key as used to sign When using an HTTPS URI then the SAML assertion does not
the contents of the Identity header field. Signing of SAML necessarily needs to be signed. If it is signed then it MUST be
signed by the same key that is used in the Transport Layer
Security mechanism utilized with HTTPS. Signing of SAML
assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].
In the following subsections, the SAML assertion profile is specified In the following subsections, the SAML assertion profile is specified
element-by-element, in a top-down, depth-first manner, beginning with element-by-element, in a top-down, depth-first manner, beginning with
the outermost element, "<Assertion>". Where applicable, the the outermost element, "<Assertion>". Where applicable, the
requirements for an element's XML attributes are also stated, as a requirements for an element's XML attributes are also stated, as a
part of the element's description. Requirements for any given part of the element's description. Requirements for any given
element or XML attribute are only stated when, in the context of use element or XML attribute are only stated when, in the context of use
of this profile, they are not already sufficiently defined by of this profile, they are not already sufficiently defined by
[OASIS.saml-core-2.0-os]. [OASIS.saml-core-2.0-os].
6.1.4.1. Element: <Assertion> 7.1.4.1. Element: <Assertion>
Attribute: ID Attribute: ID
The value for the ID XML attribute SHOULD be allocated randomly The value for the ID XML attribute SHOULD be allocated randomly
such that the value meets the randomness requirments specified in such that the value meets the randomness requirments specified in
Section 1.3.4 of [OASIS.saml-core-2.0-os]. Section 1.3.4 of [OASIS.saml-core-2.0-os].
Attribute: IssueInstant Attribute: IssueInstant
The value for the IssueInstant XML attribute SHOULD be set at the The value for the IssueInstant XML attribute SHOULD be set at the
time the SAML assertion is created (and cached for subsequent time the SAML assertion is created (and cached for subsequent
retrieval). This time instant value MAY be temporally the same as retrieval). This time instant value MAY be temporally the same as
that encoded in the SIP message's Date header, and MUST be at that encoded in the SIP message's Date header, and MUST be at
least temporally later, although it is RECOMMENDED that it not be least temporally later, although it is RECOMMENDED that it not be
10 minutes or more later. 10 minutes or more later.
6.1.4.1.1. Element: <Issuer> 7.1.4.1.1. Element: <Issuer>
The value for the Issuer XML element MUST be a value that matches The value for the Issuer XML element MUST be a value that matches
either the Issuer or the Issuer Alternative Name fields [RFC3280] in either the Issuer or the Issuer Alternative Name fields [RFC3280] in
the certificate conveyed by the SAML assertion in the ds: the certificate conveyed by the SAML assertion in the ds:
X509Certificate element located on this path within the SAML X509Certificate element located on this path within the SAML
assertion: assertion:
<Assertion <Assertion
<ds:Signature <ds:Signature
<ds:KeyInfo <ds:KeyInfo
<ds:X509Data <ds:X509Data
<ds:X509Certificate <ds:X509Certificate
6.1.4.1.2. Element: <Subject> 7.1.4.1.2. Element: <Subject>
The <Subject> element SHOULD contain both a <NameID> element and a The <Subject> element SHOULD contain both a <NameID> element and a
<SubjectConfirmation> element. <SubjectConfirmation> element.
The value of the <NameID> element MUST be the same as the Address of The value of the <NameID> element MUST be the Address of Record
Record (AoR) value used in computing the "signed-identity-digest" (AoR).
which forms the value of the Identity header. See Section 9 of
[RFC4474].
The <SubjectConfirmation> element attribute Method SHOULD be set to The <SubjectConfirmation> element attribute Method SHOULD be set to
the value: the value:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
Although it MAY be set to some other implementation- and/or Although it MAY be set to some other implementation- and/or
deployment-specific value. The <SubjectConfirmation> element itself deployment-specific value. The <SubjectConfirmation> element itself
SHOULD be empty. SHOULD be empty.
6.1.4.1.3. Element: <Conditions> 7.1.4.1.3. Element: <Conditions>
The <Conditions> element SHOULD contain an <AudienceRestriction> The <Conditions> element SHOULD contain an <AudienceRestriction>
element, which itself SHOULD contain an <Audience> element. The element, which itself SHOULD contain an <Audience> element. When
value of the <Audience> element SHOULD be the same as the addr-spec included the value of the <Audience> element MUST be the same as the
of the SIP request's To header field. addr-spec of the SIP request's To header field.
The following XML attributes of the <Conditions> element MUST be set The following XML attributes of the <Conditions> element MUST be set
as follows: as follows:
Attribute: NotBefore Attribute: NotBefore
The value of the NotBefore XML attribute MUST be set to a time The value of the NotBefore XML attribute MUST be set to a time
instant the same as the value for the IssueInstant XML attribute instant the same as the value for the IssueInstant XML attribute
discussed above, or to a later time. discussed above, or to a later time.
Attribute: NotOnOrAfter Attribute: NotOnOrAfter
The value of the NotOnOrAfter XML attribute MUST be set to a time The value of the NotOnOrAfter XML attribute MUST be set to a time
instant later than the value for NotBefore. instant later than the value for NotBefore.
6.1.4.1.4. Element: <AttributeStatement> 7.1.4.1.4. Element: <AttributeStatement>
The SAML assertion MAY contain an <AttributeStatement> element. If The SAML assertion MAY contain an <AttributeStatement> element. If
so, the <AttributeStatement> element will contain attribute-value so, the <AttributeStatement> element will contain attribute-value
pairs, e.g., of a user profile nature, encoded according to either pairs, e.g., of a user profile nature, encoded according to either
one of the "SAML Attribute Profiles" as specified in one of the "SAML Attribute Profiles" as specified in
[OASIS.saml-profiles-2.0-os], or encoded in some implementation- [OASIS.saml-profiles-2.0-os], or encoded in some implementation-
and/or deployment-specific attribute profile. and/or deployment-specific attribute profile.
The attribute-value pairs SHOULD in fact pertain to the entity The attribute-value pairs SHOULD in fact pertain to the entity
identified in the SIP From header field, since a SAML assertion identified in the SIP From header field, since a SAML assertion
formulated per this overall section is stating that they do. formulated per this overall section is stating that they do.
6.1.5. Assertion Verification 7.1.5. Assertion Verification
This section specifies the steps that a verifier participating in This section specifies the steps that a verifier participating in
this profile MUST perform in addition to the "Verifier Behavior" this profile MUST perform in addition to the "Verifier Behavior"
specified in Section 6 of [RFC4474]. specified in Section 6 of [RFC4474].
The steps are: The steps are:
1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST
extract the AS's domain certificate from the <ds: extract the AS's domain certificate from the <ds:
X509Certificate> XML element at the end of the element path X509Certificate> XML element at the end of the element path
given in Section 6.1.4.1.1. given in Section 7.1.4.1.1.
2. Perform Step 1 in Section 6 of [RFC4474]. 2. Perform Step 1 in Section 6 of [RFC4474].
3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of
that section, the verifier MUST verify the SAML assertion's that section, the verifier MUST verify the SAML assertion's
signature via the procedures specified in Section 5.4 of signature via the procedures specified in Section 5.4 of
[OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. [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 The 479 'Invalid SAML Assertion' response code is used when the
when a SAML assn signature is bad? e.g., '4xx Invalid SAML verifier is unable to process the SAML assertion.
asssertion'.
4. Perform Step 2 in Section 6 of [RFC4474]. 4. Perform Step 2 in Section 6 of [RFC4474].
5. Verify that the signer of the SIP message's Identity header 5. Verify that the signer of the SIP message's Identity header
field is the same as the signer of the SAML assertion. field is the same as the signer of the SAML assertion.
6. Perform Steps 3 and 4 in Section 6 of [RFC4474]. 6. Verify that the content of the SAML assertion matches with the
information carried in the SIP message. This may include the
following checks:
7. Verify that the SAML assertion's <Issuer> element value matches 7. Verify that the SAML assertion's <Issuer> element value matches
the Issuer or the Issuer Alternative Name fields [RFC3280] in the Issuer or the Issuer Alternative Name fields [RFC3280] in
the AS's domain certificate. the AS's domain certificate.
8. Verify that the SAML assertion's <NameID> element value is the 8. Verify that the SAML assertion's <NameID> element value is the
same as the Address of Record (AoR) value in the "signed- same as the Address of Record (AoR) value.
identity-digest". See Section 9 of [RFC4474].
9. Verify that the SAML assertion's <SubjectConfirmation> element 9. Verify that the SAML assertion's <SubjectConfirmation> element
value is set to whichever value was configured at value is set to whichever value was configured at
implementation- or deployment-time. The default value is: implementation- or deployment-time. The default value is:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
10. Verify that the SAML assertion contains an <Audience> element, 10. Verify that the SAML assertion contains an <Audience> element,
and that its value matches the value of the addr-spec of the SIP and that its value matches the value of the addr-spec of the SIP
To header field. To header field.
11. Verify that the validity period denoted by the NotBefore and 11. Verify that the validity period denoted by the NotBefore and
NotOnOrAfter attributes of the <Conditions> element meets the NotOnOrAfter attributes of the <Conditions> element meets the
requirements given in Section 6.1.4.1.3. requirements given in Section 7.1.4.1.3.
6.2. The TBD "call-by-value" Profile 7.2. Caller-driven SIP SAML Conveyed Assertion Profile
To-Be-Determined (TBD) For the "Assertion-by-value" profile we assume that a SAML assertion
is obtained out-of-band and attached to the body of the SIP message.
Note that any SIP message may be used to convey the SAML assertion
even though SIP INVITE may be the most appropriate candiate. The
verification step described in Section 7.1.5 is applicable to this
profile as well as the description on the content of the assertion
illustrated in Section 7.1.4.
7. SAML SIP Binding 8. SAML SIP Binding
This section specifies one SAML SIP Binding at this time. Additional This section specifies one SAML SIP Binding at this time. Additional
bindings may be specified in future revisions of this specification. bindings may be specified in future revisions of this specification.
The description in Section 7.1.4 is applicable to this profile.
7.1. SAML HTTP-URI-based SIP Binding 8.1. SAML HTTP-URI-based SIP Binding
This section specifies the "SAML HTTP-URI-based SIP Binding", This section specifies the "SAML HTTP-URI-based SIP Binding",
(SHUSB). (SHUSB).
The SHUSB is a profile of the "SAML URI Binding" specified in Section 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 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 a means by which SAML assertions can be referenced by URIs and thus
be obtained through resolution of such URIs. be obtained through resolution of such URIs.
This profile of the SAML URI Binding is congruent with the SAML URI This profile of the SAML URI Binding is congruent with the SAML URI
skipping to change at page 27, line 5 skipping to change at page 29, line 5
to [OASIS.saml-bindings-2.0-os]): to [OASIS.saml-bindings-2.0-os]):
Section 3.7.5.3 Security Considerations: Section 3.7.5.3 Security Considerations:
Support for TLS 1.0 or SSL 3.0 is mandatory to implement. Support for TLS 1.0 or SSL 3.0 is mandatory to implement.
Section 3.7.5.4 Error Reporting: Section 3.7.5.4 Error Reporting:
All SHOULDs in this section are to be interpreted as MUSTs. All SHOULDs in this section are to be interpreted as MUSTs.
8. The 'saml-shusb' Option Tag
This document creates and IANA registers one new option tag: "saml-
shusb". This option tag is to be used, as defined in RFC 3261, in
the Require, Supported and Unsupported headers. It is used to
indicate support for this SIP extension, this option tag is included
in a Supported header of the SIP request.
9. Example SAML Assertions 9. Example SAML Assertions
This section presents two examples of a SAML assertion, one unsigned This section presents two examples of a SAML assertion, one unsigned
(for clarity), the other signed (for accuracy). (for clarity), the other signed (for accuracy).
In the first example, Figure 4, the assertion is attesting with In the first example, Figure 6, the assertion is attesting with
respect to the subject (lines 7-15) "Alice@example.com" (line 11). respect to the subject (lines 7-15) "Alice@example.com" (line 11).
The validity conditions are expressed in lines 16-23, via both a The validity conditions are expressed in lines 16-23, via both a
validity period expressed as temporal endpoints, and an "audience validity period expressed as temporal endpoints, and an "audience
restriction" stating that this assertion's semantics are valid for restriction" stating that this assertion's semantics are valid for
only the relying party named "example2.com". Also, the assertion's only the relying party named "example2.com". Also, the assertion's
issuer is noted in lines 4-5. issuer is noted in lines 4-5.
The above items correspond to some aspects of this specification's The above items correspond to some aspects of this specification's
SAML assertion profile, as noted below in Security Considerations SAML assertion profile, as noted below in Security Considerations
dicussions, see: Section 10.1 and Section 10.2. dicussions, see: Section 10.1 and Section 10.2.
skipping to change at page 29, line 43 skipping to change at page 30, line 43
29 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 29 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
30 Name="urn:oid:2.5.4.20" 30 Name="urn:oid:2.5.4.20"
31 FriendlyName="telephoneNumber"> 31 FriendlyName="telephoneNumber">
32 <saml:AttributeValue xsi:type="xs:string"> 32 <saml:AttributeValue xsi:type="xs:string">
33 +1-888-555-1212 33 +1-888-555-1212
34 </saml:AttributeValue> 34 </saml:AttributeValue>
35 </saml:Attribute> 35 </saml:Attribute>
36 </AttributeStatement> 36 </AttributeStatement>
37 </Assertion> 37 </Assertion>
Figure 4: Unsigned SAML Assertion Illustrating Conveyance of Figure 6: Unsigned SAML Assertion Illustrating Conveyance of
Subject Attribute Subject Attribute
In the second example, Figure 5, the information described above is In the second example, Figure 7, the information described above is
the same, the addition is that this version of the assertion is the same, the addition is that this version of the assertion is
signed. All the signature information is conveyed in the <ds: signed. All the signature information is conveyed in the <ds:
signature> element, lines 7-47. Thus this assertion's origin and its signature> element, lines 7-47. Thus this assertion's origin and its
integrity are assured. Since this assertion is the same as the one integrity are assured. Since this assertion is the same as the one
in the first example above, other than having a signature added, the in the first example above, other than having a signature added, the
second example below addresses the same Security Considerations second example below addresses the same Security Considerations
aspects, plus those requiring a Signature. aspects, plus those requiring a Signature.
1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0" 2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
skipping to change at page 32, line 35 skipping to change at page 33, line 35
70 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 70 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
71 Name="urn:oid:2.5.4.20" 71 Name="urn:oid:2.5.4.20"
72 FriendlyName="telephoneNumber"> 72 FriendlyName="telephoneNumber">
73 <saml:AttributeValue xsi:type="xs:string"> 73 <saml:AttributeValue xsi:type="xs:string">
74 +1-888-555-1212 74 +1-888-555-1212
75 </saml:AttributeValue> 75 </saml:AttributeValue>
76 </saml:Attribute> 76 </saml:Attribute>
77 </AttributeStatement> 77 </AttributeStatement>
78 </Assertion> 78 </Assertion>
Figure 5: Signed SAML Assertion Illustrating Conveyance of Subject Figure 7: Signed SAML Assertion Illustrating Conveyance of Subject
Attribute Attribute
10. Security Considerations 10. Security Considerations
This section discusses security considerations when using SAML with This section discusses security considerations when using SAML with
SIP. SIP.
10.1. Man-in-the-Middle Attacks and Stolen Assertions 10.1. Man-in-the-Middle Attacks and Stolen Assertions
Threat: Threat:
skipping to change at page 33, line 29 skipping to change at page 34, line 29
assertion as it is being returned to a requester. assertion as it is being returned to a requester.
The attacker could then conceivably attempt to impersonate the The attacker could then conceivably attempt to impersonate the
subject (the putative caller) to some SIP-based target entity. subject (the putative caller) to some SIP-based target entity.
Countermeasures: Countermeasures:
Such an attack is implausible for several reasons. The primary Such an attack is implausible for several reasons. The primary
reason is that a message constructed by an imposter using a stolen reason is that a message constructed by an imposter using a stolen
assertion that conveys the public key certificate of some domain assertion that conveys the public key certificate of some domain
will not verify per [RFC4474] because the imposter will not have will not verify because the values in the SAML assertion, which
the corresponding private key with which to generate the signed are tied to the SIP message, will not verify.
Identity header value.
Also, the SIP SAML assertion profile specified herein that the Also, the SIP SAML assertion profile specified herein that the
subject's SAML assertion must adhere to causes it to be not useful subject's SAML assertion must adhere to causes it to be not useful
to arbitrary parties. The subject's assertion: to arbitrary parties. The subject's assertion:
* should be signed, thus causing any alterations to break its * should be signed, thus causing any alterations to break its
integrity and make such alterations detectable. integrity and make such alterations detectable.
* relying party is represented in the SAML assertion's Audience * relying party is represented in the SAML assertion's Audience
Restriction. Restriction.
skipping to change at page 34, line 4 skipping to change at page 34, line 47
integrity and make such alterations detectable. integrity and make such alterations detectable.
* relying party is represented in the SAML assertion's Audience * relying party is represented in the SAML assertion's Audience
Restriction. Restriction.
* Issuer is represented in the SAML assertion. * Issuer is represented in the SAML assertion.
* validity period for assertion is restricted. * validity period for assertion is restricted.
10.2. Forged Assertion 10.2. Forged Assertion
Threat: Threat:
A malicious user could forge or alter a SAML assertion in order to A malicious user could forge or alter a SAML assertion in order to
communicate with the SIP entities. communicate with the SIP entities.
Countermeasures: Countermeasures:
To avoid this kind of attack, the entities must assure that proper To avoid this kind of attack, the entities must assure that proper
mechanisms for protecting the SAML assertion are employed, e.g., mechanisms for protecting the SAML assertion are employed, e.g.,
signing the SAML assertion itself. Section 5.1 of signing the SAML assertion itself or protecting the transport of
[OASIS.saml-core-2.0-os] specifies the signing of SAML assertions. the SAML assertion from the AS to the verifying party using TLS.
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 Additionally, the assertion content dictated by the SAML assertion
profile herein ensures ample evidence for a relying party to profile herein ensures ample evidence for a relying party to
verify the assertion and its relationship with the received SIP verify the assertion and its relationship with the received SIP
request. request.
10.3. Replay Attack 10.3. Replay Attack
Threat: Threat:
Theft of SIP message protected by the mechanisms described herein Theft of SIP message protected by the mechanisms described herein
and replay of it at a later time. and replay of it at a later time.
Countermeasures: Countermeasures:
There are various provisions within [RFC4474] that prevent a The SAML assertion may contain several elements to prevent replay
replay attack. attacks. There is, however, a clear tradeoff between the
replaying an assertion and re-using it over multiple SIP
exchanges/sessions.
11. Contributors 11. Contributors
The authors would like to thank Marcus Tegnander and Henning The authors would like to thank Marcus Tegnander and Henning
Schulzrinne for his contributions to earlier versions of this Schulzrinne for his contributions to earlier versions of this
document. document.
12. Acknowledgments 12. Acknowledgments
We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida We would like to thank RL 'Bob' Morgan, Stefan Goeman, Shida
Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki Schubert, Jason Fischl, Sebastian Felis, Nie Pin, Marcos Dytz, Erkki
Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen Koivusalo, Richard Barnes, Marc Willekens, Marc Willekens, Steffen
Fries and Vijay Gurbani for their comments to this draft. The "AS- Fries and Vijay Gurbani for their comments to this draft. The "AS-
driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based
on an idea by Jon Peterson. on an idea by Jon Peterson.
13. IANA Considerations 13. IANA Considerations
13.1. IANA Registration for New SIP Option Tag 13.1. Header Field Names
The SIP option tag "saml-shusb" is created by this document, with the This document specifies the new SIP header 'SAML-Info'. Their syntax
definition and rule in Section 4.4 of this document, to be added to is given in Section 9. This header is defined by the following
sip-parameters within IANA. information, which has been added to the header sub-registry under
http://www.iana.org/assignments/sip-parameters.
13.2. 477 'Use Identity Header with SAML Assertion' Response Code Header Name: SAML-Info
Compact Form: y
13.2. 477 'Binding to SIP Message failed' Response Code
This document registers a new SIP response code. It is sent when a This document registers a new SIP response code. It is sent when a
verifier receives a SIP request that lacks an Identity header with a verifier receives a SAML assertion but the Subject and Condition
SAML assertion in order to indicate that the request should be re- elements cannot be matched to the content in the SIP message, i.e.,
sent with an Identity header pointing to a SAML assertion. This the binding between the SIP message and the SAML assertion cannot be
response code is defined by the following information, which has been accomplished. This response code is defined by the following
added to the method and response-code sub-registry under information, which has been added to the method and response-code
http://www.iana.org/assignments/sip-parameters. sub-registry under http://www.iana.org/assignments/sip-parameters.
Response Code Number: 477 Response Code Number: 477
Default Reason Phrase: Use Identity Header with SAML Assertion Default Reason Phrase: Binding to SIP Message failed
13.3. 478 'Unknown SAML Assertion Content' Response Code 13.3. 478 'Unknown SAML Assertion Content' Response Code
This document registers a new SIP response code. It is used when the This document registers a new SIP response code. It is used when the
verifier is unable to parse the content of the SAML assertion verifier is unable to parse the content of the SAML assertion,
referenced by the URI of the Identity-Info header, because, for because, for example, the assertion contains only unknown elements in
example, the assertion contains only unknown elements in in the SAML in the SAML assertion, or the SAML assertion XML document is garbled.
assertion, or the SAML assertion XML document is garbled. This This response code is defined by the following information, which has
response code is defined by the following information, which has been been added to the method and response-code sub-registry under
added to the method and response-code sub-registry under
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Response Code Number: 478 Response Code Number: 478
Default Reason Phrase: Unknown SAML Assertion Content Default Reason Phrase: Unknown SAML Assertion Content
13.4. 479 'Invalid SAML Assertion' Response Code 13.4. 479 'Invalid SAML Assertion' Response Code
This document registers a new SIP response code. It is used when the This document registers a new SIP response code. It is used when the
verifier is unable to process the SAML assertion referenced by the verifier is unable to process the SAML assertion. A verifier may be
URI of the Identity-Info header, because, for example, the assertion unable to process the SAML assertion in case the assertion is self-
is self-signed, or signed by a root certificate authority for whom signed, or signed by a root certificate authority for whom the
the verifier does not possess a root certificate. This response code verifier does not possess a root certificate. This response code is
is defined by the following information, which has been added to the defined by the following information, which has been added to the
method and response-code sub-registry under method and response-code sub-registry under
http://www.iana.org/assignments/sip-parameters. http://www.iana.org/assignments/sip-parameters.
Response Code Number: 479 Response Code Number: 479
Default Reason Phrase: Invalid SAML Assertion Default Reason Phrase: Invalid SAML Assertion
14. Open Issues 14. Change Log
A list of open issues can be found at: RFC Editor - Please remove this section before publication.
http://www.tschofenig.priv.at:8080/saml-sip/
15. Change Log 14.1. -04 to -05
RFC Editor - Please remove this section before publication. Changed the document type to experimental
15.1. -03 to -04 Removed option tag
Added the Caller-driven SIP SAML Conveyed Assertion Profile
Defined a new header (SAML-Info)
Changed the description for usage with this new header
Updated security considerations
Minor editorial cleanups
14.2. -03 to -04
Updated IANA consideration section. Updated IANA consideration section.
Added option tag Added option tag
Updated acknowledgments section Updated acknowledgments section
Minor editorial changes to the security considerations section Minor editorial changes to the security considerations section
15.2. -02 to -03 14.3. -02 to -03
Denoted that this I-D is intended to update RFC4474 per SIP working Denoted that this I-D is intended to update RFC4474 per SIP working
group consensus at IETF-69. This is the tact adopted in order to group consensus at IETF-69. This is the tact adopted in order to
address the impedance mismatch between the nature of the URIs address the impedance mismatch between the nature of the URIs
specified as to be placed in the Identity-Info header field, and what specified as to be placed in the Identity-Info header field, and what
is specified in RFC4474 as the allowable value of that header field. is specified in RFC4474 as the allowable value of that header field.
Added placeholder "TBD" section for a to-be-determined "call-by- Added placeholder "TBD" section for a to-be-determined "call-by-
value" profile, per SIP working group consensus at IETF-69. value" profile, per SIP working group consensus at IETF-69.
Removed use-case appendicies (per recollection of JHodges during Removed use-case appendicies (per recollection of JHodges during
IETF-69 discussion as being WG consensus, but such is not noted in IETF-69 discussion as being WG consensus, but such is not noted in
the minutes). the minutes).
15.3. -00 to -02 14.4. -00 to -02
Will detail in -04 rev. Will detail in -04 rev.
16. References 15. References
16.1. Normative References 15.1. Normative References
[OASIS.saml-bindings-2.0-os] [OASIS.saml-bindings-2.0-os]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Language (SAML) V2.0", OASIS
Standard saml-bindings-2.0-os, March 2005. Standard saml-bindings-2.0-os, March 2005.
[OASIS.saml-core-2.0-os] [OASIS.saml-core-2.0-os]
Cantor, S., Kemp, J., Philpott, R., and E. Maler, Cantor, S., Kemp, J., Philpott, R., and E. Maler,
"Assertions and Protocol for the OASIS Security Assertion "Assertions and Protocol for the OASIS Security Assertion
skipping to change at page 41, line 39 skipping to change at page 42, line 39
P., Philpott, R., and E. Maler, "Profiles for the OASIS P., Philpott, R., and E. Maler, "Profiles for the OASIS
Security Assertion Markup Language (SAML) V2.0", OASIS Security Assertion Markup Language (SAML) V2.0", OASIS
Standard OASIS.saml-profiles-2.0-os, March 2005. 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", BCP 14, RFC 2119, 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.
[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key
Infrastructure Operational Protocols: FTP and HTTP",
RFC 2585, May 1999.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet [RFC3280] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet
skipping to change at page 42, line 16 skipping to change at page 43, line 19
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An [RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
IETF URN Sub-namespace for Registered Protocol IETF URN Sub-namespace for Registered Protocol
Parameters", BCP 73, RFC 3553, June 2003. Parameters", BCP 73, RFC 3553, June 2003.
[RFC3893] Peterson, J., "Session Initiation Protocol (SIP) [RFC3893] Peterson, J., "Session Initiation Protocol (SIP)
Authenticated Identity Body (AIB) Format", RFC 3893, Authenticated Identity Body (AIB) Format", RFC 3893,
September 2004. September 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig, [RFC4484] Peterson, J., Polk, J., Sicker, D., and H. Tschofenig,
"Trait-Based Authorization Requirements for the Session "Trait-Based Authorization Requirements for the Session
Initiation Protocol (SIP)", RFC 4484, August 2006. Initiation Protocol (SIP)", RFC 4484, August 2006.
[W3C.xmldsig-core] [W3C.xmldsig-core]
Eastlake, D., Reagle , J., and D. Solo, "XML-Signature Eastlake, D., Reagle , J., and D. Solo, "XML-Signature
Syntax and Processing", W3C Recommendation xmldsig-core, Syntax and Processing", W3C Recommendation xmldsig-core,
October 2000, <http://www.w3.org/TR/xmldsig-core/>. October 2000, <http://www.w3.org/TR/xmldsig-core/>.
16.2. Informative References 15.2. Informative References
[IANA.application.samlassertion-xml] [IANA.application.samlassertion-xml]
OASIS Security Services Technical Committee (SSTC), OASIS Security Services Technical Committee (SSTC),
"application/samlassertion+xml MIME Media Type "application/samlassertion+xml MIME Media Type
Registration", IANA MIME Media Types Registry application/ Registration", IANA MIME Media Types Registry application/
samlassertion+xml, December 2004. samlassertion+xml, December 2004.
[OASIS.saml-conformance-2.0-os] [OASIS.saml-conformance-2.0-os]
Mishra, P., Philpott, R., and E. Maler, "Conformance Mishra, P., Philpott, R., and E. Maler, "Conformance
Requirements for the Security Assertion Markup Language Requirements for the Security Assertion Markup Language
skipping to change at page 43, line 15 skipping to change at page 44, line 22
[OASIS.sstc-saml-exec-overview-2.0-cd-01] [OASIS.sstc-saml-exec-overview-2.0-cd-01]
Madsen, P. and E. Maler, "SAML V2.0 Executive Overview", Madsen, P. and E. Maler, "SAML V2.0 Executive Overview",
OASIS SSTC Committee OASIS SSTC Committee
Draft sstc-saml-exec-overview-2.0-cd-01, April 2005. Draft sstc-saml-exec-overview-2.0-cd-01, April 2005.
[OASIS.sstc-saml-protocol-ext-thirdparty-cd-01] [OASIS.sstc-saml-protocol-ext-thirdparty-cd-01]
Cantor, S., "SAML Protocol Extension for Third-Party Cantor, S., "SAML Protocol Extension for Third-Party
Requests", OASIS SSTC Committee Draft sstc-saml-protocol- Requests", OASIS SSTC Committee Draft sstc-saml-protocol-
ext-thirdparty-cd-01, March 2006. ext-thirdparty-cd-01, March 2006.
[OASIS.sstc-saml-tech-overview-2.0-draft-08] [OASIS.sstc-saml-tech-overview-2.0-draft-16]
Hughes, J. and E. Maler, "Security Assertion Markup Ragouzis, N., Hughes, J., Philpott, R., Maler, E., Madsen,
Language (SAML) V2.0 Technical Overview", OASIS SSTC P., and T. Scavo, "Security Assertion Markup Language
Working Draft sstc-saml-tech-overview-2.0-draft-08, (SAML) V2.0 Technical Overview", OASIS SSTC Working
September 2005. Draft sstc-saml-tech-overview-2.0-draft-16, May 2008.
[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.
[RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas, [RFC2693] Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693, B., and T. Ylonen, "SPKI Certificate Theory", RFC 2693,
September 1999. September 1999.
[RFC3281] Farrell, S. and R. Housley, "An Internet Attribute [RFC3281] Farrell, S. and R. Housley, "An Internet Attribute
skipping to change at page 44, line 18 skipping to change at page 45, line 18
Nokia Siemens Networks Nokia Siemens Networks
Linnoitustie 6 Linnoitustie 6
Espoo 02600 Espoo 02600
Finland Finland
Phone: +358 (50) 4871445 Phone: +358 (50) 4871445
Email: Hannes.Tschofenig@gmx.net Email: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at URI: http://www.tschofenig.priv.at
Jeff Hodges Jeff Hodges
NeuStar, Inc. Unaffiliated
2000 Broadway Street
Redwood City, CA 94063
US
Email: Jeff.Hodges@neustar.biz Email: Jeff.Hodges@KingsMountain.com
Jon Peterson Jon Peterson
NeuStar, Inc. NeuStar, Inc.
1800 Sutter St Suite 570 1800 Sutter St Suite 570
Concord, CA 94520 Concord, CA 94520
US US
Email: jon.peterson@neustar.biz Email: jon.peterson@neustar.biz
James Polk James Polk
 End of changes. 104 change blocks. 
225 lines changed or deleted 279 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/