< draft-ietf-sip-saml-01.txt   draft-ietf-sip-saml-02.txt >
SIP H. Tschofenig SIP H. Tschofenig
Internet-Draft Siemens Networks GmbH & Co KG Internet-Draft Nokia Siemens Networks
Intended status: Standards Track J. Hodges Intended status: Standards Track J. Hodges
Expires: April 26, 2007 J. Peterson Expires: November 29, 2007 J. Peterson
NeuStar, Inc. NeuStar, Inc.
J. Polk J. Polk
Cisco Cisco
D. Sicker D. Sicker
CU Boulder CU Boulder
October 23, 2006 May 28, 2007
SIP SAML Profile and Binding SIP SAML Profile and Binding
draft-ietf-sip-saml-01.txt draft-ietf-sip-saml-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 26, 2007. This Internet-Draft will expire on November 29, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This document specifies a Session Initiation Protocol (SIP) profile This document specifies a Session Initiation Protocol (SIP) profile
of Security Assertion Markup Language (SAML) as well as a SAML SIP of Security Assertion Markup Language (SAML) as well as a SAML SIP
binding. The defined SIP SAML Profile composes with the mechanisms binding. The defined SIP SAML Profile composes with the mechanisms
defined in the SIP Identity specification and satisfy requirements defined in the SIP Identity specification and satisfy requirements
presented in "Trait-based Authorization Requirements for the Session presented in "Trait-based Authorization Requirements for the Session
Initiation Protocol (SIP)". Initiation Protocol (SIP)".
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 7 3. SAML Introduction . . . . . . . . . . . . . . . . . . . . . . 6
3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 8 3.1. SAML Assertions . . . . . . . . . . . . . . . . . . . . . 7
3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 9 3.2. Abstract Request/Response Protocol . . . . . . . . . . . . 8
4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 10 4. Specification Scope . . . . . . . . . . . . . . . . . . . . . 9
5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 12 5. Employing SAML in SIP . . . . . . . . . . . . . . . . . . . . 11
6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 14 6. SIP SAML Profiles . . . . . . . . . . . . . . . . . . . . . . 13
6.1. AS-driven SIP SAML URI-based Attribute Assertion 6.1. AS-driven SIP SAML URI-based Attribute Assertion
Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 14 Fetch Profile . . . . . . . . . . . . . . . . . . . . . . 13
6.1.1. Required Information . . . . . . . . . . . . . . . . . 14 6.1.1. Required Information . . . . . . . . . . . . . . . . . 13
6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 14 6.1.2. Profile Overview . . . . . . . . . . . . . . . . . . . 13
6.1.3. Profile Description . . . . . . . . . . . . . . . . . 18 6.1.3. Profile Description . . . . . . . . . . . . . . . . . 17
6.1.4. Assertion Profile Description . . . . . . . . . . . . 21 6.1.4. Assertion Profile Description . . . . . . . . . . . . 20
6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 24 6.1.5. Assertion Verification . . . . . . . . . . . . . . . . 22
7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 26 7. SAML SIP Binding . . . . . . . . . . . . . . . . . . . . . . . 24
7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 26 7.1. SAML HTTP-URI-based SIP Binding . . . . . . . . . . . . . 24
8. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 25
8.1. 425 (Bad SAML Assertion) Response Code . . . . . . . . . . 27 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
8.2. The SAML Reason Protocol . . . . . . . . . . . . . . . . . 27 9.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 30
8.3. Failure Reasons to be Registered . . . . . . . . . . . . . 28 9.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 31
8.3.1. SAML Assertion Content Not Supported . . . . . . . . . 28 9.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 31
8.3.2. Authentication Statements Desired Instead . . . . . . 28 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.3.3. Authorization Statements Desired Instead . . . . . . . 29 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 33
8.3.4. Attribute Statements Desired Instead . . . . . . . . . 29 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
8.3.5. Unsupported Content . . . . . . . . . . . . . . . . . 29 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 35
8.3.6. Unable to Dereference . . . . . . . . . . . . . . . . 30 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.3.7. Cannot Parse SAML Assertion . . . . . . . . . . . . . 30 14.1. Normative References . . . . . . . . . . . . . . . . . . . 36
8.3.8. Conflicting SAML Assertions Supplied . . . . . . . . . 30 14.2. Informative References . . . . . . . . . . . . . . . . . . 37
8.3.9. Insufficient SAML Statements . . . . . . . . . . . . . 31 Appendix A. Appendix: Use-case Scenarios . . . . . . . . . . . . 40
8.3.10. Dereference Timeout . . . . . . . . . . . . . . . . . 31 A.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 40
9. Example SAML Assertions . . . . . . . . . . . . . . . . . . . 32 A.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 37 A.3. Compensation using SIP and SAML . . . . . . . . . . . . . 43
10.1. Man-in-the-middle Attacks and Stolen Assertions . . . . . 37 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
10.2. Forged Assertion . . . . . . . . . . . . . . . . . . . . . 38 Intellectual Property and Copyright Statements . . . . . . . . . . 46
10.3. Replay Attack . . . . . . . . . . . . . . . . . . . . . . 38
11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 39
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 40
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
13.1. IANA Registration for Response Code 4XX . . . . . . . . . 41
13.2. IANA Registration of the SAML Reason Protocol . . . . . . 41
14. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 42
15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
15.1. Normative References . . . . . . . . . . . . . . . . . . . 43
15.2. Informative References . . . . . . . . . . . . . . . . . . 44
Appendix A. Appendix: Use-case Scenarios . . . . . . . . . . . . 47
A.1. PSTN-to-SIP Phone Call . . . . . . . . . . . . . . . . . . 47
A.2. SIP Conferencing . . . . . . . . . . . . . . . . . . . . . 48
A.3. Compensation using SIP and SAML . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . . . . 53
1. Introduction 1. Introduction
This document specifies composition of the Security Assertion Markup This document specifies composition of the Security Assertion Markup
Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate Language (SAML) V2.0 with SIP [RFC3261] in order to accommodate
richer authorization mechanisms and enable "trait-based richer authorization mechanisms and enable "trait-based
authorization." Trait-based authorization is where one is authorized authorization." Trait-based authorization is where one is authorized
to make use of some resource based on roles or traits rather than to make use of some resource based on roles or traits rather than
ones identifier(s). Motivations for trait-based authorization, along ones identifier(s). Motivations for trait-based authorization, along
with use-case scenarios, are presented in with use-case scenarios, are presented in [RFC4484].
[I-D.ietf-sipping-trait-authz].
Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML- Security Assertion Markup Language (SAML) v2.0, "SAMLv2", is an XML-
based framework for creating and exchanging security information. based framework for creating and exchanging security information.
[OASIS.sstc-saml-exec-overview-2.0-cd-01] and [OASIS.sstc-saml-exec-overview-2.0-cd-01] and
[OASIS.sstc-saml-tech-overview-2.0-draft-08] provide non-normative [OASIS.sstc-saml-tech-overview-2.0-draft-08] provide non-normative
overviews of SAMLv2. The SAMLv2 specification set is normatively overviews of SAMLv2. The SAMLv2 specification set is normatively
defined by [OASIS.saml-conformance-2.0-os]. defined by [OASIS.saml-conformance-2.0-os].
Various means of providing trait-based authorization exist: Various means of providing trait-based authorization exist:
authorization certificates [RFC3281], SPKI [RFC2693], or extensions authorization certificates [RFC3281], SPKI [RFC2693], or extensions
skipping to change at page 5, line 12 skipping to change at page 4, line 12
Alliance, and the Internet2 project, areas where the applicability to Alliance, and the Internet2 project, areas where the applicability to
SIP is widely desired. SIP is widely desired.
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
[I-D.ietf-sip-identity]. We reuse this term to refer to a network [RFC4474]. We reuse this term to refer to a network element that
element that authenticates and authorizes a user and creates a "SIP authenticates and authorizes a user and creates a "SIP identity
identity assertion". This system entity is the logical equivalent of assertion". This system entity is the logical equivalent of a "SAML
a "SAML Authority" in the SAML terminology. Authority" in the SAML terminology.
For overall SIP terminology, see [RFC3261]. For overall SIP terminology, see [RFC3261].
In this specification, the term, or term component, "SAML" refers to In this specification, the term, or term component, "SAML" refers to
SAML V2.0 in all cases. For example, the term "SAML assertion" SAML V2.0 in all cases. For example, the term "SAML assertion"
implicitly means "SAMLv2 assertion". For overall SAML terminology, implicitly means "SAMLv2 assertion". For overall SAML terminology,
see [OASIS.saml-glossary-2.0-os]. see [OASIS.saml-glossary-2.0-os].
The below list maps other various SIP terms to their SAML The below list maps other various SIP terms to their SAML
(rough-)equivalents: (rough-)equivalents:
skipping to change at page 10, line 12 skipping to change at page 9, line 12
based SIP communication session establishment, the topic of this based SIP communication session establishment, the topic of this
specification, is another. specification, is another.
4. Specification Scope 4. Specification Scope
The scope of this specification is: The scope of this specification is:
o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such o Specify a SIP profile of SAML -- aka a "SIP SAML profile" -- such
that a subject's profile attributes, and their domain's that a subject's profile attributes, and their domain's
certificate, can be conveyed to a relying party using SAML. In certificate, can be conveyed to a relying party using SAML. In
doing so, satisfy the requirements outlined in doing so, satisfy the requirements outlined in [RFC4484], and
[I-D.ietf-sipping-trait-authz], and compose with compose with [RFC4474].
[I-D.ietf-sip-identity].
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
subject-by-subject basis, and/or on a domain-by-domain basis. subject-by-subject basis, and/or on a domain-by-domain basis.
o The definition of specific conveyed subject profile attributes o The definition of specific conveyed subject profile attributes
(aka traits). (aka traits).
Discussion: Discussion:
This specification defines a facility enabling "trait-based This specification defines a facility enabling "trait-based
authorization" as discussed in [I-D.ietf-sipping-trait-authz]. authorization" as discussed in [RFC4484].
The attributes of interest in trait-based authorization will be The attributes of interest in trait-based authorization will be
ones akin to, for example: roles, organizational membership, ones akin to, for example: roles, organizational membership,
access rights, or authentication event context. Definition of access rights, or authentication event context. Definition of
such attributes is application- and/or deployment-context- such attributes is application- and/or deployment-context-
dependent and are not defined in this specification. However, The dependent and are not defined in this specification. However, The
SAMLv2 specification defines several "SAML Attribute Profiles" for SAMLv2 specification defines several "SAML Attribute Profiles" for
encoding attributes from various application domains, e.g., LDAP, encoding attributes from various application domains, e.g., LDAP,
UUID/GUID, DCE PAC, and XACML, in SAML assertions UUID/GUID, DCE PAC, and XACML, in SAML assertions
[OASIS.saml-profiles-2.0-os]. [OASIS.saml-profiles-2.0-os].
skipping to change at page 12, line 16 skipping to change at page 11, line 16
Employing SAML in SIP necessitates devising a new SAML profile(s) and Employing SAML in SIP necessitates devising a new SAML profile(s) and
binding(s) because the those already specified in the SAMLv2 binding(s) because the those already specified in the SAMLv2
specification set are specific to other use contexts, e.g., HTTP- specification set are specific to other use contexts, e.g., HTTP-
based web browsing. Although SIP bears some similarity to HTTP, it based web browsing. Although SIP bears some similarity to HTTP, it
is a seperately distinct protocol, thus requiring specification of is a seperately distinct protocol, thus requiring specification of
SIP-specific SAML profile(s) and binding(s). This is technically SIP-specific SAML profile(s) and binding(s). This is technically
straightforward as both SAML and SIP are explicitly extensible. straightforward as both SAML and SIP are explicitly extensible.
The "Authenticated Identity Management in SIP" specification The "Authenticated Identity Management in SIP" specification
[I-D.ietf-sip-identity] (aka "SIP Identity") facilitates the [RFC4474] (aka "SIP Identity") facilitates the composition of SAML
composition of SAML and SIP in that it defines a "mediated and SIP in that it defines a "mediated authentication architecture"
authentication architecture" where verifying endpoints verify SIP where verifying endpoints verify SIP identity assertions -- i.e., the
identity assertions -- i.e., the "Identity" header value -- signed by "Identity" header value -- signed by an Authentication Service (AS).
an Authentication Service (AS). The semantic being that the AS is The semantic being that the AS is vouching that it did indeed
vouching that it did indeed authenticate the calling party. authenticate the calling party.
Such an Authentication Service, which likely has access to various Such an Authentication Service, which likely has access to various
pieces of information concerning the calling party, could also act as pieces of information concerning the calling party, could also act as
a SAML Authority, and make such information available to the callee a SAML Authority, and make such information available to the callee
via SAML. via SAML.
Since [I-D.ietf-sip-identity] stipulates that the AS must make its Since [RFC4474] stipulates that the AS must make its certificate
certificate available for retrieval and convey the availability and available for retrieval and convey the availability and access
access mechanism via a URI, in the Identity-Info header, we have an mechanism via a URI, in the Identity-Info header, we have an
opportunity to compose SIP Identity and SAML. opportunity to compose SIP Identity and SAML.
Such composition can be accomplished by having the resource referred Such composition can be accomplished by having the resource referred
to by the URI in the Identity-Info be a SAML assertion conveying both to by the URI in the Identity-Info be a SAML assertion conveying both
the AS's certificate and user profile attributes. This is the the AS's certificate and user profile attributes. This is the
approach defined in this specification. Figure 1 illustrates this approach defined in this specification. Figure 1 illustrates this
approach in a high-level summary fashion. Figure 2, further below, approach in a high-level summary fashion. Figure 2, further below,
illustrates additional details. illustrates additional details.
+--------+ +--------------+ +--------+ +--------+ +--------------+ +--------+
skipping to change at page 13, line 48 skipping to change at page 12, line 48
|<----------------------+----------------------| |<----------------------+----------------------|
| | | | | |
Figure 1: SIP-SAML-based Network Asserted Identity Figure 1: SIP-SAML-based Network Asserted Identity
Since the AS already being trusted to create and add the Identity Since the AS already being trusted to create and add the Identity
header containing the SIP Identity Assertion, and to supply a pointer header containing the SIP Identity Assertion, and to supply a pointer
to its domain certificate, having it point instead to a SAML to its domain certificate, having it point instead to a SAML
assertion conveying the domain certificate and possibly some user assertion conveying the domain certificate and possibly some user
profile attributes, does not significantly alter the first-order profile attributes, does not significantly alter the first-order
security considerations examined in [I-D.ietf-sip-identity]. This security considerations examined in [RFC4474]. This specification
specification provides some additional security considerations provides some additional security considerations analysis below in
analysis below in Section 10. Section 9.
6. SIP SAML Profiles 6. SIP SAML Profiles
This section defines one SIP SAML profile: This section defines one SIP SAML profile:
The "AS-driven SIP SAML URI-based Attribute Assertion Fetch The "AS-driven SIP SAML URI-based Attribute Assertion Fetch
Profile" Profile"
6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile 6.1. AS-driven SIP SAML URI-based Attribute Assertion Fetch Profile
skipping to change at page 15, line 7 skipping to change at page 14, line 7
6.1.2. Profile Overview 6.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, and in [I-D.ietf-sip-identity], may be applied to any SIP herein, and in [RFC4474], may be applied to any SIP request message.
request message.
Figure 2 begins on the next page. Figure 2 begins on the next page.
+------------------+ +------------------+ +-----------------+ +------------------+ +------------------+ +-----------------+
| Caller | |Authn Service (AS)| | Callee | | Caller | |Authn Service (AS)| | Callee |
|Alice@example.com | | @example.com | | Bob@example2.com| |Alice@example.com | | @example.com | | Bob@example2.com|
+--------+---------+ +--------+---------+ +--------+--------+ +--------+---------+ +--------+---------+ +--------+--------+
- - | | | (steps) - - | | | (steps)
^ ^ | INVITE | | ^ ^ | INVITE | |
| | |---------------------->| | (1a) | | |---------------------->| | (1a)
skipping to change at page 17, line 27 skipping to change at page 16, line 27
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 [I-D.ietf-sip-identity] and 1 was skipped, as specified in [RFC4474] and [RFC3261].
[RFC3261]. Depending on the chosen SIP security mechanism Depending on the chosen SIP security mechanism for client
for client authentication either digest authentication, authentication either digest authentication, client side
client side authentication of Transport Layer Security, or a authentication of Transport Layer Security, or a combination
combination of both is used to provide the AS with a strong of both is used to provide the AS with a strong assurance
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 [I-D.ietf-sip-identity] and [RFC3261]. If the specified in [RFC4474] and [RFC3261]. If the authorization
authorization is successful, the AS will form the "identity is successful, the AS will form the "identity signature" for
signature" for the message and add Identity and Identity- the message and add Identity and Identity-Info header fields
Info header fields to the message. The AS also at this time to the message. The AS also at this time constructs and
constructs and caches a SAML assertion asserting Alice's caches a SAML assertion asserting Alice's profile attributes
profile attributes required by Bob's domain (example2.com), required by Bob's domain (example2.com), and also containing
and also containing a the domain's (example.com) public key a the domain's (example.com) public key certificate, or a
certificate, or a reference to it. This certificate MUST reference to it. This certificate MUST contain the public
contain the public key corresponding to the private key used key corresponding to the private key used to construct the
to construct the signature whose value was placed in the signature whose value was placed in the Identity header.
Identity header. The AS constructs a HTTP-based SAML URI The AS constructs a HTTP-based SAML URI Reference
Reference incorporating the assertion's Assertion ID (see incorporating the assertion's Assertion ID (see section
section 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses 2.3.3 of [OASIS.saml-core-2.0-os]). The AS uses this URI as
this URI as the value for the Identity-Info header it adds the value for the Identity-Info header it adds to the INVITE
to the INVITE message. message.
The AS determines which profile attributes (if any) to The AS determines which profile attributes (if any) to
assert in the <AttributeStatement> via local configuration assert in the <AttributeStatement> via local configuration
and/or obtaining example2.com's metadata and/or obtaining example2.com's metadata
[OASIS.saml-metadata-2.0-os]. The AS then sends the updated [OASIS.saml-metadata-2.0-os]. The AS then sends the updated
INVITE message to Bob. INVITE message to Bob.
Step 4. Callee Dereferences HTTP-based SAML URI Reference Step 4. Callee Dereferences HTTP-based SAML URI Reference
Bob's UAC or SIP Proxy receives the message and begins Bob's UAC or SIP Proxy receives the message and begins
verifying it per the "Verifier Behavior" specified in verifying it per the "Verifier Behavior" specified in
[I-D.ietf-sip-identity]. In order to accomplish this task, [RFC4474]. In order to accomplish this task, it needs to
it needs to obtain Alice's domain certificate. It obtains obtain Alice's domain certificate. It obtains the HTTP-
the HTTP-based SAML URI Reference from the message's based SAML URI Reference from the message's Identity-Info
Identity-Info header and dereferences it per Section 7.1. header and dereferences it per Section 7.1. Note that this
Note that this is not a SIP message, but an HTTP message is not a SIP message, but an HTTP message [RFC2616].
[RFC2616].
Step 5. AS Returns SAML Assertion Step 5. AS Returns SAML Assertion
Upon receipt of the above HTTP request, which contains an Upon receipt of the above HTTP request, which contains an
embedded reference to Alice's SAML Assertion, Alice's AS embedded reference to Alice's SAML Assertion, Alice's AS
returns her assertion in an HTTP response message. returns her assertion in an HTTP response message.
Upon receipt of Alice's SAML Assertion, the AS continues its Upon receipt of Alice's SAML Assertion, the AS continues its
verification of the INVITE message. If successful, it verification of the INVITE message. If successful, it
returns a 200 OK message directly to Alice. Otherwise it returns a 200 OK message directly to Alice. Otherwise it
skipping to change at page 19, line 46 skipping to change at page 18, line 46
| | | | | |
| | | | | |
| | ? | (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 6.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 [I-D.ietf-sip-identity]. If the SIP request Service Behavior" of [RFC4474]. If the SIP request sent by the
sent by the caller in substep 1a is deemed insufficiently caller in substep 1a is deemed insufficiently authenticated by the AS
authenticated by the AS per the rules stipulated by per the rules stipulated by [RFC4474] Steps 1 and 2, then the AS MUST
[I-D.ietf-sip-identity] Steps 1 and 2, then the AS MUST authenticate authenticate the sender of the message. The particulars of how this
the sender of the message. The particulars of how this is is accomplished depend upon implementation and/or deployment
accomplished depend upon implementation and/or deployment instantiation as discussed in [RFC4474]. Substeps 1b and 1c as shown
instantiation as discussed in [I-D.ietf-sip-identity]. Substeps 1b in Figure 3 are non-normative and illustrative only.
and 1c as shown in Figure 3 are non-normative and illustrative only.
6.1.3.2. Sender sends SIP Request Message with Authorization 6.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 [I-D.ietf-sip-identity]. This request is presumed to be Behavior" of [RFC4474]. This request is presumed to be made in a
made in a context such that the AS will not challenge it -- i.e., the context such that the AS will not challenge it -- i.e., the AS will
AS will consider the sender of the message to be authenticated. If consider the sender of the message to be authenticated. If this is
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 [I-D.ietf-sip-identity] Steps 1 and 2, and if stipulated in [RFC4474] Steps 1 and 2, and if successful, this
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 6.1.3.3. AS Authorizes the SIP Request and Forwards it to Verifier
This first portion of this step maps to Steps 3 and 4 of Section 5 This first portion of this step maps to Steps 3 and 4 of Section 5
"Authentication Service Behavior" of [I-D.ietf-sip-identity], which "Authentication Service Behavior" of [RFC4474], which the AS MUST
the AS MUST perform, although with the following additional substeps: perform, although with the following additional substeps:
The AS MUST construct a SAML assertion according to the "Assertion The AS MUST construct a SAML assertion according to the "Assertion
Profile Description" specified in Section 6.1.4 of this Profile Description" specified in Section 6.1.4 of this
specification. specification.
The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI The AS SHOULD construct an HTTPS, and MAY construct an HTTP, URI
per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os]. per Section "3.7.5.1 URI Syntax" of [OASIS.saml-bindings-2.0-os].
The AS MUST use the URI constructed in the immediately preceding The AS MUST use the URI constructed in the immediately preceding
substep as the value of the Identity-Info header that is added to substep as the value of the Identity-Info header that is added to
the SIP request message per Step 4 of Section 5 of the SIP request message per Step 4 of Section 5 of [RFC4474].
[I-D.ietf-sip-identity].
Upon successful completion of all of the above, the AS forwards the Upon successful completion of all of the above, the AS forwards the
request message. request message.
At this point in this step, after perhaps traversing some number of At this point in this step, after perhaps traversing some number of
intermediaries, the SIP request message arrives at a SIP network intermediaries, the SIP request message arrives at a SIP network
entity performing the "verifier" role. This role and its behavior entity performing the "verifier" role. This role and its behavior
are specified in Section 6 "Verifier Behavior" of are specified in Section 6 "Verifier Behavior" of [RFC4474]. The
[I-D.ietf-sip-identity]. The verifier MUST perform the steps verifier MUST perform the steps enumerated in the aforementioned
enumerated in the aforementioned section, with the following section, with the following modifications:
modifications:
Step 1 of [I-D.ietf-sip-identity] Section 6 maps to and is updated Step 1 of [RFC4474] Section 6 maps to and is updated by, the
by, the following two steps in this procedure. following two steps in this procedure.
Steps 2, 3, and 4 of [I-D.ietf-sip-identity] Section 6 may be Steps 2, 3, and 4 of [RFC4474] Section 6 may be mapped across this
mapped across this latter portion of this step, and/or the latter portion of this step, and/or the following two steps, as
following two steps, as appropriate. appropriate.
6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference 6.1.3.4. Verifier Dereferences HTTP-based SAML URI Reference
The verifier SHOULD ascertain whether it has a current cached copy of The verifier SHOULD ascertain whether it has a current cached copy of
the SIP message sender's SAML assertion and domain certificate. If the SIP message sender's SAML assertion and domain certificate. If
not, or if the verifier chooses to (e.g., due to local policy), it not, or if the verifier chooses to (e.g., due to local policy), it
MUST dereference the the HTTP-based SAML URI Reference found in the MUST dereference the the HTTP-based SAML URI Reference found in the
SIP message's Identity-Info header. To do so, the verifier MUST SIP message's Identity-Info header. To do so, the verifier MUST
employ the "SAML HTTP-URI-based SIP Binding" specified in employ the "SAML HTTP-URI-based SIP Binding" specified in
Section 7.1. Section 7.1.
skipping to change at page 21, line 48 skipping to change at page 20, line 44
SIP request it received. SIP request it received.
6.1.4. Assertion Profile Description 6.1.4. Assertion Profile Description
This section defines the particulars of how the sender, i.e., the This section defines the particulars of how the sender, i.e., the
SAML Authority, MUST construct certain portions of the SAML SAML Authority, MUST construct certain portions of the SAML
assertions it issues. The schema for SAML assertions themselves is assertions it issues. The schema for SAML assertions themselves is
defined in Section 2.3 of [OASIS.saml-core-2.0-os]. defined in Section 2.3 of [OASIS.saml-core-2.0-os].
An example SAML assertion, formulated according to this profile is An example SAML assertion, formulated according to this profile is
given in Section 9. given in Section 8.
Overall SAML assertion profile requirements: Overall SAML assertion profile requirements:
The SAML assertion MUST be signed by the same key as used to sign The SAML assertion MUST be signed by the same key as used to sign
the contents of the Identity header field. Signing of SAML the contents of the Identity header field. Signing of SAML
assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os]. assertions is defined in Section 5.4 of [OASIS.saml-core-2.0-os].
In the following subsections, the SAML assertion profile is specified In the following subsections, the SAML assertion profile is specified
element-by-element, in a top-down, depth-first manner, beginning with element-by-element, in a top-down, depth-first manner, beginning with
the outermost element, "<Assertion>". Where applicable, the the outermost element, "<Assertion>". Where applicable, the
skipping to change at page 23, line 13 skipping to change at page 21, line 51
<ds:X509Certificate <ds:X509Certificate
6.1.4.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 same as the Address of The value of the <NameID> element MUST be the same as the Address of
Record (AoR) value used in computing the "signed-identity-digest" Record (AoR) value used in computing the "signed-identity-digest"
which forms the value of the Identity header. See Section 9 of which forms the value of the Identity header. See Section 9 of
[I-D.ietf-sip-identity]. [RFC4474].
The <SubjectConfirmation> element attribute Method SHOULD be set to The <SubjectConfirmation> element attribute Method SHOULD be set to
the value: the value:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
Although it MAY be set to some other implementation- and/or Although it MAY be set to some other implementation- and/or
deployment-specific value. The <SubjectConfirmation> element itself deployment-specific value. The <SubjectConfirmation> element itself
SHOULD be empty. SHOULD be empty.
skipping to change at page 24, line 13 skipping to change at page 22, line 52
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 6.1.5. Assertion Verification
This section specifies the steps that a verifier participating in This section specifies the steps that a verifier participating in
this profile MUST perform in addition to the "Verifier Behavior" this profile MUST perform in addition to the "Verifier Behavior"
specified in Section 6 of [I-D.ietf-sip-identity]. specified in Section 6 of [RFC4474].
The steps are: The steps are:
1. Before Step 1 in Section 6 of [I-D.ietf-sip-identity], the 1. Before Step 1 in Section 6 of [RFC4474], the verifier MUST
verifier MUST extract the AS's domain certificate from the <ds: extract the AS's domain certificate from the <ds:
X509Certificate> XML element at the end of the element path X509Certificate> XML element at the end of the element path
given in Section 6.1.4.1.1. given in Section 6.1.4.1.1.
2. Perform Step 1 in Section 6 of [I-D.ietf-sip-identity]. 2. Perform Step 1 in Section 6 of [RFC4474].
3. After Step 1 in Section 6 of [I-D.ietf-sip-identity], but before 3. After Step 1 in Section 6 of [RFC4474], but before Step 2 of
Step 2 of that section, the verifier MUST verify the SAML that section, the verifier MUST verify the SAML assertion's
assertion's signature via the procedures specified in Section signature via the procedures specified in Section 5.4 of
5.4 of [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core]. [OASIS.saml-core-2.0-os] as well as [W3C.xmldsig-core].
@@ TODO: do we need to define a new SIP error response code for @@ TODO: do we need to define a new SIP error response code for
when a SAML assn signature is bad? e.g., '4xx Invalid SAML when a SAML assn signature is bad? e.g., '4xx Invalid SAML
asssertion'. asssertion'.
4. Perform Step 2 in Section 6 of [I-D.ietf-sip-identity]. 4. Perform Step 2 in Section 6 of [RFC4474].
5. Verify that the signer of the SIP message's Identity header 5. Verify that the signer of the SIP message's Identity header
field is the same as the signer of the SAML assertion. field is the same as the signer of the SAML assertion.
6. Perform Steps 3 and 4 in Section 6 of [I-D.ietf-sip-identity]. 6. Perform Steps 3 and 4 in Section 6 of [RFC4474].
7. Verify that the SAML assertion's <Issuer> element value matches 7. Verify that the SAML assertion's <Issuer> element value matches
the Issuer or the Issuer Alternative Name fields [RFC3280] in the Issuer or the Issuer Alternative Name fields [RFC3280] in
the AS's domain certificate. the AS's domain certificate.
8. Verify that the SAML assertion's <NameID> element value is the 8. Verify that the SAML assertion's <NameID> element value is the
same as the Address of Record (AoR) value in the "signed- same as the Address of Record (AoR) value in the "signed-
identity-digest". See Section 9 of [I-D.ietf-sip-identity]. identity-digest". See Section 9 of [RFC4474].
9. Verify that the SAML assertion's <SubjectConfirmation> element 9. Verify that the SAML assertion's <SubjectConfirmation> element
value is set to whichever value was configured at value is set to whichever value was configured at
implementation- or deployment-time. The default value is: implementation- or deployment-time. The default value is:
urn:oasis:names:tc:SAML:2.0:cm:sender-vouches urn:oasis:names:tc:SAML:2.0:cm:sender-vouches
10. Verify that the SAML assertion contains an <Audience> element, 10. Verify that the SAML assertion contains an <Audience> element,
and that its value matches the value of the addr-spec of the SIP and that its value matches the value of the addr-spec of the SIP
To header field. To header field.
skipping to change at page 27, line 5 skipping to change at page 25, 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. Error Codes 8. Example SAML Assertions
8.1. 425 (Bad SAML Assertion) Response Code
If a UAS or SIP intermediary detects an error in a request message
specific to the location information, a new 4XX level error is
created here to indicate a problem with the request message. This
document creates and IANA registers the new error code:
425 (Bad SAML Assertion)
The 425 (Bad SAML Assertion) response code is a rejection of the
content of a SAML assertion within the original SIP Request
indicating the SAML assertion was malformed or not satisfactory for
the recipient's purpose or could not be dereferenced. No further
action by the UAC is required.
The UAC can use means outside the scope of this document to ensure
that subsequent requests are going to contain SAML assertions that
are acceptable to the UAS. There is no cross-transaction awareness
expected by either the UAS or SIP intermediary as a result of this
error message.
More resolution of the error for which the 425 was generated MAY be
included in a Reason header [RFC3326]. For these more granular
location specific errors, the 'protocol' in the Reason header is
'SAML', defined in Section 3.4. of RFC 3326 [RFC3326] states that the
Reason Header normally is not found in a response. This document
extends the use of Reason to include its use within a 425 response.
This new error code is IANA registered in Section 9 of this document.
An initial set of error codes can be found in Section 8.
8.2. The SAML Reason Protocol
For use with the Reason header, discussed in Section 8.1, this
document defines and IANA registers a new Reason Protocol per RFC
3326 [RFC3326].
Protocol Value Protocol Cause Reference
SAML Status RFCyyyy (i.e., this document)
8.3. Failure Reasons to be Registered
Here is the list and description of each IANA registered location
error reason code. If the location generator were to receive one of
these indications in a SIP response, it would be in a Reason header.
The protocol field of this Reason header would be "SAML", as defined
in Section 8.2. Examples of the Reason header are given for each
indication below.
8.3.1. SAML Assertion Content Not Supported
"SAML Assertion Content Not Supported" means the SAML content
supplied in the request was not processed even though the recipient
understood SAML. If the SAML content is understood, but not desired,
a cause=2 or cause=3 response SHOULD be returned.
Cause value: 1
Default text string: SAML Assertion Content Not Supported
An example usage in a SIP Reason header:
Reason: SAML; cause=1; SAML Assertion Content Not Supported
8.3.2. Authentication Statements Desired Instead
"Authentication Statements Desired Instead" means the SAML assertion
supplied in the request was understood and supported, but that the
recipient, or an application on the recipient demands authentication
statements.
Cause value: 2
Default text string: Authentication Statements Desired Instead
An example usage in a SIP Reason header:
Reason: SAML; cause=2; Authentication Statements Desired Instead
8.3.3. Authorization Statements Desired Instead
"Authorization Statements Desired Instead" means the SAML assertion
supplied in the request was understood and supported, but that the
recipient, or an application on the recipient demands authorization
statements.
Cause value: 3
Default text string: Authorization Statements Desired Instead
An example usage in a SIP Reason header:
Reason: SAML; cause=3; Authorization Statements Desired Instead
8.3.4. Attribute Statements Desired Instead
"Attribute Statements Desired Instead" means the SAML assertion
supplied in the request was understood and supported, but that the
recipient, or an application on the recipient demands attribute
statements.
Cause value: 4
Default text string: Attribute Statements Desired Instead
An example usage in a SIP Reason header:
Reason: SAML; cause=4; Attribute Statements Desired Instead
8.3.5. Unsupported Content
"Unsupported Content" means the recipient encounters a problem with
the content of the SAML assertion.
Cause value: 5
Default text string: Unsupported Content
An example usage in a SIP Reason header:
Reason: SAML; cause=5; Unsupported Content
8.3.6. Unable to Dereference
"Unable to Dereference" means the recipient cannot resolve the
reference to a SAML assertion. This may mean the URI is bad, or the
indicated server had some other error or rejected the request.
Cause value: 6
Default text string: Unable to Dereference
An example usage in a SIP Reason header:
Reason: SAML; cause=6; Unable to Dereference
8.3.7. Cannot Parse SAML Assertion
"Cannot Parse SAML Assertion" means the SAML assertion is not well
formed.
Cause value: 7
Default text string: Cannot Parse SAML Assertion
An example usage in a SIP Reason header:
Reason: SAML; cause=7; Cannot Parse SAML Assertion
8.3.8. Conflicting SAML Assertions Supplied
"Conflicting SAML Assertions Supplied" means a recipient received
more than one SAML assertion and their content is conflicting
Cause value: 8
Default text string: Conflicting SAML Assertion Supplied
An example usage in a SIP Reason header:
Reason: SAML; cause=8; Conflicting SAML Assertion Supplied
8.3.9. Insufficient SAML Statements
"Insufficient SAML Statements" means there is not enough information
in the SAML assertion to sufficiently authenticate or authorize the
requesting party.
Cause value: 9
Default text string: Insufficient SAML Statements
An example usage in a SIP Reason header:
Reason: SAML; cause=9; Insufficient SAML Statements
8.3.10. Dereference Timeout
"Dereference Timeout" means that the dereferencing node has not
received a response within a reasonable timeframe.
Cause value: 10
Default text string: Dereference Timeout
An example usage in a SIP Reason header:
Reason: SAML; cause=10; Dereference Timeout
9. Example SAML Assertions
This section presents two examples of a SAML assertion, one unsigned This section presents two examples of a SAML assertion, one unsigned
(for clarity), the other signed (for accuracy). (for clarity), the other signed (for accuracy).
In the first example, Figure 16, the assertion is attesting with In the first example, Figure 5, the assertion is attesting with
respect to the subject (lines 7-15) "Alice@example.com" (line 11). respect to the subject (lines 7-15) "Alice@example.com" (line 11).
The validity conditions are expressed in lines 16-23, via both a The validity conditions are expressed in lines 16-23, via both a
validity period expressed as temporal endpoints, and an "audience validity period expressed as temporal endpoints, and an "audience
restriction" stating that this assertion's semantics are valid for restriction" stating that this assertion's semantics are valid for
only the relying party named "example2.com". Also, the assertion's only the relying party named "example2.com". Also, the assertion's
issuer is noted in lines 4-5. issuer is noted in lines 4-5.
The above items correspond to some aspects of this specification's The above items correspond to some aspects of this specification's
SAML assertion profile, as noted below in Security Considerations SAML assertion profile, as noted below in Security Considerations
dicussions, see: Section 10.1 and Section 10.2. dicussions, see: Section 9.1 and Section 9.2.
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 33, line 43 skipping to change at page 26, line 43
29 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 29 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
30 Name="urn:oid:2.5.4.20" 30 Name="urn:oid:2.5.4.20"
31 FriendlyName="telephoneNumber"> 31 FriendlyName="telephoneNumber">
32 <saml:AttributeValue xsi:type="xs:string"> 32 <saml:AttributeValue xsi:type="xs:string">
33 +1-888-555-1212 33 +1-888-555-1212
34 </saml:AttributeValue> 34 </saml:AttributeValue>
35 </saml:Attribute> 35 </saml:Attribute>
36 </AttributeStatement> 36 </AttributeStatement>
37 </Assertion> 37 </Assertion>
Figure 16: Unsigned SAML Assertion Illustrating Conveyance of Figure 5: Unsigned SAML Assertion Illustrating Conveyance of
Subject Attribute Subject Attribute
In the second example, Figure 17, the information described above is In the second example, Figure 6, the information described above is
the same, the addition is that this version of the assertion is the same, the addition is that this version of the assertion is
signed. All the signature information is conveyed in the <ds: signed. All the signature information is conveyed in the <ds:
signature> element, lines 7-47. Thus this assertion's origin and its signature> element, lines 7-47. Thus this assertion's origin and its
integrity are assured. Since this assertion is the same as the one integrity are assured. Since this assertion is the same as the one
in the first example above, other than having a signature added, the in the first example above, other than having a signature added, the
second example below addresses the same Security Considerations second example below addresses the same Security Considerations
aspects, plus those requiring a Signature. aspects, plus those requiring a Signature.
1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc" 1 <Assertion ID="_a75adf55-01d7-40cc-929f-dbd8372ebdfc"
2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0" 2 IssueInstant="2003-04-17T00:46:02Z" Version="2.0"
skipping to change at page 36, line 35 skipping to change at page 29, line 35
70 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri" 70 "urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
71 Name="urn:oid:2.5.4.20" 71 Name="urn:oid:2.5.4.20"
72 FriendlyName="telephoneNumber"> 72 FriendlyName="telephoneNumber">
73 <saml:AttributeValue xsi:type="xs:string"> 73 <saml:AttributeValue xsi:type="xs:string">
74 +1-888-555-1212 74 +1-888-555-1212
75 </saml:AttributeValue> 75 </saml:AttributeValue>
76 </saml:Attribute> 76 </saml:Attribute>
77 </AttributeStatement> 77 </AttributeStatement>
78 </Assertion> 78 </Assertion>
Figure 17: Signed SAML Assertion Illustrating Conveyance of Subject Figure 6: Signed SAML Assertion Illustrating Conveyance of Subject
Attribute Attribute
10. Security Considerations 9. Security Considerations
This section discusses security considerations when using SAML with This section discusses security considerations when using SAML with
SIP. SIP.
10.1. Man-in-the-middle Attacks and Stolen Assertions 9.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 conceivably attempt to impersonate the
subject (the putative caller) to some SIP-based target entity. subject (the putative caller) to some SIP-based target entity.
Countermeasures: Countermeasures:
Such an attack is implausible for several reasons. The primary Such an attack is implausible for several reasons. The primary
reason is that a message constructed by an imposter using a stolen reason is that a message constructed by an imposter using a stolen
assertion that conveys the public key certificate of some domain assertion that conveys the public key certificate of some domain
will not verify per [I-D.ietf-sip-identity] because the imposter will not verify per [RFC4474] because the imposter will not have
will not have the corresponding private key with which to generate the corresponding private key with which to generate the signed
the signed Identity header value. Identity header value.
Also, the SIP SAML assertion profile specified herein that the Also, the SIP SAML assertion profile specified herein that the
subject's SAML assertion must adhere to causes it to be not useful subject's SAML assertion must adhere to causes it to be not useful
to arbitrary parties. The subject's assertion: to arbitrary parties. The subject's assertion:
* should be signed, thus causing any alterations to break its * should be signed, thus causing any alterations to break its
integrity and make such alterations detectable. integrity and make such alterations detectable.
* does not contain an authentication statement. Thus no parties * does not contain an authentication statement. Thus no parties
implementing this specification should be relying on SAML implementing this specification should be relying on SAML
skipping to change at page 38, line 7 skipping to change at page 31, line 7
* relying party is represented in the SAML assertion's Audience * relying party is represented in the SAML assertion's Audience
Restriction. Restriction.
* Issuer is represented in the SAML assertion. * Issuer is represented in the SAML assertion.
* validity period for assertion is restricted. * validity period for assertion is restricted.
* etc. * etc.
10.2. Forged Assertion 9.2. Forged Assertion
Threat: Threat:
A malicious user could forge or alter a SAML assertion in order to A malicious user could forge or alter a SAML assertion in order to
communicate with the SIP entities. communicate with the SIP entities.
Countermeasures: Countermeasures:
To avoid this kind of attack, the entities must assure that proper To avoid this kind of attack, the entities must assure that proper
mechanisms for protecting the SAML assertion are employed, e.g., mechanisms for protecting the SAML assertion are employed, e.g.,
signing the SAML assertion itself. Section 5.1 of signing the SAML assertion itself. Section 5.1 of
[OASIS.saml-core-2.0-os] specifies the signing of SAML assertions. [OASIS.saml-core-2.0-os] specifies the signing of SAML assertions.
Additionally, the assertion content dictated by the SAML assertion Additionally, the assertion content dictated by the SAML assertion
profile herein ensures ample evidence for a relying party to profile herein ensures ample evidence for a relying party to
verify the assertion and its relationship with the received SIP verify the assertion and its relationship with the received SIP
request. request.
10.3. Replay Attack 9.3. Replay Attack
Threat: Threat:
Theft of SIP message protected by the mechanisms described herein Theft of SIP message protected by the mechanisms described herein
and replay of it at a later time. and replay of it at a later time.
Countermeasures: Countermeasures:
There are various provisions within [I-D.ietf-sip-identity] that There are various provisions within [RFC4474] that prevent a
prevent a replay attack. replay attack.
11. Contributors 10. Contributors
The authors would like to thank Marcus Tegnander and Henning The authors would like to thank Marcus Tegnander and Henning
Schulzrinne for his contributions to earlier versions of this Schulzrinne for his contributions to earlier versions of this
document. document.
12. Acknowledgments 11. 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 and Vijay Gurbani for their comments to this Schubert, Jason Fischl and Vijay Gurbani for their comments to this
draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch draft. The "AS-driven SIP SAML URI-based Attribute Assertion Fetch
Profile" is based on an idea by Jon Peterson. Profile" is based on an idea by Jon Peterson.
13. IANA Considerations 12. IANA Considerations
13.1. IANA Registration for Response Code 4XX
Reference: RFC-XXXX (i.e. this document)
Response code: 425
Default reason phrase: Bad SAML Assertion
This SIP Response code is defined in Section 8.1 of this document.
13.2. IANA Registration of the SAML Reason Protocol
The Reason Protocol value "SAML" is created by this document, with
the definition and values in Section 8.1.
Cause-Code Optional-Default-Text Reference
---------- --------------------- ---------
Cause=1 Location Format Not Supported [This doc]
Cause=2 Geo-location Format Desired [This doc]
Cause=3 Civic-location Format Desired [This doc]
Cause=4 Unsupported Schema [This doc]
Cause=5 Cannot Parse Location Supplied [This doc]
Cause=6 Cannot Find Location [This doc]
Cause=7 Cannot Dereference [This doc]
Cause=8 Conflicting Locations Supplied [This doc]
Cause=9 Incomplete Location Supplied [This doc]
Cause=10 Dereference Timeout [This doc]
Cause=11 Cannot Process Dereference [This doc]
Cause=400 Bad Request [This doc]
Cause=403 Forbidden [This doc]
Cause=404 Not Found [This doc]
Cause=414 Location Error [This doc]
Cause=500 Server Internal Error [This doc]
Cause=501 Service Not Implemented [This doc]
Cause=504 Server Time-Out [This doc]
Legend: [Editor's Note: A future version of this document will provide IANA
------ considerations.]
Cause-Code - Cause value for this indication
Optional-Default-Text - optional text string of indication
Reference - document which is the reference for this
cause value
14. Open Issues 13. Open Issues
A list of open issues can be found at: A list of open issues can be found at:
http://www.tschofenig.com:8080/saml-sip/ http://www.tschofenig.com:8080/saml-sip/
15. References 14. References
15.1. Normative References
[I-D.ietf-sip-identity]
Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session
Initiation Protocol (SIP)", draft-ietf-sip-identity-06
(work in progress), October 2005.
[I-D.ietf-sipping-trait-authz] 14.1. Normative References
Peterson, J., "Trait-based Authorization Requirements for
the Session Initiation Protocol (SIP)",
draft-ietf-sipping-trait-authz-02 (work in progress),
January 2006.
[OASIS.saml-bindings-2.0-os] [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 44, line 16 skipping to change at page 37, line 5
[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.
[RFC3326] Schulzrinne, H., Oran, D., and G. Camarillo, "The Reason
Header Field for the Session Initiation Protocol (SIP)",
RFC 3326, December 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.
[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.
[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,
"Trait-Based Authorization Requirements for the Session
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/>.
15.2. Informative References 14.2. Informative References
[I-D.ietf-sip-content-indirect-mech] [I-D.ietf-sip-content-indirect-mech]
Burger, E., "A Mechanism for Content Indirection in Burger, E., "A Mechanism for Content Indirection in
Session Initiation Protocol (SIP) Messages", Session Initiation Protocol (SIP) Messages",
draft-ietf-sip-content-indirect-mech-05 (work in draft-ietf-sip-content-indirect-mech-05 (work in
progress), October 2004. progress), October 2004.
[I-D.ietf-sipping-certs] [I-D.ietf-sipping-certs]
Jennings, C. and J. Peterson, "Certificate Management Jennings, C. and J. Peterson, "Certificate Management
Service for The Session Initiation Protocol (SIP)", Service for The Session Initiation Protocol (SIP)",
draft-ietf-sipping-certs-03 (work in progress), draft-ietf-sipping-certs-03 (work in progress),
March 2006. March 2006.
[I-D.jennings-sipping-pay] [I-D.jennings-sipping-pay]
Jennings, C., "Payment for Services in Session Initiation Jennings, C., "Payment for Services in Session Initiation
Protocol (SIP)", draft-jennings-sipping-pay-04 (work in Protocol (SIP)", draft-jennings-sipping-pay-05 (work in
progress), June 2006. progress), October 2006.
[I-D.peterson-message-identity] [I-D.peterson-message-identity]
Peterson, J., "Security Considerations for Impersonation Peterson, J., "Security Considerations for Impersonation
and Identity in Messaging Systems", and Identity in Messaging Systems",
draft-peterson-message-identity-00 (work in progress), draft-peterson-message-identity-00 (work in progress),
October 2004. October 2004.
[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
skipping to change at page 47, line 8 skipping to change at page 40, line 8
[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.
Appendix A. Appendix: Use-case Scenarios Appendix A. Appendix: Use-case Scenarios
This Appendix explores message flows based on various use-case This Appendix explores message flows based on various use-case
scenarios in [I-D.ietf-sipping-trait-authz], and from various scenarios in [RFC4484], and from various discussions, to which SAML-
discussions, to which SAML-based solutions are applied. Appendix A.2 based solutions are applied. Appendix A.2 shows a SIP conferencing
shows a SIP conferencing scenario with role-based access control scenario with role-based access control using SAML.
using SAML.
Note that we present these scenarios as illustrations of possible Note that we present these scenarios as illustrations of possible
SAML-based use cases in SIP. This document does not provide a SAML-based use cases in SIP. This document does not provide a
detailed exposition of these scenarios -- that is left for addtional detailed exposition of these scenarios -- that is left for addtional
documents. documents.
A.1. PSTN-to-SIP Phone Call A.1. PSTN-to-SIP Phone Call
Alice, using a phone connected to the PSTN, wants to make a call to Alice, using a phone connected to the PSTN, wants to make a call to
Bob, who resides in a SIP network. Her call is switched through the Bob, who resides in a SIP network. Her call is switched through the
skipping to change at page 48, line 25 skipping to change at page 41, line 25
| | +--------+ | | | +--------+ |
O | | Bob's | | O | | Bob's | |
O /|\ <----+----| SIP | | O /|\ <----+----| SIP | |
/|\ / \ SIP | | Proxy | | /|\ / \ SIP | | Proxy | |
/ \ Bob | | | | / \ Bob | | | |
Alice | +--------+ | Alice | +--------+ |
| SIP based | | SIP based |
| Network | | Network |
+---------------------+ +---------------------+
Figure 20: PSTN to SIP call Figure 7: PSTN to SIP call
Note that the INVITE emitted by the PSTN/SIP gateway could Note that the INVITE emitted by the PSTN/SIP gateway could
alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone, alternatively be simply forwarded by Bob's SIP Proxy to Bob's phone,
and Bob's phone could take on the SIP Identity "verifier" role, which and Bob's phone could take on the SIP Identity "verifier" role, which
is being played by Bob's SIP proxy in the figure. is being played by Bob's SIP proxy in the figure.
Whichever approach is employed is a decision local to Bob's Whichever approach is employed is a decision local to Bob's
administrative domain and can be made independently. administrative domain and can be made independently.
A.2. SIP Conferencing A.2. SIP Conferencing
skipping to change at page 48, line 47 skipping to change at page 41, line 47
This section is meant to foster discussion about the usage of SAML in This section is meant to foster discussion about the usage of SAML in
the domain of conferencing. A user agent who routes its SIP message the domain of conferencing. A user agent who routes its SIP message
through the Authentication Service (Asserting Party) towards a through the Authentication Service (Asserting Party) towards a
conferencing server may want or need various of her profile conferencing server may want or need various of her profile
attributes included and may also need to be authenticated by the attributes included and may also need to be authenticated by the
conference server. The following properties could be provided by conference server. The following properties could be provided by
this procedure: this procedure:
o The user identity can be replaced to allow the user to be o The user identity can be replaced to allow the user to be
anonymous with regard to the Focus. This can be accomplished via anonymous with regard to the Focus. This can be accomplished via
[RFC3323] in combination with [I-D.ietf-sip-identity], per the [RFC3323] in combination with [RFC4474], per the latter, or,
latter, or,
o The user identity could be asserted to the Focus, via o The user identity could be asserted to the Focus, via [RFC4474]
[I-D.ietf-sip-identity] mechanisms, and/or, mechanisms, and/or,
o the SAML assertion could provide additional user profile o the SAML assertion could provide additional user profile
information such as group membership (belongs to the students, information such as group membership (belongs to the students,
staff, faculty group of university X). This could, for non- staff, faculty group of university X). This could, for non-
identity-based authorization systems, imply certain rights. identity-based authorization systems, imply certain rights.
The corresponding SIP message flow (in high level detail) could have The corresponding SIP message flow (in high level detail) could have
the following shape: the following shape:
+-----+ +-----------+ +-----------+ +-----+ +-----------+ +-----------+
skipping to change at page 49, line 47 skipping to change at page 42, line 47
| OK |<------------------| | OK |<------------------|
|<------------------| | |<------------------| |
| | | | | |
| ACK | | | ACK | |
|------------------>| ACK | |------------------>| ACK |
| |------------------>| | |------------------>|
| | | | | |
| | | | | |
... many more msgs... ... many more msgs...
Figure 21: SIP Conferencing and SAML Figure 8: SIP Conferencing and SAML
However, there are obvious scaling issues with the conference server However, there are obvious scaling issues with the conference server
having to do the outbound requests in order to obtain SAML assertions having to do the outbound requests in order to obtain SAML assertions
and certificates for conference participants. and certificates for conference participants.
This could be addressed by creating another SIP SAML Profile where This could be addressed by creating another SIP SAML Profile where
the caller obtains the necessary information, e.g., SAML assertions, the caller obtains the necessary information, e.g., SAML assertions,
and places them into its SIP request message prior to sending it. and places them into its SIP request message prior to sending it.
This would obviate the need for the callee relying party to make This would obviate the need for the callee relying party to make
requests in order to obtain said information. This is a topic for requests in order to obtain said information. This is a topic for
skipping to change at page 51, line 4 skipping to change at page 44, line 4
| | | | | |
| 4) SAML Assertion | | | 4) SAML Assertion | |
| (=Receipt) | | | (=Receipt) | |
|---------------------->| | |---------------------->| |
| | 5) Call + Receipt | | | 5) Call + Receipt |
| |------------------------>| | |------------------------>|
| | | | | |
| | 6) 200 OK | | | 6) 200 OK |
| |<------------------------| | |<------------------------|
| | | | | |
Figure 22: Message flow for SIP payment Figure 9: Message flow for SIP payment
User Alice and the Merchant Bob interact with each other using SIP User Alice and the Merchant Bob interact with each other using SIP
and the Alice uses HTTP to exchange messages with a Payment Provider. and the Alice uses HTTP to exchange messages with a Payment Provider.
Initially, Alice makes a call to Bob (1). Bob determines that a Initially, Alice makes a call to Bob (1). Bob determines that a
payment is required and includes information about the payment in an payment is required and includes information about the payment in an
Offer body of a 402 (Payment Required) response to Alice (2). Alice Offer body of a 402 (Payment Required) response to Alice (2). Alice
looks at this Offer and decides to make a payment. Alice therefore looks at this Offer and decides to make a payment. Alice therefore
instructs her Payment Provider to make a transfer from Alice"s instructs her Payment Provider to make a transfer from Alice"s
account to the Merchants"s account (3) using a request for a SAML account to the Merchants"s account (3) using a request for a SAML
assertion with the extensions defined in this document. The Payment assertion with the extensions defined in this document. The Payment
skipping to change at page 52, line 8 skipping to change at page 45, line 8
Provider made the transaction and protects the Receipt with a digital Provider made the transaction and protects the Receipt with a digital
signature. Alice resubmits the call to the Merchant Bob with the signature. Alice resubmits the call to the Merchant Bob with the
Receipt from the Payment Provier. Merchant Bob can check for replay Receipt from the Payment Provier. Merchant Bob can check for replay
attacks using the timestamp and a replay protection indiciator attacks using the timestamp and a replay protection indiciator
initially provided with the Offer. Bob can then check the signature initially provided with the Offer. Bob can then check the signature
is valid using the Payment Provider"s public key. is valid using the Payment Provider"s public key.
Authors' Addresses Authors' Addresses
Hannes Tschofenig Hannes Tschofenig
Siemens Networks GmbH & Co KG Nokia Siemens Networks
Otto-Hahn-Ring 6 Otto-Hahn-Ring 6
Munich, Bavaria 81739 Munich, Bavaria 81739
Germany Germany
Email: Hannes.Tschofenig@siemens.com Email: Hannes.Tschofenig@siemens.com
Jeff Hodges Jeff Hodges
NeuStar, Inc. NeuStar, Inc.
2000 Broadway Street 2000 Broadway Street
Redwood City, CA 94063 Redwood City, CA 94063
skipping to change at page 53, line 7 skipping to change at page 46, line 7
Douglas C. Sicker Douglas C. Sicker
University of Colorado at Boulder University of Colorado at Boulder
ECOT 430 ECOT 430
Boulder, CO 80309 Boulder, CO 80309
US US
Email: douglas.sicker@colorado.edu Email: douglas.sicker@colorado.edu
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
 End of changes. 68 change blocks. 
436 lines changed or deleted 173 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/