< draft-ietf-abfab-aaa-saml-12.txt		draft-ietf-abfab-aaa-saml-13.txt >
	ABFAB J. Howlett		ABFAB J. Howlett
	Internet-Draft Janet		Internet-Draft Janet
	Intended status: Informational S. Hartman		Intended status: Standards Track S. Hartman
	Expires: April 21, 2016 Painless Security		Expires: June 16, 2016 Painless Security
	A. Perez-Mendez, Ed.		A. Perez-Mendez, Ed.
	University of Murcia		University of Murcia
	October 19, 2015		December 14, 2015
	A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and		A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and
	Confirmation Methods for SAML		Confirmation Methods for SAML
	draft-ietf-abfab-aaa-saml-12		draft-ietf-abfab-aaa-saml-13
	Abstract		Abstract
	This document describes the use of the Security Assertion Mark-up		This document describes the use of the Security Assertion Mark-up
	Language (SAML) with RADIUS in the context of the ABFAB architecture.		Language (SAML) with RADIUS in the context of the ABFAB architecture.
	It defines two RADIUS attributes, a SAML binding, a SAML name		It defines two RADIUS attributes, a SAML binding, a SAML name
	identifier format, two SAML profiles, and two SAML confirmation		identifier format, two SAML profiles, and two SAML confirmation
	methods. The RADIUS attributes permit encapsulation of SAML		methods. The RADIUS attributes permit encapsulation of SAML
	assertions and protocol messages within RADIUS, allowing SAML		assertions and protocol messages within RADIUS, allowing SAML
	entities to communicate using the binding. The two profiles describe		entities to communicate using the binding. The two profiles describe
	the application of this binding for ABFAB authentication and		the application of this binding for ABFAB authentication and
	assertion query/request, enabling a Relying Party to request		assertion query/request, enabling a Relying Party to request
	authentication of, or assertions for, users or machines (Clients).		authentication of, or assertions for, users or machines (Clients).
	These Clients may be named using a NAI name identifier format.		These Clients may be named using a NAI name identifier format.
	Finally, the subject confirmation methods allow requests and queries		Finally, the subject confirmation methods allow requests and queries
	to be issued for a previously authenticated user or machine without		to be issued for a previously authenticated user or machine without
	needing to explicitly identify them as the subject. These artifacts		needing to explicitly identify them as the subject. The use of the
	have been defined to permit application in AAA scenarios other than		artifacts defined in this document is not exclusive to ABFAB. They
	ABFAB, such as network access.		can be applied in any AAA scenario, such as the network access
			control.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at 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 June 16, 2016.
	This Internet-Draft will expire on April 21, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2015 IETF Trust and the persons identified as the		Copyright (c) 2015 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 3, line 34 ¶		skipping to change at page 3, line 37 ¶
	11.3. Registration of the ABFAB URN Namespace . . . . . . . . 25		11.3. Registration of the ABFAB URN Namespace . . . . . . . . 25
	12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25		13. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	13.1. Normative References . . . . . . . . . . . . . . . . . . 25		13.1. Normative References . . . . . . . . . . . . . . . . . . 25
	13.2. Informative References . . . . . . . . . . . . . . . . . 27		13.2. Informative References . . . . . . . . . . . . . . . . . 27
	Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 29		Appendix A. XML Schema . . . . . . . . . . . . . . . . . . . . . 29
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
	1. Introduction		1. Introduction
	Within the ABFAB architecture [I-D.ietf-abfab-arch] it is often		Within the ABFAB (Application Bridging for Federated Access Beyond
	desirable to convey Security Assertion Mark-up Language (SAML)		web) architecture [I-D.ietf-abfab-arch] it is often desirable to
	assertions and protocol messages.		convey Security Assertion Mark-up Language (SAML) assertions and
			protocol messages.
	SAML typically only considers the use of HTTP-based transports, known		SAML typically only considers the use of HTTP-based transports, known
	as bindings [OASIS.saml-bindings-2.0-os], which are primarily		as bindings [OASIS.saml-bindings-2.0-os], which are primarily
	intended for use with the SAML V2.0 Web Browser Single Sign-On		intended for use with the SAML V2.0 Web Browser Single Sign-On
	Profile [OASIS.saml-profiles-2.0-os]. However the goal of ABFAB is		Profile [OASIS.saml-profiles-2.0-os]. However the goal of ABFAB is
	to extend the applicability of federated identity beyond the Web to		to extend the applicability of federated identity beyond the Web to
	other applications by building on the AAA framework. Consequently		other applications by building on the AAA framework. Consequently
	there exists a requirement for SAML to integrate with the AAA		there exists a requirement for SAML to integrate with the AAA
	framework and protocols such as RADIUS [RFC2865] and Diameter		framework and protocols such as RADIUS [RFC2865] and Diameter
	[RFC3588], in addition to HTTP.		[RFC6733], in addition to HTTP.
	In summary this document specifies:		In summary this document specifies:
	o Two RADIUS attributes to encapsulate SAML assertions and protocol		o Two RADIUS attributes to encapsulate SAML assertions and protocol
	messages respectively.		messages respectively.
	o A SAML RADIUS binding that defines how SAML assertions and		o A SAML RADIUS binding that defines how SAML assertions and
	protocol messages can be transported by RADIUS within a SAML		protocol messages can be transported by RADIUS within a SAML
	exchange.		exchange.
	skipping to change at page 4, line 43 ¶		skipping to change at page 4, line 46 ¶
	o A reference to previously defined bindings or profiles that the		o A reference to previously defined bindings or profiles that the
	new binding updates or obsoletes.		new binding updates or obsoletes.
	o In the case of a profile, any SAML confirmation method identifiers		o In the case of a profile, any SAML confirmation method identifiers
	defined and/or utilized by the profile.		defined and/or utilized by the profile.
	1.1. Terminology		1.1. Terminology
	This document uses terminology from a number of related standards,		This document uses terminology from a number of related standards,
	which tend to addopt different terms for similar or identical		which tend to adopt different terms for similar or identical
	concepts. In general the document uses, when possible, the ABFAB		concepts. In general the document uses, when possible, the ABFAB
	term for the entity, as described in [I-D.ietf-abfab-arch]. For		term for the entity, as described in [I-D.ietf-abfab-arch]. For
	reference we include this table which maps the different terms into a		reference we include this table which maps the different terms into a
	single view.		single view.
	+----------+-----------+------------------+-------------------+		+----------+-----------+------------------+-------------------+
	| Protocol | Client | Relying Party | Identity Provider |		| Protocol | Client | Relying Party | Identity Provider |
	+----------+-----------+------------------+-------------------+		+----------+-----------+------------------+-------------------+
	| ABFAB | Client | Relying Party | Identity Provider |		| ABFAB | Client | Relying Party | Identity Provider |
	| | | | |		| | | | |
	skipping to change at page 7, line 33 ¶		skipping to change at page 7, line 33 ¶
	4.1. Required Information		4.1. Required Information
	Identification: urn:ietf:params:abfab:bindings:radius		Identification: urn:ietf:params:abfab:bindings:radius
	Contact information: iesg@ietf.org		Contact information: iesg@ietf.org
	Updates: None.		Updates: None.
	4.2. Operation		4.2. Operation
	RADIUS can be used over multiple underlying transports. It is		In this specification, the Relying Party MUST trust any statement in
	REQUIRED that the RADIUS exchange is protected using TLS encryption		the SAML messages from the IdP in the same way that it trusts
	for RADIUS [RFC6614] to provide confidentiality and integrity		information contained in RADIUS attributes. These entities MUST
	protection, unless alternative methods are used to ensure		trust the RADIUS infrastructure to provide integrity of the SAML
	confidentiality, such as IPSEC tunnels or a sufficiently secure		messages.
	internal network.
			Hence, it is REQUIRED that the RADIUS exchange is protected using TLS
			encryption for RADIUS [RFC6614] to provide confidentiality and
			integrity protection, unless alternative methods to ensure them are
			used, such as IPSEC tunnels or a sufficiently secure internal
			network.
	Implementations of this profile can take advantage of mechanisms to		Implementations of this profile can take advantage of mechanisms to
	permit the transport of longer SAML messages over RADIUS transports,		permit the transport of longer SAML messages over RADIUS transports,
	such as the Support of fragmentation of RADIUS packets [RFC7499] or		such as the Support of fragmentation of RADIUS packets [RFC7499] or
	Larger Packets for RADIUS over TCP [I-D.ietf-radext-bigger-packets].		Larger Packets for RADIUS over TCP [I-D.ietf-radext-bigger-packets].
	There are two system models for the use of SAML over RADIUS. The		There are two system models for the use of SAML over RADIUS. The
	first is a request-response model, using the RADIUS SAML-Protocol		first is a request-response model, using the RADIUS SAML-Protocol
	attribute defined in Section 3 to encapsulate the SAML protocol		attribute defined in Section 3 to encapsulate the SAML protocol
	messages.		messages.
	skipping to change at page 14, line 34 ¶		skipping to change at page 14, line 34 ¶
	Contact information: iesg@ietf.org		Contact information: iesg@ietf.org
	SAML Confirmation Method Identifiers: The SAML V2.0 "RADIUS State"		SAML Confirmation Method Identifiers: The SAML V2.0 "RADIUS State"
	confirmation method identifiers, either urn:ietf:params:abfab:cm:user		confirmation method identifiers, either urn:ietf:params:abfab:cm:user
	or urn:ietf:params:abfab:cm:machine, are used by this profile.		or urn:ietf:params:abfab:cm:machine, are used by this profile.
	Updates: None.		Updates: None.
	7.2. Profile Overview		7.2. Profile Overview
	To implement this scenario, a profile of the SAML Authentication		To implement this scenario, this profile of the SAML Authentication
	Request protocol is used in conjunction with the SAML RADIUS binding		Request protocol MUST be used in conjunction with the SAML RADIUS
	defined in Section 4.		binding defined in Section 4.
	This profile is based on the SAML V2.0 Web Browser Single Sign-On		This profile is based on the SAML V2.0 Web Browser Single Sign-On
	Profile [OASIS.saml-profiles-2.0-os]. There are some important		Profile [OASIS.saml-profiles-2.0-os]. There are some important
	differences, specifically:		differences, specifically:
	Authentication: This profile does not require the use of any		Authentication: This profile does not require the use of any
	particular authentication method. The ABFAB architecture does		particular authentication method. The ABFAB architecture does
	require the use of EAP [RFC3579], but this specification may be		require the use of EAP [RFC3579], but this specification may be
	used in other non-ABFAB scenarios.		used in other non-ABFAB scenarios.
	skipping to change at page 16, line 15 ¶		skipping to change at page 16, line 15 ¶
	3. Identity Provider identifies Client (Section 7.3.3). In step 3,		3. Identity Provider identifies Client (Section 7.3.3). In step 3,
	the Client is authenticated and identified by the Identity		the Client is authenticated and identified by the Identity
	Provider, while honoring any requirements imposed by the Relying		Provider, while honoring any requirements imposed by the Relying
	Party in the <samlp:AuthnRequest> message if provided.		Party in the <samlp:AuthnRequest> message if provided.
	4. Identity Provider issues <samlp:Response> to Relying Party		4. Identity Provider issues <samlp:Response> to Relying Party
	(Section 7.3.4). In step 4, the Identity Provider issues a		(Section 7.3.4). In step 4, the Identity Provider issues a
	<samlp:Response> message to the Relying Party using the SAML		<samlp:Response> message to the Relying Party using the SAML
	RADIUS binding. The response either indicates an error or		RADIUS binding. The response either indicates an error or
	includes a SAML Authentication Statement in exactly one SAML		includes a SAML Authentication Statement in exactly one SAML
	Assertion.		Assertion. If the RP did not send an <samlp:AuthnRequest>, the
			IdP issues an unsolicited <samlp:Assertion>, as described in
			Section 7.4.4.
	5. Relying Party grants or denies access to Client (Section 7.3.5).		5. Relying Party grants or denies access to Client (Section 7.3.5).
	In step 5, having received the response from the Identity		In step 5, having received the response from the Identity
	Provider, the Relying Party can respond to the Client with its		Provider, the Relying Party can respond to the Client with its
	own error, or can establish its own security context for the		own error, or can establish its own security context for the
	Client and return the requested resource.		Client and return the requested resource.
	7.3. Profile Description		7.3. Profile Description
	The ABFAB Authentication Profile is a profile of the SAML V2.0		The ABFAB Authentication Profile is a profile of the SAML V2.0
	skipping to change at page 27, line 18 ¶		skipping to change at page 27, line 18 ¶
	(SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March		(SAML) V2.0", OASIS Standard saml-metadata-2.0-os, March
	2005.		2005.
	13.2. Informative References		13.2. Informative References
	[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An		[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An
	IETF URN Sub-namespace for Registered Protocol		IETF URN Sub-namespace for Registered Protocol
	Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June		Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June
	2003, <http://www.rfc-editor.org/info/rfc3553>.		2003, <http://www.rfc-editor.org/info/rfc3553>.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.		[RFC6733] Fajardo, V., Ed., Arkko, J., Loughney, J., and G. Zorn,
	Arkko, "Diameter Base Protocol", RFC 3588,		Ed., "Diameter Base Protocol", RFC 6733,
	DOI 10.17487/RFC3588, September 2003,		DOI 10.17487/RFC6733, October 2012,
	<http://www.rfc-editor.org/info/rfc3588>.		<http://www.rfc-editor.org/info/rfc6733>.
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<http://www.rfc-editor.org/info/rfc5226>.		<http://www.rfc-editor.org/info/rfc5226>.
	[RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for		[RFC7055] Hartman, S., Ed. and J. Howlett, "A GSS-API Mechanism for
	the Extensible Authentication Protocol", RFC 7055,		the Extensible Authentication Protocol", RFC 7055,
	DOI 10.17487/RFC7055, December 2013,		DOI 10.17487/RFC7055, December 2013,
	<http://www.rfc-editor.org/info/rfc7055>.		<http://www.rfc-editor.org/info/rfc7055>.
	skipping to change at page 27, line 47 ¶		skipping to change at page 27, line 47 ¶
	<http://www.rfc-editor.org/info/rfc7499>.		<http://www.rfc-editor.org/info/rfc7499>.
	[I-D.ietf-abfab-arch]		[I-D.ietf-abfab-arch]
	Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.		Howlett, J., Hartman, S., Tschofenig, H., Lear, E., and J.
	Schaad, "Application Bridging for Federated Access Beyond		Schaad, "Application Bridging for Federated Access Beyond
	Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work		Web (ABFAB) Architecture", draft-ietf-abfab-arch-13 (work
	in progress), July 2014.		in progress), July 2014.
	[I-D.ietf-radext-bigger-packets]		[I-D.ietf-radext-bigger-packets]
	Hartman, S., "Larger Packets for RADIUS over TCP", draft-		Hartman, S., "Larger Packets for RADIUS over TCP", draft-
	ietf-radext-bigger-packets-03 (work in progress), March		ietf-radext-bigger-packets-05 (work in progress), December
	2015.		2015.
	[W3C.REC-xmlschema-1]		[W3C.REC-xmlschema-1]
	Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,		Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
	"XML Schema Part 1: Structures", W3C REC-xmlschema-1, May		"XML Schema Part 1: Structures", W3C REC-xmlschema-1, May
	2001, <http://www.w3.org/TR/xmlschema-1/>.		2001, <http://www.w3.org/TR/xmlschema-1/>.
	Appendix A. XML Schema		Appendix A. XML Schema
	The following schema formally defines the		The following schema formally defines the
End of changes. 13 change blocks.
	29 lines changed or deleted		37 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/