< draft-ietf-sip-saml-06.txt   draft-ietf-sip-saml-07.txt >
SIP H. Tschofenig SIP H. Tschofenig
Internet-Draft Nokia Siemens Networks Internet-Draft Nokia Siemens Networks
Intended status: Experimental J. Hodges Intended status: Experimental J. Hodges
Expires: September 9, 2009 Unaffiliated Expires: September 9, 2010
J. Peterson J. Peterson
NeuStar, Inc. NeuStar, Inc.
J. Polk J. Polk
Cisco Cisco
D. Sicker D. Sicker
CU Boulder CU Boulder
March 8, 2009 March 8, 2010
SIP SAML Profile and Binding SIP SAML Profile and Binding
draft-ietf-sip-saml-06.txt draft-ietf-sip-saml-07.txt
Abstract
This document specifies a Session Initiation Protocol (SIP) profile
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)".
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and 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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 48
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 September 9, 2009. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
This document specifies a Session Initiation Protocol (SIP) profile described in the BSD License.
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 Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 8 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7
3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 9 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8
3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 10 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9
4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 11 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10
5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12
6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 14 6. URI Parameter Definition . . . . . . . . . . . . . . . . . . . 14
6.1. AS-driven SIP SAML URI-based Attribute Assertion 7. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 15
Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 14 7.1. AS-driven SIP SAML URI-based Attribute Assertion
6.1.1. Required Information . . . . . . . . . . . . . . . . . 14 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 15
6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 14 7.1.1. Required Information . . . . . . . . . . . . . . . . . 15
6.1.3. Profile Description . . . . . . . . . . . . . . . . . 18 7.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 16
6.1.4. Assertion Profile Description . . . . . . . . . . . . 21 7.1.3. Profile Description . . . . . . . . . . . . . . . . . 19
6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 23 7.2. Caller-driven SIP SAML Conveyed Assertion Profile . . . . 22
6.2. Caller-driven SIP SAML Conveyed Assertion Profile . . . . 24 8. Assertion Profile . . . . . . . . . . . . . . . . . . . . . . 23
7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 26 8.1. Assertion Profile Description . . . . . . . . . . . . . . 23
7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 26 8.1.1. Element: <Assertion> . . . . . . . . . . . . . . . . . 23
8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 27 8.2. Assertion Verification . . . . . . . . . . . . . . . . . . 25
9. Authentication Service Behavior . . . . . . . . . . . . . . . 32 9. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 27
10. Verifier Behavior . . . . . . . . . . . . . . . . . . . . . . 34 9.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 27
11. SAML-Info Header Field . . . . . . . . . . . . . . . . . . . . 36 10. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 28
12. Extended RFC 4474 SIP Identity Signature Mechanism . . . . . . 38 11. Security Considerations . . . . . . . . . . . . . . . . . . . 33
13. Security Considerations . . . . . . . . . . . . . . . . . . . 41 11.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 33
13.1. Man-in-the-Middle Attacks and Stolen Assertions . . . . . 41 11.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 33
13.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 41 11.3. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 34
13.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 42 11.4. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 35
14. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 43 12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 36
15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 37
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 45 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
16.1. Header Field Names . . . . . . . . . . . . . . . . . . . . 45 14.1. URI Parameter . . . . . . . . . . . . . . . . . . . . . . 38
16.2. 477 'Binding to SIP Message failed' Response Code . . . . 45 14.2. 477 'Binding to SIP Message failed' Response Code . . . . 38
16.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 45 14.3. 478 'Unknown SAML Assertion Content' Response Code . . . . 38
16.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 46 14.4. 479 'Invalid SAML Assertion' Response Code . . . . . . . . 39
16.5. 480 'Use SAML Header' Response Code . . . . . . . . . . . 46 15. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 40
17. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 47 15.1. -06 to -07 . . . . . . . . . . . . . . . . . . . . . . . . 40
17.1. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 47 15.2. -05 to -06 . . . . . . . . . . . . . . . . . . . . . . . . 40
17.2. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 47 15.3. -04 to -05 . . . . . . . . . . . . . . . . . . . . . . . . 40
17.3. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 47 15.4. -03 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 40
17.4. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 47 15.5. -02 to -03 . . . . . . . . . . . . . . . . . . . . . . . . 40
17.5. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 48 15.6. -00 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 41
18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 49 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
18.1. Normative References . . . . . . . . . . . . . . . . . . . 49 16.1. Normative References . . . . . . . . . . . . . . . . . . . 42
18.2. Informative References . . . . . . . . . . . . . . . . . . 50 16.2. Informative References . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 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 identity. Motivations for trait-based authorization, along with
with use-case scenarios, are presented in [RFC4484]. 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-16] 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 for encoding authorization information exists, such as
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]. This document focuses
SAML due to its increasing use in environments, such as the Liberty on an encoding of the authorization information using SAML assertions
Alliance, and the Internet2 project, areas where the applicability to but does not exclude other formats to be used utilized in the future.
SIP is widely desired.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
The SIP network element "Authentication Service" is introduced in The SIP network element "Authentication Service" is introduced in
[RFC4474]. We reuse this term to refer to a network element that [RFC4474]. We reuse this term to refer to a network element that
authenticates and authorizes a user and creates a "SIP identity authenticates and authorizes a user and creates a "SIP identity
skipping to change at page 8, line 14 skipping to change at page 7, line 14
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-16] 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 Thus one can employ SAML to make and encode statements such as "Alice
"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
example input it into some local policy evaluation for access to some example input it into some local policy evaluation for access to some
resource. This is done in a particular "context of use". Such a resource. This is done in a particular "context of use". Such a
context of use could be, for example, deciding whether to accept and context of use could be, for example, deciding whether to accept and
act upon a SIP-based invitation to initiate a communication session. act upon a SIP-based invitation to initiate a communication session.
The specification of how SAML is employed in a particular context of The specification of how SAML is employed in a particular context of
use is known as a "SAML profile". The specification of how SAML use is known as a "SAML profile". The specification of how SAML
skipping to change at page 11, line 10 skipping to change at page 10, line 10
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 -- also known as a "SIP SAML o Specify a SIP profile of SAML -- also known as a "SIP SAML
profile" -- such that a subject's profile attributes. In doing profile" -- such that a subject's profile attributes, and their
so, satisfy the requirements outlined in [RFC4484]. domain's certificate, can be conveyed to a relying party using
SAML. In doing so, satisfy the requirements outlined in
[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 12 skipping to change at page 12, line 12
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 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). SIP-specific SAML profile(s) and binding(s). This is technically
straightforward as both SAML and SIP are explicitly extensible.
The SIP SAML Profiles defined in this document make use of concepts The SIP SAML Profiles defined in this document make use of concepts
defined by [RFC4474] "Enhancements for Authenticated Identity defined by [RFC4474] "Enhancements for Authenticated Identity
Management in the Session Initiation Protocol (SIP)" -- also known as Management in the Session Initiation Protocol (SIP)" -- also known as
"SIP Identity". In particular, they leverage the "mediated "SIP Identity". SIP Identity allows the SIP UA client and an entity
authentication architecture" utilizing the Authentication Service on behalf of the UA client to attach a SAML assertion (or a reference
(AS). The overall semantic being that the AS is vouching that it did to it). Since intermediaries, like an outbound SIP proxy, are not
indeed authenticate the calling party. allowed to modify the body of a SIP message such an intermediary
would attach a pointer to the assertion instead.
Such an Authentication Service, which likely has access to various The specific details on how the SAML assertion is requested are
pieces of information concerning the calling party, could also act as outside the scope of this document. Possible mechanisms are to use a
a SAML Authority, and make such information available to the callee software library that can be accessed via an API, a separate
via SAML. authorization server that can be queried via HTTP (as envisioned the
'OAuth Web Resource Authorization Profiles' specification
[I-D.hardt-oauth]), or any other mechanism. As such, this document
does not further describe the functional split between the party that
attaches the SAML assertion to the SIP message and the party that
creates the SAML assertion. The SIP Identity specification calls the
party that makes identity assertions about the caller "Authentication
Service (AS)". 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. This document uses the term SAML
Authority and Authentication Service interchangable particularly
because of the fact that the entity that attaches the SAML assertion
to the SIP message also uses the SIP Identity mechanism to bind it to
the message.
The approach used by this document is similar to the one used for SIP Note that technically there is a difference between attaching a
Identity, i.e. the AS creates a SAML assertion and makes it available reference to a SAML assertion and attaching a SAML assertion to the
to the verifier via a reference, in the particular case of the AS- body of a message. We define two different profiles to cover these
driven SIP SAML URI-based Attribute Assertion Fetch Profile. two cases:
Figure 1 illustrates this approach in a high-level summary fashion.
Figure 2, further below, illustrates additional details. In case of
the Assertion-by Value profile the SAML assertion is made available
to the verifying party directly without the additional step of
utilizing a reference. This approach is described in Section 6.2.
+--------+ +--------------+ +--------+ AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile:
|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/SAML-Info and |
| | w/SAML-Signature |
| |--------------------->|
| | |
| | |
| | HTTP GET SAML assn |
| |<==================== |
| | |
| | |
| | HTTP 200 OK + assn |
| |=====================>|
| | |
| 200 OK | |
|<----------------------+----------------------|
| | |
Figure 1: SIP-SAML-based Network Asserted Identity In case of this profile the AS attaches a reference to a SAML
assertion to the SIP message and makes it available to the
verifier. More details about this profile can be found in
Section 7.1.
Figure 1 shows an exchange based on the AS-driven SIP SAML URI-based Assertion-by-Value Profile:
Attribute Assertion Fetch Profile where the AS creates a SAML
assertion, creates a reference to it, and puts that reference into
the SAML-Info header before forwarding the SIP message. To tie the
SAML-Info field to the message a digial signature is computed and
placed in the SAML-Signature header. Bob in our case acting as the
verifier uses the reference to retrieve the SAML assertion, verifies
it and the SAML-Signature.
6. SIP SAML Profiles In case of this profile the SAML assertion is made available to
the verifying party directly without the additional step of
utilizing a reference. This approach is described in Section 7.2.
6. URI Parameter Definition
This document represents the URL pointing to the authorization
information using a URI parameter. The grammar for this parameter is
(following the ABNF [RFC4234] in Section 25 of RFC 3261 [RFC3261]):
token-info =
"token-info" HCOLON ident-info *( SEMI ident-info-params )
ident-info = LAQUOT absoluteURI RAQUOT
ident-info-params = generic-param
Figure 1: 'token-info' ABNF Grammar
The "absoluteURI" 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. 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.
An example of the syntax of the "token-info" parameter is given
below:
From: <tel:+17005554141;
token-info=https://example.com/assns/?ID=abcde>;
tag=1928301774
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 "Assertion-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
skipping to change at page 14, line 45 skipping to change at page 16, line 5
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 2 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, may be applied to any SIP request message. herein, may be applied to any SIP request message.
skipping to change at page 16, line 34 skipping to change at page 17, line 34
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
| | | | | |
G = | | SAML-Info: | G = | | token-info: |
| | https://example.com| | | https://example.com|
| N | | /assns/?ID=abcde | | N | | /assns/?ID=abcde |
| | | | SAML-Signature |
| | | | | | | |
| + | |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> |
| | | | <saml:Subject> | | | | | <saml:Subject> |
| | | | <saml:NameID> | | | | | <saml:NameID> |
skipping to change at page 17, line 24 skipping to change at page 18, line 23
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 2. 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
challenge, or uses cached credentials for the domain if step challenge, or uses cached credentials for the domain if step
1 was skipped, as specified in [RFC4474] and [RFC3261]. 1 was skipped, as specified in [RFC4474] and [RFC3261].
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
procedure is successful, the AS creates a SAML assertion is successful, the AS constructs and caches a SAML assertion
asserting Alice's profile attributes required by Bob's asserting Alice's profile attributes required by Bob's
domain (example2.com)., and also containing a the domain's domain (example2.com), and also containing a the domain's
(example.com) public key certificate, or a reference to it. (example.com) public key certificate, or a reference to it.
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
the value for the SAML-Info header it adds to the INVITE and puts the value into the token-info parameter.
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 needs to Bob's UAC or SIP Proxy receives the message and begins
obtain Alice's domain certificate that is contained in the verifying it per the "Verifier Behavior" specified in
SAML assertion. It obtains the HTTP-based SAML URI [RFC4474]. In order to accomplish this task, it needs to
Reference from the message's SAML-Info header and obtain Alice's domain certificate. It obtains the HTTP-
dereferences it per Section 7.1. Note that this is not a based SAML URI reference from the message's token-info
SIP message, but an HTTP message [RFC2616]. parameter and dereferences it per Section 9.1. Note that
this is not 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 binding between Upon receipt of Alice's SAML Assertion, the AS continues its
the SAML assertion and the SIP message is verified. A verification of the INVITE message. If successful, it
detailed description can be found in Section 10. Various returns a 200 OK message directly to Alice. Otherwise it
elements contained in the SAML assertion are inspected and returns an appropriate SIP error response.
the processing of the INVITE message is continued.
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 3, 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)|
skipping to change at page 19, line 26 skipping to change at page 20, line 26
| | | | | |
| ACK | | | ACK | |
|---------------------->| | (1c) |---------------------->| | (1c)
| | | | | |
| | | | | |
|SIP Req + authorization| | |SIP Req + authorization| |
| header w/ creds | | | header w/ creds | |
|---------------------->| | (2) |---------------------->| | (2)
| | | | | |
| | | | | |
| | SIP Req + SAML-Info | | | SIP Req + token-info |
| | + SIP-Signature |
| |--------------------->| (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 3: 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 3 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 9, This first portion of this step maps to Steps 3 and 4 of Section 5
which the AS MUST perform, although with the following additional "Authentication Service Behavior" of [RFC4474], which the AS MUST
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 8.1 of this
specification. specification.
The AS MUST construct an HTTP URI per Section "3.7.5.1 URI Syntax" The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI
of [OASIS.saml-bindings-2.0-os]. To enable proper caching, the per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os].
HTTP URI pointing to the SAML assertion MUST be unique, i.e., if
the content of the SAML assertion changes then the HTTP URI
reference MUST be different than any previously used HTTP URI
references used before.
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 SAML-Info header that is added to the substep as the value of the token-info parameter that is added to
SIP request message. the 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 10. are specified in Section 6 "Verifier Behavior" of [RFC4474]. The
verifier MUST perform the steps enumerated in the aforementioned
section, with the following modifications:
6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference Step 1 of [RFC4474] Section 6 maps to and is updated by, the
following two steps in this procedure.
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
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 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 SAML-Info header. To do so, the verifier MUST employ SIP message's token-info parameter. To do so, the verifier MUST
the "SAML HTTP-URI-based SIP Binding" specified in Section 7.1. employ the "SAML HTTP-URI-based SIP Binding" specified in
Section 9.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 9.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 SAML-Info' Response code. 'Bad token-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 8.2
Section 6.1.5 "Assertion Verification", below. If successful, then "Assertion Verification", below. If successful, then this procedure
this procedure continues with the next step. 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.2. Caller-driven SIP SAML Conveyed Assertion Profile
This section defines the particulars of how the sender, i.e., the For the "Assertion-by-value" profile we assume that a SAML assertion
SAML Authority, MUST construct certain portions of the SAML is obtained out-of-band and attached to the body of the SIP message.
assertions it issues. The schema for SAML assertions themselves is Note that any SIP message may be used to convey the SAML assertion
defined in Section 2.3 of [OASIS.saml-core-2.0-os]. even though SIP INVITE may be the most appropriate candiate. The
verification step described in Section 8.2 is applicable to this
profile as well as the description on the content of the assertion
illustrated in Section 8.1.
8. Assertion Profile
This section provides some guidance on what information should be put
into a SAML assertion by the SAML Authority and how that information
is then used by the Verifier.
8.1. Assertion Profile Description
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 An example SAML assertion, formulated according to this profile is
given in Section 8. given in Section 10.
Overall SAML assertion profile requirements:
If a SAML assertion 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].
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> 8.1.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> 8.1.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
This field contains the domain certificate of the AS. 8.1.1.2. Element: <Subject>
6.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 Address of Record The value of the <NameID> element MUST be the Address of Record
(AoR). (AoR).
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> 8.1.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. When element, which itself SHOULD contain an <Audience> element. When
included the value of the <Audience> element MUST be the same as the included the value of the <Audience> element MUST be the same as the
addr-spec 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> 8.1.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 8.2. Assertion Verification
This section specifies the steps that a verifier participating in This section specifies the steps that a verifier has to perform to
this profile MUST perform in addition to the "Verifier Behavior" verify a SAML assertion created according to the profile from
specified in Section 6 of [RFC4474]. Section 8.1.1.
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:X509Certificate> extract the AS's domain certificate from the <ds:
XML element at the end of the element path given in X509Certificate> XML element at the end of the element path
Section 6.1.4.1.1. given in Section 8.1.1.1.
2. Perform Step 1 in Section 6 of [RFC4474].
3. After Step 1 in Section 6 of [RFC4474], 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].
The 479 'Invalid SAML Assertion' response code is used when the
verifier is unable to process the SAML assertion.
4. Perform Step 2 in Section 6 of [RFC4474].
5. Verify that the signer of the SIP message's Identity header field 2. Perform Step 1 in Section 6 of [RFC4474].
is the same as the signer of the SAML assertion.
6. Verify that the content of the SAML assertion, if present, 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of
matches with the information carried in the SIP message. This that section, the verifier MUST verify the SAML assertion's
may include the following checks: signature via the procedures specified in Section 5.4 of
[OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. The 479
'Invalid SAML Assertion' response code is used when the verifier
is unable to process the SAML assertion.
7. 4. Perform Step 2 in Section 6 of [RFC4474].
* Verify that the SAML assertion's <Issuer> element value 5. Verify that the signer of the SIP message's Identity header
matches the Issuer or the Issuer Alternative Name fields field is the same as the signer of the SAML assertion, if SIP
[RFC3280] in the AS's domain certificate. Identity is used to bind the token-info parameter to the SIP
signaling message. Note that without such protection certain
attacks are feasible as described in Section 11.
* Verify that the SAML assertion's <NameID> element value is the 6. Verify that the content of the SAML assertion matches with the
same as the Address of Record (AoR) value. information carried in the SIP message. This may include the
following checks:
* Verify that the SAML assertion's <SubjectConfirmation> element 7. Verify that the SAML assertion's <Issuer> element value matches
value is set to whichever value was configured at the Issuer or the Issuer Alternative Name fields [RFC3280] in
implementation- or deployment-time. The default value is: the AS's domain certificate.
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches 8. Verify that the SAML assertion's <NameID> element value is the
same as the Address of Record (AoR) value.
* Verify that the SAML assertion contains an <Audience> element, 9. Verify that the SAML assertion's <SubjectConfirmation> element
and that its value matches the value of the addr-spec of the value is set to whichever value was configured at
SIP To header field. implementation- or deployment-time. The default value is:
* Verify that the validity period denoted by the NotBefore and urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
NotOnOrAfter attributes of the <Conditions> element meets the
requirements given in Section 6.1.4.1.3.
6.2. Caller-driven SIP SAML Conveyed Assertion Profile 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.
For the "Assertion-by-value" profile we assume that a SAML assertion 11. Verify that the validity period denoted by the NotBefore and
is obtained out-of-band and attached to the body of the SIP message. NotOnOrAfter attributes of the <Conditions> element meets the
Note that any SIP message may be used to convey the SAML assertion requirements given in Section 8.1.1.3.
even though SIP INVITE may be the most appropriate candiate. The
verification step described in Section 6.1.5 is applicable to this
profile as well as the description on the content of the assertion
illustrated in Section 6.1.4.
7. SAML SIP Binding 9. 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 6.1.4 is applicable to this profile. The description in Section 8.1 is applicable to this profile.
7.1. SAML HTTP-URI-based SIP Binding 9.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 28, 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. Example SAML Assertions 10. 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 4, 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 13.1 and Section 13.2. dicussions, see: Section 11.1 and Section 11.3.
In lines 24-36, Alice's telephone number is conveyed, in a "typed" In lines 24-36, Alice's telephone number is conveyed, in a "typed"
fashion, using LDAP/X.500 schema as the typing means. fashion, using LDAP/X.500 schema as the typing means.
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"
3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> 3 xmlns="urn:oasis:names:tc:SAML:2.0:assertion">
4 <Issuer> 4 <Issuer>
5 example.com 5 example.com
6 </Issuer> 6 </Issuer>
skipping to change at page 32, line 5 skipping to change at page 33, line 5
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 5: Signed SAML Assertion Illustrating Conveyance of Subject
Attribute Attribute
9. Authentication Service Behavior 11. Security Considerations
[RFC4474] defined a new role for SIP entities called an
authentication service. This document re-uses the concept and hence
the same constraints and properties apply to this document. The
subsequent text is copied from [RFC4474] and modified to fit to the
usage of SAML.
Any entity that instantiates the authentication service role MUST
possess the private key of a domain certificate. Intermediaries that
instantiate this role MUST be capable of authenticating one or more
SIP users that can register in that domain. Commonly, this role will
be instantiated by a proxy server, since these entities are more
likely to have a static hostname, hold a corresponding certificate,
and have access to SIP registrar capabilities that allow them to
authenticate users in their domain. It is also possible that the
authentication service role might be instantiated by an entity that
acts as a redirect server, but that is left as a topic for future
work.
SIP entities that act as an authentication service MUST add a Date
header field to SIP requests if one is not already present.
Similarly, authentication services MUST add a Content- Length header
field to SIP requests if one is not already present; this can help
verifiers to double-check that they are hashing exactly as many bytes
of message-body as the authentication service when they verify the
message.
Entities instantiating the authentication service role perform the
following steps, in order, to generate an Identity header for a SIP
request:
Step 1:
The authentication service MUST extract the identity of the sender
from the request. The authentication service takes this value
from the From header field; this AoR will be referred to here as
the 'identity field'. If the identity field contains a SIP or SIP
Secure (SIPS) URI, the authentication service MUST extract the
hostname portion of the identity field and compare it to the
domain(s) for which it is responsible (following the procedures in
RFC 3261, Section 16.4, used by a proxy server to determine the
domain(s) for which it is responsible). If the identity field
uses the TEL URI scheme, the policy of the authentication service
determines whether or not it is responsible for this identity. If
the authentication service is not responsible for the identity in
question, it SHOULD process and forward the request normally, but
it MUST NOT add a SAML-Info and a SAML-Signature header.
Step 2:
The authentication service MUST determine whether or not the
sender of the request is authorized to claim the identity given in
the identity field. In order to do so, the authentication service
MUST authenticate the sender of the message.
Step 3:
The authentication service SHOULD ensure that any preexisting Date
header in the request is accurate. Local policy can dictate
precisely how accurate the Date must be; a RECOMMENDED maximum
discrepancy of ten minutes will ensure that the request is
unlikely to upset any verifiers. If the Date header contains a
time different by more than ten minutes from the current time
noted by the authentication service, the authentication service
SHOULD reject the request. This behavior is not mandatory because
a user agent client (UAC) could only exploit the Date header in
order to cause a request to fail verification; the SAML-Signature
header is not intended to provide a source of non-repudiation or a
perfect record of when messages are processed. Finally, the
authentication service MUST verify that the Date header falls
within the validity period of its certificate.
Step 4:
The authentication service MUST form the signature and add the
SAML-Signature header to the request containing this signature.
After the SAML-Signature header has been added to the request, the
authentication service MUST also add an SAML-Info header. The
SAML-Info header contains a URI from which the SAML assertion and
a domain certificate can be acquired.
Finally, the authentication service MUST forward the message
normally.
10. Verifier Behavior
When a verifier receives a SIP message containing an SAML-Signature
and SAML-Info header, it may inspect these two header fields.
Typically, the results of a verification are provided as input to an
authorization process that is outside the scope of this document. If
an SAML-Info and SAML-Signature header is not present in a request,
and one is required by local policy (for example, based on a per-
sending-domain policy, or a per-sending-user policy), then a 428 'Use
SAML Header' response MUST be sent.
In order to verify the identity of the sender of a message, an entity
acting as a verifier MUST perform the following steps, in the order
here specified.
Step 1:
The verifier has to acquire the certificate for the signing
domain. Implementations supporting this specification SHOULD have
some means of retaining domain certificates (in accordance with
normal practices for certificate lifetimes and revocation) in
order to prevent themselves from needlessly downloading the same
certificate every time a request from the same domain is received.
Certificates cached in this manner should be indexed by the URI
given in the SAML-Info header field value.
Provided that the domain certificate used to sign this message is
not previously known to the verifier, SIP entities SHOULD discover
this certificate by dereferencing the SAML-Info header, unless
they have some more efficient implementation-specific way of
acquiring certificates for that domain. The domain certificate
can be found in the SAML assertion, either by reference or by
value. The verifier processes this certificate in the usual ways,
including checking that it has not expired, that the chain is
valid back to a trusted certification authority (CA), and that it
does not appear on revocation lists. Once the certificate is
acquired, it MUST be validated following the procedures in RFC
3280 [RFC3280]. If the certificate cannot be validated (it is
self-signed and untrusted, or signed by an untrusted or unknown
certificate authority, expired, or revoked), the verifier MUST
send a 437 'Unsupported Certificate' response.
Step 2:
The verifier MUST follow the process described in Section 13.4 of
[RFC4474] to determine if the signer is authoritative for the URI
in the From header field.
Step 3:
The verifier MUST verify the signature in the SAML-Signature
header field, following the procedures for generating the hashed
digest-string described in Section 12. If a verifier determines
that the signature on the message does not correspond to the
reconstructed digest- string, then a 479 'Invalid SAML Assertion'
response MUST be returned.
Step 4:
The verifier MUST validate the Date, Contact, and Call-ID headers.
It must furthermore ensure that the value of the Date header falls
within the validity period of the certificate whose corresponding
private key was used to sign the Identity header.
11. SAML-Info Header Field
This document introduces the SIP header field "SAML-Info" to carry a
reference to a SAML assertion. 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 6: 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 7: New SAML-Info Row for RFC3261 Table 2
The SAML-Info header MUST NOT appear in CANCEL.
12. Extended RFC 4474 SIP Identity Signature Mechanism
To allow the SIP Identity mechanism [RFC4474] to protect also the
reference to the SAML assertion additional SIP header fields need to
be protected by the signature calculation mechanisms. The extended
signature computation is included in the SAML-Signature header field.
The grammar for this new header is (following the ABNF [RFC4234] in
RFC 3261 [RFC3261]):
SAML-Signature = "SAML-Signature" HCOLON ( signed-identity-digest
sig-info-fields sig-info-alg ) / sig-info-extension
signed-identity-digest = LDQUOT 32LHEX RDQUOT
sig-info-alg = "alg" EQUAL token
sig-info-fields = "fields" EQUAL token
sig-info-extension = generic-param
The signed-identity-digest is a signed hash of a canonical string
generated from certain components of a SIP request. To create the
contents of the signed-identity-digest, the following elements of a
SIP message MUST be placed in a bit-exact string in the order
specified here, separated by a vertical line, "|" or %x7C, character:
o The AoR of the UA sending the message, or addr-spec of the From
header field (referred to occasionally here as the 'identity
field').
o The addr-spec component of the To header field, which is the AoR
to which the request is being sent.
o The callid from Call-Id header field.
o The digit (1*DIGIT) and method (method) portions from CSeq header
field, separated by a single space (ABNF SP, or %x20). Note that
th CSeq header field allows linear whitespace (LWS) rather than SP
to separate the digit and method portions, and thus the CSeq
header field may need to be transformed in order to be
canonicalized. The authentication service MUST strip leading
zeros from the 'digit' portion of the Cseq before generating the
digest-string.
o The Date header field, with exactly one space each for each SP and
the weekday and month items case set as shown in BNF in RFC 3261.
RFC 3261 specifies that the BNF for weekday and month is a choice
amongst a set of tokens. The RFC 2234 rules for the BNF specify
that tokens are case sensitive. However, when used to construct
the canonical string defined here, the first letter of each week
and month MUST be capitalized, and the remaining two letters must
be lowercase. This matches the capitalization provided in the
definition of each token. All requests that use the Identity
mechanism MUST contain a Date header.
o The addr-spec component of the Contact header field value. If the
request does not contain a Contact header, this field MUST be
empty (i.e., there will be no whitespace between the fourth and
fifth "|" characters in the canonical string).
o The sig-info-params parameter contains a list of SIP header fields
whose values have to be included into the signature calculation.
The individual field names in small letters are encoded in the
token parameter of the sig-info-fields, each name separated by a
"|" character.
o The body content of the message with the bits exactly as they are
in the Message (in the ABNF for SIP, the message-body). This
includes all components of multipart message bodies. Note that
the message-body does NOT include the CRLF separating the SIP
headers from the message-body, but does include everything that
follows that CRLF. If the message has no body, then message-body
will be empty, and the final "|" will not be followed by any
additional characters.
The precise formulation of this digest-string is, therefore
(following the ABNF [RFC4234] in RFC 3261 [RFC3261]):
digest-string = addr-spec "|" addr-spec "|" callid "|"
1*DIGIT SP Method "|" SIP-date "|" [ addr-spec ] "|"
sigfields "|" message-body
The signfields parameter represent the concatination of the values of
the SIP header fields that are included in the signature calculation.
Note again that the first addr-spec MUST be taken from the From
header field value, the second addr-spec MUST be taken from the To
header field value, and the third addr-spec MUST be taken from the
Contact header field value, provided the Contact header is present in
the request.
After the digest-string is formed, it MUST be hashed and signed with
the certificate for the domain. The hashing and signing algorithm is
specified by the 'alg' parameter. This document defines only one
value for the 'alg' parameter: 'rsa-sha1'. All implementations of
this specification MUST support 'rsa-sha1'. When the 'rsa-sha1'
algorithm is specified in the 'alg' parameter of Identity-Info, the
hash and signature MUST be generated as follows: compute the results
of signing this string with sha1WithRSAEncryption as described in RFC
3370 [RFC3370] and base64 encode the results as specified in RFC 3548
[RFC3548]. A 1024-bit or longer RSA key MUST be used. The result is
placed in the SAML-Signature header field.
This document adds the following entries to Table 2 of RFC 3261
[RFC3261]:
Header field where proxy ACK BYE CAN INV OPT REG
------------ ----- ----- --- --- --- --- --- ---
SAML-Signature R a o o - o o o
SUB NOT REF INF UPD PRA
--- --- --- --- --- ---
o o o o o o
Note, in the table above, that this mechanism does not protect the
CANCEL method. The CANCEL method cannot be challenged, because it is
hop-by-hop, and accordingly authentication service behavior for
CANCEL would be significantly limited. Note as well that the
REGISTER method uses Contact header fields in very unusual ways that
complicate its applicability to this mechanism, and the use of
Identity with REGISTER is consequently a subject for future study,
although it is left as optional here for forward-compatibility
reasons. The SAML-Signature header MUST NOT appear in CANCEL.
13. Security Considerations
This section discusses security considerations when using SAML with This section discusses security considerations when using SAML with
SIP. SIP.
13.1. Man-in-the-Middle Attacks and Stolen Assertions 11.1. Man-in-the-Middle Attacks and Stolen Assertions
Threat: Threat:
By making SAML assertions available via HTTP-based requests by a By making SAML assertions available via HTTP-based requests by a
potentially unbounded set of requesters, it is conceivably potentially unbounded set of requesters, it is conceivably
possible that anyone would be able to simply request one and possible that anyone would be able to simply request one and
obtain it. By SIP intermediaries on the signaling path for obtain it. By SIP intermediaries on the signaling path for
example. Or, an HTTP intermediary/proxy could intercept the example. Or, an HTTP intermediary/proxy could intercept the
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 attempt to utilize the SAML assertion in
subject (the putative caller) to some SIP-based target entity. another exchange in order to impersonate the 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 because the values in the SAML assertion, which will not verify because the values in the SAML assertion, which
are tied to the SIP message, will not verify. are tied to the SIP message, will not verify.
Also, the SIP SAML assertion profile specified herein that the Furthermore, the SIP SAML assertion may contain restrictions
subject's SAML assertion must adhere to causes it to be not useful regarding the parties it can be used by. Finally, the assertion
to arbitrary parties. The subject's assertion: should be signed and thus causing any alterations to break its
integrity and make such alterations detectable.
* should be signed, thus causing any alterations to break its 11.2. Privacy
integrity and make such alterations detectable.
* relying party is represented in the SAML assertion's Audience Threat:
Restriction.
* Issuer is represented in the SAML assertion. The ability for other entities to obtain additional information
about an individual, such as role in an organization or other
authorization relevant information raises privacy concerns.
* validity period for assertion is restricted. Since the SAML assertion itself is not confidentiality protected
nor the exchange of the reference to the SAML assertion an
intermediary or a third party adversary would be allowed to gain
additional information about an individual
13.2. Forged Assertion Countermeasures:
To address the threats three cases need to be differentiated.
First, a third party that did not participate in any of the
exchange is prevented from eavesdropping on the content of the
SAML assertion by employing confidentiality protection of the SIP
signaling exchange as well as the HTTP exchange. This ensures
that an eavesdropper on the wire is unable to obtain information.
However, this does not prevent intermediaries, such as SIP proxies
from observing a URL to a SAML assertion (in the token-info
parameter). To deal with this second type of attacker depending
on the environment where such a threat must be addressed it is
necessary to authenticate the entity that tries to resolve the
reference to a SAML assertion and to only provide a positive
response (with the SAML assertion) if the requestor is authorized
to obtain the desired information. When a SAML assertion is
carried inband then such a protection is more difficult to
accomplish as the SAML assertion would have to be confidentiality
protected with the key of the intented recipient, for example
using S/MIME. Finally, the last type of threat concerns the
intented recipient of the SAML assertion itself. Proper
permissions for the distribution of information about the caller
via the content of the SAML assertion to certain recipients need
to be available. This permission must be provided by the caller
itself or, in certain circumstances, by someone on behalf of the
caller. From a technical point of view, some form of
authorization policies will be required.
11.3. 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.
13.3. Replay Attack 11.4. 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:
The SAML assertion may contain several elements to prevent replay The SAML assertion may contain several elements to prevent replay
attacks. There is, however, a clear tradeoff between the attacks. There is, however, a clear tradeoff between the
replaying an assertion and re-using it over multiple SIP replaying an assertion and re-using it over multiple SIP
exchanges/sessions. exchanges/sessions.
14. Contributors Additionally, the SAML assertion can be tied to the SIP exchange
with the help of the SIP Identity mechanism. RFC 4474 [RFC4474]
signs certain header fields and the SIP message body and thereby
helps to protect message modifications. If a recipient knows that
all messages from a certain originator arrive with SIP Identity
protection applies then downgrading attacks are not possible.
12. 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.
15. Acknowledgments 13. 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.
driven SIP SAML URI-based Attribute Assertion Fetch Profile" is based
on an idea by Jon Peterson.
We would also like to thank Eric Rescorla for his expert review. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile"
is based on an idea by Jon Peterson.
16. IANA Considerations 14. IANA Considerations
16.1. Header Field Names When a SAML assertion is attached to the body of the message then the
"application/samlassertion+xml" MIME media type is used. This MIME
type is already registered with IANA and no further action is
required from IANA.
This document specifies two new SIP header fields: 'SAML-Info' (see 14.1. URI Parameter
Section 11 and 'SAML-Signature' (see Section 12). IANA is requested
to add these two headers to the header sub-registry under
http://www.iana.org/assignments/sip-parameters.
Header Name: SAML-Info This document extends the registry of URI parameters, as defined RFC
3969 [RFC3969] with the following value:
Compact Form: y Parameter Name: token-info
Header Name: SAML-Signature Predefined Values: No
Compact Form: y Reference: This document
16.2. 477 'Binding to SIP Message failed' Response Code 14.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 SAML assertion but the Subject and Condition verifier receives a SAML assertion but the Subject and Condition
elements cannot be matched to the content in the SIP message, i.e., elements cannot be matched to the content in the SIP message, i.e.,
the binding between the SIP message and the SAML assertion cannot be the binding between the SIP message and the SAML assertion cannot be
accomplished. This response code is defined by the following accomplished. This response code is defined by the following
information, which has been added to the method and response-code information, which has been added to the method and response-code
sub-registry under 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: Binding to SIP Message failed Default Reason Phrase: Binding to SIP Message failed
16.3. 478 'Unknown SAML Assertion Content' Response Code 14.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,
because, for example, the assertion contains only unknown elements in because, for example, the assertion contains only unknown elements in
in the SAML assertion, or the SAML assertion XML document is garbled. in the SAML assertion, or the SAML assertion XML document is garbled.
This response code is defined by the following information, which has This response code is defined by the following information, which has
been added to the method and response-code sub-registry under been 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
16.4. 479 'Invalid SAML Assertion' Response Code 14.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. A verifier may be verifier is unable to process the SAML assertion. A verifier may be
unable to process the SAML assertion in case the assertion is self- unable to process the SAML assertion in case the assertion is self-
signed, or signed by a root certificate authority for whom the signed, or signed by a root certificate authority for whom the
verifier does not possess a root certificate. This response code is verifier does not possess a root certificate. This response code 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
16.5. 480 'Use SAML Header' Response Code 15. Change Log
This document registers a new SIP response code. It is used when a RFC Editor - Please remove this section before publication.
SAML-Info and SAML-Signature header is not present in a request, and
one is required by local policy (for example, based on a per-sending-
domain policy, or a per-sending-user policy). This response code is
defined by the following information, which has been added to the
method and response-code sub-registry under
http://www.iana.org/assignments/sip-parameters.
Response Code Number: 480 15.1. -06 to -07
Default Reason Phrase: Use SAML Header Undo changes made in version 6.
17. Change Log Removed the header fields and switched to a URI parameter
RFC Editor - Please remove this section before publication. Editorial changes
17.1. -05 to -06 15.2. -05 to -06
In response to the review comments by Eric Rescorla a new signature Defined a new SIP Identity signature mechanism.
SIP header field was added.
17.2. -04 to -05 15.3. -04 to -05
Changed the document type to experimental Changed the document type to experimental
Removed option tag Removed option tag
Added the Caller-driven SIP SAML Conveyed Assertion Profile Added the Caller-driven SIP SAML Conveyed Assertion Profile
Defined a new header (SAML-Info) Defined a new header (SAML-Info)
Changed the description for usage with this new header Changed the description for usage with this new header
Updated security considerations Updated security considerations
Minor editorial cleanups Minor editorial cleanups
17.3. -03 to -04 15.4. -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
17.4. -02 to -03 15.5. -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).
17.5. -00 to -02 15.6. -00 to -02
Will detail in -04 rev. Initial specifications to kickstart the work.
18. References 16. References
18.1. Normative References 16.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 50, line 8 skipping to change at page 43, line 8
[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
X.509 Public Key Infrastructure Certificate and X.509 Public Key Infrastructure Certificate and
Certificate Revocation List (CRL) Profile", RFC 3280, Certificate Revocation List (CRL) Profile", RFC 3280,
April 2002. April 2002.
[RFC3370] Housley, R., "Cryptographic Message Syntax (CMS)
Algorithms", RFC 3370, August 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3548] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 3548, July 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.
[RFC3969] Camarillo, G., "The Internet Assigned Number Authority
(IANA) Uniform Resource Identifier (URI) Parameter
Registry for the Session Initiation Protocol (SIP)",
BCP 99, RFC 3969, December 2004.
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005. Specifications: ABNF", RFC 4234, October 2005.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
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/>.
18.2. Informative References 16.2. Informative References
[I-D.hardt-oauth]
Hardt, D., Tom, A., Eaton, B., and Y. Goland, "OAuth Web
Resource Authorization Profiles", draft-hardt-oauth-01
(work in progress), January 2010.
[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 51, line 45 skipping to change at page 45, line 5
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
Certificate Profile for Authorization", RFC 3281, Certificate Profile for Authorization", RFC 3281,
April 2002. April 2002.
[RFC3323] Peterson, J., "A Privacy Mechanism for the Session [RFC3323] Peterson, J., "A Privacy Mechanism for the Session
Initiation Protocol (SIP)", RFC 3323, November 2002. Initiation Protocol (SIP)", RFC 3323, November 2002.
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
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
Unaffiliated
Email: Jeff.Hodges@KingsMountain.com 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
 End of changes. 127 change blocks. 
644 lines changed or deleted 390 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/