draft-ietf-kitten-sasl-saml-ec-06.txt   draft-ietf-kitten-sasl-saml-ec-07.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 S. Josefsson
Expires: August 2, 2013 SJD AB Expires: October 31, 2013 SJD AB
January 29, 2013 April 29, 2013
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-06.txt draft-ietf-kitten-sasl-saml-ec-07.txt
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 to facilitate an
extensible authentication model. This document specifies a SASL and extensible authentication model. This document specifies a SASL and
GSS-API mechanism for SAML 2.0 that leverages the capabilities of a GSS-API mechanism for SAML 2.0 that leverages the capabilities of a
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 August 2, 2013. This Internet-Draft will expire on October 31, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 6 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 7
4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 10
4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 10
4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 11
4.4. User Authentication with Identity Provider . . . . . . . . 10 4.4. User Authentication with Identity Provider . . . . . . . . 11
4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 11
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 11
5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 13
5.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12 5.1. GSS-API Credential Delegation . . . . . . . . . . . . . . 13
5.2. Session Key Derivation . . . . . . . . . . . . . . . . . . 13 5.2. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 14
5.2.1. Generated by Identity Provider . . . . . . . . . . . . 14 5.3. Session Key Derivation . . . . . . . . . . . . . . . . . . 14
5.2.2. Alternate Key Derivation Mechanisms . . . . . . . . . 14 5.3.1. Generated by Identity Provider . . . . . . . . . . . . 15
5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 15 5.3.2. Alternate Key Derivation Mechanisms . . . . . . . . . 16
5.4. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15 5.4. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 16
5.5. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15 5.5. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 17
5.5.1. User Naming Considerations . . . . . . . . . . . . . . 16 5.6. GSS-API Principal Name Types for SAML EC . . . . . . . . . 17
5.5.2. Service Naming Considerations . . . . . . . . . . . . 17 5.6.1. User Naming Considerations . . . . . . . . . . . . . . 18
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 5.6.2. Service Naming Considerations . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 26 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 26 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 28
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 28
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 29
8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 28 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 28 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.2. Normative References for GSS-API Implementers . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 31
9.3. Informative References . . . . . . . . . . . . . . . . . . 31 9.2. Normative References for GSS-API Implementers . . . . . . 32
Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 32 9.3. Informative References . . . . . . . . . . . . . . . . . . 33
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 33 Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 34
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 34 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 36
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
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). It includes a number of protocols, protocol
bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles bindings [OASIS.saml-bindings-2.0-os], and interoperability profiles
[OASIS.saml-profiles-2.0-os] designed for different use cases. [OASIS.saml-profiles-2.0-os] designed for different use cases.
skipping to change at page 3, line 32 skipping to change at page 4, line 32
that newer authentication mechanisms can be added as needed. that newer authentication mechanisms can be added as needed.
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.
This document defines a pure SASL mechanism for SAML, but it conforms This document defines a pure SASL mechanism for SAML, but it conforms
to the bridge between SASL and the GSS-API called GS2 [RFC5801]. to the bridge between SASL and the GSS-API called GS2 [RFC5801].
This means that this document defines both a SASL mechanism and a This means that this document defines both a SASL mechanism and a
GSS-API mechanism. The GSS-API interface is optional for SASL GSS-API mechanism. The GSS-API interface is optional for SASL
implementers, and the GSS-API considerations can be avoided in implementers, and the GSS-API considerations can be avoided in
environments that uses SASL directly without GSS-API. 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 6, line 42 skipping to change at page 7, line 42
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
configuration ahead of time). The user authenticates to the IdP configuration ahead of time). The user authenticates to the IdP
ahead of, during, or after the delivery of this message, and ahead of, during, or after the delivery of this message, and
perhaps explicitly authorizes the response to the RP. perhaps 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 a SAML <Assertion> containing message will include one or more SAML <Assertion> elements
authentication, and possibly attribute, information about the containing authentication, and possibly attribute, statements
user. Either the response or assertion alone is signed, and the about the subject. Either the response or each assertion is
assertion may be encrypted to a key negotiated with or known to signed, and the assertion(s) may be encrypted to a key negotiated
belong to the RP. with or known to belong to the RP.
5. The client then delivers the SOAP envelope containing the 5. The client then delivers the SOAP envelope containing the
<Response> to the RP at a location the IdP directs (which acts as <Response> to the RP at a location the IdP directs (which acts as
an additional, though limited, defense against MITM attacks). an additional, though limited, defense against MITM attacks).
This completes the SAML exchange. This completes the SAML exchange.
6. The RP now has sufficient identity information to approve the 6. The RP now has sufficient identity information to approve the
original HTTP request or not, and acts accordingly. Everything original HTTP request or not, and acts accordingly. Everything
between the original request and this response can be thought of between the original request and this response can be thought of
as an "interruption" of the original HTTP exchange. as an "interruption" of the original HTTP exchange.
skipping to change at page 9, line 14 skipping to change at page 10, line 14
4. SAML SASL Mechanism Specification 4. SAML 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" application session initiation, it displays the name "SAML20EC"
and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms and/or "SAML20EC-PLUS" in the list of supported SASL mechanisms (the
(depending on its support for channel binding). latter indicating support for channel binding).
4.2. Initiation 4.2. Initiation
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 is as follows: The format of the initial client response 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"
mutual = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \ mutual = "urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp:2.0:" \
"WantAuthnRequestsSigned" "WantAuthnRequestsSigned"
initial-resp = gs2-cb-flag "," [gs2-authzid] "," [hok] "," [mutual] del = "y"
The gs2-cb-flag MUST be set as defined in [RFC5801] to indicate initial-resp = gs2-cb "," [authzid] "," [hok] "," [mutual] "," [del]
The gs2-cb 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.
The optional "gs2-authzid" field holds the authorization identity, as The optional "authzid" field holds the authorization identity, as
requested by the client. requested by the client.
The optional "hok" field is a constant that signals the client's The optional "hok" field is a constant that signals the client's
support for stronger security by means of a locally held key. This support for stronger security by means of a locally held key. This
takes the place of the PAOS HTTP header extension used in [SAMLECP20] takes the place of the PAOS HTTP header extension used in [SAMLECP20]
to indicate "holder of key" support. to indicate "holder of key" support.
The optional "mutual" field is a constant that signals the client's The optional "mutual" field is a constant that signals the client's
desire for mutual authentication. If set, the SASL server MUST desire for mutual authentication. If set, the SASL server MUST
digitally sign its SAML <AuthnRequest> message. The URN constant digitally sign its SAML <AuthnRequest> message. The URN constant
above is a single string; the linefeed is shown for RFC formatting above is a single string; the linefeed is shown for RFC formatting
reasons. reasons.
The optional "del" field is a constant that signals the client's
desire for the acceptor to request an assertion usable for delegation
of the client's identity to the acceptor.
4.3. Server Response 4.3. Server Response
The SASL server responds with a SOAP envelope constructed in The SASL server responds with a SOAP envelope constructed in
accordance with section 2.3.2 of [SAMLECP20]. This includes adhering accordance with section 2.3.2 of [SAMLECP20]. This includes adhering
to the SOAP header requirements of the SAML PAOS Binding to the SOAP 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. Various SOAP headers are also consumed by the client in profile. Various SOAP headers are also consumed by the client in
exactly the same manner prescribed by that section. exactly the same manner prescribed by that section.
4.4. User Authentication with Identity Provider 4.4. User Authentication with Identity Provider
skipping to change at page 12, line 38 skipping to change at page 13, line 38
If the mutual_state flag is not requested, or is not set, then the If the mutual_state flag is not requested, or is not set, then the
security layer managed by the application outside of the GSS-API security layer managed by the application outside of the GSS-API
mechanism is responsible for authenticating the acceptor. In this mechanism is responsible for authenticating the acceptor. In this
case, applications MUST match the server identity from the existing case, applications MUST match the server identity from the existing
security layer with the target name. For TLS, this matching MUST be security layer with the target name. For TLS, this matching MUST be
performed as discussed in [RFC6125]. For SSH, this matching MUST be performed as discussed in [RFC6125]. For SSH, this matching MUST be
performed as discussed in [RFC4462]. performed as discussed in [RFC4462].
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> of the SAML assertion received by the any, in the <AuthnStatement> element(s) of the SAML assertion(s)
RP. received by the RP. By convention, in the rare case that multiple
valid/confirmed assertions containing <AuthnStatement> elements are
received, the most restrictive SessionNotOnOrAfter is generally
applied.
SAML EC supports credential delegation through the issuance of SAML 5.1. GSS-API Credential Delegation
assertions that the issuing identity provider will accept as proof of
authentication by a service on behalf of a user. Such assertions
MUST contain an <AudienceRestriction> condition element identifying
the identity provider, and a <SubjectConfirmation> element that the
acceptor can satisy. In such a case, the security context may have
its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE.
5.1. GSS-API Channel Binding This mechanism supports credential delegation through the issuance of
SAML assertions that the issuing identity provider will accept as
proof of authentication by a service on behalf of a subject. An
initiator may request delegation of its credentials by setting the
last option field in the initial client response to "y".
An acceptor, upon receipt of this flag, requests a delegated
assertion by including in its <AuthnRequest> message a <Conditions>
element containing an <AudienceRestriction> identifying the IdP as a
desired audience for the assertion(s) to be issued.
Upon receipt of an assertion satisfying this property, and containing
a <SubjectConfirmation> element that the acceptor can satisfy, the
the security context may have its deleg_state flag (GSS_C_DELEG_FLAG)
set to TRUE. The acceptor SHOULD signal failure to the initiator as
the outcome of the exchange if it cannot obtain such a result from
the IdP.
As noted previous, the exact means of client authentication 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
acceptor acting as an initiator. In practice, some profile of
[WSS-SAML] is used to attach the assertion and a confirmation proof
to the SOAP message from the client to the IdP.
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 name for an enclosing channel between the
initiator and acceptor. The initiator sends channel binding data and initiator and acceptor. The initiator sends channel binding data and
the acceptor confirms that channel binding data has been checked. 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.2. 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 identity provider. In other cases such as assertions based on
"holder of key" confirmation bound to a client-controlled key, there "holder of key" confirmation bound to a client-controlled key, there
may be additional methods defined in the future, and extension points may be additional methods defined in the future, and extension points
are provided for this purpose. are provided for this purpose.
skipping to change at page 13, line 42 skipping to change at page 15, line 16
It is omitted to identify the use of an Identity Provider-generated It is omitted to identify the use of an Identity Provider-generated
key (see following section) or will contain a URI value identifying a key (see 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 name of a supported encryption type defined in accordance with the name of a supported encryption type defined in accordance with
[RFC3961]. [RFC3961]. Encryption types should be provided in order of
preference by the acceptor.
In the final client response message, a single <samlec:SessionKey> In the final client response message, a single <samlec:SessionKey>
SOAP header block MUST be included. A single <EncType> element MUST SOAP header block MUST be included. A single <EncType> element MUST
be included to identify the chosen encryption type used by the be included to identify the chosen encryption type used by the
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, defined by [RFC3962]. type, 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.2.1. Generated by Identity Provider 5.3.1. Generated by Identity Provider
The identity provider, if issuing a bearer assertion for use with The identity provider, if issuing a bearer assertion for use with
this mechanism, SHOULD provide a generated key for use by the this mechanism, SHOULD provide a generated key for use by the
initiator and acceptor. This key is used as the protocol key for a initiator and acceptor. This key is used as pseudorandom input to
specific encryption type defined in accordance with [RFC3961]. The the "random-to-key" function for a specific encryption type defined
key is base64-encoded and placed inside a <samlec:GeneratedKey> in accordance with [RFC3961]. The key is base64-encoded and placed
element. The identity provider does not participate in the selection inside a <samlec:GeneratedKey> element. The identity provider does
of the encryption type and simply generates enough pseudorandom bits not participate in the selection of the encryption type and simply
to supply key material to the other parties. generates enough pseudorandom bits to supply key material to the
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. A copy of the element <saml:Advice> element of the assertion issued. The identity provider
is also added as a SOAP header block in the response from the SHOULD encrypt the assertion; if channel binding is not used, the
identity provider to the client. assertion MUST be encrypted. If multiple assertions are issued
(allowed, but not typical), the element need only be included in one
of the assertions issued for use by the relying party.
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
when constructing the response to the acceptor).
If this mechanism is used by the initiator, then the <samlec: If this mechanism is used by the initiator, then the <samlec:
SessionKey> SOAP header block attached to the final client response SessionKey> SOAP header block attached to the final client response
message will identify this via the omission of the Algorithm 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"
S:actor="http://schemas.xmlsoap.org/soap/actor/next"> S:actor="http://schemas.xmlsoap.org/soap/actor/next">
<samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType> <samlec:EncType>aes128-cts-hmac-sha1-96</samlec:EncType>
<samlec:SessionKey> <samlec:SessionKey>
Both the initiator and acceptor MUST execute the chosen encryption Both the initiator and acceptor MUST execute the chosen encryption
type's random-to-key function over the pseudorandom value provided by type's random-to-key function over the pseudorandom value provided by
the <samlec:GeneratedKey> element. The result of that function is the <samlec:GeneratedKey> element. The result of that function is
used as the protocol key. used as the protocol key.
5.2.2. Alternate Key Derivation Mechanisms 5.3.2. Alternate Key Derivation Mechanisms
In the event that a client is proving possession of a secret or In the event that a client is proving possession of a secret or
private key, a formal key agreement algorithm might be supported. private key, a formal key agreement algorithm might be supported.
This specification does not define such a mechanism, but the <samlec: This specification does not define such a mechanism, but the <samlec:
SessionKey> element is extensible to allow for future work in this SessionKey> element is extensible to allow for future work in this
space by means of the Algorithm attribute and an optional <ds: space by means of the Algorithm attribute and an optional <ds:
KeyInfo> child element to carry extensible content related to key KeyInfo> child element to carry extensible content related to key
establishment. establishment.
However a key is derived, the <samlec:EncType> element will identify However a key is derived, the <samlec:EncType> element will identify
the chosen encrytion type, and both the initiator and acceptor MUST the chosen encrytion type, and both the initiator and acceptor MUST
execute the encryption type's random-to-key function over the result execute the encryption type's random-to-key function over the result
of the key agreement or derivation process. The result of that of the key agreement or derivation process. The result of that
function is used as the protocol key. function is used as the protocol key.
5.3. Per-Message Tokens 5.4. Per-Message Tokens
The per-message tokens SHALL be the same as those for the Kerberos V5 The per-message tokens SHALL be the same as those for the Kerberos V5
GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections). GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections).
The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state The replay_det_state (GSS_C_REPLAY_FLAG), sequence_state
(GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail (GSS_C_SEQUENCE_FLAG), conf_avail (GSS_C_CONF_FLAG) and integ_avail
(GSS_C_INTEG_FLAG) security context flags are always set to TRUE. (GSS_C_INTEG_FLAG) security context flags are always set to TRUE.
The "protocol key" SHALL be a key established in a manner described The "protocol key" SHALL be a key established in a manner described
in the previous section. "Specific keys" are then derived as usual in the previous section. "Specific keys" are then derived as usual
as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962]. as described in Section 2 of [RFC4121], [RFC3961], and [RFC3962].
The terms "protocol key" and "specific key" are Kerberos V5 terms The terms "protocol key" and "specific key" are Kerberos V5 terms
[RFC3961]. [RFC3961].
SAML20EC is PROT_READY as soon as the SAML response message has been SAML20EC is PROT_READY as soon as the SAML response message has been
seen. seen.
5.4. Pseudo-Random Function (PRF) 5.5. Pseudo-Random Function (PRF)
The GSS-API has been extended with a Pseudo-Random Function (PRF) The GSS-API has been extended with a Pseudo-Random Function (PRF)
interface in [RFC4401]. The purpose is to enable applications to interface in [RFC4401]. The purpose is to enable applications to
derive a cryptographic key from an established GSS-API security derive a cryptographic key from an established GSS-API security
context. This section defines a GSS_Pseudo_random that is applicable context. This section defines a GSS_Pseudo_random that is applicable
for the SAML20EC GSS-API mechanism. for the SAML20EC GSS-API mechanism.
The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the The GSS_Pseudo_random() [RFC4401] SHALL be the same as for the
Kerberos V5 GSS-API mechanism [RFC4402]. There is no acceptor- Kerberos V5 GSS-API mechanism [RFC4402]. There is no acceptor-
asserted sub-session key, thus GSS_C_PRF_KEY_FULL and asserted sub-session key, thus GSS_C_PRF_KEY_FULL and
GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used GSS_C_PRF_KEY_PARTIAL are equivalent. The protocol key to be used
for the GSS_Pseudo_random() SHALL be the same as the key defined in for the GSS_Pseudo_random() SHALL be the same as the key defined in
the previous section. the previous section.
5.5. GSS-API Principal Name Types for SAML EC 5.6. GSS-API Principal Name Types for SAML EC
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
skipping to change at page 16, line 28 skipping to change at page 18, line 9
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 identity provider, and the information supplied
by the identity provider to the acceptor. These relationships must by the identity provider to the acceptor. These relationships must
be managed through local policy at the initiator and acceptor. be managed through local 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 [I-D.ietf-abfab-gss-eap-naming]. in accordance with [I-D.ietf-abfab-gss-eap-naming].
5.5.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 identity provider, and
supply it to the server for use by the acceptor. supply it to the 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:
skipping to change at page 17, line 17 skipping to change at page 18, line 47
As noted in the previous section, it is expected that most As noted in the previous section, it is expected that most
applications able to rely on SAML authentication would make use of applications able to rely on SAML authentication would make use of
naming extensions to obtain additional information about the user naming extensions to obtain additional information about the user
based on the assertion. This is particularly true in the anonymous based on the assertion. This is particularly true in the anonymous
case, or in cases in which the SAML name is pseudonymous or transient case, or in cases in which the SAML name is pseudonymous or transient
in nature. The ability to express the SAML name in in nature. The ability to express the SAML name in
GSS_C_NT_USER_NAME form is intended for compatibility with GSS_C_NT_USER_NAME form is intended for compatibility with
applications that cannot make use of additional information. applications that cannot make use of additional information.
5.5.2. Service Naming Considerations 5.6.2. Service Naming Considerations
The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running The GSS_C_NT_HOSTBASED_SERVICE name form represents a service running
on a host; it is textually represented as "service@host". This name on a host; it is textually represented as "service@host". This name
form is required by most SASL profiles and is used by many existing form is required by most SASL profiles and is used by many existing
applications that use the Kerberos GSS-API mechanism. Such a name is applications that use the Kerberos GSS-API mechanism. Such a name is
used directly by this mechanism as the effective used directly by this mechanism as the effective
AssertionConsumerService "location" associated with the service. AssertionConsumerService "location" associated with the service.
This value is used in the construction of the responseConsumerURL and This value is used in the construction of the responseConsumerURL and
AssertionConsumerServiceURL attributes, and for eventual comparison AssertionConsumerServiceURL attributes, and for eventual comparison
skipping to change at page 18, line 41 skipping to change at page 20, line 41
<mechanism>PLAIN</mechanism> <mechanism>PLAIN</mechanism>
<mechanism>SAML20EC</mechanism> <mechanism>SAML20EC</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
Step 4: Client selects an authentication mechanism and sends the Step 4: Client selects an authentication mechanism and sends the
initial client response (it is base64 encoded as specified by the initial client response (it is base64 encoded as specified by the
XMPP SASL protocol profile): XMPP SASL protocol profile):
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20EC'> <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='SAML20EC'>
biwsLA== biwsLCw=
</auth> </auth>
The initial response is "n,," which signals that channel binding is The initial response is "n,,,," which signals that channel binding is
not used, there is no authorization identity, and the client does not not used, there is no authorization identity, and the client does not
support key-based confirmation or want mutual authentication. support key-based confirmation, or want mutual authentication or
delegation.
Step 5: Server sends a challenge to client in the form of a SOAP Step 5: Server sends a challenge to client in the form of a SOAP
envelope containing its SAML <AuthnRequest>: envelope containing its SAML <AuthnRequest>:
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT PFM6RW52ZWxvcGUKICAgIHhtbG5zOnNhbWw9InVybjpvYXNpczpuYW1lczp0YzpT
QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h QU1MOjIuMDphc3NlcnRpb24iCiAgICB4bWxuczpzYW1scD0idXJuOm9hc2lzOm5h
bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj bWVzOnRjOlNBTUw6Mi4wOnByb3RvY29sIgogICAgeG1sbnM6Uz0iaHR0cDovL3Nj
aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K aGVtYXMueG1sc29hcC5vcmcvc29hcC9lbnZlbG9wZS8iPgogIDxTOkhlYWRlcj4K
ICAgIDxwYW9zOlJlcXVlc3QgeG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoy ICAgIDxwYW9zOlJlcXVlc3QgeG1sbnM6cGFvcz0idXJuOmxpYmVydHk6cGFvczoy
skipping to change at page 30, line 9 skipping to change at page 32, line 9
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, March 2011. Security (TLS)", RFC 6125, March 2011.
[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 Working Draft OASIS.sstc-saml-ecp- Version 2.0", OASIS Working Draft OASIS.sstc-saml-ecp-
v2.0-wd06, October 2012. v2.0-wd07, April 2013.
[W3C.soap11] [W3C.soap11]
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer, Mendelsohn, N., Nielsen, H., Thatte, S., and D. Winer,
"Simple Object Access Protocol (SOAP) 1.1", W3C "Simple Object Access Protocol (SOAP) 1.1", W3C
Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>. Note soap11, May 2000, <http://www.w3.org/TR/SOAP/>.
9.2. Normative References for GSS-API Implementers 9.2. Normative References for GSS-API Implementers
[I-D.ietf-abfab-gss-eap-naming] [I-D.ietf-abfab-gss-eap-naming]
skipping to change at page 32, line 5 skipping to change at page 33, line 37
[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, June 2006. Windows", RFC 4559, June 2006.
[W3C.REC-xmlschema-1] [W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1, "XML Schema Part 1: Structures", W3C REC-xmlschema-1,
May 2001, <http://www.w3.org/TR/xmlschema-1/>. May 2001, <http://www.w3.org/TR/xmlschema-1/>.
[WSS-SAML]
Monzillo, R., "Web Services Security SAML Token Profile
Version 1.1.1", OASIS Standard OASIS.wss-SAMLTokenProfile,
May 2012.
Appendix A. XML Schema Appendix A. XML Schema
The following schema formally defines the The following schema formally defines the
"urn:ietf:params:xml:ns:samlec" namespace used in this document, in "urn:ietf:params:xml:ns:samlec" namespace used in this document, in
conformance with [W3C.REC-xmlschema-1] While XML validation is conformance with [W3C.REC-xmlschema-1] While XML validation is
optional, the schema that follows is the normative definition of the optional, the schema that follows is the normative definition of the
constructs it defines. Where the schema differs from any prose in constructs it defines. Where the schema differs from any prose in
this specification, the schema takes precedence. this specification, the schema takes precedence.
<schema <schema
skipping to change at page 33, line 8 skipping to change at page 35, line 8
<attribute ref="S:actor"/> <attribute ref="S:actor"/>
</extension> </extension>
</simpleContent> </simpleContent>
</complexType> </complexType>
</schema> </schema>
Appendix B. Acknowledgments Appendix B. Acknowledgments
The authors would like to thank Klaas Wierenga, Sam Hartman, Nico The authors would like to thank Klaas Wierenga, Sam Hartman, Nico
Williams, and Jim Basney for their contributions. Williams, Jim Basney, and Venkat Yekkirala 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 07, editorial changes, expanded section on delegation, multiple
assertion clarifications
o 06, simplified session key schema, moved responsibility for o 06, simplified session key schema, moved responsibility for
random-to-key to the endpoints, and defined advertisement of random-to-key to the endpoints, and defined advertisement of
session key algorithm and enctypes by acceptor session key algorithm and enctypes by acceptor
o 05, revised session key material, added requirement for random-to- o 05, revised session key material, added requirement for random-to-
key, revised XML schema to capture enctype name, updated GSS key, revised XML schema to capture enctype name, updated GSS
naming reference naming reference
o 04, stripped down the session key material to simplify it, and o 04, stripped down the session key material to simplify it, and
define an IdP-brokered keying approach, moved session key XML define an IdP-brokered keying approach, moved session key XML
 End of changes. 34 change blocks. 
88 lines changed or deleted 134 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/