< draft-ietf-dime-erp-15.txt		draft-ietf-dime-erp-16.txt >
	Network Working Group J. Bournelle		Network Working Group J. Bournelle
	Internet-Draft L. Morand		Internet-Draft L. Morand
	Intended status: Standards Track Orange Labs		Intended status: Standards Track Orange Labs
	Expires: June 13, 2013 S. Decugis		Expires: June 14, 2013 S. Decugis
	INSIDE Secure		INSIDE Secure
	Q. Wu		Q. Wu
	Huawei		Huawei
	G. Zorn		G. Zorn
	Network Zen		Network Zen
	December 10, 2012		December 11, 2012
	Diameter Support for the EAP Re-authentication Protocol (ERP)		Diameter Support for the EAP Re-authentication Protocol (ERP)
	draft-ietf-dime-erp-15.txt		draft-ietf-dime-erp-16.txt
	Abstract		Abstract
	The EAP Re-authentication Protocol (ERP) defines extensions to the		The EAP Re-authentication Protocol (ERP) defines extensions to the
	Extensible Authentication Protocol (EAP) to support efficient re-		Extensible Authentication Protocol (EAP) to support efficient re-
	authentication between the peer and an EAP Re-authentication (ER)		authentication between the peer and an EAP Re-authentication (ER)
	server through a compatible authenticator. This document specifies		server through a compatible authenticator. This document specifies
	Diameter support for ERP. It defines a new Diameter ERP application		Diameter support for ERP. It defines a new Diameter ERP application
	to transport ERP messages between an ER authenticator and the ER		to transport ERP messages between an ER authenticator and the ER
	server, and a set of new AVPs that can be used to transport the		server, and a set of new AVPs that can be used to transport the
	skipping to change at page 1, line 43 ¶		skipping to change at page 1, line 43 ¶
	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 13, 2013.		This Internet-Draft will expire on June 14, 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 37 ¶		skipping to change at page 2, line 37 ¶
	8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12		8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12
	8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12		8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12
	8.3. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . 12		8.3. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.3.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 12		8.3.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 12
	8.3.2. Keying-Material AVP . . . . . . . . . . . . . . . . . 12		8.3.2. Keying-Material AVP . . . . . . . . . . . . . . . . . 12
	8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 13		8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 13
	8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13		8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13
	9. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13		9. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13
	9.1. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13		9.1. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		10.1. Diameter Application Identifier . . . . . . . . . . . . . 13
	12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		10.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13
	12.1. Diameter Application Identifier . . . . . . . . . . . . . 14		10.3. New Permanent Failures Result-Code AVP Values . . . . . . 14
	12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	12.3. New Permanent Failures Result-Code AVP Values . . . . . . 14		12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14
	13. Security Considerations . . . . . . . . . . . . . . . . . . . 14		13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	14.1. Normative References . . . . . . . . . . . . . . . . . . . 15		14.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	14.2. Informative References . . . . . . . . . . . . . . . . . . 15		14.2. Informative References . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	Cao, et al. [RFC6696] defines the EAP Re-authentication Protocol		Cao, et al. [RFC6696] defines the EAP Re-authentication Protocol
	(ERP). It consists of the following steps:		(ERP). It consists of the following steps:
	Bootstrapping		Bootstrapping
	skipping to change at page 3, line 38 ¶		skipping to change at page 3, line 38 ¶
	This document also discusses the distribution of the root key during		This document also discusses the distribution of the root key during
	bootstrapping, in conjunction with either the initial EAP		bootstrapping, in conjunction with either the initial EAP
	authentication (implicit bootstrapping) or the first ERP exchange		authentication (implicit bootstrapping) or the first ERP exchange
	(explicit bootstrapping). Security considerations for this key		(explicit bootstrapping). Security considerations for this key
	distribution are detailed in Salowey, et al. [RFC5295].		distribution are detailed in Salowey, et al. [RFC5295].
	2. Terminology		2. Terminology
	This document uses terminology defined in Aboba, et al. [RFC3748],		This document uses terminology defined in Aboba, et al. [RFC3748],
	Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, Hiller		Salowey, et al. [RFC5295], Cao, et al. [RFC6696], and Eronen, et
	& Zorn [RFC4072].		al. [RFC4072].
	The re-athentication Domain-Specific Root Key (rDSRK) is a re-		The re-athentication Domain-Specific Root Key (rDSRK) is a re-
	authentication Root Key (rRK, [RFC6696]) derived from the DSRK		authentication Root Key (rRK, [RFC6696]) derived from the DSRK
	instead of the EMSK.		instead of the EMSK.
	"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK		"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK
	derived from an EMSK, depending on the location of the ER server in		derived from an EMSK, depending on the location of the ER server in
	home or foreign domain.		home or foreign domain.
	We use the notation "ERP/DER" and "ERP/DEA" in this document to refer		We use the notation "ERP/DER" and "ERP/DEA" in this document to refer
	to Diameter-EAP-Request and Diameter-EAP-Answer commands with the		to Diameter-EAP-Request and Diameter-EAP-Answer commands with the
	Application Id set to <Diameter ERP Application> Section 12.1; the		Application Id set to <Diameter ERP Application> Section 10.1; the
	same commands are denoted "EAP/DER" and "EAP/DEA" when the		same commands are denoted "EAP/DER" and "EAP/DEA" when the
	Application Id in the message is set to <Diameter EAP Application>		Application Id in the message is set to <Diameter EAP Application>
	[RFC4072].		[RFC4072].
	2.1. Requirements Language		2.1. Requirements Language
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	skipping to change at page 5, line 4 ¶		skipping to change at page 5, line 4 ¶
	Figure 1: Diameter ERP Overview.		Figure 1: Diameter ERP Overview.
	The ER server is located either in the home domain (same as EAP		The ER server is located either in the home domain (same as EAP
	server) or in the visited domain (same as authenticator, when it		server) or in the visited domain (same as authenticator, when it
	differs from the home domain).		differs from the home domain).
	When the peer initiates an ERP exchange, the authenticator creates a		When the peer initiates an ERP exchange, the authenticator creates a
	Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of		Diameter-EAP-Request (DER) message [RFC4072]. The Application Id of
	the message is set to that of the Diameter ERP application		the message is set to that of the Diameter ERP application
	Section 12.1 in the message. The generation of the ERP/DER message		Section 10.1 in the message. The generation of the ERP/DER message
	is detailed in Section 6.		is detailed in Section 6.
	If there is an ER server in the same domain as the authenticator		If there is an ER server in the same domain as the authenticator
	(i.e., the local domain), Diameter routing MUST be configured so that		(i.e., the local domain), Diameter routing MUST be configured so that
	this ERP/DER message reaches that server, even if the Destination-		this ERP/DER message reaches that server, even if the Destination-
	Realm is not the same as local domain.		Realm is not the same as local domain.
	If there is no local ER server, the message is routed according to		If there is no local ER server, the message is routed according to
	its Destination-Realm AVP content, extracted from the realm component		its Destination-Realm AVP content, extracted from the realm component
	of the keyName-NAI attribute. As specified in RFC 6696, this realm		of the keyName-NAI attribute. As specified in RFC 6696, this realm
	skipping to change at page 9, line 18 ¶		skipping to change at page 9, line 18 ¶
	the Domain- Name TLV attribute with the content from the ERP-Realm		the Domain- Name TLV attribute with the content from the ERP-Realm
	AVP. The server creates the EAP/DEA reply message [RFC4072]		AVP. The server creates the EAP/DEA reply message [RFC4072]
	including an instance of the Key AVP (Section 8.3) with Key-Type AVP		including an instance of the Key AVP (Section 8.3) with Key-Type AVP
	set to rRK and an instance of the Domain-Name TLV attribute with the		set to rRK and an instance of the Domain-Name TLV attribute with the
	content from the ERP-Realm AVP.		content from the ERP-Realm AVP.
	The ER server receives this EAP/DEA and proxies it as follows, in		The ER server receives this EAP/DEA and proxies it as follows, in
	addition to standard proxy operations:		addition to standard proxy operations:
	Set the Application Id back to Diameter ERP Application Id		Set the Application Id back to Diameter ERP Application Id
	(Section 12.1)		(Section 10.1)
	Extract and cache the content of the Key AVP with Key-Type set to		Extract and cache the content of the Key AVP with Key-Type set to
	rRK, as described in Section 5.1).		rRK, as described in Section 5.1).
	The ERP/DEA message is then forwarded to the authenticator, that can		The ERP/DEA message is then forwarded to the authenticator, that can
	use the rMSK as described in RFC 6696.		use the rMSK as described in RFC 6696.
	The figure below captures this proxy behavior:		The figure below captures this proxy behavior:
	Authenticator ER server Home Diameter server		Authenticator ER server Home Diameter server
	skipping to change at page 11, line 19 ¶		skipping to change at page 11, line 19 ¶
	the content of the User-Name and Destination-Realm AVPs.		the content of the User-Name and Destination-Realm AVPs.
	The Auth-Request-Type AVP content is set to the appropriate value.		The Auth-Request-Type AVP content is set to the appropriate value.
	The EAP-Payload AVP contains the EAP-Initiate/Re-Auth message.		The EAP-Payload AVP contains the EAP-Initiate/Re-Auth message.
	Then this ERP/DER message is sent as described in Section 4.		Then this ERP/DER message is sent as described in Section 4.
	The ER server receives and processes this request as described in		The ER server receives and processes this request as described in
	Section 4. It then creates an ERP/DEA message following the general		Section 4. It then creates an ERP/DEA message following the general
	process described in RFC4072 [RFC4072], with the following		process described in Eronen, et al. [RFC4072], with the following
	differences:		differences:
	The Application Id in the header is set to <Diameter ERP> (code		The Application Id in the header is set to <Diameter ERP> (code
	TBD1).		TBD1).
	The value of the Auth-Application-Id AVP is also set to <Diameter		The value of the Auth-Application-Id AVP is also set to <Diameter
	ERP>.		ERP>.
	The EAP-Payload AVP contains the EAP-Finish/Re-auth message.		The EAP-Payload AVP contains the EAP-Finish/Re-auth message.
	skipping to change at page 13, line 34 ¶		skipping to change at page 13, line 34 ¶
	Errors that fall within the Permanent Failures category are used to		Errors that fall within the Permanent Failures category are used to
	inform the peer that the request failed and SHOULD NOT be attempted		inform the peer that the request failed and SHOULD NOT be attempted
	again.		again.
	DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD4)		DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD4)
	This error code is used by the Diameter server to inform the		This error code is used by the Diameter server to inform the
	peer that the received EAP-PAYLOAD AVP contains an EAP packet		peer that the received EAP-PAYLOAD AVP contains an EAP packet
	with an unknown EAP code.		with an unknown EAP code.
	10. Contributors		10. IANA Considerations
	Hannes Tschofenig wrote the initial draft of this document.
	Lakshminath Dondeti contributed to the early versions of the
	document.
	11. Acknowledgements
	Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies, Menachem
	Dodge, Vincent Roca and Jouni Korhonen provided useful reviews.
	Vidya Narayanan reviewed a rough draft version of the document and
	found some errors.
	Many thanks to these people!
	12. IANA Considerations
	This document requires IANA registration of the following new		This document requires IANA registration of the following new
	elements in the Authentication, Authorization, and Accounting (AAA)		elements in the Authentication, Authorization, and Accounting (AAA)
	Parameters registries [AAAPARAMS].		Parameters registries [AAAPARAMS].
	12.1. Diameter Application Identifier		10.1. Diameter Application Identifier
	This specification requires IANA to allocate a new value "Diameter		This specification requires IANA to allocate a new value "Diameter
	ERP" (code: TBD1) in the "Application IDs" registry using the policy		ERP" (code: TBD1) in the "Application IDs" registry using the
	specified in Section 11.3 of RFC 3588 [RFC3588].		"Specification Required" policy [RFC5226]; see Section 11.3 of RFC
			3588 [RFC3588] for further details.
	12.2. New AVPs		10.2. New AVPs
	This specification requires IANA to allocate new values from the "AVP		This specification requires IANA to allocate new values from the "AVP
	Codes" registry according to the policy specified in Section 11.1 of		Codes" registry according to the policy specified in Section 11.1 of
	Fajardo, et al. [RFC6733] for the following AVPs:		Fajardo, et al. [RFC6733] for the following AVPs:
	ERP-RK-Request (code: TBD2)		ERP-RK-Request (code: TBD2)
	ERP-Realm (code: TBD3)		ERP-Realm (code: TBD3)
	These AVPs are defined in Section 8.		These AVPs are defined in Section 8.
	12.3. New Permanent Failures Result-Code AVP Values		10.3. New Permanent Failures Result-Code AVP Values
	This specification requires IANA to allocate a new value from the		This specification requires IANA to allocate a new value from the
	"Result-Code AVP Values (code 268) - Permanent Failure" registry		"Result-Code AVP Values (code 268) - Permanent Failure" registry
	according to the policy specified in Section 11.3.2 of Fajardo, et		according to the policy specified in Section 11.3.2 of Fajardo, et
	al. [RFC6733] for the following Result-Code:		al. [RFC6733] for the following Result-Code:
	DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: TBD4)		DIAMETER_ERROR_EAP_CODE_UNKNOWN (code: TBD4)
	This result-code value is defined in Section 9.		This result-code value is defined in Section 9.
	13. Security Considerations		11. Security Considerations
	The security considerations from the following documents apply here:		The security considerations from the following documents apply here:
	o Fajardo, et al. [RFC6733]		o Eronen, et al. [RFC4072]
	o RFC 4072 [RFC4072]		o Cao, et al. [RFC6696]
	o RFC 6696 [RFC6696]		o Fajardo, et al. [RFC6733]
	o Zorn, Wu and Cakulev [RFC6734]		o Zorn, et al. [RFC6734]
	14. References		12. Contributors
			Hannes Tschofenig wrote the initial draft of this document.
			Lakshminath Dondeti contributed to the early versions of the
			document.
			13. Acknowledgements
			Hannes Tschofenig, Zhen Cao, Benoit Claise, Elwyn Davies, Menachem
			Dodge, Vincent Roca and Jouni Korhonen provided useful reviews.
			Vidya Narayanan reviewed a rough draft version of the document and
			found some errors.
			Many thanks to these people!
			14. References
	14.1. Normative References		14.1. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
	Arkko, "Diameter Base Protocol", RFC 3588,
	September 2003.
	[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and		[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and
	H. Levkowetz, "Extensible Authentication Protocol		H. Levkowetz, "Extensible Authentication Protocol
	(EAP)", RFC 3748, June 2004.		(EAP)", RFC 3748, June 2004.
	[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter		[RFC4072] Eronen, P., Hiller, T., and G. Zorn, "Diameter
	Extensible Authentication Protocol (EAP) Application",		Extensible Authentication Protocol (EAP) Application",
	RFC 4072, August 2005.		RFC 4072, August 2005.
			[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
			IANA Considerations Section in RFCs", BCP 26, RFC 5226,
			May 2008.
	[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M.		[RFC5295] Salowey, J., Dondeti, L., Narayanan, V., and M.
	Nakhjiri, "Specification for the Derivation of Root Keys		Nakhjiri, "Specification for the Derivation of Root Keys
	from an Extended Master Session Key (EMSK)", RFC 5295,		from an Extended Master Session Key (EMSK)", RFC 5295,
	August 2008.		August 2008.
	[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP		[RFC6696] Cao, Z., He, B., Shi, Y., Wu, Q., and G. Zorn, "EAP
	Extensions for the EAP Re-authentication Protocol		Extensions for the EAP Re-authentication Protocol
	(ERP)", RFC 6696, July 2012.		(ERP)", RFC 6696, July 2012.
	[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,		[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
	skipping to change at page 16, line 5 ¶		skipping to change at page 15, line 43 ¶
	[RFC6734] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute-		[RFC6734] Zorn, G., Wu, Q., and V. Cakulev, "Diameter Attribute-
	Value Pairs for Cryptographic Key Transport", RFC 6734,		Value Pairs for Cryptographic Key Transport", RFC 6734,
	October 2012.		October 2012.
	14.2. Informative References		14.2. Informative References
	[AAAPARAMS] Internet Assigned Numbers Authority, "Authentication,		[AAAPARAMS] Internet Assigned Numbers Authority, "Authentication,
	Authorization, and Accounting (AAA) Parameters",		Authorization, and Accounting (AAA) Parameters",
	http://www.iana.org/assignments/aaa-parameters/.		http://www.iana.org/assignments/aaa-parameters/.
			[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
			Arkko, "Diameter Base Protocol", RFC 3588,
			September 2003.
	Authors' Addresses		Authors' Addresses
	Julien Bournelle		Julien Bournelle
	Orange Labs		Orange Labs
	38-40 rue du general Leclerc		38-40 rue du general Leclerc
	Issy-Les-Moulineaux 92794		Issy-Les-Moulineaux 92794
	France		France
	EMail: julien.bournelle@orange-ftgroup.com		EMail: julien.bournelle@orange-ftgroup.com
End of changes. 27 change blocks.
	52 lines changed or deleted		56 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/