draft-ietf-dime-erp-06.txt		draft-ietf-dime-erp-07.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: November 5, 2011 S. Decugis		Expires: March 9, 2012 S. Decugis
	Free Diameter		Free Diameter
	Q. Wu		Q. Wu
	Huawei		Huawei
	G. Zorn		G. Zorn
	Network Zen		Network Zen
	May 4, 2011		September 6, 2011
	Diameter support for EAP Re-authentication Protocol (ERP)		Diameter support for EAP Re-authentication Protocol (ERP)
	draft-ietf-dime-erp-06.txt		draft-ietf-dime-erp-07.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 November 5, 2011.		This Internet-Draft will expire on March 9, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 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
	skipping to change at page 2, line 35		skipping to change at page 2, line 35
	6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 9		6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 9
	7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11		7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11
	8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 11		8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 11
	8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 11		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 . . . . . . . . . . . . . . . . . . . 12		8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 12
	9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
	10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		10.1. Diameter Application Identifier . . . . . . . . . . . . . 13
	11.1. Diameter Application Identifier . . . . . . . . . . . . . 14		10.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 13
	11.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 14		11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	12. Security Considerations . . . . . . . . . . . . . . . . . . . 14		12. Normative References . . . . . . . . . . . . . . . . . . . . . 13
	13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	13.2. Informative 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 4, line 19		skipping to change at page 4, line 19
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Assumptions		3. Assumptions
	This document assumes the existence of at most one logical ER server		This document assumes the existence of at most one logical ER server
	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.		interchangeably. If multiple ER servers are deployed across the
			domains, we assume only one ER server that is near to the peer is
			getting involved in the ERP.
			Also this document assumes the existence of at most one EAP server
			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
			home EAP server, the ER server may cache the Destination-Host AVP
			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 |
	skipping to change at page 4, line 47		skipping to change at page 5, line 7
	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 reaches 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 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 case of bootstrapping
	exchange ('B' flag is set in ERP message) or the domain of the		exchange ('B' flag is set in ERP message) or the domain of 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
	skipping to change at page 5, line 26		skipping to change at page 5, line 35
	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 [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 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.
	If the EAP-Initiate/Re-Auth message has its 'B' flag set		The ER server may or may not possess the root key in its local
	(Bootstrapping exchange), the ER server should not possess the root		database. If the EAP-Initiate/Re-Auth message has its 'B' flag set
	key in its local database. In this case, the ER server acts as a		(Bootstrapping exchange) and the ER server possess the root key,the
	proxy, and forwards the message to the home EAP server after changing		ER server should respond directly to the peer that initiate ERP
	its Application Id to Diameter EAP and adding the ERP-RK-Request AVP		exchange otherwise, Otherwise, the ER server should act as a proxy,
	to request the root key. See section Section 5 for more detail on		and forwards the message to the home EAP server after changing its
	this process.		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.
	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 9		skipping to change at page 6, line 17
	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 immediatly 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.
	skipping to change at page 6, line 44		skipping to change at page 7, line 4
	<-------------------------		<-------------------------
	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 authenticator creates the first DER of the full EAP
	and adds the ERP-RK-Request AVP inside, if this AVP is not already in		authentication and send it to the ER server. The ER server proxies
	the message (which might happen if there are several ER servers on		the first DER of the full EAP authentication and adds the ERP-RK-
	the path), then forwards the request.		Request AVP inside, then forwards the request to the home EAP server.
	If the EAP server does not support the ERP extensions, it simply		If the home EAP server does not support the Diameter ERP extensions
	ignores the ERP-RK-Request AVP and continues as specified in RFC 4072		for ERP-RK-Request AVP, it simply ignores the ERP-RK-Request AVP and
	[RFC4072]. If the server supports the ERP extensions, it saves the		continues as specified in RFC 4072 [RFC4072]. If the server supports
	value of the ERP-Realm AVP found inside the ERP-RK-Request AVP, and		the ERP extensions, it saves the value of the ERP-Realm AVP found
	continues with the EAP authentication. When the authentication		inside the ERP-RK-Request AVP, and continues with the EAP
	completes, if it is successful and the EAP method has generated an		authentication. When the authentication completes, if it is
	EMSK, the server MUST derive the rRK as specified in RFC 5296		successful and the EAP method has generated an EMSK, the server MUST
	[RFC5296], using the saved domain name. It then includes the rRK		derive the rRK as specified in RFC 5296 [RFC5296], using the saved
	inside a Key AVP Section 8.3 with the Key-Type AVP set to rRK, before		domain name. It then includes the rRK inside a Key AVP Section 8.3
	sending the DEA as usual.		with the Key-Type AVP set to 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-Type
	AVP set to rRK. If the message does not contain such Key AVP, the ER		AVP set to rRK. If the message does not contain such Key AVP, the ER
	server may cache the information that ERP is not possible for this		server may cache the information that ERP is not possible for this
	session to avoid possible subsequent attempts. In any case, the		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.
	skipping to change at page 7, line 40		skipping to change at page 7, line 49
	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 less resource-consuming, since		known as explicit bootstrapping) is only needed when there is no
	root keys are generated and cached only when needed. On the other		local ER server in the visited domain and there is the ER server in
	hand, in that case first re-authentication requires a one-round-trip		the home domain. It is less resource-consuming, since EMSK generated
	exchange with the home EAP server, which is less efficient than the		during initial EAP authentication is reused to derive root keys. On
	implicit bootstrapping scenario.		the other hand, in that case first re-authentication requires a one-
			round-trip exchange with the home EAP server, since the EMSK is
	The ER server receives the ERP/DER message containing the EAP-		generated during initial EAP authentication and never leaves the home
	Initiate/Re-Auth message with the 'B' flag set. It proxies this		EAP server, which is less efficient than the implicit bootstrapping
	message, and performs the following processing in addition to		scenario.
	standard proxy operations:
	Changes the Application Id in the header of the message to
	Diameter EAP Application (code 5).
	Change the content of Application-Auth-Id accordingly.
	QUESTION: Is it better to leave it unmodified, so that the server		The EAP-Initiate/Re-auth message is sent to the home ER server. The
	can easily differenciate between ERP and standard EAP message?		home ER server receives the ERP/DER message containing the EAP-
			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
			following processing:
	Add the ERP-RK-Request AVP, which contains the name of the domain		Set the Application Id in the header of the message as Diameter
	where the ER server is located.		EAP Application (code 5).
	PROBLEM: Add the Destination-Host AVP to reach the appropriate		Extract ERP-RK-request from ERP/DER, which contains the name of
	Diameter EAP server in case there is more than one in destination		domain where the ER server is located and add it into newly
	domain, the one with the EMSK. How does the ER server know this		created ERP/DER message.
	information? Or can we require that all Diameter EAP servers can
	be used interchangeably for this purpose?
	Then the proxied EAP/DER request 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 server.
	If the home EAP server does not support ERP extensions, it replies		If the home EAP server does not support ERP extensions, it replies
	with an error since the encapsulated EAP-Initiate/Re-auth command is		with an error since the encapsulated ERP-RK-request AVP is not
	not understood. Otherwise, it processes the ERP request as described		understood. Otherwise, it processes the DSRK request as described in
	in [RFC5296]. In particular, it includes the Domain- Name TLV		[RFC5296]. In particular, it includes the Domain- Name TLV attribute
	attribute with the content from the ERP-Realm AVP. It creates the		with the content from the ERP-Realm AVP. It creates the EAP/DEA
	EAP/DEA reply message [RFC4072]. including an instance of the Key AVP		reply message [RFC4072]including an instance of the Key AVP Section
	Section 8.3 with Key-Type AVP set to rRK.		8.3 with Key-Type AVP set to rRK. In particular, it includes 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 ERPApplication Id (code		Set the Application Id back to Diameter ERP Application 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-Response)
	(ERP-RK-Request)		(ERP-RK-Request)
	<------------------------		<------------------------
	Diameter EAP/DEA		Diameter EAP/DEA
	(EAP-Finish)		(EAP-Success)
	(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
	skipping to change at page 10, line 18		skipping to change at page 10, line 18
	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, 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 ERP/DER message following
	following the general process of Diameter EAP [RFC4072], with the		the general process of Diameter EAP [RFC4072], with the following
	following differences:		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 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.
	The Auth-Request-Type AVP content is set to [Editor's note: FFS].		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.
	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		processing described in RFC4072 [RFC4072], with the following
	differences:		differences:
	skipping to change at page 12, line 34		skipping to change at page 12, line 34
	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. Open issues		9. Acknowledgements
	This document does not address some known issues in Diameter ERP
	mechanism. The authors would like to hear ideas about how to address
	them.
	The main issue is the use of ERP for authentication after a handover
	of the peer to a new authenticator (or different authenticator port).
	Diameter ERP is not meant to be a mobility application. A number of
	issues appear when we try to do handover while using Diameter ERP:
	how to manage the Session-Id AVP -- is it a new session each time,
	or do we try to reuse the same Diameter session?;
	how does the ER authenticator acquire the Authorization AVPs? Is
	it cached in the Diameter ER server (received during
	bootstrapping) or do we use first Authenticate-Only with ER
	server, then Authorize-Only with home domain (and in that case how
	does the ER authenticator learn what the home domain is?)
	how does the peer learn the ERP domain of the new authenticator --
	this is being addressed in HOKEY architecture draft;
	how does the home server reachs the peer to for example terminate
	the session if there is no notification sent to the home domain;
	Another issue concerns the case where the home realm contains several
	EAP servers. In multi rounds full EAP authentication, the
	Destination-Host AVP provides the solution to reach the same server
	across the exchanges. Only this server possess the EMSK for the
	session. In case of explicit bootstrapping, the ER server must
	therefore be able to reach the correct server to request the DSRK. A
	solution might consist in saving the Origin-Host AVP of all
	successful EAP/DEA in the ER server, which is a bit similar to the
	implicit bootstrapping scenario described here -- only we save the
	server name instead of the root key, and we must then be able to
	match the DSRK with the user name.
	In roaming environments, it might be useful that a broker provides
	ERP services. The security implications of storing the DSRK
	generated for the visited domain into the broker's server should be
	studied.
	Finally, this document currently lacks a description of what happens
	when a Re-Auth-Request is received for a peer on the authenticator.
	10. Acknowledgements
	Hannes Tschofenig wrote the initial draft for this document and		Hannes Tschofenig wrote the initial draft for this document and
	provided useful reviews.		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.
	Lakshminath Dondeti contributed to the early versions of the		Lakshminath Dondeti contributed to the early versions of the
	document.		document.
	Many thanks to these people!		Many thanks to these people!
	11. IANA Considerations		10. 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		10.1. Diameter Application Identifier
	This specification requires IANA to allocate a new value "Diameter		This specification requires IANA to allocate a new value "Diameter
	ERP" 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		10.2. New AVPs
	This specification requires IANA to allocate new values from the "AVP		This specification requires IANA to allocate new values from the "AVP
	Codes" registry according to the policy specified in Section 11.1 of		Codes" registry according to the policy specified in Section 11.1 of
	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		11. Security Considerations
	The security considerations from the following documents apply here:		The security considerations from the following documents apply here:
	o RFC3588 [RFC3588]		o RFC3588 [RFC3588]
	o RFC4072 [RFC4072]		o RFC4072 [RFC4072]
	o RFC5247 [RFC5247]
	o RFC5295 [RFC5295]
	o RFC5296 [RFC5296]		o RFC5296 [RFC5296]
	FFS: Do we really respect these security considerations with the		o I-D.ietf-dime-local-keytran[I-D.ietf-dime-local-keytran]
	mechanism we describe here? Is it safe to use ERP-RK-Request & Key
	AVPs? What is the worst case? For example if a domain tricks the
	peer into beliving it is located in a different domain?
	EAP channel bindings may be necessary to ensure that the Diameter
	client and the server are in sync regarding the key Requesting
	Entity's Identity. Specifically, the Requesting Entity advertises
	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
	communicates that identity to the Diameter server) via the EAP method
	for user/peer to server verification of the Requesting Entity's
	Identity.
	QUESTION: What does this paragraph actually mean?
	13. References
	13.1. Normative References		12. Normative References
	[I-D.ietf-dime-local-keytran] Wu, Q., Zorn, G., and V. Cakulev,		[I-D.ietf-dime-local-keytran] Wu, Q., Zorn, G., and V. Cakulev,
	"Diameter support for local key		"Diameter support for local key
	transport protocol between local		transport protocol between local
	server and home AAA server",		server and home AAA server",
	draft-ietf-dime-local-keytran-09 (work		draft-ietf-dime-local-keytran-09 (work
	in progress), April 2011.		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",
	skipping to change at page 15, line 46		skipping to change at page 14, line 26
	V., and M. Nakhjiri, "Specification		V., and M. Nakhjiri, "Specification
	for the Derivation of Root Keys from		for the Derivation of Root Keys from
	an Extended Master Session Key		an Extended Master Session Key
	(EMSK)", RFC 5295, August 2008.		(EMSK)", RFC 5295, August 2008.
	[RFC5296] Narayanan, V. and L. Dondeti, "EAP		[RFC5296] Narayanan, V. and L. Dondeti, "EAP
	Extensions for EAP Re-authentication		Extensions for EAP Re-authentication
	Protocol (ERP)", RFC 5296,		Protocol (ERP)", RFC 5296,
	August 2008.		August 2008.
	13.2. Informative References
	[RFC5247] Aboba, B., Simon, D., and P. Eronen,
	"Extensible Authentication Protocol
	(EAP) Key Management Framework",
	RFC 5247, August 2008.
	URIs
	[1] <http://www.iana.org/assignments/aaa-parameters/>		[1] <http://www.iana.org/assignments/aaa-parameters/>
	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
End of changes. 32 change blocks.
	156 lines changed or deleted		85 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/