< draft-ietf-dime-erp-09.txt		draft-ietf-dime-erp-10.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: August 13, 2012 S. Decugis		Expires: December 5, 2012 S. Decugis
	INSIDE Secure		INSIDE Secure
	Q. Wu		Q. Wu
	Huawei		Huawei
	G. Zorn		G. Zorn
	Network Zen		Network Zen
	February 10, 2012		June 3, 2012
	Diameter Support for the EAP Re-authentication Protocol (ERP)		Diameter Support for the EAP Re-authentication Protocol (ERP)
	draft-ietf-dime-erp-09.txt		draft-ietf-dime-erp-10.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 August 13, 2012.		This Internet-Draft will expire on December 5, 2012.
	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 35 ¶		skipping to change at page 2, line 35 ¶
	6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 10		6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 10
	7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11
	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. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. Result-Code AVP Values . . . . . . . . . . . . . . . . . . . . 13
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		9.1. Permanent Failures . . . . . . . . . . . . . . . . . . . . 13
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Diameter Application Identifier . . . . . . . . . . . . . 13		11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	11.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13		12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 14		12.1. Diameter Application Identifier . . . . . . . . . . . . . 14
	13. Normative References . . . . . . . . . . . . . . . . . . . . . 14		12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14
			12.3. New Permanent Failures Result-Code AVP Values . . . . . . 14
			13. Security Considerations . . . . . . . . . . . . . . . . . . . 14
			14. Normative References . . . . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	RFC5296 [RFC5296] defines the EAP Re-authentication Protocol (ERP).		RFC5296 [RFC5296] defines the EAP Re-authentication Protocol (ERP).
	It consists of the following steps:		It consists of the following steps:
	Bootstrapping		Bootstrapping
	A root key for re-authentication is derived from the Extended		A root key for re-authentication is derived from the Extended
	Master Session Key (EMSK) created during EAP authentication		Master Session Key (EMSK) created during EAP authentication
	skipping to change at page 3, line 46 ¶		skipping to change at page 3, line 46 ¶
	This document uses terminology defined in RFC3748 [RFC3748], RFC5295		This document uses terminology defined in RFC3748 [RFC3748], RFC5295
	[RFC5295], RFC5296 [RFC5296], and RFC4072 [RFC4072].		[RFC5295], RFC5296 [RFC5296], and RFC4072 [RFC4072].
	"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 11.1; the		Application Id set to <Diameter ERP Application> Section 12.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 4, line 50 ¶		skipping to change at page 4, line 50 ¶
	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 11.1 in the message. The generation of the ERP/DER message		Section 12.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 RFC5296 [RFC5296],		of the keyName-NAI attribute. As specified in RFC5296 [RFC5296],
	skipping to change at page 8, line 26 ¶		skipping to change at page 8, line 26 ¶
	Set the Application Id in the header of the message to <Diameter		Set the Application Id in the header of the message to <Diameter
	EAP Application> [RFC4072]		EAP Application> [RFC4072]
	Extract the ERP-RK-Request AVP from the ERP/DER message, which		Extract the ERP-RK-Request AVP from the ERP/DER message, which
	contains the name of the domain where the ER server is located and		contains the name of the domain where the ER server is located and
	add it to the newly created ERP/DER message.		add it to the newly created ERP/DER message.
	Then the newly created EAP/DER is sent and routed to the home		Then the newly created EAP/DER is sent and routed to the home
	Diameter EAP application server.		Diameter EAP application server.
	If the home Diameter server does not support ERP extensions, it		If the home Diameter EAP server does not support ERP extensions, EAP
	replies with an error since the encapsulated ERP-RK-Request AVP is		packets with an unknown ERP-specific code (EAP-Initiate) are not
	not understood. Otherwise, it processes the DSRK request as		understood. In such a case, the home Diameter EAP server MUST send
	described in [RFC5296]. In particular, it includes the Domain- Name		an EAP/DEA with a Result-Code set to DIAMETER_ERROR_EAP_CODE_UNKNOWN.
	TLV attribute with the content from the ERP-Realm AVP. The server		The Failed-AVP AVP MUST be included and contain a copy of the EAP-
			Payload AVP. Otherwise, it processes the DSRK request as described
			in [RFC5296]. In particular, it includes the Domain- Name TLV
			attribute with the content from the ERP-Realm AVP. The server
	creates the EAP/DEA reply message [RFC4072] including an instance of		creates the EAP/DEA reply message [RFC4072] including an instance of
	the Key AVP (Section 8.3) with Key-Type AVP set to rRK and an		the Key AVP (Section 8.3) with Key-Type AVP set to rRK and an
	instance of the Domain-Name TLV attribute with the content from the		instance of the Domain-Name TLV attribute with the content from the
	ERP-Realm AVP.		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 11.1 )		(Section 12.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 the implicit scenario (Section 5.1).		rRK, as described in the implicit scenario (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 5296 [RFC5296].		use the rMSK as described in RFC 5296 [RFC5296].
	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 13, line 16 ¶		skipping to change at page 13, line 16 ¶
	This AVP contains the EMSKname which identifies the keying material.		This AVP contains the EMSKname which identifies the keying material.
	The derivation of this name is specified in RGC 5296 [RFC5296].		The derivation of this name is specified in RGC 5296 [RFC5296].
	8.3.4. Key-Lifetime AVP		8.3.4. Key-Lifetime AVP
	The Key-Lifetime AVP contains the lifetime of the keying material in		The Key-Lifetime AVP contains the lifetime of the keying material in
	seconds. It MUST NOT be greater than the remaining lifetime of the		seconds. It MUST NOT be greater than the remaining lifetime of the
	EMSK from which the material was derived.		EMSK from which the material was derived.
	9. Contributors		9. Result-Code AVP Values
			This section defines new Result-Code [I-D.ietf-dime-rfc3588bis]
			values that MUST be supported by all Diameter implementations that
			conform to this specification.
			9.1. Permanent Failures
			Errors that fall within the Permanent Failures category are used to
			inform the peer that the request failed and SHOULD NOT be attempted
			again.
			DIAMETER_ERROR_ EAP_CODE_UNKNOWN (TBD)
			This error code is used by the Diameter server to inform the
			peer that the received EAP-PAYLOAD AVP contains an EAP packet
			with an unknown EAP code.
			10. Contributors
	Hannes Tschofenig wrote the initial draft of this document.		Hannes Tschofenig wrote the initial draft of this document.
	Lakshminath Dondeti contributed to the early versions of the		Lakshminath Dondeti contributed to the early versions of the
	document.		document.
	10. Acknowledgements		11. Acknowledgements
	Hannes Tschofenig provided useful reviews.		Hannes Tschofenig provided useful reviews.
	Vidya Narayanan reviewed a rough draft version of the document and		Vidya Narayanan reviewed a rough draft version of the document and
	found some errors.		found some errors.
	Many thanks to these people!		Many thanks to these people!
	11. IANA Considerations		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 [1] registries.		Parameters [1] registries.
	11.1. Diameter Application Identifier		12.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" in the "Application IDs" registry using the policy specified in		ERP" in the "Application IDs" registry using the policy specified in
	Section 11.3 of RFC 3588 [RFC3588].		Section 11.3 of RFC 3588 [RFC3588].
	11.2. New AVPs		12.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. [I-D.ietf-dime-rfc3588bis] for the following AVPs:		Fajardo, et al. [I-D.ietf-dime-rfc3588bis] for the following AVPs:
	ERP-RK-Request		ERP-RK-Request
	ERP-Realm		ERP-Realm
	These AVPs are defined in Section 8.		These AVPs are defined in Section 8.
	12. Security Considerations		12.3. New Permanent Failures Result-Code AVP Values
			This specification requires IANA to allocate a new value from the
			"Result-Code AVP Values (code 268) - Permanent Failure" registry
			according to the policy specified in Section 11.3.2 of Fajardo, et
			al. [I-D.ietf-dime-rfc3588bis] for the following Result-Code:
			DIAMETER_ERROR_EAP_CODE_UNKNOWN TBD
			This result-code value is defined in Section 9.
			13. Security Considerations
	The security considerations from the following documents apply here:		The security considerations from the following documents apply here:
	o Fajardo, et al. [I-D.ietf-dime-rfc3588bis]		o Fajardo, et al. [I-D.ietf-dime-rfc3588bis]
	o RFC 4072 [RFC4072]		o RFC 4072 [RFC4072]
	o RFC 5296 [RFC5296]		o RFC 5296 [RFC5296]
	o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran]		o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran]
	13. Normative References		14. Normative References
	[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,		[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,
	"Diameter Attribute-Value Pairs for		"Diameter Attribute-Value Pairs for
	Cryptographic Key Transport",		Cryptographic Key Transport",
	draft-ietf-dime-local-keytran-14 (work		draft-ietf-dime-local-keytran-14 (work
	in progress), August 2011.		in progress), August 2011.
	[I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J.,		[I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J.,
	and G. Zorn, "Diameter Base Protocol",		and G. Zorn, "Diameter Base Protocol",
	draft-ietf-dime-rfc3588bis-29 (work in		draft-ietf-dime-rfc3588bis-33 (work in
	progress), August 2011.		progress), May 2012.
	[RFC2119] Bradner, S., "Key words for use in		[RFC2119] Bradner, S., "Key words for use in
	RFCs to Indicate Requirement Levels",		RFCs to Indicate Requirement Levels",
	BCP 14, RFC 2119, March 1997.		BCP 14, RFC 2119, March 1997.
	[RFC3588] Calhoun, P., Loughney, J., Guttman,		[RFC3588] Calhoun, P., Loughney, J., Guttman,
	E., Zorn, G., and J. Arkko, "Diameter		E., Zorn, G., and J. Arkko, "Diameter
	Base Protocol", RFC 3588,		Base Protocol", RFC 3588,
	September 2003.		September 2003.
End of changes. 18 change blocks.
	28 lines changed or deleted		64 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/