draft-ietf-kitten-sasl-saml-ec-19.txt   draft-ietf-kitten-sasl-saml-ec-20.txt 
Network Working Group S. Cantor Network Working Group S. Cantor
Internet-Draft Shibboleth Consortium Internet-Draft Shibboleth Consortium
Intended status: Standards Track S. Josefsson Intended status: Standards Track M. Cullen
Expires: February 29, 2020 SJD AB Expires: November 11, 2021 Painless Security
August 28, 2019 S. Josefsson
SJD AB
May 10, 2021
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-19 draft-ietf-kitten-sasl-saml-ec-20
Abstract Abstract
Security Assertion Markup Language (SAML) 2.0 is a generalized Security Assertion Markup Language (SAML) 2.0 is a generalized
framework for the exchange of security-related information between framework for the exchange of security-related information between
asserting and relying parties. Simple Authentication and Security asserting and relying parties. Simple Authentication and Security
Layer (SASL) and the Generic Security Service Application Program Layer (SASL) and the Generic Security Service Application Program
Interface (GSS-API) are application frameworks to facilitate an Interface (GSS-API) are application frameworks that facilitate an
extensible authentication model. This document specifies a SASL and extensible authentication model, among other things. This document
GSS-API mechanism for SAML 2.0 that leverages the capabilities of a specifies a SASL and GSS-API mechanism for SAML 2.0 that leverages
SAML-aware "enhanced client" to address significant barriers to the capabilities of a SAML-aware "enhanced client" to address
federated authentication in a manner that encourages reuse of significant barriers to federated authentication in a manner that
existing SAML bindings and profiles designed for non-browser encourages reuse of existing SAML bindings and profiles designed for
scenarios. non-browser scenarios.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on February 29, 2020. This Internet-Draft will expire on November 11, 2021.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2021 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 Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . 5 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . 6
4. SAML Enhanced Client SASL Mechanism Specification . . . . . . 8 4. SAML Enhanced Client SASL Mechanism Specification . . . . . . 8
4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 8
4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 9
4.4. User Authentication with Identity Provider . . . . . . . 9 4.4. User Authentication with Identity Provider . . . . . . . 10
4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 9 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . 10 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . 10
5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 10 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 11
5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 11 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 12
5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 13
5.3. Session Key Derivation . . . . . . . . . . . . . . . . . 12 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . 13
5.3.1. Generated by Identity Provider . . . . . . . . . . . 13 5.3.1. Generated by Identity Provider . . . . . . . . . . . 14
5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 14 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 15
5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . 14 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . 15
5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . 15 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . 15
5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . 15 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . 16
5.6.1. User Naming Considerations . . . . . . . . . . . . . 16 5.6.1. User Naming Considerations . . . . . . . . . . . . . 16
5.6.2. Service Naming Considerations . . . . . . . . . . . . 17 5.6.2. Service Naming Considerations . . . . . . . . . . . . 17
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . 26 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . 26
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . 26 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . 26
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 27 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 27
8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . 27 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . 27
skipping to change at page 3, line 11 skipping to change at page 3, line 12
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 33
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 33 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Security Assertion Markup Language (SAML) 2.0 Security Assertion Markup Language (SAML) 2.0
[OASIS.saml-core-2.0-os] is a modular specification that provides [OASIS.saml-core-2.0-os] is a modular specification that provides
various means for a user to be identified to a relying party (RP) various means for a user to be identified to a relying party (RP)
through the exchange of (typically signed) assertions issued by an through the exchange of (typically signed) assertions issued by an
identity provider (IdP). It includes a number of protocols, protocol identity provider (IdP).
bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
[OASIS.saml-profiles-2.0-os] designed for different use cases.
Additional profiles and extensions are also routinely developed and
published.
Simple Authentication and Security Layer (SASL) [RFC4422] is a Simple Authentication and Security Layer (SASL) [RFC4422] is a
generalized mechanism for identifying and authenticating a user and generalized mechanism for identifying and authenticating a user and
for optionally negotiating a security layer for subsequent protocol for optionally negotiating a security layer for subsequent protocol
interactions. SASL is used by application protocols like IMAP, POP interactions. SASL is used by application protocols like IMAP
and XMPP [RFC6120]. The effect is to make authentication modular, so [RFC3501], the Post Office Protocol(POP [RFC1939]) and XMPP
[RFC6120]. The effect of SASL is to make authentication modular, so
that newer authentication mechanisms can be added as needed. that newer authentication mechanisms can be added as needed.
There are related protocols, protocol bindings
[OASIS.saml-bindings-2.0-os], and interoperability profiles
[OASIS.saml-profiles-2.0-os] designed for different use cases.
Additional profiles and extensions are also routinely developed and
published.
The Generic Security Service Application Program Interface (GSS-API) The Generic Security Service Application Program Interface (GSS-API)
[RFC2743] provides a framework for applications to support multiple [RFC2743] provides a framework for applications to support multiple
authentication mechanisms through a unified programming interface. authentication mechanisms through a unified programming interface, as
This document defines a pure SASL mechanism for SAML, but it conforms well as additional optional cryptographic functionality. This
to the bridge between SASL and the GSS-API called GS2 [RFC5801]. document defines a pure SASL mechanism for SAML, but it conforms to
This means that this document defines both a SASL mechanism and a the bridge between SASL and GSS-API called GS2 [RFC5801]. This means
GSS-API mechanism. The GSS-API interface is optional for SASL that this document defines both a SASL mechanism and a GSS-API
implementers, and the GSS-API considerations can be avoided in mechanism. The GSS-API interface is optional for SASL implementers,
environments that use SASL directly without GSS-API. and the GSS-API considerations can be avoided in environments that
use SASL directly without GSS-API.
The mechanisms specified in this document allow a SASL- or GSS-API- The mechanisms specified in this document allow a SASL- or GSS-API-
enabled server to act as a SAML relying party, or service provider enabled server to act as a SAML relying party, or service provider
(SP), by advertising this mechanism as an option for SASL or GSS-API (SP), by advertising this mechanism as an option for SASL or GSS-API
clients that support the use of SAML to communicate identity and clients that support the use of SAML to communicate identity and
attribute information. Clients supporting this mechanism are termed attribute information. Clients supporting this mechanism are termed
"enhanced clients" in SAML terminology because they understand the "enhanced clients" in SAML terminology because they understand the
federated authentication model and have specific knowledge of the federated authentication model and have specific knowledge of the
IdP(s) associated with the user. This knowledge, and the ability to IdP(s) associated with the user. This knowledge, and the ability to
act on it, addresses a significant problem with browser-based SAML act on it, addresses a significant problem with browser-based SAML
skipping to change at page 4, line 43 skipping to change at page 5, line 5
+--|--+ +--|--+
+------------+ v +------------+ v
| | +----------+ | | +----------+
| SAML | SAML SOAP | | | SAML | SAML SOAP | |
| Identity |<--------------->| Client | | Identity |<--------------->| Client |
| Provider | Binding | | | Provider | Binding | |
+------------+ +----------+ +------------+ +----------+
Figure 1: Interworking Architecture Figure 1: Interworking Architecture
+-------+ +-------+ +-------+
| SAML | |Client | | SAML |
| IDP | | | | RP |
+---+---+ +---+---+ +---+---+
| | |
| |---------------------->|
| | Resource Request |
| | |
| | |
|<----------------------+-----------------------|
| | SAML Auth Request |
| | |
| | |
|<--------------------->| |
| User Authentication | |
| | |
| | |
|-----------------------+---------------------->|
| SAML Auth Response | |
| | |
| | |
| |<----------------------|
| | Requested Resource |
| | |
Figure 2: Communication Flow
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", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.
The reader is also assumed to be familiar with the terms used in the The reader is also assumed to be familiar with the terms used in the
SAML 2.0 specification, and an understanding of the Enhanced Client SAML 2.0 specification, and an understanding of the Enhanced Client
or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of or Proxy (ECP) Profile (V2.0) [SAMLECP20] is necessary, as part of
this mechanism explicitly reuses and references it. this mechanism explicitly reuses and references it.
This document can be implemented without knowledge of GSS-API since This document can be implemented without knowledge of GSS-API since
the normative aspects of the GS2 protocol syntax have been duplicated the normative aspects of the GS2 protocol syntax have been duplicated
in this document. The document may also be implemented to provide a in this document. The document may also be implemented to provide a
GSS-API mechanism, and then knowledge of GSS-API is essential. To GSS-API mechanism, and then knowledge of GSS-API is essential.
faciliate these two variants, the references has been split into two
parts, one part that provides normative references for all readers,
and one part that adds additional normative references required for
implementers that wish to implement the GSS-API portion.
3. Applicability for Non-HTTP Use Cases 3. Applicability for Non-HTTP Use Cases
While SAML is designed to support a variety of application scenarios, While SAML is designed to support a variety of application scenarios,
the profiles for authentication defined in the original standard are the profiles for authentication defined in the original standard are
designed around HTTP [RFC7230] applications. They are not, however, designed around HTTP [RFC7230] applications. They are not, however,
limited to browsers, because it was recognized that browsers suffer limited to browsers, because browsers do not always meet the needs of
from a variety of functional and security deficiencies that would be more security-sensitive applications. Specifically, the notion of an
useful to avoid where possible. Specifically, the notion of an
"Enhanced Client" (or a proxy acting as one on behalf of a browser, "Enhanced Client" (or a proxy acting as one on behalf of a browser,
thus the term "ECP") was specified for a software component that acts thus the term "ECP") was specified for a software component that acts
somewhat like a browser from an application perspective, but includes somewhat like a browser from an application perspective, but includes
limited, but sufficient, awareness of SAML to play a more conscious limited, but sufficient, awareness of SAML to play a more conscious
role in the authentication exchange between the RP and the IdP. What role in the authentication exchange between the RP and the IdP. What
follows is an outline of the Enhanced Client or Proxy (ECP) Profile follows is an outline of the Enhanced Client or Proxy (ECP) Profile
(V2.0) [SAMLECP20], as applied to the web/HTTP service use case: (V2.0) [SAMLECP20], as applied to the web/HTTP service use case:
1. The Enhanced Client requests a resource of a Relying Party (RP) 1. The Enhanced Client requests a resource of a Relying Party (RP)
(via an HTTP request). In doing so, it advertises its "enhanced" (via an HTTP request). In doing so, it advertises its "enhanced"
skipping to change at page 5, line 48 skipping to change at page 6, line 33
2. The RP, desiring SAML authentication and noting the client's 2. The RP, desiring SAML authentication and noting the client's
capabilities, responds not with an HTTP redirect or form, but capabilities, responds not with an HTTP redirect or form, but
with a SOAP [W3C.soap11] envelope containing a SAML with a SOAP [W3C.soap11] envelope containing a SAML
<AuthnRequest> along with some supporting headers. This request <AuthnRequest> along with some supporting headers. This request
identifies the RP (and may be signed), and may provide hints to identifies the RP (and may be signed), and may provide hints to
the client as to what IdPs the RP finds acceptable, but the the client as to what IdPs the RP finds acceptable, but the
choice of IdP is generally left to the client. choice of IdP is generally left to the client.
3. The client is then responsible for delivering the body of the 3. The client is then responsible for delivering the body of the
SOAP message to the IdP it is instructed to use (often via SOAP message to the IdP it is instructed to use (often via out-
configuration ahead of time). The user authenticates to the IdP of-band configuration). The user authenticates to the IdP ahead
ahead of, during, or after the delivery of this message, and of, during, or after the delivery of this message, and perhaps
perhaps explicitly authorizes the response to the RP. explicitly authorizes the response to the RP.
4. Whether authentication succeeds or fails, the IdP responds with 4. Whether authentication succeeds or fails, the IdP responds with
its own SOAP envelope, generally containing a SAML <Response> its own SOAP envelope, generally containing a SAML <Response>
message for delivery to the RP. In a successful case, the message for delivery to the RP. In a successful case, the
message will include one or more SAML <Assertion> elements message will include one or more SAML <Assertion> elements
containing authentication, and possibly attribute, statements containing authentication, and possibly attribute, statements
about the subject. Either the response or each assertion is about the subject. Either the response or each assertion is
signed, and the assertion(s) may be encrypted to a key negotiated signed, and the assertion(s) may be encrypted to a key negotiated
with or known to belong to the RP. with or known to belong to the RP.
skipping to change at page 7, line 28 skipping to change at page 8, line 12
participate in the selection of, or evaluation of, the location to participate in the selection of, or evaluation of, the location to
which the SASL Client Response will be delivered by the client. The which the SASL Client Response will be delivered by the client. The
use of GSS-API Channel Binding is an important mitigation of the risk use of GSS-API Channel Binding is an important mitigation of the risk
of a "Man in the Middle" attack between the client and RP, as is the of a "Man in the Middle" attack between the client and RP, as is the
use of a negotiated or derived session key in whatever protocol is use of a negotiated or derived session key in whatever protocol is
secured by this mechanism. secured by this mechanism.
With all of this in mind, the typical flow appears as follows: With all of this in mind, the typical flow appears as follows:
SASL Serv. Client IdP SASL Serv. Client IdP
|>-----(1)----->| | Advertisement |------(1)----->| | Advertisement
| | | | | |
|<-----(2)-----<| | Initiation |<-----(2)------| | Initiation
| | | | | |
|>-----(3)----->| | SASL Server Response |------(3)----->| | SASL Server Response
| | | | | |
| |<- - -(4)- - >| SOAP AuthnRequest + user authn | |<- - -(4)- - >| SOAP AuthnRequest + user authn
| | | | | |
|<-----(5)-----<| | SASL Client Response |<-----(5)------| | SASL Client Response
| | | | | |
|>-----(6)----->| | Server sends Outcome |------(6)----->| | Server sends Outcome
| | | | | |
----- = SASL ----- = SASL
- - - = SOAP over HTTPS (external to SASL) - - - = SOAP over HTTPS (external to SASL)
Figure 2: Authentication flow Figure 3: Authentication flow
4. SAML Enhanced Client SASL Mechanism Specification 4. SAML Enhanced Client SASL Mechanism Specification
Based on the previous figures, the following operations are defined Based on the previous figures, the following operations are defined
by the SAML SASL mechanism: by the SAML SASL mechanism:
4.1. Advertisement 4.1. Advertisement
To advertise that a server supports this mechanism, during To advertise that a server supports this mechanism, during
application session initiation, it displays the name "SAML20EC" and/ application session initiation, it displays the name "SAML20EC" and/
skipping to change at page 8, line 32 skipping to change at page 9, line 17
A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If A client initiates "SAML20EC" or "SAML20EC-PLUS" authentication. If
supported by the application protocol, the client MAY include an supported by the application protocol, the client MAY include an
initial response, otherwise it waits until the server has issued an initial response, otherwise it waits until the server has issued an
empty challenge (because the mechanism is client-first). empty challenge (because the mechanism is client-first).
The format of the initial client response ("initresp") is as follows: The format of the initial client response ("initresp") is as follows:
hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key" hok = "urn:oasis:names:tc:SAML:2.0:cm:holder-of-key"
mut = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ mut = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \
"WantAuthnRequestsSigned" "WantAuthnRequestsSigned"
del = "urn:oasis:names:tc:SAML:2.0:conditions:delegation" del = "urn:oasis:names:tc:SAML:2.0:conditions:delegation"
initresp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mut] "," [del] initresp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mut] "," [del]
The gs2-cb-flag flag MUST be set as defined in [RFC5801] to indicate The gs2-cb-flag flag MUST be set as defined in [RFC5801] to indicate
whether the client supports channel binding. This takes the place of whether the client supports channel binding. This takes the place of
the PAOS HTTP header extension used in [SAMLECP20] to indicate the PAOS HTTP header extension used in [SAMLECP20] to indicate
channel binding support. channel binding support.
skipping to change at page 9, line 49 skipping to change at page 10, line 35
header requirements of the SAML PAOS Binding header requirements of the SAML PAOS Binding
[OASIS.saml-bindings-2.0-os], for compatibility with the existing [OASIS.saml-bindings-2.0-os], for compatibility with the existing
profile. If the client is unable to obtain a response from the IdP, profile. If the client is unable to obtain a response from the IdP,
or must otherwise signal failure, it responds to the SASL server with or must otherwise signal failure, it responds to the SASL server with
a SOAP envelope containing a SOAP fault. a SOAP envelope containing a SOAP fault.
4.6. Outcome 4.6. Outcome
The SAML protocol exchange having completed, the SASL server will The SAML protocol exchange having completed, the SASL server will
transmit the outcome to the client depending on local validation of transmit the outcome to the client depending on local validation of
the client responses. This outcome is transmitted in accordance with the client responses (including the assertion conveyed from the
the application protocol in use. chosen IDP). This outcome is transmitted in accordance with the
application protocol in use.
4.7. Additional Notes 4.7. Additional Notes
Because this mechanism is an adaptation of an HTTP-based profile, Because this mechanism is an adaptation of an HTTP-based profile,
there are a few requirements outlined in [SAMLECP20] that make there are a few requirements outlined in [SAMLECP20] that make
reference to a response URL that is normally used to regulate where reference to a response URL that is normally used to regulate where
the client returns information to the RP. There are also security- the client returns information to the RP. There are also security-
related checks built into the profile that involve this location. related checks built into the profile that involve this location.
For compatibility with existing IdP and profile behavior, and to For compatibility with existing IdP and profile behavior, and to
skipping to change at page 10, line 30 skipping to change at page 11, line 16
encoded per [RFC3986]. encoded per [RFC3986].
The IdP MUST securely associate the service name with the SAML The IdP MUST securely associate the service name with the SAML
entityID claimed by the SASL server, such as through the use of SAML entityID claimed by the SASL server, such as through the use of SAML
metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, a SASL metadata [OASIS.saml-metadata-2.0-os]. If metadata is used, a SASL
service's <SPSSODescriptor> role MUST contain a corresponding service's <SPSSODescriptor> role MUST contain a corresponding
<AssertionConsumerService> whose Location attribute contains the <AssertionConsumerService> whose Location attribute contains the
appropriate service name, as described above. The Binding attribute appropriate service name, as described above. The Binding attribute
MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or MUST be one of "urn:ietf:params:xml:ns:samlec" (RECOMMENDED) or
"urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with "urn:oasis:names:tc:SAML:2.0:bindings:PAOS" (for compatibility with
older implementations of the ECP profile in existing identity older implementations of the ECP profile in existing IdP software).
provider software).
Finally, note that the use of HTTP status signaling between the RP Finally, note that the use of HTTP status signaling between the RP
and client mandated by [SAMLECP20] may not be applicable. and client mandated by [SAMLECP20] may not be applicable.
5. SAML EC GSS-API Mechanism Specification 5. SAML EC GSS-API Mechanism Specification
This section and its sub-sections and all normative references of it This section and its sub-sections and all normative references of it
not referenced elsewhere in this document are INFORMATIONAL for SASL not referenced elsewhere in this document are INFORMATIONAL for SASL
implementors, but they are NORMATIVE for GSS-API implementors. implementors, but they are NORMATIVE for GSS-API implementors.
The SAML Enhanced Client SASL mechanism is also a GSS-API mechanism. The SAML Enhanced Client SASL mechanism is also a GSS-API mechanism.
The messages are the same, but a) the GS2 [RFC5801] header on the The messages are the same, but a) the GS2 [RFC5801] header on the
client's first message is excluded when SAML EC is used as a GSS-API client's first authentication message is excluded when SAML EC is
mechanism, and b) the [RFC2743] section 3.1 initial context token used as a GSS-API mechanism, and b) the [RFC2743] section 3.1 initial
header is prefixed to the client's first authentication message context token header is used for the client's first authentication
(context token). message (context token) instead, with the body of the message being
the same as for the SASL mechanism case.
The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see The GSS-API mechanism OID for SAML EC is OID-TBD (IANA to assign: see
IANA considerations). The DER encoding of the OID is TBD. IANA considerations). The DER encoding of the OID is TBD.
The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE, The mutual_state request flag (GSS_C_MUTUAL_FLAG) MAY be set to TRUE,
resulting in the "mut" option set in the initial client response. resulting in the "mut" option set in the initial client response.
The security context mutual_state flag is set to TRUE only if the The security context mutual_state flag is set to TRUE only if the
server digitally signs its SAML <AuthnRequest> message and the server digitally signs its SAML <AuthnRequest> message and the
signature and signing credential are appropriately verified by the signature and signing credential are appropriately verified by the
identity provider. The identity provider signals this to the client IdP. The IdP signals this to the client in an
in an <ecp:RequestAuthenticated> SOAP header block. <ecp:RequestAuthenticated> SOAP header block.
The lifetime of a security context established with this mechanism The lifetime of a security context established with this mechanism
SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if SHOULD be limited by the value of a SessionNotOnOrAfter attribute, if
any, in the <AuthnStatement> element(s) of the SAML assertion(s) any, in the <AuthnStatement> element(s) of the SAML assertion(s)
received by the RP. By convention, in the rare case that multiple received by the RP. By convention, in the rare case that multiple
valid/confirmed assertions containing <AuthnStatement> elements are valid/confirmed assertions containing <AuthnStatement> elements are
received, the most restrictive SessionNotOnOrAfter is generally received, the most restrictive SessionNotOnOrAfter is generally
applied. applied.
5.1. GSS-API Credential Delegation 5.1. GSS-API Credential Delegation
This mechanism can support credential delegation through the issuance This mechanism can support credential delegation through the issuance
of SAML assertions that an identity provider will accept as proof of of SAML assertions that an IdP will accept as proof of authentication
authentication by a service on behalf of a subject. An initiator may by a service on behalf of a subject. An initiator may request
request delegation of its credentials by setting the "del" option delegation of its credentials by setting the "del" option field in
field in the initial client response to the initial client response to
"urn:oasis:names:tc:SAML:2.0:conditions:delegation". "urn:oasis:names:tc:SAML:2.0:conditions:delegation".
An acceptor, upon receipt of this constant, requests a delegated An acceptor, upon receipt of this constant, requests a delegated
assertion by including in its <AuthnRequest> message a <Conditions> assertion by including in its <AuthnRequest> message a <Conditions>
element containing an <AudienceRestriction> identifying the IdP as a element containing an <AudienceRestriction> identifying the IdP as a
desired audience for the assertion(s) to be issued. In the event desired audience for the assertion(s) to be issued. In the event
that the specific identity provider to be used is unknown, the that the specific IdP to be used is unknown, the constant
constant "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be "urn:oasis:names:tc:SAML:2.0:conditions:delegation" may be used as a
used as a stand-in, per Section 2.3.2 of [SAMLECP20]. stand-in, per Section 2.3.2 of [SAMLECP20].
Upon receipt of an assertion satisfying this property, and containing Upon receipt of an assertion satisfying this property, and containing
a <SubjectConfirmation> element that the acceptor can satisfy, the a <SubjectConfirmation> element that the acceptor can satisfy, the
security context may have its deleg_state flag (GSS_C_DELEG_FLAG) set security context will have its deleg_state flag (GSS_C_DELEG_FLAG)
to TRUE. set to TRUE.
The identity provider, if it issues a delegated assertion to the The IdP, if it issues a delegated assertion to the acceptor, MUST
acceptor, MUST include in the SOAP response to the initiator a include in the SOAP response to the initiator a <samlec:Delegated>
<samlec:Delegated> SOAP header block, indicating that delegation was SOAP header block, indicating that delegation was enabled. It has no
enabled. It has no content, other than mandatory SOAP attributes (an content, other than mandatory SOAP attributes (an example follows):
example follows):
<samlec:Delegated xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:Delegated xmlns:samlec="urn:ietf:params:xml:ns:samlec"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" /> S:actor="http://schemas.xmlsoap.org/soap/actor/next" />
Upon receipt of such a header block, the initiator MUST fail the Upon receipt of such a header block, the initiator MUST fail the
establishment of the security context if it did not request establishment of the security context if it did not request
delegation in its initial client response to the acceptor. It SHOULD delegation in its initial client response to the acceptor. It SHOULD
signal this failure to the acceptor with a SOAP fault message in its signal this failure to the acceptor with a SOAP fault message in its
skipping to change at page 12, line 20 skipping to change at page 13, line 4
Upon receipt of such a header block, the initiator MUST fail the Upon receipt of such a header block, the initiator MUST fail the
establishment of the security context if it did not request establishment of the security context if it did not request
delegation in its initial client response to the acceptor. It SHOULD delegation in its initial client response to the acceptor. It SHOULD
signal this failure to the acceptor with a SOAP fault message in its signal this failure to the acceptor with a SOAP fault message in its
final client response. final client response.
As noted previously, the exact means of client authentication to the As noted previously, the exact means of client authentication to the
IdP is formally out of scope of this mechanism. This extends to the IdP is formally out of scope of this mechanism. This extends to the
use of a delegation assertion as a means of authentication by an use of a delegation assertion as a means of authentication by an
acceptor acting as an initiator. In practice, some profile of acceptor acting as an initiator. In practice, some profile of
[WSS-SAML] is used to attach the assertion and a confirmation proof [WSS-SAML] is used to attach the assertion and a confirmation proof
to the SOAP message from the client to the IdP. to the SOAP message from the client to the IdP.
5.2. GSS-API Channel Binding 5.2. GSS-API Channel Binding
GSS-API channel binding [RFC5554] is a protected facility for GSS-API channel binding [RFC5554] is a protected facility for
exchanging a cryptographic name for an enclosing channel between the exchanging a cryptographic identifier for an enclosing channel
initiator and acceptor. The initiator sends channel binding data and between the initiator and acceptor. The initiator sends channel
the acceptor confirms that channel binding data has been checked. binding data and the acceptor confirms that channel binding data has
been checked.
The acceptor SHOULD accept any channel binding provided by the The acceptor SHOULD accept any channel binding provided by the
initiator if null channel bindings are passed into initiator if null channel bindings are passed into
gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559] gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559]
depend on this behavior of some Kerberos implementations. depend on this behavior of some Kerberos implementations.
The exchange and verification of channel binding information is The exchange and verification of channel binding information is
described by [SAMLECP20]. described by [SAMLECP20].
5.3. Session Key Derivation 5.3. Session Key Derivation
Some GSS-API features (discussed in the following sections) require a Some GSS-API features (discussed in the following sections) require a
session key be established as a result of security context session key be established as a result of security context
establishment. In the common case of a "bearer" assertion in SAML, a establishment. In the common case of a "bearer" assertion in SAML, a
mechanism is defined to communicate a key to both parties via the mechanism is defined to communicate a key to both parties via the
identity provider. In other cases such as assertions based on IdP. In other cases such as assertions based on "holder of key"
"holder of key" confirmation bound to a client-controlled key, there confirmation bound to a client-controlled key, there may be
may be additional methods defined in the future, and extension points additional methods defined in the future, and extension points are
are provided for this purpose. provided for this purpose.
Information defining or describing the session key, or a process for Information defining or describing the session key, or a process for
deriving one, is communicated between the initiator and acceptor deriving one, is communicated between the initiator and acceptor
using a <samlec:SessionKey> element, defined by the XML schema in using a <samlec:SessionKey> element, defined by the XML schema in
Appendix A. This element is a SOAP header block. The content of the Appendix A. This element is a SOAP header block. The content of the
element further depends on the specific use in the mechanism. The element further depends on the specific use in the mechanism. The
Algorithm XML attribute identifies a mechanism for key derivation. Algorithm XML attribute identifies a mechanism for key derivation.
It is omitted to identify the use of an Identity Provider-generated It is omitted to identify the use of an IdP-generated key (see
key (see following section) or will contain a URI value identifying a following section) or will contain a URI value identifying a
derivation mechanism defined outside this specification. Each header derivation mechanism defined outside this specification. Each header
block's mustUnderstand and actor attributes MUST be set to "1" and block's mustUnderstand and actor attributes MUST be set to "1" and
"http://schemas.xmlsoap.org/soap/actor/next" respectively. "http://schemas.xmlsoap.org/soap/actor/next" respectively.
In the acceptor's first response message containing its SAML request, In the acceptor's first response message containing its SAML request,
one or more <samlec:SessionKey> SOAP header blocks MUST be included. one or more <samlec:SessionKey> SOAP header blocks MUST be included.
The element MUST contain one or more <EncType> elements containing The element MUST contain one or more <EncType> elements containing
the number of a supported encryption type defined in accordance with the number of a supported encryption type defined in accordance with
[RFC3961]. Encryption types should be provided in order of [RFC3961]. Encryption types should be provided in order of
preference by the acceptor. preference by the acceptor.
skipping to change at page 13, line 33 skipping to change at page 14, line 18
initiator. initiator.
All parties MUST support the "aes128-cts-hmac-sha1-96" encryption All parties MUST support the "aes128-cts-hmac-sha1-96" encryption
type, number 17, defined by [RFC3962]. type, number 17, defined by [RFC3962].
Further details depend on the mechanism used, one of which is Further details depend on the mechanism used, one of which is
described in the following section. described in the following section.
5.3.1. Generated by Identity Provider 5.3.1. Generated by Identity Provider
The identity provider, if issuing a bearer assertion for use with The IdP, if issuing a bearer assertion for use with this mechanism,
this mechanism, SHOULD provide a generated key for use by the SHOULD provide a generated key for use by the initiator and acceptor.
initiator and acceptor. This key is used as pseudorandom input to This key is used as pseudorandom input to the "random-to-key"
the "random-to-key" function for a specific encryption type defined function for a specific encryption type defined in accordance with
in accordance with [RFC3961]. The key is base64-encoded and placed [RFC3961]. The key is base64-encoded and placed inside a
inside a <samlec:GeneratedKey> element. The identity provider does <samlec:GeneratedKey> element. The IdP does not participate in the
not participate in the selection of the encryption type and simply selection of the encryption type and simply generates enough
generates enough pseudorandom bits to supply key material to the pseudorandom bits to supply key material to the other parties.
other parties.
The resulting <samlec:GeneratedKey> element is placed within the The resulting <samlec:GeneratedKey> element is placed within the
<saml:Advice> element of the assertion issued. The identity provider <saml:Advice> element of the assertion issued. The identity provider
MUST encrypt the assertion (implying that it MUST have the means to MUST encrypt the assertion (implying that it MUST have the means to
do so, typically knowledge of a key associated with the RP). If do so, typically knowledge of a key associated with the RP). If
multiple assertions are issued (allowed, but not typical), the multiple assertions are issued (allowed, but not typical), the
element need only be included in one of the assertions issued for use element need only be included in one of the assertions issued for use
by the relying party. by the relying party.
A copy of the element is also added as a SOAP header block in the A copy of the element is also added as a SOAP header block in the
response from the identity provider to the client (and then removed response from the IdP to the client (and then removed when
when constructing the response to the acceptor). constructing the response to the acceptor).
If this mechanism is used by the initiator, then the If this mechanism is used by the initiator, then the
<samlec:SessionKey> SOAP header block attached to the final client <samlec:SessionKey> SOAP header block attached to the final client
response message will identify this via the omission of the Algorithm response message will identify this via the omission of the Algorithm
attribute and will identify the chosen encryption type using the attribute and will identify the chosen encryption type using the
<samlec:EncType> element: <samlec:EncType> element:
<samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
skipping to change at page 15, line 45 skipping to change at page 16, line 23
Services that act as SAML relying parties are typically identified by Services that act as SAML relying parties are typically identified by
means of a URI called an "entityID". Clients that are named in the means of a URI called an "entityID". Clients that are named in the
<Subject> element of a SAML assertion are typically identified by <Subject> element of a SAML assertion are typically identified by
means of a <NameID> element, which is an extensible XML structure means of a <NameID> element, which is an extensible XML structure
containing, at minimum, an element value that names the subject and a containing, at minimum, an element value that names the subject and a
Format attribute. Format attribute.
In practice, a GSS-API client and server are unlikely to know in In practice, a GSS-API client and server are unlikely to know in
advance the name of the initiator as it will be expressed by the SAML advance the name of the initiator as it will be expressed by the SAML
identity provider upon completion of authentication. It is also IdP upon completion of authentication. It is also generally
generally incorrect to assume that a particular acceptor name will incorrect to assume that a particular acceptor name will directly map
directly map into a particular RP entityID, because there is often a into a particular RP entityID, because there is often a layer of
layer of naming indirection between particular services on hosts and naming indirection between particular services on hosts and the
the identity of a relying party in SAML terms. identity of a relying party in SAML terms.
To avoid complexity, and avoid unnecessary use of XML within the To avoid complexity, and avoid unnecessary use of XML within the
naming layer, the SAML EC mechanism relies on the common/expected naming layer, the SAML EC mechanism relies on the common/expected
name types used for acceptors and initiators, name types used for acceptors and initiators,
GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism GSS_C_NT_HOSTBASED_SERVICE and GSS_C_NT_USER_NAME. The mechanism
provides for validation of the host-based service name in conjunction provides for validation of the host-based service name in conjunction
with the SAML exchange. It does not attempt to solve the problem of with the SAML exchange. It does not attempt to solve the problem of
mapping between an initiator "username", the user's identity while mapping between an initiator "username", the user's identity while
authenticating to the identity provider, and the information supplied authenticating to the IdP, and the information supplied by the IdP to
by the identity provider to the acceptor. These relationships must the acceptor. These relationships must be managed through local
be managed through local policy at the initiator and acceptor. policy at the initiator and acceptor.
SAML-based information associated with the initiator SHOULD be SAML-based information associated with the initiator SHOULD be
expressed to the acceptor using GSS-API naming extensions [RFC6680], expressed to the acceptor using GSS-API naming extensions [RFC6680],
in accordance with [RFC7056]. in a similar manner to [RFC7056].
5.6.1. User Naming Considerations 5.6.1. User Naming Considerations
The GSS_C_NT_USER_NAME form represents the name of an individual The GSS_C_NT_USER_NAME form represents the name of an individual
user. Clients often rely on this value to determine the appropriate user. Clients often rely on this value to determine the appropriate
credentials to use in authenticating to the identity provider, and credentials to use in authenticating to the IdP, and supply it to the
supply it to the server for use by the acceptor. server for use by the acceptor.
Upon successful completion of this mechanism, the server MUST Upon successful completion of this mechanism, the server MUST
construct the authenticated initiator name based on the <saml:NameID> construct the authenticated initiator name based on the <saml:NameID>
element in the assertion it successfully validated. The name is element in the assertion it successfully validated. The name is
constructed as a UTF-8 string in the following form: constructed as a UTF-8 string in the following form:
name = element-value "!" Format "!" NameQualifier name = element-value "!" Format "!" NameQualifier
"!" SPNameQualifier "!" SPProvidedID "!" SPNameQualifier "!" SPProvidedID
The "element-value" token refers to the content of the <saml:NameID> The "element-value" token refers to the content of the <saml:NameID>
skipping to change at page 20, line 31 skipping to change at page 20, line 31
<samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"> S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>17</samlec:EncType> <samlec:EncType>17</samlec:EncType>
<samlec:EncType>18</samlec:EncType> <samlec:EncType>18</samlec:EncType>
<samlec:SessionKey> <samlec:SessionKey>
</S:Header> </S:Header>
<S:Body> <S:Body>
<samlp:AuthnRequest <samlp:AuthnRequest
ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2007-12-10T11:39:34Z" ID="c3a4f8b9c2d" Version="2.0" IssueInstant="2020-12-10T11:39:34Z"
AssertionConsumerServiceURL="xmpp@xmpp.example.com"> AssertionConsumerServiceURL="xmpp@xmpp.example.com">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">
https://xmpp.example.com https://xmpp.example.com
</saml:Issuer> </saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true" <samlp:NameIDPolicy AllowCreate="true"
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/> Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"/>
<samlp:RequestedAuthnContext Comparison="exact"> <samlp:RequestedAuthnContext Comparison="exact">
<saml:AuthnContextClassRef> <saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef> </saml:AuthnContextClassRef>
skipping to change at page 21, line 11 skipping to change at page 21, line 11
</S:Envelope> </S:Envelope>
Step 5 (alt): Server returns error to client: Step 5 (alt): Server returns error to client:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/> <incorrect-encoding/>
</failure> </failure>
</stream:stream> </stream:stream>
Step 6: Client relays the request to IdP in a SOAP message Step 6: Client relays the request to IdP in a SOAP message
transmitted over HTTP (over TLS). HTTP portion not shown, use of transmitted over HTTP (over TLS). The HTTP portion is not shown, so
Basic Authentication is assumed. The body of the SOAP envelope is the use of Basic Authentication is assumed. The body of the SOAP
exactly the same as received in the previous step. envelope is exactly the same as received in the previous step.
<S:Envelope <S:Envelope
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> xmlns:S="http://schemas.xmlsoap.org/soap/envelope/">
<S:Body> <S:Body>
<samlp:AuthnRequest> <samlp:AuthnRequest>
<!-- same as above --> <!-- same as above -->
</samlp:AuthnRequest> </samlp:AuthnRequest>
</S:Body> </S:Body>
skipping to change at page 22, line 19 skipping to change at page 22, line 19
<S:Header> <S:Header>
<ecp:Response S:mustUnderstand="1" <ecp:Response S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next" S:actor="http://schemas.xmlsoap.org/soap/actor/next"
AssertionConsumerServiceURL="xmpp@xmpp.example.com"/> AssertionConsumerServiceURL="xmpp@xmpp.example.com"/>
<samlec:GeneratedKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"> <samlec:GeneratedKey xmlns:samlec="urn:ietf:params:xml:ns:samlec">
3w1wSBKUosRLsU69xGK7dg== 3w1wSBKUosRLsU69xGK7dg==
</samlec:GeneratedKey> </samlec:GeneratedKey>
</S:Header> </S:Header>
<S:Body> <S:Body>
<samlp:Response ID="d43h94r389309r" Version="2.0" <samlp:Response ID="d43h94r389309r" Version="2.0"
IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d" IssueInstant="2020-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d"
Destination="xmpp@xmpp.example.com"> Destination="xmpp@xmpp.example.com">
<saml:Issuer>https://saml.example.org</saml:Issuer> <saml:Issuer>https://saml.example.org</saml:Issuer>
<samlp:Status> <samlp:Status>
<samlp:StatusCode <samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status> </samlp:Status>
<saml:EncryptedAssertion> <saml:EncryptedAssertion>
<!-- contents elided, copy of samlec:GeneratedKey in Advice --> <!-- contents elided, copy of samlec:GeneratedKey in Advice -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
skipping to change at page 24, line 22 skipping to change at page 24, line 22
S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/> S:mustUnderstand="1" refToMessageID="6c3a4f8b9c2d"/>
<samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec" <samlec:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/" xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
S:mustUnderstand="1" S:mustUnderstand="1"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"> S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>17</samlec:EncType> <samlec:EncType>17</samlec:EncType>
<samlec:SessionKey> <samlec:SessionKey>
</S:Header> </S:Header>
<S:Body> <S:Body>
<samlp:Response ID="d43h94r389309r" Version="2.0" <samlp:Response ID="d43h94r389309r" Version="2.0"
IssueInstant="2007-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d" IssueInstant="2020-12-10T11:42:34Z" InResponseTo="c3a4f8b9c2d"
Destination="xmpp@xmpp.example.com"> Destination="xmpp@xmpp.example.com">
<saml:Issuer>https://saml.example.org</saml:Issuer> <saml:Issuer>https://saml.example.org</saml:Issuer>
<samlp:Status> <samlp:Status>
<samlp:StatusCode <samlp:StatusCode
Value="urn:oasis:names:tc:SAML:2.0:status:Success"/> Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
</samlp:Status> </samlp:Status>
<saml:EncryptedAssertion> <saml:EncryptedAssertion>
<!-- contents elided, copy of samlec:GeneratedKey in Advice --> <!-- contents elided, copy of samlec:GeneratedKey in Advice -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
skipping to change at page 26, line 9 skipping to change at page 26, line 9
with the use of SAML with SASL applications. For considerations with the use of SAML with SASL applications. For considerations
relating to SAML in general, the reader is referred to the SAML relating to SAML in general, the reader is referred to the SAML
specification and to other literature. Similarly, for general SASL specification and to other literature. Similarly, for general SASL
Security Considerations, the reader is referred to that Security Considerations, the reader is referred to that
specification. specification.
Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds Version 2.0 of the Enhanced Client or Proxy Profile [SAMLECP20] adds
optional support for channel binding and use of "Holder of Key" optional support for channel binding and use of "Holder of Key"
subject confirmation. The former is strongly recommended for use subject confirmation. The former is strongly recommended for use
with this mechanism to detect "Man in the Middle" attacks between the with this mechanism to detect "Man in the Middle" attacks between the
client and the RP without relying on flawed commercial TLS client and the RP without relying on the commercial TLS
infrastructure. The latter may be impractical in many cases, but is infrastructure that does not provide the level of assurance desired
a valuable way of strengthening client authentication, protecting by sensitive SAML applications. The latter may be impractical in
against phishing, and improving the overall mechanism. many cases, but is a valuable way of strengthening client
authentication, protecting against phishing, and improving the
overall mechanism.
7.1. Risks Left Unaddressed 7.1. Risks Left Unaddressed
The adaptation of a web-based profile that is largely designed around The adaptation of a web-based profile that is largely designed around
security-oblivious clients and a bearer model for security token security-oblivious clients and a bearer model for security token
validation results in a number of basic security exposures that validation results in a number of basic security exposures that
should be weighed against the compatibility and client simplification should be weighed against the compatibility and client simplification
benefits of this mechanism. benefits of this mechanism.
When channel binding is not used, protection against "Man in the When channel binding is not used, protection against "Man in the
Middle" attacks is left to lower layer protocols such as TLS, and the Middle" attacks is left solely to lower layer protocols such as TLS,
development of user interfaces able to implement that has not been and the development of user interfaces able to implement that has not
effectively demonstrated. Failure to detect a MITM can result in been effectively demonstrated. Failure to detect a MITM can result
phishing of the user's credentials if the attacker is between the in phishing of the user's credentials if the attacker is between the
client and IdP, or the theft and misuse of a short-lived credential client and IdP, or the theft and misuse of a short-lived credential
(the SAML assertion) if the attacker is able to impersonate a RP. (the SAML assertion) if the attacker is able to impersonate a RP.
SAML allows for source address checking as a minor mitigation to the SAML allows for source address checking as a minor mitigation to the
latter threat, but this is often impractical. IdPs can mitigate to latter threat, but this is often impractical. IdPs can mitigate to
some extent the exposure of personal information to RP attackers by some extent the exposure of personal information to RP attackers by
encrypting assertions with authenticated keys. encrypting assertions with authenticated keys.
7.2. User Privacy 7.2. User Privacy
The IdP is aware of each RP that a user logs into. There is nothing The IdP is aware of each RP that a user logs into. There is nothing
skipping to change at page 30, line 11 skipping to change at page 30, line 15
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", [RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme",
RFC 7617, DOI 10.17487/RFC7617, September 2015, RFC 7617, DOI 10.17487/RFC7617, September 2015,
<https://www.rfc-editor.org/info/rfc7617>. <https://www.rfc-editor.org/info/rfc7617>.
[RFC7802] Emery, S. and N. Williams, "A Pseudo-Random Function (PRF) [RFC7802] Emery, S. and N. Williams, "A Pseudo-Random Function (PRF)
for the Kerberos V Generic Security Service Application for the Kerberos V Generic Security Service Application
Program Interface (GSS-API) Mechanism", RFC 7802, Program Interface (GSS-API) Mechanism", RFC 7802,
DOI 10.17487/RFC7802, March 2016, DOI 10.17487/RFC7802, March 2016,
<https://www.rfc-editor.org/info/rfc7802>. <https://www.rfc-editor.org/info/rfc7802>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[SAMLECP20] [SAMLECP20]
Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile Cantor, S., "SAML V2.0 Enhanced Client or Proxy Profile
Version 2.0", OASIS Committee Specification OASIS.sstc- Version 2.0", OASIS Committee Specification OASIS.sstc-
saml-ecp-v2.0-cs01, August 2013. saml-ecp-v2.0-cs01, August 2013.
[W3C.soap11] [W3C.soap11]
skipping to change at page 30, line 34 skipping to change at page 30, line 42
Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>. Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>.
9.2. Informative References 9.2. Informative References
[OASIS.saml-metadata-2.0-os] [OASIS.saml-metadata-2.0-os]
Cantor, S., Moreh, J., Philpott, R., and E. Maler, Cantor, S., Moreh, J., Philpott, R., and E. Maler,
"Metadata for the Security Assertion Markup Language "Metadata for the Security Assertion Markup Language
(SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March (SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March
2005. 2005.
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
<https://www.rfc-editor.org/info/rfc1939>.
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
<https://www.rfc-editor.org/info/rfc3501>.
[RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006, Windows", RFC 4559, DOI 10.17487/RFC4559, June 2006,
<https://www.rfc-editor.org/info/rfc4559>. <https://www.rfc-editor.org/info/rfc4559>.
[RFC6120] Saint-Andre, P., "Extensible Messaging and Presence [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/info/rfc6120>. March 2011, <https://www.rfc-editor.org/info/rfc6120>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
skipping to change at page 33, line 7 skipping to change at page 33, line 7
<complexType name="DelegatedType"> <complexType name="DelegatedType">
<sequence/> <sequence/>
<attribute ref="S:mustUnderstand" use="required"/> <attribute ref="S:mustUnderstand" use="required"/>
<attribute ref="S:actor" use="required"/> <attribute ref="S:actor" use="required"/>
</complexType> </complexType>
</schema> </schema>
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors would like to thank Klaas Wierenga, Sam Hartman, Nico The authors would also like to thank Klaas Wierenga, Sam Hartman,
Williams, Jim Basney, and Venkat Yekkirala for their contributions. Nico Williams, Jim Basney, Venkat Yekkirala, and Ben Kaduk for their
contributions.
Appendix C. Changes Appendix C. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 20, address nits and easy fixes from Ben Kaduk's AD review
o 19, update obsoleted references o 19, update obsoleted references
o 15,16,17,18 avoid expiration o 15,16,17,18 avoid expiration
o 14, address some minor comments o 14, address some minor comments
o 13, clarify SAML metadata usage, adding a recommended Binding o 13, clarify SAML metadata usage, adding a recommended Binding
value alongside the backward-compatibility usage of PAOS value alongside the backward-compatibility usage of PAOS
o 12, clarifying comments based on WG feedback, with a normative o 12, clarifying comments based on WG feedback, with a normative
skipping to change at page 34, line 21 skipping to change at page 34, line 24
Scott Cantor Scott Cantor
Shibboleth Consortium Shibboleth Consortium
1050 Carmack Rd 1050 Carmack Rd
Columbus, Ohio 43210 Columbus, Ohio 43210
United States United States
Phone: +1 614 247 6147 Phone: +1 614 247 6147
Email: cantor.2@osu.edu Email: cantor.2@osu.edu
Margaret Cullen
Painless Security
4 High St, Suite 134
North Andover, Massachusets 01845
United States
Phone: +1 781 405 7464
Email: mrcullen42@painless-security.com
Simon Josefsson Simon Josefsson
SJD AB SJD AB
Hagagatan 24 Hagagatan 24
Stockholm 113 47 Stockholm 113 47
SE SE
Email: simon@josefsson.org Email: simon@josefsson.org
URI: http://josefsson.org/ URI: http://josefsson.org/
 End of changes. 55 change blocks. 
133 lines changed or deleted 190 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/