draft-ietf-dime-erp-05.txt		draft-ietf-dime-erp-06.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: April 25, 2011 S. Decugis, Ed.		Expires: November 5, 2011 S. Decugis
	NICT		Free Diameter
	Q. Wu		Q. Wu
	Huawei		Huawei
	G. Zorn, Ed.		G. Zorn
	Network Zen		Network Zen
	October 22, 2010		May 4, 2011
	Diameter Support for the EAP Re-authentication Protocol (ERP)		Diameter support for EAP Re-authentication Protocol (ERP)
	draft-ietf-dime-erp-05.txt		draft-ietf-dime-erp-06.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 April 25, 2011.		This Internet-Draft will expire on November 5, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3		2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4
	3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4		4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
	5. Bootstrapping the ER Server . . . . . . . . . . . . . . . . . 5		5. Bootstrapping the ER Server . . . . . . . . . . . . . . . . . 5
	5.1. Bootstrapping During the Initial EAP authentication . . . 5		5.1. Bootstrapping During the Initial EAP authentication . . . 6
	5.2. Bootstrapping During the First Re-authentication . . . . . 7		5.2. Bootstrapping During the First Re-authentication . . . . . 7
	6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 9		6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 9
	7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12		8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12		8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 11
	8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12		8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 11
	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 . . . . . . . . . . . . . . . . . . . . . 12		8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 12
	8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13		8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 12
	9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13		9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	11.1. Diameter Application Identifier . . . . . . . . . . . . . 14		11.1. Diameter Application Identifier . . . . . . . . . . . . . 14
	11.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14		11.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 14		12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 15		13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	13.2. Informative References . . . . . . . . . . . . . . . . . . 16		13.2. Informative References . . . . . . . . . . . . . . . . . . 15
	1. Introduction		1. Introduction
	RFC 5296 [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
	[RFC5295]. This root key is transported from the EAP server to		[RFC5295]. This root key is transported from the EAP server to
	the ER server.		the ER server.
	Re-authentication		Re-authentication
	A one-round-trip exchange between the peer and the ER server,		A one-round-trip exchange between the peer and the ER server,
	resulting in mutual authentication. To support the EAP		resulting in mutual authentication. To support the EAP
	reauthentication functionality, ERP defines two new EAP codes -		reauthentication functionality, ERP defines two new EAP codes -
	EAP-Initiate and EAP-Finish.		EAP-Initiate and EAP-Finish.
	This document defines how Diameter transports the ERP messages during		This document defines how Diameter transports the ERP messages during
	the re-authentication process. For this purpose, we define a new		the re-authentication process. For this purpose, we define a new
	Application Identifier for ERP, and re-use the Diameter EAP commands		Application Identifier for ERP, and re-use the Diameter EAP commands
	(DER/DEA).		(DER/DEA).
	skipping to change at page 3, line 35		skipping to change at page 3, line 37
	(DER/DEA).		(DER/DEA).
	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 RFC 5295 [RFC5295].		distribution are detailed in RFC 5295 [RFC5295].
	2. Terminology		2. Terminology
	This document uses terminology defined in RFC 3748 [RFC3748], RFC		This document uses terminology defined in RFC3748 [RFC3748], RFC5295
	5295 [RFC5295], RFC 5296 [RFC5296], and RFC 4072 [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 11.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"
	skipping to change at page 4, line 21		skipping to change at page 4, line 26
	the ERP states (root keys) between these servers. This replication		the ERP states (root keys) between these servers. This replication
	mechanism is out of the scope of this document. If multiple ER		mechanism is out of the scope of this document. If multiple ER
	servers are deployed in the domain, we assume that they can be used		servers are deployed in the domain, we assume that they can be used
	interchangeably.		interchangeably.
	4. Protocol Overview		4. Protocol Overview
	The following figure shows the components involved in ERP, and their		The following figure shows the components involved in ERP, and their
	interactions.		interactions.
	Diameter +--------+		Diameter +--------+
	+-------------+ ERP +-----------+ (*) | Home |		+-------------+ ERP +-----------+ (*) | Home |
	Peer <->|Authenticator|<=======>| ER server | <---> | EAP |		Peer <->|Authenticator|<=======>| ER server | <---> | EAP |
	+-------------+ +-----------+ | server |		+-------------+ +-----------+ | server |
	+--------+		+--------+
	(*) Diameter EAP application, explicit bootstrapping scenario only.		(*) Diameter EAP application, explicit bootstrapping scenario only.
	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 message [RFC4072]. The Application Id of the		Diameter-EAP-Request message [RFC4072]. The Application Id of the
	message is set to that of the Diameter ERP application (code: TBD) in		message is set to that of the Diameter ERP application (code: TBD) in
	the message. The generation of the ERP/DER message is detailed in		the message. The generation of the ERP/DER message is detailed in
	Section 6.		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
	(local domain), Diameter routing must be configured so that this ERP/		(local domain), Diameter routing must be configured so that this ERP/
	DER message reachs this server, even if the Destination-Realm is not		DER message reachs this server, even if the Destination-Realm is not
	the local domain.		the 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 5296 [RFC5296],		of the keyName-NAI attribute. As specified in RFC5296 [RFC5296],
	this realm is the home domain of the peer in case of a bootstrapping		this realm is the home domain of the peer in case of bootstrapping
	exchange (the 'B' flag is set in the ERP message) or the domain of		exchange ('B' flag is set in ERP message) or the domain of the
	the bootstrapped ER server otherwise.		bootstrapped ER server otherwise .
	If no ER server is available in the home domain either, the ERP/DER		If no ER server is available in the home domain either, the ERP/DER
	message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER		message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER
	is generated [RFC3588] and returned to the authenticator. The		is generated as specified in [RFC3588] and returned to the
	authenticator may cache this information (with limited duration) to		authenticator. The authenticator may cache this information (with
	avoid further attempts for ERP with this realm. It may also fallback		limited duration) to avoid further attempts for ERP with this realm.
	to full EAP authentication to authenticate the peer.		It may also fallback to full EAP authentication to authenticate the
			peer.
	When an ER server receives the ERP/DER message, it searches its local		When an ER server receives the ERP/DER message, it searches its local
	database for a root key matching the keyName part of the User-Name		database for a root key matching the keyName part of the User-Name
	AVP. If such key is found, the ER server processes the ERP message		AVP. If such key is found, the ER server processes the ERP message
	as described in RFC 5296 [RFC5296] then creates the ERP/DEA answer as		as described in [RFC5296] then creates the ERP/DEA answer as
	described in Section 6. The rMSK is included in this answer.		described in Section 6. The rMSK is included in this answer.
	Finally, the authenticator extracts the rMSK from the ERP/DEA as		Finally, the authenticator extracts the rMSK from the ERP/DEA as
	described in RFC 5296 [RFC5296], and forwards the content of the EAP-		described in RFC5296 [RFC5296], and forwards the content of the EAP-
	Payload AVP, the EAP-Finish/Re-Auth message, to the peer.		Payload AVP, the EAP-Finish/Re-Auth message, to the peer.
	If the EAP-Initiate/Re-Auth message has its 'B' flag set		If the EAP-Initiate/Re-Auth message has its 'B' flag set
	(Bootstrapping exchange), the ER server should not possess the root		(Bootstrapping exchange), the ER server should not possess the root
	key in its local database. In this case, the ER server acts as a		key in its local database. In this case, the ER server acts as a
	proxy, and forwards the message to the home EAP server after changing		proxy, and forwards the message to the home EAP server after changing
	its Application Id to Diameter EAP and adding the ERP-RK-Request AVP		its Application Id to Diameter EAP and adding the ERP-RK-Request AVP
	to request the root key. See Section 5 for more detail on this		to request the root key. See section Section 5 for more detail on
	process.		this process.
	5. Bootstrapping the ER Server		5. Bootstrapping the ER Server
	The bootstrapping process involves the home EAP server and the ER		The bootstrapping process involves the home EAP server and the ER
	server, but also impacts the peer and the authenticator. In ERP, the		server, but also impacts the peer and the authenticator. In ERP, the
	peer must derive the same keying material as the ER server. To		peer must derive the same keying material as the ER server. To
	achieve this, it must learn the domain name of the ER server. How		achieve this, it must learn the domain name of the ER server. How
	this information is acquired is outside the scope of this		this information is acquired is outside the scope of this
	specification, but it may involves that the authenticator is		specification, but it may involves that the authenticator is
	configured to advertize this domain name, especially in the case of		configured to advertize this domain name, especially in the case of
	skipping to change at page 6, line 4		skipping to change at page 6, line 10
	EMSK -- from which the root key is derived -- is created, during the		EMSK -- from which the root key is derived -- is created, during the
	first re-authentication, or sometime between those events. We only		first re-authentication, or sometime between those events. We only
	consider the first two possibilities in this specification, in the		consider the first two possibilities in this specification, in the
	following sub-sections.		following sub-sections.
	5.1. Bootstrapping During the Initial EAP authentication		5.1. Bootstrapping During the Initial EAP authentication
	Bootstrapping the ER server during the initial EAP authentication		Bootstrapping the ER server during the initial EAP authentication
	(also known as implicit bootstrapping) offers the advantage that the		(also known as implicit bootstrapping) offers the advantage that the
	server is immediatly available for re-authentication of the peer,		server is immediatly available for re-authentication of the peer,
	thus minimizing re-authentication delay. On the other hand, it is		thus minimizing the re-authentication delay. On the other hand, it
	possible that only a small number of peers will use re-authentication		is possible that only a small number of peers will use re-
	in the visited domain. Deriving and caching key material for all the		authentication in the visited domain. Deriving and caching key
	peers (for example, for the peers that do not support ERP) is a waste		material for all the peers (for example, for the peers that do not
	of resources and should be avoided.		support ERP) is a waste of resources and should be avoided.
	To achieve implicit bootstrapping, the ER server acts as a Diameter		To achieve implicit bootstrapping, the ER server acts as a Diameter
	EAP Proxy, and Diameter routing must be configured so that Diameter		EAP Proxy , and Diameter routing must be configured so that Diameter
	EAP application messages are routed through this proxy. The figure		EAP application messages are routed through this proxy. The figure
	bellow illustrates this mechanism.		bellow illustrates this mechanism.
	ER server &		ER server &
	Authenticator EAP Proxy Home EAP server		Authenticator EAP Proxy Home EAP server
	============= =========== ===============		============= =========== ===============
	------------------------->		------------------------->
	Diameter EAP/DER		Diameter EAP/DER
	(EAP-Response)		(EAP-Response)
	------------------------->		------------------------->
	Diameter EAP/DER		Diameter EAP/DER
	(EAP-Response)		(EAP-Response)
	(ERP-RK-Request)		(ERP-RK-Request)
	<==================================================>		<==================================================>
	Multi-round Diameter EAP exchanges, unmodified		Multi-round Diameter EAP exchanges, unmodified
	<-------------------------		<-------------------------
	Diameter EAP/DEA		Diameter EAP/DEA
	(EAP-Success)		(EAP-Success)
	(MSK)		(MSK)
	(Key AVP (rRK))		(Key AVP (rRK))
	<-------------------------		<-------------------------
	Diameter EAP/DEA		Diameter EAP/DEA
	(EAP-Success)		(EAP-Success)
	(MSK)		(MSK)
	[ ERP-Realm ]		[ERP-Realm]
	Figure 2: ERP Bootstrapping During Full EAP Authentication		Figure 2: ERP Bootstrapping During Full EAP Authentication
	The ER server proxies the first DER of the full EAP authentication		The ER server proxies the first DER of the full EAP authentication
	and adds the ERP-RK-Request AVP inside, if this AVP is not already in		and adds the ERP-RK-Request AVP inside, if this AVP is not already in
	the message (which might happen if there are several ER servers on		the message (which might happen if there are several ER servers on
	the path), then forwards the request.		the path), then forwards the request.
	If the EAP server does not support the ERP extensions, it simply		If the EAP server does not support the ERP extensions, it simply
	ignores the ERP-RK-Request AVP and continues as specified in RFC 4072		ignores the ERP-RK-Request AVP and continues as specified in RFC 4072
	skipping to change at page 8, line 5		skipping to change at page 8, line 7
	The ER server receives the ERP/DER message containing the EAP-		The ER server receives the ERP/DER message containing the EAP-
	Initiate/Re-Auth message with the 'B' flag set. It proxies this		Initiate/Re-Auth message with the 'B' flag set. It proxies this
	message, and performs the following processing in addition to		message, and performs the following processing in addition to
	standard proxy operations:		standard proxy operations:
	Changes the Application Id in the header of the message to		Changes the Application Id in the header of the message to
	Diameter EAP Application (code 5).		Diameter EAP Application (code 5).
	Change the content of Application-Auth-Id accordingly.		Change the content of Application-Auth-Id accordingly.
	QUESTION:		QUESTION: Is it better to leave it unmodified, so that the server
	Is it better to leave it unmodified, so that the server can		can easily differenciate between ERP and standard EAP message?
	easily differenciate between ERP and standard EAP message ?
	Add the ERP-RK-Request AVP, which contains the name of the domain		Add the ERP-RK-Request AVP, which contains the name of the domain
	where the ER server is located.		where the ER server is located.
	PROBLEM:		PROBLEM: Add the Destination-Host AVP to reach the appropriate
	Add the Destination-Host AVP to reach the appropriate Diameter		Diameter EAP server in case there is more than one in destination
	EAP server in case there is more than one in destination		domain, the one with the EMSK. How does the ER server know this
	domain, the one with the EMSK. How does the ER server know		information? Or can we require that all Diameter EAP servers can
	this information? Or can we require that all Diameter EAP		be used interchangeably for this purpose?
	servers can be used interchangeably for this purpose?
	Then the proxied EAP/DER request is sent and routed to the home		Then the proxied EAP/DER request is sent and routed to the home
	Diameter EAP server.		Diameter EAP server.
	If the home EAP server does not support the ERP extensions, it		If the home EAP server does not support ERP extensions, it replies
	replies with an error since the encapsulated EAP-Initiate/Re-auth		with an error since the encapsulated EAP-Initiate/Re-auth command is
	command is not understood. Otherwise, it processes the ERP request		not understood. Otherwise, it processes the ERP request as described
	as described in [RFC5296]. In particular, it includes the Domain-		in [RFC5296]. In particular, it includes the Domain- Name TLV
	Name TLV attribute with the content from the ERP-Realm AVP. It		attribute with the content from the ERP-Realm AVP. It creates the
	creates the EAP/DEA reply message [RFC4072]. including an instance of		EAP/DEA reply message [RFC4072]. including an instance of the Key AVP
	the Key AVP Section 8.3 with Key-Type AVP set to rRK.		Section 8.3 with Key-Type AVP set to rRK.
	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 (code		Set the Application Id back to Diameter ERPApplication Id (code
	TBD)		TBD)
	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 implicit scenario.		rRK, as described in implicit scenario.
	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 EAP server		Authenticator ER server Home EAP server
	============= ========= ===============		============= ========= ===============
	----------------------->		----------------------->
	Diameter ERP/DER		Diameter ERP/DER
	(EAP-Initiate)		(EAP-Initiate)
	------------------------>		------------------------>
	Diameter EAP/DER		Diameter EAP/DER
	(EAP-Initiate)		(EAP-Initiate)
	(ERP-RK-Request)		(ERP-RK-Request)
	<------------------------		<------------------------
	Diameter EAP/DEA		Diameter EAP/DEA
	(EAP-Finish)		(EAP-Finish)
	(Key AVP (rRK))		(Key AVP (rRK))
	(Key AVP (rMSK))		(Key AVP (rMSK))
	<----------------------		<----------------------
	Diameter ERP/DEA		Diameter ERP/DEA
	(EAP-Finish)		(EAP-Finish)
	(Key AVP (rMSK))		(Key AVP (rMSK))
	Figure 3: ERP Explicit Bootstrapping Message Flow		Figure 3: ERP Explicit Bootstrapping Message Flow
	6. Re-Authentication		6. Re-Authentication
	This section describes in detail a re-authentication exchange with an		This section describes in detail a re-authentication exchange with an
	ER server that was previously bootstrapped. The following figure		ER server that was previously bootstrapped. The following figure
	summarizes the re-authentication exchange.		summarizes the re-authentication exchange.
	ER server		ER server
	skipping to change at page 10, line 39		skipping to change at page 10, line 17
	the authenticator. Alternatively, the authenticator may send an EAP-		the authenticator. Alternatively, the authenticator may send an EAP-
	Initiate/Re-auth-Start message to the peer to trigger the mechanism.		Initiate/Re-auth-Start message to the peer to trigger the mechanism.
	In this case, the peer responds with an EAP-Initiate/Re-auth message.		In this case, the peer responds with an EAP-Initiate/Re-auth message.
	If the authenticator does not support ERP (pure Diameter EAP		If the authenticator does not support ERP (pure Diameter EAP
	[RFC4072] support), it discards the EAP packets with an unknown ERP-		[RFC4072] support), it discards the EAP packets with an unknown ERP-
	specific code (EAP-Initiate). The peer should fallback to full EAP		specific code (EAP-Initiate). The peer should fallback to full EAP
	authentication in this case.		authentication in this case.
	When the authenticator receives an EAP-Initiate/Re-auth message from		When the authenticator receives an EAP-Initiate/Re-auth message from
	the peer, it processes as described in [RFC5296] with regards to the		the peer, it process as described in [RFC5296] with regards to the
	EAP state machine. It creates a Diameter EAP Request message		EAP state machine. It creates a Diameter EAP Request message
	following the general process of Diameter EAP [RFC4072], with the		following the general process of Diameter EAP [RFC4072], with the
	following differences:		following 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 TBD
	TBD).		).
	The value in Auth-Application-Id AVP is also set to Diameter ERP		The value in Auth-Application-Id AVP is also set to Diameter ERP
	Application.		Application.
	The keyName-NAI attribute from ERP message is used to create the		The keyName-NAI attribute from ERP message is used to create the
	content of User-Name AVP and Destination-Realm AVP.		content of User-Name AVP and Destination-Realm AVP.
	FFS:		The Auth-Request-Type AVP content is set to [Editor's note: FFS].
	What about Session-ID AVP ?
	The Auth-Request-Type AVP content is set to [Editor's note: FFS --
	cf. open issues].
	The EAP-Payload AVP contains the EAP-Initiate/Re-Auth message.		The EAP-Payload AVP contains the EAP-Initiate/Re-Auth.
	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
	processing described in RFC 4072 [RFC4072], with the following		processing described in RFC4072 [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
	TBD).		TBD).
	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 Application.		ERP Application.
	The EAP-Payload AVP contains the EAP-Finish/Re-auth message.		The EAP-Payload AVP contains the EAP-Finish/Re-auth message.
	In case of successful authentication, an instance of the Key AVP		In case of successful authentication, an instance of the Key AVP
	containing the Re-authentication Master Session Key (rMSK) derived		containing the Re-authentication Master Session Key (rMSK) derived
	by ERP is included.		by ERP is included.
	When the authenticator receives this ERP/DEA answer, it processes it		When the authenticator receives this ERP/DEA answer, it processes it
	as described in Diameter EAP [RFC4072] and RFC 5296 [RFC5296]: the		as described in Diameter EAP [RFC4072] and RFC5296 [RFC5296]: the
	content of EAP-Payload AVP content is forwarded to the peer, and the		content of EAP-Payload AVP content is forwarded to the peer, and the
	contents of the Keying-Material AVP [I-D.ietf-dime-local-keytran] is		contents of the Keying-Material AVP [I-D.ietf-dime-local-keytran] is
	used as a shared secret for Secure Association Protocol.		used as a shared secret for Secure Association Protocol.
	7. Application Id		7. Application Id
	We define a new Diameter application in this document, Diameter ERP		We define a new Diameter application in this document, Diameter ERP
	Application, with an Application Id value of TBD. Diameter nodes		Application, with an Application Id value of TBD. Diameter nodes
	conforming to this specification in the role of ER server MUST		conforming to this specification in the role of ER server MUST
	advertise support by including an Auth-Application-Id AVP with a		advertise support by including an Auth-Application-Id AVP with a
	value of Diameter ERP Application in the of the Capabilities-		value of Diameter ERP Application in the of the Capabilities-
	Exchange-Request and Capabilities-Exchange-Answer commands [RFC3588].		Exchange-Request and Capabilities-Exchange-Answer commands [RFC3588].
	The primary use of the Diameter ERP Application Id is to ensure		The primary use of the Diameter ERP Application Id is to ensure
	proper routing of the messages, and that the nodes that advertise the		proper routing of the messages, and that the nodes that advertise the
	support for this application do understand the new AVPs defined in		support for this application do understand the new AVPs defined in
	Section 8, although these AVP have the 'M' flag cleared.		Section 8 , although these AVP have the 'M' flag cleared.
	8. AVPs		8. AVPs
	This section discusses the AVPs used by the Diameter ERP application.		This section discusses the AVPs used by the Diameter ERP application.
	8.1. ERP-RK-Request AVP		8.1. ERP-RK-Request AVP
	The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This		The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This
	AVP is used by the ER server to indicate its willingness to act as ER		AVP is used by the ER server to indicate its willingness to act as ER
	server for a particular session.		server for a particular session.
	This AVP has the M and V bits cleared.		This AVP has the M and V bits cleared.
	ERP-RK-Request ::= < AVP Header: TBD >		ERP-RK-Request ::= < AVP Header: TBD >
	{ ERP-Realm }		{ ERP-Realm }
	* [ AVP ]		* [ AVP ]
	Figure 5: ERP-RK-Request ABNF		Figure 5: ERP-RK-Request ABNF
	8.2. ERP-Realm AVP		8.2. ERP-Realm AVP
	The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It		The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It
	contains the name of the realm in which the ER server is located.		contains the name of the realm in which the ER server is located.
	This AVP has the M and V bits cleared.		This AVP has the M and V bits cleared.
	skipping to change at page 14, line 48		skipping to change at page 14, line 25
	RFC 3588 [RFC3588] for the following AVPs:		RFC 3588 [RFC3588] 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. Security Considerations
	The security considerations from the following documents also apply		The security considerations from the following documents apply here:
	here:
	o RFC 3588 [RFC3588]		o RFC3588 [RFC3588]
	o RFC 4072 [RFC4072]		o RFC4072 [RFC4072]
	o RFC 5247 [RFC5247]		o RFC5247 [RFC5247]
	o RFC 5295 [RFC5295]		o RFC5295 [RFC5295]
	o [RFC5296]		o RFC5296 [RFC5296]
	FFS:		FFS: Do we really respect these security considerations with the
	Do we really respect these security considerations with the		mechanism we describe here? Is it safe to use ERP-RK-Request & Key
	mechanism we describe here? Is it safe to use ERP-RK-Request &		AVPs? What is the worst case? For example if a domain tricks the
	Key AVPs? What is the worst case? For example if a domain tricks		peer into beliving it is located in a different domain?
	the peer into beliving it is located in a different domain?
	EAP channel bindings may be necessary to ensure that the Diameter		EAP channel bindings may be necessary to ensure that the Diameter
	client and the server are in sync regarding the key Requesting		client and the server are in sync regarding the key Requesting
	Entity's Identity. Specifically, the Requesting Entity advertises		Entity's Identity. Specifically, the Requesting Entity advertises
	its identity through the EAP lower layer, and the user or the EAP		its identity through the EAP lower layer, and the user or the EAP
	peer communicates that identity to the EAP server (and the EAP server		peer communicates that identity to the EAP server (and the EAP server
	communicates that identity to the Diameter server) via the EAP method		communicates that identity to the Diameter server) via the EAP method
	for user/peer to server verification of the Requesting Entity's		for user/peer to server verification of the Requesting Entity's
	Identity.		Identity.
	QUESTION:		QUESTION: What does this paragraph actually mean?
	What does this paragraph actually mean?
	13. References		13. References
	13.1. Normative References		13.1. Normative References
	[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,		[I-D.ietf-dime-local-keytran] Wu, Q., Zorn, G., and V. Cakulev,
	"Diameter Attribute-Value Pairs for		"Diameter support for local key
	Cryptographic Key Transport",		transport protocol between local
	draft-ietf-dime-local-keytran-08 (work		server and home AAA server",
	in progress), October 2010.		draft-ietf-dime-local-keytran-09 (work
			in progress), April 2011.
	[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.
	skipping to change at page 17, line 4		skipping to change at page 16, line 18
	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
	Lionel Morand		Lionel Morand
	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: lionel.morand@orange-ftgroup.com		EMail: lionel.morand@orange-ftgroup.com
	Sebastien Decugis (editor)		Sebastien Decugis
	NICT		Free Diameter
	4-2-1 Nukui-Kitamachi		4-2-1 Nukui-Kitamachi
	Tokyo 184-8795		Tokyo, Koganei 184-8795
	Koganei, Japan		Japan
	EMail: sdecugis@nict.go.jp		EMail: sdecugis@freediameter.net
	Qin Wu		Qin Wu
	Huawei Technologies Co., Ltd		Huawei Technologies Co., Ltd
	Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.		Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
	Nanjing 210001		Nanjing 210001
	China		China
	EMail: sunseawq@huawei.com		EMail: sunseawq@huawei.com
			Glen Zorn
	Glen Zorn (editor)
	Network Zen		Network Zen
	1463 East Republican Street		227/358 Thanon Sanphawut
	Seattle, Washington 98112		Bang Na, Bangkok 10260
	USA		Thailand
	Phone: +1 206 931 0768
	EMail: gwz@net-zen.net		EMail: gwz@net-zen.net
End of changes. 57 change blocks.
	148 lines changed or deleted		142 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/