--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/New_ERP_draft_src.txt	Tue Mar 17 14:20:38 2009 +0900
@@ -0,0 +1,41 @@
+Abstract
+
+The EAP Re-authentication Protocol [RFC5296] provides an optimization for EAP authentication when a peer moves from an authenticator to another. This protocol assumes that a AAA protocol is available to transport the ERP messages between authenticator and ER servers. [draft-gaonkar-radext-erp-attrs-03] specifies the transport of ERP using RADIUS. This document specifies the transport of ERP using Diameter [RFC3588].
+
+
+Differences with [draft-ietf-dime-erp-00]
+
+In this document, we specify a new Diameter application ID for Diameter messages transporting ERP exchanges. We also re-use the mechanism described in [draft-ietf-dime-erp-00]  as an option available to provide implicit bootstrapping to the local ER server.
+
+
+Introduction.
+
+During full EAP authentication, both the peer and the home EAP server derive EMSK material in addition to MSK. The EMSK can be used to derive a re-authentication root key (rRK or rDSRK) as described in [RFC5296]. This root key is transported to an ER server, this is called bootstrapping of the ER server. When the peer re-authenticates, a one round-trip exchange occurs with this ER server and new rMSK material is derived. The ER server may be located in the visited domain or home domain. 
+
+There are two types of exchanges involved in the Re-authentication mechanism: transport of the re-authentication root key between the home EAP server and the ER server to bootstrap the mechanism, and communication between authenticator and ER server to derive new rMSK material during re-authentication. This document specifies how both types of exchanges can be transported using Diameter. Some architectural considerations are also given.
+
+
+Overview
+
+We define a new Diameter Application ID for ERP. When the authenticator receives a EAP-Initiate/Re-auth message, it encapsulates in a DER message following the rules described in [RFC4072]. The application id of the DER message is set to this new ERP application ID. The User-Name and Destination-Realm AVPs are extracted from the keyName-NAI included in the ERP message, as described in [RFC5296]. In the case were ERP is already bootstrapped in this domain, the Destination-Realm of the message is the local domain. In the case were the peer is initiating a bootstrapping ERP exchange, the Destination-Realm is the home domain.
+
+When ERP is already bootstrapped, the message is routed to the ER server in the local domain. This server processes the ERP message as described in [RFC5296] then derives a new rMSK and answers a DEA encapsulating the EAP-Finish/Re-auth answer and the rMSK for the authenticator.
+
+There are several options to bootstrap the local ER server. This document discusses some of the options, but a deployment may use a different mechanism not described here.
+
+
+
+
+
+
+Assumptions.
+
+For the peer to start an ERP exchange when attaching to a new authenticator, the following assumptions must be verified. Note that the peer can always fall back to full EAP authentication if one of these conditions is not met.
+
+The peer must have non-expired keying material (EMSK) derived from a previous full EAP authentication.
+
+The peer must learn the realm of the new authenticator before starting the exchange. If this condition is not met, the peer cannot assume that a ER server is available and bootstrapped in the domain of this authenticator, and should start a bootstrapping exchange as described in [RFC5296]. In addition, if the peer is attaching to this realm for the first time since the EMSK was derived (inter-domain handover), a bootstrapping exchange must be initiated.
+
+The authenticator must support ERP extensions. If this condition is not met, the ERP messages will be dropped by the authenticator conforming to [RFC4072] and ERP will fail.
+
+