draft-ietf-kitten-sasl-saml-ec-03.txt   draft-ietf-kitten-sasl-saml-ec-04.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: March 21, 2013 SJD AB Expires: April 20, 2013 SJD AB
September 17, 2012 October 17, 2012
SAML Enhanced Client SASL and GSS-API Mechanisms SAML Enhanced Client SASL and GSS-API Mechanisms
draft-ietf-kitten-sasl-saml-ec-03.txt draft-ietf-kitten-sasl-saml-ec-04.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 March 21, 2013. This Internet-Draft will expire on April 20, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 26 skipping to change at page 2, line 26
3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 6 3. Applicability for Non-HTTP Use Cases . . . . . . . . . . . . . 6
4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9 4. SAML SASL Mechanism Specification . . . . . . . . . . . . . . 9
4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9 4.1. Advertisement . . . . . . . . . . . . . . . . . . . . . . 9
4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. Initiation . . . . . . . . . . . . . . . . . . . . . . . . 9
4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10 4.3. Server Response . . . . . . . . . . . . . . . . . . . . . 10
4.4. User Authentication with Identity Provider . . . . . . . . 10 4.4. User Authentication with Identity Provider . . . . . . . . 10
4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10 4.5. Client Response . . . . . . . . . . . . . . . . . . . . . 10
4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10 4.7. Additional Notes . . . . . . . . . . . . . . . . . . . . . 10
5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12 5. SAML EC GSS-API Mechanism Specification . . . . . . . . . . . 12
5.1. Session Key Derivation . . . . . . . . . . . . . . . . . . 12 5.1. GSS-API Channel Binding . . . . . . . . . . . . . . . . . 12
5.1.1. TLS-Exported Session Keys . . . . . . . . . . . . . . 13 5.2. Session Key Derivation . . . . . . . . . . . . . . . . . . 13
5.1.2. Bearer Assertion Session Keys . . . . . . . . . . . . 14 5.2.1. Generated by Identity Provider . . . . . . . . . . . . 13
5.1.3. Holder of Key Session Keys . . . . . . . . . . . . . . 14 5.2.2. Derived Session Keys . . . . . . . . . . . . . . . . . 14
5.2. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 15 5.3. Per-Message Tokens . . . . . . . . . . . . . . . . . . . . 14
5.3. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15 5.4. Pseudo-Random Function (PRF) . . . . . . . . . . . . . . . 15
5.4. GSS-API Principal Name Types for SAML EC . . . . . . . . . 16 5.5. GSS-API Principal Name Types for SAML EC . . . . . . . . . 15
5.4.1. User Naming Considerations . . . . . . . . . . . . . . 16 5.5.1. User Naming Considerations . . . . . . . . . . . . . . 16
5.4.2. Service Naming Considerations . . . . . . . . . . . . 17 5.5.2. Service Naming Considerations . . . . . . . . . . . . 16
6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26
7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 25 7.1. Risks Left Unaddressed . . . . . . . . . . . . . . . . . . 26
7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 25 7.2. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 26
7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 26 7.3. Collusion between RPs . . . . . . . . . . . . . . . . . . 27
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8.1. GSS-API and SASL Mechanism Registration . . . . . . . . . 28
9.1. Normative References . . . . . . . . . . . . . . . . . . . 28 8.2. XML Namespace Name for SAML-EC . . . . . . . . . . . . . . 28
9.2. Normative References for GSS-API Implementers . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.3. Informative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . . 29
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 31 9.2. Normative References for GSS-API Implementers . . . . . . 30
Appendix B. Changes . . . . . . . . . . . . . . . . . . . . . . . 32 9.3. Informative References . . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Appendix A. Appendix A. XML Schema . . . . . . . . . . . . . . . 32
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 34
Appendix C. Changes . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
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 12, line 14 skipping to change at page 12, line 14
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 SASL Enhanced Clients mechanism is also a GSS-API mechanism. The SAML SASL Enhanced Clients mechanism is also a GSS-API mechanism.
The messages are the same, but a) the GS2 header on the client's The messages are the same, but a) the GS2 header on the client's
first message is excluded when SAML EC is used as a GSS-API first message is excluded when SAML EC is used as a GSS-API
mechanism, and b) the RFC2743 section 3.1 initial context token mechanism, and b) the [RFC2743] section 3.1 initial context token
header is prefixed to the client's first authentication message header is prefixed to the client's first authentication message
(context token). (context token).
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 "mutual-auth" option set in the initial client resulting in the "mutual-auth" option set in the initial client
response. The security context mutual_state flag is set to TRUE only response. The security context mutual_state flag is set to TRUE only
if the server digitally signs its SAML <AuthnRequest> message, and if the server digitally signs its SAML <AuthnRequest> message, and
skipping to change at page 12, line 49 skipping to change at page 12, line 49
RP. RP.
SAML EC supports credential delegation through the issuance of SAML SAML EC supports credential delegation through the issuance of SAML
assertions that the issuing identity provider will accept as proof of assertions that the issuing identity provider will accept as proof of
authentication by a service on behalf of a user. Such assertions authentication by a service on behalf of a user. Such assertions
MUST contain an <AudienceRestriction> condition element identifying MUST contain an <AudienceRestriction> condition element identifying
the identity provider, and a <SubjectConfirmation> element that the the identity provider, and a <SubjectConfirmation> element that the
acceptor can satisy. In such a case, the security context will have acceptor can satisy. In such a case, the security context will have
its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE. its deleg_state flag (GSS_C_DELEG_FLAG) set to TRUE.
5.1. Session Key Derivation 5.1. GSS-API Channel Binding
Some GSS-API features (discussed in the following sections) require a GSS-API channel binding [RFC5554] is a protected facility for
session key be established as a result security context exchanging a cryptographic name for an enclosing channel between the
establishment. In the common case of a "bearer" assertion in SAML, initiator and acceptor. The initiator sends channel binding data and
there is no secure mechanism by which such a key can be established the acceptor confirms that channel binding data has been checked.
other than by exporting key material from TLS (discussed below). In
other cases such as assertions based on "holder of key" confirmation,
there may be additional methods available.
Information defining or describing the session key, or a process for The acceptor SHOULD accept any channel binding provided by the
deriving one, is communicated by the client to the server using an initiator if null channel bindings are passed into
<ecp:SessionKey> SOAP header block, as defined in [SAMLECP20]. This gss_accept_sec_context. Protocols such as HTTP Negotiate [RFC4559]
header contains a <ds:KeyInfo> element as a generic container, and is depend on this behavior of some Kerberos implementations.
designed to support reuse of mechanisms defined by [XMLENC11] or
other specifications.
5.1.1. TLS-Exported Session Keys The exchange and verification of channel binding information is
described by [SAMLECP20].
If a TLS session is established between the initiator and acceptor, 5.2. Session Key Derivation
it may be used to produce a session key using the mechanism defined
by [RFC5705]. The disambiguating label string MUST be set to
"EXPORTER_SAML20EC". [Remove upon publication, IANA to assign at the
following location: http://www.iana.org/assignments/tls-parameters/
tls-parameters.xml#exporter-labels] The per-association context value
MUST be set to a 128-bit pseudorandom value generated by the client.
The pseudorandom octets are then base64- encoded and placed in a
<CipherData> element inside a <ecp:SessionKey> SOAP header block in
the following manner:
<ecp:SessionKey S:mustUnderstand="1" Some GSS-API features (discussed in the following sections) require a
S:actor="http://schemas.xmlsoap.org/soap/actor/next" session key be established as a result of security context
xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" establishment. In the common case of a "bearer" assertion in SAML,
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> there are a pair of approaches defined: exporting key material from
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> TLS and communicating a key to both parties via the identity
<xenc11:DerivedKey xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"> provider. Both are discussed below. In other cases such as
<xenc11:KeyDerivationMethod Algorithm="TBD"> assertions based on "holder of key" confirmation bound to a client-
<xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"> controlled key, there may be additional methods available.
<xenc:CipherValue>h1dqhs+aHxYjYNKiEwzjVg==</xenc:CipherValue>
</xenc:CipherData>
</xenc11:KeyDerivationMethod>
</xenc11:DerivedKey>
</ds:KeyInfo>
</ecp:SessionKey>
The derivation algorithm of TBD (IANA to assign: see IANA Information defining or describing the session key, or a process for
considerations) signifies the TLS-Exported approach described above. deriving one, is communicated using a <samlec:SessionKey> element,
defined in the schema in Appendix A. This element can be used as a
SOAP header block or as an extension within a SAML assertion,
depending on the context of communication. The content of the
element further depends on the specific use in the mechanism and is
discussed below.
5.1.2. Bearer Assertion Session Keys 5.2.1. Generated by Identity Provider
In the event that a client is not capable of supporting the "holder The identity provider, if issuing a bearer assertion for use with
of key" option (or if other infrastructure components do not do so) this mechanism, SHOULD provide a generated key for use by the
and cannot use a TLS-exported key, but still wishes to make use of a initiator and acceptor. This key is used as the protocol key for a
session key, the client MAY generate a pseudorandom value of 128 bits specific encryption type defined in accordance with [RFC3961]. The
to use as a key. The octets are then base64-encoded and placed in a key is base64-encoded and placed inside a <samlec:GeneratedKey>
<CipherData> element inside a <ecp:SessionKey> SOAP header block in element. The element's Algorithm XML attribute is set to the
the following manner: encryption type name from the registry established by [RFC3961].
<ecp:SessionKey S:mustUnderstand="1" The <samlec:GeneratedKey> element is placed within a <samlec:
S:actor="http://schemas.xmlsoap.org/soap/actor/next" SessionKey> element, and this element is placed within the <saml:
xmlns:ecp="urn:oasis:names:tc:SAML:2.0:profiles:SSO:ecp" Advice> element of the assertion issued. A copy of the element is
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> also added as a SOAP header block in the response from the identity
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> provider to the client.
<xenc11:DerivedKey xmlns:xenc11="http://www.w3.org/2009/xmlenc11#">
<xenc11:KeyDerivationMethod Algorithm="TBD">
<xenc:CipherData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
<xenc:CipherValue>h1dqhs+aHxYjYNKiEwzjVg==</xenc:CipherValue>
</xenc:CipherData>
</xenc11:KeyDerivationMethod>
</xenc11:DerivedKey>
</ds:KeyInfo>
</ecp:SessionKey>
The derivation algorithm of TBD (IANA to assign: see IANA The identity provider is left to determine which encryption type the
considerations) signifies the client-generated approach described parties should use. It is unspecified how the initiator's
above. capabilities are determined in this respect, but the acceptor MAY
indicate the algorithms it supports in its SAML metadata by means of
one or more <SessionKeyMethod> elements in an <samlmd:Extensions>
element, and an identity provider can leverage this information.
Multiple such extension elements may appear, in order of preference
by the acceptor.
Applications that rely on this mechanism do so with the understanding All parties MUST support the "aes128-cts-hmac-sha1-96" encryption
that it is not a secure approach, but merely for compatibility if the type, defined by [RFC3962].
risk is acceptable.
5.1.3. Holder of Key Session Keys 5.2.2. Derived Session Keys
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, the session key can be communicated in a manner that private key, a formal key agreement algorithm may be supported. For
proves its authenticity, or a formal key agreement algorithm may be example, if the server has an elliptic curve public key, the ECDH-ES
supported. For example, if the server has an elliptic curve public key agreement algorithm, as defined in [XMLENC11] may be used.
key, the ECDH-ES key agreement algorithm, as defined in [XMLENC11]
may be used.
If a key agreement or derivation process is not possible, then the
mechanism defined in the previous section can be used, with the added
benefit that the client's request will be strongly authenticated by a
key. However, if channel binding is not used, the generated key
SHOULD be wrapped or transported under the protection of a key
belonging to the server, such as an RSA public key. The <xenc:
EncryptedKey> element and associated key wrap and transport
algorithms (see [XMLENC11]) can be used for this purpose.
Note that this serves no purpose in the bearer case, since if channel In such a case, the initiator communicates to the acceptor what
binding is not used, an attacker can generate its own key, and if it algorithm to use and any inputs to the process using a <SessionKey>
is used, there is no MITM to see the key. SOAP header block containing a <ds:KeyInfo> element, added to the
client response to the acceptor. The <ds:KeyInfo> element will
typically contain an <xenc11:DerivedKey> element conforming to
[XMLENC11]. The <ds:KeyInfo> element may also contain other
extensible content related to key establishment mechanisms defined
elsewhere.
5.2. Per-Message Tokens 5.3. Per-Message Tokens
The per-message tokens SHALL be the same as those for the Kerberos V 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), using GSS-API mechanism [RFC4121] (see Section 4.2 and sub-sections).
the Kerberos V "aes128-cts-hmac-sha1-96" enctype [RFC3962].
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_CONF_FLAG) security context flags are always set to TRUE. (GSS_C_CONF_FLAG) security context flags are always set to TRUE.
The 128-bit session "protocol key" SHALL be a session key established The "protocol key" SHALL be a session key established in a manner
in a manner described in the previous section. "Specific keys" are described in the previous section. "Specific keys" are then derived
then derived as usual as described in Section 2 of [RFC4121], as usual as described in Section 2 of [RFC4121], [RFC3961], and
[RFC3961], and [RFC3962]. [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.3. Pseudo-Random Function (PRF) 5.4. 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 V 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.4. GSS-API Principal Name Types for SAML EC 5.5. 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 38 skipping to change at page 16, line 5
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 expressed to the acceptor using GSS-API naming extensions
[I-D.ietf-kitten-gssapi-naming-exts], in accordance with [I-D.ietf-kitten-gssapi-naming-exts], in accordance with
[I-D.ietf-abfab-gss-eap-naming]. [I-D.ietf-abfab-gss-eap-naming].
5.4.1. User Naming Considerations 5.5.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 28 skipping to change at page 16, line 43
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.4.2. Service Naming Considerations 5.5.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 of the server. AssertionConsumerService of the server.
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 21, line 20 skipping to change at page 21, line 20
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>
</S:Envelope> </S:Envelope>
Step 7: IdP responds to client with a SOAP response containing a SAML Step 7: IdP responds to client with a SOAP response containing a SAML
<Response> containing a short-lived SSO assertion (shown as an <Response> containing a short-lived SSO assertion (shown as an
encrypted variant in the example). encrypted variant in the example). A session key is included in the
assertion and in a header for the client.
<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: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:SessionKey xmlns:samlec="urn:ietf:params:xml:ns:samlec">
<samlec:GeneratedKey Algorithm="aes128-cts-hmac-sha1-96">
3w1wSBKUosRLsU69xGK7dg==
</samlec:GeneratedKey>
</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="2007-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 --> <!-- contents elided, has copy of session key in Advice -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
Step 8: Client sends SOAP envelope containing the SAML <Response> as Step 8: Client sends SOAP envelope containing the SAML <Response> as
a response to the SASL server's challenge: a response to the SASL server's challenge:
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy PFM6RW52ZWxvcGUNCiAgICB4bWxuczpzYW1sPSJ1cm46b2FzaXM6bmFtZXM6dGM6U0FNTDoy
skipping to change at page 23, line 24 skipping to change at page 23, line 47
<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="2007-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 --> <!-- contents elided, has copy of session key in Advice -->
</saml:EncryptedAssertion> </saml:EncryptedAssertion>
</samlp:Response> </samlp:Response>
</S:Body> </S:Body>
</S:Envelope> </S:Envelope>
Step 9: Server informs client of successful authentication: Step 9: Server informs client of successful authentication:
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 9 (alt): Server informs client of failed authentication: Step 9 (alt): Server informs client of failed authentication:
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/> <temporary-auth-failure/>
skipping to change at page 25, line 48 skipping to change at page 26, line 48
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
in the protocol to hide this information from the IdP. It is not a in the protocol to hide this information from the IdP. It is not a
requirement to track the activity, but there is nothing technically requirement to track the activity, but there is nothing technically
that prohibits the collection of this information. SASL servers that prohibits the collection of this information. Servers should be
should be aware that SAML IdPs will track - to some extent - user aware that SAML IdPs will track - to some extent - user access to
access to their services. their services. This exposure extends to the use of session keys
generated by the IdP to secure messages between the parties.
It is also out of scope of the mechanism to determine under what It is also out of scope of the mechanism to determine under what
conditions an IdP will release particular information to a relying conditions an IdP will release particular information to a relying
party, and it is generally unclear in what fashion user consent could party, and it is generally unclear in what fashion user consent could
be established in real time for the release of particular be established in real time for the release of particular
information. The SOAP exchange with the IdP does not preclude such information. The SOAP exchange with the IdP does not preclude such
interaction, but neither does it define that interoperably. interaction, but neither does it define that interoperably.
7.3. Collusion between RPs 7.3. Collusion between RPs
skipping to change at page 27, line 7 skipping to change at page 28, line 7
directed, identity. This allows the IdP to manage opaque, pairwise directed, identity. This allows the IdP to manage opaque, pairwise
identifiers for each user that are specific to each RP. However, identifiers for each user that are specific to each RP. However,
correlation is often possible based on other attributes supplied, and correlation is often possible based on other attributes supplied, and
is generally a topic that is beyond the scope of this mechanism. It is generally a topic that is beyond the scope of this mechanism. It
is sufficient to say that this mechanism does not introduce new is sufficient to say that this mechanism does not introduce new
correlation opportunities over and above the use of SAML in web-based correlation opportunities over and above the use of SAML in web-based
use cases. use cases.
8. IANA Considerations 8. IANA Considerations
8.1. GSS-API and SASL Mechanism Registration
The IANA is requested to assign a new entry for this GSS mechanism in The IANA is requested to assign a new entry for this GSS mechanism in
the sub-registry for SMI Security for Mechanism Codes, whose prefix the sub-registry for SMI Security for Mechanism Codes, whose prefix
is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to is iso.org.dod.internet.security.mechanisms (1.3.6.1.5.5) and to
reference this specification in the registry. reference this specification in the registry.
The IANA is requested to register the following SASL profile: The IANA is requested to register the following SASL profile:
SASL mechanism profiles: SAML20EC and SAML20EC-PLUS SASL mechanism profiles: SAML20EC and SAML20EC-PLUS
Security Considerations: See this document Security Considerations: See this document
Published Specification: See this document Published Specification: See this document
For further information: Contact the authors of this document. For further information: Contact the authors of this document.
Owner/Change controller: the IETF Owner/Change controller: the IETF
Note: None Note: None
The IANA is requested to assign a new entry of "EXPORTER_SAML20EC" in 8.2. XML Namespace Name for SAML-EC
the TLS Parameters Exporter Label Registry.
The IANA is requested to assign two URIs to identify the key A URN sub-namespace for XML constructs introduced by this mechanism
derivation algorithms described in this document for TLS-exported, is defined as follows:
and client-generated session keys.
URI: urn:ietf:params:xml:ns:samlec
Specification: See Appendix A of this document.
Description: This is the XML namespace name for XML constructs
introduced by the SAML Enhanced Client SASL and GSS-API Mechanisms.
Registrant Contact: the IESG
9. References 9. References
9.1. Normative References 9.1. Normative References
[OASIS.saml-bindings-2.0-os] [OASIS.saml-bindings-2.0-os]
Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E. Cantor, S., Hirsch, F., Kemp, J., Philpott, R., and E.
Maler, "Bindings for the OASIS Security Assertion Markup Maler, "Bindings for the OASIS Security Assertion Markup
Language (SAML) V2.0", OASIS Language (SAML) V2.0", OASIS
Standard saml-bindings-2.0-os, March 2005. Standard saml-bindings-2.0-os, March 2005.
skipping to change at page 29, line 9 skipping to change at page 30, 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-wd05, July 2012. v2.0-wd06, October 2012.
[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]
Hartman, S. and J. Howlett, "Name Attributes for the GSS- Hartman, S. and J. Howlett, "Name Attributes for the GSS-
API EAP mechanism", draft-ietf-abfab-gss-eap-naming-04 API EAP mechanism", draft-ietf-abfab-gss-eap-naming-06
(work in progress), August 2012. (work in progress), October 2012.
[I-D.ietf-kitten-gssapi-naming-exts] [I-D.ietf-kitten-gssapi-naming-exts]
Williams, N., Johansson, L., Hartman, S., and S. Williams, N., Johansson, L., Hartman, S., and S.
Josefsson, "GSS-API Naming Extensions", Josefsson, "GSS-API Naming Extensions",
draft-ietf-kitten-gssapi-naming-exts-15 (work in draft-ietf-kitten-gssapi-naming-exts-15 (work in
progress), May 2012. progress), May 2012.
[RFC2743] Linn, J., "Generic Security Service Application Program [RFC2743] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
skipping to change at page 30, line 5 skipping to change at page 31, line 5
July 2005. July 2005.
[RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API [RFC4401] Williams, N., "A Pseudo-Random Function (PRF) API
Extension for the Generic Security Service Application Extension for the Generic Security Service Application
Program Interface (GSS-API)", RFC 4401, February 2006. Program Interface (GSS-API)", RFC 4401, February 2006.
[RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the [RFC4402] Williams, N., "A Pseudo-Random Function (PRF) for the
Kerberos V Generic Security Service Application Program Kerberos V Generic Security Service Application Program
Interface (GSS-API) Mechanism", RFC 4402, February 2006. Interface (GSS-API) Mechanism", RFC 4402, February 2006.
[RFC5705] Rescorla, E., "Keying Material Exporters for Transport [RFC5554] Williams, N., "Clarifications and Extensions to the
Layer Security (TLS)", RFC 5705, March 2010. Generic Security Service Application Program Interface
(GSS-API) for the Use of Channel Bindings", RFC 5554,
May 2009.
[RFC5801] Josefsson, S. and N. Williams, "Using Generic Security [RFC5801] Josefsson, S. and N. Williams, "Using Generic Security
Service Application Program Interface (GSS-API) Mechanisms Service Application Program Interface (GSS-API) Mechanisms
in Simple Authentication and Security Layer (SASL): The in Simple Authentication and Security Layer (SASL): The
GS2 Mechanism Family", RFC 5801, July 2010. GS2 Mechanism Family", RFC 5801, July 2010.
[XMLENC11] [XMLENC11]
Hirsch, F. and T. Roessler, "XML Encryption Syntax and Hirsch, F. and T. Roessler, "XML Encryption Syntax and
Processing Version 1.1", W3C Editor's Draft W3C.xmlenc- Processing Version 1.1", W3C Editor's Draft W3C.xmlenc-
core-11-ed, August 2012. core-11-ed, September 2012.
9.3. Informative References 9.3. 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, (SAML) V2.0", OASIS Standard saml-metadata-2.0-os,
March 2005. March 2005.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
Appendix A. Acknowledgments [RFC4559] Jaganathan, K., Zhu, L., and J. Brezak, "SPNEGO-based
Kerberos and NTLM HTTP Authentication in Microsoft
Windows", RFC 4559, June 2006.
[W3C.REC-xmlschema-1]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures", W3C REC-xmlschema-1,
May 2001, <http://www.w3.org/TR/xmlschema-1/>.
Appendix A. Appendix A. XML Schema
The following schema formally defines the
"urn:ietf:params:xml:ns:samlec" namespace used in this document, in
conformance with [W3C.REC-xmlschema-1] While XML validation is
optional, the schema that follows is the normative definition of the
constructs it defines. Where the schema differs from any prose in
this specification, the schema takes precedence.
<schema
targetNamespace="urn:ietf:params:xml:ns:samlec"
xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:samlec="urn:ietf:params:xml:ns:samlec"
elementFormDefault="unqualified"
attributeFormDefault="unqualified"
blockDefault="substitution"
version="1.0">
<import namespace="http://www.w3.org/2000/09/xmldsig#"/>
<import namespace="http://schemas.xmlsoap.org/soap/envelope/"/>
<element name="SessionKey" type="samlec:SessionKeyType"/>
<complexType name="SessionKeyType">
<choice>
<element ref="samlec:GeneratedKey"/>
<element ref="ds:KeyInfo"/>
</choice>
<attribute ref="S:mustUnderstand"/>
<attribute ref="S:actor"/>
</complexType>
<element name="GeneratedKey" type="samlec:GeneratedKeyType"/>
<complexType name="GeneratedKeyType">
<simpleContent>
<extension base="base64Binary">
<attribute name="Algorithm" type="string" use="required"/>
</extension>
</simpleContent>
</complexType>
<element name="SessionKeyMethod" type="samlec:SessionKeyMethodType"/>
<complexType name="SessionKeyMethodType">
<sequence>
<any namespace="##any" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
</schema>
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, and Jim Basney for their contributions.
Appendix B. Changes Appendix C. Changes
This section to be removed prior to publication. This section to be removed prior to publication.
o 04, stripped down the session key material to simplify it, and
define an IdP-brokered keying approach, moved session key XML
constructs from OASIS draft into this one
o 03, added TLS key export as a session key option, revised GSS o 03, added TLS key export as a session key option, revised GSS
naming material based on list discussion naming material based on list discussion
o 02, major revision of GSS-API material and updated references o 02, major revision of GSS-API material and updated references
o 01, SSH language added, noted non-assumption of HTTP error o 01, SSH language added, noted non-assumption of HTTP error
handling, added guidance on life of security context. handling, added guidance on life of security context.
o 00, Initial Revision, first WG-adopted draft. Removed support for o 00, Initial Revision, first WG-adopted draft. Removed support for
unsolicited SAML responses. unsolicited SAML responses.
 End of changes. 45 change blocks. 
145 lines changed or deleted 206 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/