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/