draft-ietf-dime-erp-07.txt		draft-ietf-dime-erp-08.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: March 9, 2012 S. Decugis		Expires: July 16, 2012 S. Decugis
	Free Diameter		INSIDE Secure
	Q. Wu		Q. Wu
	Huawei		Huawei
	G. Zorn		G. Zorn
	Network Zen		Network Zen
	September 6, 2011		January 13, 2012
	Diameter support for EAP Re-authentication Protocol (ERP)		Diameter support for EAP Re-authentication Protocol (ERP)
	draft-ietf-dime-erp-07.txt		draft-ietf-dime-erp-08.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 March 9, 2012.		This Internet-Draft will expire on July 16, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	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
	skipping to change at page 2, line 25		skipping to change at page 2, line 25
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2.1. Requirements Language . . . . . . . . . . . . . . . . . . 4		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 . . . 6		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 . . . . . . . . . . . . . . . . . . . . . . 10
	7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 11		8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12
	8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 11		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 . . . . . . . . . . . . . . . . . . . . . 12		8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 13
	8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 12		8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
	10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	10.1. Diameter Application Identifier . . . . . . . . . . . . . 13		11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	10.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13		11.1. Diameter Application Identifier . . . . . . . . . . . . . 13
	11. Security Considerations . . . . . . . . . . . . . . . . . . . 13		11.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13
	12. Normative References . . . . . . . . . . . . . . . . . . . . . 13		12. Security Considerations . . . . . . . . . . . . . . . . . . . 14
			13. Normative References . . . . . . . . . . . . . . . . . . . . . 14
	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 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>
	[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].
	3. Assumptions		3. Assumptions
	skipping to change at page 4, line 24		skipping to change at page 4, line 24
	entity in a domain. If several physical servers are deployed for		entity in a domain. If several physical servers are deployed for
	robustness, a replication mechanism must be deployed to synchronize		robustness, a replication mechanism must be deployed to synchronize
	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. If multiple ER servers are deployed across the		interchangeably. If multiple ER servers are deployed across the
	domains, we assume only one ER server that is near to the peer is		domains, we assume only one ER server that is near to the peer is
	getting involved in the ERP.		getting involved in the ERP.
	Also this document assumes the existence of at most one EAP server		Also this document assumes the existence of at most one EAP server
	entity in the home domain.In case of multiple physical home EAP		entity in the home domain. In case of multiple physical home EAP
	servers in the same domain, if the ER server wants to reach the same		servers in the same domain, if the ER server wants to reach the same
	home EAP server, the ER server may cache the Destination-Host AVP		home EAP server, the ER server may cache the Destination-Host AVP
	corresponding to the home EAP server it requests.		corresponding to the home EAP server it requests.
	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 (DER) message [RFC4072]. The Application Id of
	message is set to that of the Diameter ERP application (code: TBD) in		the message is set to that of the Diameter ERP application
	the message. The generation of the ERP/DER message is detailed in		Section 11.1 in the message. The generation of the ERP/DER message
	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
	(local domain), Diameter routing must be configured so that this ERP/		(i.e., the local domain), Diameter routing MUST be configured so that
	DER message reaches this server, even if the Destination-Realm is not		this ERP/DER message reaches that server, even if the Destination-
	the 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],
	this realm is the home domain of the peer in case of bootstrapping		this realm is the home domain of the peer in the case of
	exchange ('B' flag is set in ERP message) or the domain of the		bootstrapping exchange ('B' flag is set in ERP message) or the domain
	bootstrapped ER server otherwise .		of the 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 as specified in [RFC3588] and returned to the		MUST be generated as specified in [I-D.ietf-dime-rfc3588bis] and
	authenticator. The authenticator may cache this information (with		returned to the authenticator. The authenticator MAY cache this
	limited duration) to avoid further attempts for ERP with this realm.		information (with limited duration) to avoid further attempts to
	It may also fallback to full EAP authentication to authenticate the		execute ERP with this realm. It MAY also fallback to full EAP
	peer.		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 valid, unexpired root key matching the keyName part of
	AVP. If such key is found, the ER server processes the ERP message		the User-Name AVP. If such key is found, the ER server processes the
	as described in [RFC5296] then creates the ERP/DEA answer as		ERP message as described in [RFC5296] then creates the ERP/DEA answer
	described in Section 6. The rMSK is included in this answer.		as 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 RFC5296 [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.
	The ER server may or may not possess the root key in its local		The ER server may or may not possess the root key in its local
	database. If the EAP-Initiate/Re-Auth message has its 'B' flag set		database. If the EAP-Initiate/Re-Auth message has its 'B' flag set
	(Bootstrapping exchange) and the ER server possess the root key,the		(Bootstrapping exchange) and the ER server possesses the root key,
	ER server should respond directly to the peer that initiate ERP		the ER server SHOULD respond directly to the peer that initiated the
	exchange otherwise, Otherwise, the ER server should act as a proxy,		ERP exchange. Otherwise, the ER server SHOULD act as a proxy and
	and forwards the message to the home EAP server after changing its		forward the message to the home EAP server after changing its
	Application Id to Diameter EAP and adding the ERP-RK-Request AVP to		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 process.		request the root key. See Section 5 for more detail on 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 the authenticator might be configured to advertize
	configured to advertize this domain name, especially in the case of		this domain name, especially in the case of re-authentication after a
	re-authentication after a handover.		handover.
	The bootstrapping of an ER server with a given root key happens		The bootstrapping of an ER server with a given root key happens
	either during the initial EAP authentication of the peer when the		either during the initial EAP authentication of the peer when the
	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 immediately available for re-authentication of the peer,		server is immediately available for re-authentication of the peer,
	thus minimizing the re-authentication delay. On the other hand, it		thus minimizing the re-authentication delay. On the other hand, it
	is possible that only a small number of peers will use re-		is possible that only a small number of peers will use re-
	authentication in the visited domain. Deriving and caching key		authentication in the visited domain. Deriving and caching key
	material for all the peers (for example, for the peers that do not		material for all the peers (for example, for the peers that do not
	support ERP) is a waste 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)
	------------------------->		------------------------->
	skipping to change at page 7, line 10		skipping to change at page 7, line 10
	<-------------------------		<-------------------------
	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 authenticator creates the first DER of the full EAP		The authenticator creates the first DER of the full EAP
	authentication and send it to the ER server. The ER server proxies		authentication and sends it to the ER server. The ER server proxies
	the first DER of the full EAP authentication and adds the ERP-RK-		the first DER of the full EAP authentication and adds the ERP-RK-
	Request AVP inside, then forwards the request to the home EAP server.		Request AVP inside, then forwards the request to the home EAP server.
	If the home EAP server does not support the Diameter ERP extensions		If the home Diameter server does not support the Diameter ERP
	for ERP-RK-Request AVP, it simply ignores the ERP-RK-Request AVP and		extensions, it simply ignores the ERP-RK-Request AVP and continues as
	continues as specified in RFC 4072 [RFC4072]. If the server supports		specified in RFC 4072 [RFC4072]. If the server supports the ERP
	the ERP extensions, it saves the value of the ERP-Realm AVP found		extensions, it saves the value of the ERP-Realm AVP found inside the
	inside the ERP-RK-Request AVP, and continues with the EAP		ERP-RK-Request AVP, and continues with the EAP authentication. When
	authentication. When the authentication completes, if it is		the authentication completes, if it is successful and the EAP method
	successful and the EAP method has generated an EMSK, the server MUST		has generated an EMSK, the server MUST derive the rRK as specified in
	derive the rRK as specified in RFC 5296 [RFC5296], using the saved		RFC 5296 [RFC5296], using the saved domain name. It then includes
	domain name. It then includes the rRK inside a Key AVP Section 8.3		the rRK inside a Key AVP (Section 8.3) with the Key-Type AVP set to
	with the Key-Type AVP set to rRK, before sending the DEA as usual.		rRK, before sending the DEA as usual.
	When the ER server proxies a Diameter-EAP-Answer message with a		When the ER server proxies a Diameter-EAP-Answer message with a
	Session-Id corresponding to a message to which it added an ERP-RK-		Session-Id corresponding to a message to which it added an ERP-RK-
	Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine		Request AVP, and the Result-Code is DIAMETER_SUCCESS, it MUST examine
	the message and save and remove any Key AVP Section 8.3 with Key-Type		the message and save and remove any Key AVP (Section 8.3) with Key-
	AVP set to rRK. If the message does not contain such Key AVP, the ER		Type AVP set to rRK. If the message does not contain such Key AVP,
	server may cache the information that ERP is not possible for this		the ER server may cache the information that ERP is not possible for
	session to avoid possible subsequent attempts. In any case, the		this session to avoid possible subsequent attempts. In any case, the
	information stored in ER server concerning a session should not have		information stored in ER server concerning a session should not have
	a lifetime greater than the EMSK for this session.		a lifetime greater than the EMSK for this session.
	If the ER server is successfully bootstrapped, it should also add the		If the ER server is successfully bootstrapped, it should also add the
	ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the		ERP-Realm AVP after removing the Key AVP with Key-Type of rRK in the
	EAP/DEA message. This ERP-Realm information can be used by the		EAP/DEA message. This ERP-Realm information can be used by the
	authenticator to notify the peer that ER server is bootstrapped, and		authenticator to notify the peer that ER server is bootstrapped, and
	for which domain. How this information can be transmitted to the		for which domain. How this information can be transmitted to the
	peer is outside the scope of this document. This information needs		peer is outside the scope of this document. This information needs
	to be sent to the peer if both implicit and explicit bootstrapping		to be sent to the peer if both implicit and explicit bootstrapping
	mechanisms are possible, because the ERP message and the root key		mechanisms are possible, because the ERP message and the root key
	used for protecting this message are different in bootstrapping		used for protecting this message are different in bootstrapping
	exchanges and non-bootstrapping exchanges.		exchanges and non-bootstrapping exchanges.
	5.2. Bootstrapping During the First Re-authentication		5.2. Bootstrapping During the First Re-authentication
	Bootstrapping the ER server during the first re-authentication (also		Bootstrapping the ER server during the first re-authentication (also
	known as explicit bootstrapping) is only needed when there is no		known as explicit bootstrapping) is only needed when there is no
	local ER server in the visited domain and there is the ER server in		local ER server in the visited domain and there is an ER server in
	the home domain. It is less resource-consuming, since EMSK generated		the home domain. It is less resource-intensive, since the EMSK
	during initial EAP authentication is reused to derive root keys. On		generated during initial EAP authentication is reused to derive root
	the other hand, in that case first re-authentication requires a one-		keys. On the other hand, the first re-authentication requires a one-
	round-trip exchange with the home EAP server, since the EMSK is		round-trip exchange with the home EAP server, since the EMSK is
	generated during initial EAP authentication and never leaves the home		generated during the initial EAP authentication and never leaves the
	EAP server, which is less efficient than the implicit bootstrapping		home EAP server, which is less efficient than the implicit
	scenario.		bootstrapping scenario.
	The EAP-Initiate/Re-auth message is sent to the home ER server. The		The EAP-Initiate/Re-auth message is sent to the home ER server. The
	home ER server receives the ERP/DER message containing the EAP-		home ER server receives the ERP/DER message containing the EAP-
	Initiate/Re-Auth message with the 'B' flag set. It creates the new		Initiate/Re-Auth message with the 'B' flag set. It creates the new
	EAP/DER message using the received DRP/DER message and performs the		EAP/DER message using the received DRP/DER message and performs the
	following processing:		following processing:
	Set the Application Id in the header of the message as Diameter		Set the Application Id in the header of the message to <Diameter
	EAP Application (code 5).		EAP Application> [RFC4072]
	Extract ERP-RK-request from ERP/DER, which contains the name of		Extract the ERP-RK-Request AVP from the ERP/DER message, which
	domain where the ER server is located and add it into newly		contains the name of the domain where the ER server is located and
	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 server.		Diameter EAP application server.
	If the home EAP server does not support ERP extensions, it replies		If the home Diameter server does not support ERP extensions, it
	with an error since the encapsulated ERP-RK-request AVP is not		replies with an error since the encapsulated ERP-RK-Request AVP is
	understood. Otherwise, it processes the DSRK request as described in		not understood. Otherwise, it processes the DSRK request as
	[RFC5296]. In particular, it includes the Domain- Name TLV attribute		described in [RFC5296]. In particular, it includes the Domain- Name
	with the content from the ERP-Realm AVP. It creates the EAP/DEA		TLV attribute with the content from the ERP-Realm AVP. The server
	reply message [RFC4072]including an instance of the Key AVP Section		creates the EAP/DEA reply message [RFC4072] including an instance of
	8.3 with Key-Type AVP set to rRK. In particular, it includes the		the Key AVP (Section 8.3) with Key-Type AVP set to rRK and an
	Domain- Name TLV attribute with the content from the ERP-Realm AVP.		instance of the Domain-Name TLV attribute with the 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 (code		Set the Application Id back to Diameter ERP Application Id
	TBD)		(Section 11.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 implicit scenario.		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 EAP server		Authenticator ER server Home Diameter server
	============= ========= ===============		============= ========= ====================
	----------------------->		----------------------->
	Diameter ERP/DER		Diameter ERP/DER
	(EAP-Initiate)		(EAP-Initiate)
	------------------------>		------------------------>
	Diameter EAP/DER		Diameter EAP/DER
	(EAP-Response)		(EAP-Response)
	(ERP-RK-Request)		(ERP-RK-Request)
	<------------------------		<------------------------
	Diameter EAP/DEA		Diameter EAP/DEA
	skipping to change at page 10, line 17		skipping to change at page 10, line 45
	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 process as described in [RFC5296] with regards to the		the peer, the message is processed as described in [RFC5296] with
	EAP state machine. It creates a Diameter ERP/DER message following		regard to the EAP state machine. It creates a Diameter ERP/DER
	the general process of Diameter EAP [RFC4072], with the following		message following the general process of Diameter EAP [RFC4072], with
	differences:		the following differences:
	The Application Id in the header is set to Diameter ERP (code TBD		The Application Id in the header is set to <Diameter ERP> (code
	).		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
	Application.		ERP>.
	The keyName-NAI attribute from ERP message is used to create the		The keyName-NAI attribute from the ERP message is used to create
	content of User-Name AVP and Destination-Realm AVP.		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.		The EAP-Payload AVP contains the EAP-Initiate/Re-Auth meassge.
	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 RFC4072 [RFC4072], with the following		process 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>.
	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		If authentication is successful, 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 RFC5296 [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 the EAP-Payload AVP 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 a secure association protocol specific to
			the lower-layer in use.
	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 in the Capabilities-Exchange-Request and
	Exchange-Request and Capabilities-Exchange-Answer commands [RFC3588].		Capabilities-Exchange-Answer commands [I-D.ietf-dime-rfc3588bis].
	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.		The following sub-sections discuss 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 >
	skipping to change at page 12, line 18		skipping to change at page 12, line 45
	used to carry the rRK or rMSK and associated attributes. The usage		used to carry the rRK or rMSK and associated attributes. The usage
	of the Key AVP and its constituent AVPs in this application is		of the Key AVP and its constituent AVPs in this application is
	specified in the following sub-sections.		specified in the following sub-sections.
	8.3.1. Key-Type AVP		8.3.1. Key-Type AVP
	The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK.		The value of the Key-Type AVP MUST be set to 2 for rRK or 3 for rMSK.
	8.3.2. Keying-Material AVP		8.3.2. Keying-Material AVP
	The Keying-Material AVP contains rRK sent by the home EAP server to		The Keying-Material AVP contains the rRK sent by the home EAP server
	the ER server, in answer to a request containing an ERP-RK-Request		to the ER server, in answer to a request containing an ERP-RK-Request
	AVP, or the rMSK sent by ER server to authenticator. How this		AVP, or the rMSK sent by the ER server to the authenticator. How
	material is derived and used is specified in RFC 5296 [RFC5296].		this material is derived and used is specified in RFC 5296 [RFC5296].
	8.3.3. Key-Name AVP		8.3.3. Key-Name AVP
	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. Acknowledgements		9. Contributors
	Hannes Tschofenig wrote the initial draft for this document and
	provided useful reviews.
	Vidya Narayanan reviewed a rough draft version of the document and		Hannes Tschofenig wrote the initial draft of this document.
	found some errors.
	Lakshminath Dondeti contributed to the early versions of the		Lakshminath Dondeti contributed to the early versions of the
	document.		document.
			10. Acknowledgements
			Hannes Tschofenig provided useful reviews.
			Vidya Narayanan reviewed a rough draft version of the document and
			found some errors.
	Many thanks to these people!		Many thanks to these people!
	10. IANA Considerations		11. 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.
	10.1. Diameter Application Identifier		11.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].
	10.2. New AVPs		11.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
	RFC 3588 [RFC3588] 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.
	11. Security Considerations		12. Security Considerations
	The security considerations from the following documents apply here:		The security considerations from the following documents apply here:
	o RFC3588 [RFC3588]		o Fajardo, et al. [I-D.ietf-dime-rfc3588bis]
	o RFC4072 [RFC4072]		o RFC 4072 [RFC4072]
	o RFC5296 [RFC5296]		o RFC 5296 [RFC5296]
	o I-D.ietf-dime-local-keytran[I-D.ietf-dime-local-keytran]		o Zorn, Wu and Cakulev [I-D.ietf-dime-local-keytran]
	12. Normative References		13. Normative References
	[I-D.ietf-dime-local-keytran] Wu, Q., Zorn, G., and V. Cakulev,		[I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,
	"Diameter support for local key		"Diameter Attribute-Value Pairs for
	transport protocol between local		Cryptographic Key Transport",
	server and home AAA server",		draft-ietf-dime-local-keytran-14 (work
	draft-ietf-dime-local-keytran-09 (work		in progress), August 2011.
	in progress), April 2011.
			[I-D.ietf-dime-rfc3588bis] Fajardo, V., Arkko, J., Loughney, J.,
			and G. Zorn, "Diameter Base Protocol",
			draft-ietf-dime-rfc3588bis-29 (work in
			progress), August 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 15, line 4		skipping to change at page 15, line 35
	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		Sebastien Decugis
	Free Diameter		INSIDE Secure
	4-2-1 Nukui-Kitamachi		41 Parc Club du Golf
	Tokyo, Koganei 184-8795		Aix-en-Provence 13856
	Japan		France
			Phone: +33 (0)4 42 39 63 00
	EMail: sdecugis@freediameter.net		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
	Network Zen		Network Zen
	skipping to change at page 15, line 26		skipping to change at page 16, line 18
	China		China
	EMail: sunseawq@huawei.com		EMail: sunseawq@huawei.com
	Glen Zorn		Glen Zorn
	Network Zen		Network Zen
	227/358 Thanon Sanphawut		227/358 Thanon Sanphawut
	Bang Na, Bangkok 10260		Bang Na, Bangkok 10260
	Thailand		Thailand
	EMail: gwz@net-zen.net		EMail: glenzorn@gmail.com
End of changes. 67 change blocks.
	144 lines changed or deleted		155 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/