< draft-ietf-abfab-arch-11.txt		draft-ietf-abfab-arch-12.txt >
	ABFAB J. Howlett		ABFAB J. Howlett
	Internet-Draft JANET(UK)		Internet-Draft JANET(UK)
	Intended status: Informational S. Hartman		Intended status: Informational S. Hartman
	Expires: August 15, 2014 Painless Security		Expires: August 17, 2014 Painless Security
	H. Tschofenig		H. Tschofenig
	Nokia Siemens Networks		ARM Ltd.
	E. Lear		E. Lear
	Cisco Systems GmbH		Cisco Systems GmbH
	J. Schaad		J. Schaad
	Soaring Hawk Consulting		Soaring Hawk Consulting
	February 11, 2014		February 13, 2014
	Application Bridging for Federated Access Beyond Web (ABFAB)		Application Bridging for Federated Access Beyond Web (ABFAB)
	Architecture		Architecture
	draft-ietf-abfab-arch-11.txt		draft-ietf-abfab-arch-12.txt
	Abstract		Abstract
	Over the last decade a substantial amount of work has occurred in the		Over the last decade a substantial amount of work has occurred in the
	space of federated access management. Most of this effort has		space of federated access management. Most of this effort has
	focused on two use cases: network access and web-based access.		focused on two use cases: network access and web-based access.
	However, the solutions to these use cases that have been proposed and		However, the solutions to these use cases that have been proposed and
	deployed tend to have few building blocks in common.		deployed tend to have few building blocks in common.
	This memo describes an architecture that makes use of extensions to		This memo describes an architecture that makes use of extensions to
	skipping to change at page 2, line 7 ¶		skipping to change at page 2, line 7 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on August 15, 2014.		This Internet-Draft will expire on August 17, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2014 IETF Trust and the persons identified as the		Copyright (c) 2014 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 20, line 51 ¶		skipping to change at page 20, line 51 ¶
	For the AAA framework there are two different places where security		For the AAA framework there are two different places where security
	needs to be examined. The first is the security that is in place for		needs to be examined. The first is the security that is in place for
	the links in the AAA backbone being used. The second are the nodes		the links in the AAA backbone being used. The second are the nodes
	that form the AAA backbone.		that form the AAA backbone.
	The default link security for RADIUS is showing its age as it uses		The default link security for RADIUS is showing its age as it uses
	MD5 and a shared secret to both obfuscate passwords and to provide		MD5 and a shared secret to both obfuscate passwords and to provide
	integrity on the RADIUS messages. While some EAP methods include the		integrity on the RADIUS messages. While some EAP methods include the
	ability to protect the client authentication credentials, the MSK		ability to protect the client authentication credentials, the MSK
	returned from the IDP to the RP is protected only by the RADIUS		returned from the IdP to the RP is protected only by the RADIUS
	security. In many environments this is considered to be		security. In many environments this is considered to be
	insufficient, especially as not all attributes are obfuscated and can		insufficient, especially as not all attributes are obfuscated and can
	thus leak information to a passive eavesdropper. The use of RADIUS		thus leak information to a passive eavesdropper. The use of RADIUS
	with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls] addresses these		with TLS [RFC6614] and/or DTLS [I-D.ietf-radext-dtls] addresses these
	attacks. The same level of security is included in the base Diameter		attacks. The same level of security is included in the base Diameter
	specifications.		specifications.
	2.1.5. SAML Assertions		2.1.5. SAML Assertions
	For the traditional use of AAA frameworks, network access, the only		For the traditional use of AAA frameworks, network access, the only
	skipping to change at page 32, line 27 ¶		skipping to change at page 32, line 27 ¶
	information needs to be part of the validation process. If one has		information needs to be part of the validation process. If one has
	just a host name and not a port in the information being validated,		just a host name and not a port in the information being validated,
	then this is not going to be a successful strategy.		then this is not going to be a successful strategy.
	3.4. Additional GSS-API Services		3.4. Additional GSS-API Services
	GSS-API provides per-message security services that can provide		GSS-API provides per-message security services that can provide
	confidentiality and/or integrity. Some IETF protocols such as NFS		confidentiality and/or integrity. Some IETF protocols such as NFS
	and SSH take advantage of these services. As a result GSS-EAP needs		and SSH take advantage of these services. As a result GSS-EAP needs
	to support these services. As with mutual authentication, per-		to support these services. As with mutual authentication, per-
	message services will limit the set of EAP methods that can be used		message security services will limit the set of EAP methods that can
	to those that generate a Master Session Key (MSK). Any EAP method		be used to those that generate a Master Session Key (MSK). Any EAP
	that produces an MSK is able to support per-message security services		method that produces an MSK is able to support per-message security
	described in [RFC2743].		services described in [RFC2743].
	GSS-API provides a pseudo-random function. This function generates a		GSS-API provides a pseudo-random function. This function generates a
	pseudo-random sequence using the shared session key as the seed for		pseudo-random sequence using the shared session key as the seed for
	the bytes generated. This provides an algorithm that both the		the bytes generated. This provides an algorithm that both the
	initiator and acceptor can run in order to arrive at the same key		initiator and acceptor can run in order to arrive at the same key
	value. The use of this feature allows for an application to generate		value. The use of this feature allows for an application to generate
	keys or other shared secrets for use in other places in the protocol.		keys or other shared secrets for use in other places in the protocol.
	In this regards, it is similar in concept to the TLS extractor (RFC		In this regards, it is similar in concept to the TLS extractor (RFC
	5705 [RFC5705].). While no current IETF protocols require this, non-		5705 [RFC5705].). While no current IETF protocols require this, non-
	IETF protocols are expected to take advantage of this in the near		IETF protocols are expected to take advantage of this in the near
	skipping to change at page 36, line 40 ¶		skipping to change at page 36, line 40 ¶
	that has access to the EAP MSK is able to decrypt and eavesdrop on		that has access to the EAP MSK is able to decrypt and eavesdrop on
	any traffic encrypted using that EAP MSK (i.e., all communications		any traffic encrypted using that EAP MSK (i.e., all communications
	between the Client and RP). This problem can be mitigted by the		between the Client and RP). This problem can be mitigted by the
	application protocol setting up a secure tunnel between the Client		application protocol setting up a secure tunnel between the Client
	and the RP and performing a cryptographic binding between the		and the RP and performing a cryptographic binding between the
	tunnel and EAP MSK.		tunnel and EAP MSK.
	o Related to the above, the AAA server has access to the material		o Related to the above, the AAA server has access to the material
	necessary to derive the session key, thus the AAA server can		necessary to derive the session key, thus the AAA server can
	observe any traffic encrypted between the Client and RP. This		observe any traffic encrypted between the Client and RP. This
	"feature" was" chosen as a simplification and to make performance		"feature" was chosen as a simplification and to make performance
	faster; if it was decided that this trade-off was not desirable		faster; if it was decided that this trade-off was not desirable
	for privacy and security reasons, then extensions to ABFAB that		for privacy and security reasons, then extensions to ABFAB that
	make use of techniques such as Diffie-Helman key exchange would		make use of techniques such as Diffie-Helman key exchange would
	mitigate against this.		mitigate against this.
	The choice of EAP method used has other potential privacy		The choice of EAP method used has other potential privacy
	implications. For example, if the EAP method in use does not support		implications. For example, if the EAP method in use does not support
	trust anchors to enable mutual authentication, then there are no		trust anchors to enable mutual authentication, then there are no
	guarantees that the IdP is who it claims to be, and thus the full NAI		guarantees that the IdP is who it claims to be, and thus the full NAI
	including a username and a realm might be sent to any entity		including a username and a realm might be sent to any entity
	skipping to change at page 39, line 34 ¶		skipping to change at page 39, line 34 ¶
	order to prevent attacks, this is a hard problem in general and is		order to prevent attacks, this is a hard problem in general and is
	going to be even harder for kiosk environments.		going to be even harder for kiosk environments.
	Selection of the EAP methods to be permitted by clients and IdPs is		Selection of the EAP methods to be permitted by clients and IdPs is
	important. The use of a tunneling method such as TEAP		important. The use of a tunneling method such as TEAP
	[I-D.ietf-emu-eap-tunnel-method] allows for other EAP methods to be		[I-D.ietf-emu-eap-tunnel-method] allows for other EAP methods to be
	used while hiding the contents of those EAP exchanges from the RP and		used while hiding the contents of those EAP exchanges from the RP and
	the AAA framework. When considering inner EAP methods the		the AAA framework. When considering inner EAP methods the
	considerations outlined in [RFC7029] about binding the inner and		considerations outlined in [RFC7029] about binding the inner and
	outer EAP methods needs to be considered. Finally, one wants to have		outer EAP methods needs to be considered. Finally, one wants to have
	the ability to support channel binding those cses where the client		the ability to support channel binding in those cases where the
	needs to validate it is talking to the correct RP.		client needs to validate that it is talking to the correct RP.
	In those places where SAML statements are used, RPs will generally be		In those places where SAML statements are used, RPs will generally be
	unable to validate signatures on the SAML statement, either because		unable to validate signatures on the SAML statement, either because
	it is stripped off by the IdP or because it is unable to validate the		it is stripped off by the IdP or because it is unable to validate the
	binding between the signer, the key used to sign and the realm		binding between the signer, the key used to sign and the realm
	represented by the IdP. For these reasons it is required that IdPs		represented by the IdP. For these reasons it is required that IdPs
	do the necessary trust checking on the SAML statements and RPs can		do the necessary trust checking on the SAML statements and RPs can
	trust the AAA infrastructure to keep the SAML statement valid.		trust the AAA infrastructure to keep the SAML statement valid.
	When a pseudonym is generated as a unique long term identifier for a		When a pseudonym is generated as a unique long term identifier for a
	skipping to change at page 43, line 42 ¶		skipping to change at page 43, line 42 ¶
	8.3. URIs		8.3. URIs
	[1] http://www.openid.net		[1] http://www.openid.net
	[2] https://community.ja.net/system/files/288/Trust-Router-Overview-		[2] https://community.ja.net/system/files/288/Trust-Router-Overview-
	IETF86.pptx		IETF86.pptx
	[3] https://commmunity.ja.net/system/files/288/Trust-Router-Overview-		[3] https://commmunity.ja.net/system/files/288/Trust-Router-Overview-
	IETF86.pptx		IETF86.pptx
	[4] http://www.eduroam.org		[4] https://www.eduroam.org
	Editorial Comments		Editorial Comments
	[CREF1] JLS: Should this be an EAP failure to the client as well?		[CREF1] JLS: Should this be an EAP failure to the client as well?
	Authors' Addresses		Authors' Addresses
	Josh Howlett		Josh Howlett
	JANET(UK)		JANET(UK)
	Lumen House, Library Avenue, Harwell		Lumen House, Library Avenue, Harwell
	Oxford OX11 0SG		Oxford OX11 0SG
	skipping to change at page 44, line 19 ¶		skipping to change at page 44, line 19 ¶
	Phone: +44 1235 822363		Phone: +44 1235 822363
	Email: Josh.Howlett@ja.net		Email: Josh.Howlett@ja.net
	Sam Hartman		Sam Hartman
	Painless Security		Painless Security
	Email: hartmans-ietf@mit.edu		Email: hartmans-ietf@mit.edu
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		ARM Ltd.
	Linnoitustie 6		110 Fulbourn Rd
	Espoo 02600		Cambridge CB1 9NJ
	Finland		Great Britain
	Phone: +358 (50) 4871445		Email: Hannes.tschofenig@gmx.net
	Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	Eliot Lear		Eliot Lear
	Cisco Systems GmbH		Cisco Systems GmbH
	Richtistrasse 7		Richtistrasse 7
	Wallisellen, ZH CH-8304		Wallisellen, ZH CH-8304
	Switzerland		Switzerland
	Phone: +41 44 878 9200		Phone: +41 44 878 9200
	Email: lear@cisco.com		Email: lear@cisco.com
End of changes. 12 change blocks.
	20 lines changed or deleted		19 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/