--- a/New_ERP_draft_src.txt	Tue Mar 17 14:20:38 2009 +0900
+++ b/New_ERP_draft_src.txt	Tue Mar 17 17:22:52 2009 +0900
@@ -1,34 +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].
+*Abstract*
 
-
-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.
+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 server. [draft-gaonkar-radext-erp-attrs-03] specifies the transport of ERP using RADIUS. This document specifies the transport of ERP using Diameter [RFC3588].
 
 
-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.
+*Differences with [draft-ietf-dime-erp-00]*
 
-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.
+In this document, we specify a new Diameter application ID for Diameter messages transporting ERP exchanges. We re-use the mechanism described in [draft-ietf-dime-erp-00] as an option available to provide implicit bootstrapping to the 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 the ER server. When the peer re-authenticates, a one round-trip exchange occurs between the authenticator and 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 the re-authentication exchange is transported using Diameter. It also contains information on how bootstrapping exchange can be transported with Diameter. Some architectural considerations are given.
+
+                        Diameter                    +--------+
+        +-------------+   ERP   +-----------+  (*)  |  Home  |
+Peer <->|Authenticator|<=======>| ER server | <---> |  EAP   |
+        +-------------+         +-----------+       | server |
+                                                    +--------+
+(*) The protocol used here depends on situation.
 
 
 
-Assumptions.
+*Overview*
+
+We define a new Diameter Application ID for ERP. When the authenticator receives an 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 the 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, and the peer knows it, the Destination-Realm of the message is the local domain. In the other case, the peer is initiating a bootstrapping ERP exchange, and 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. Re-authentication is complete {see pending question in the end of this document}.
+
+There are several options to bootstrap the local ER server. This document discusses some of the options, but a different mechanism not described here may be deployed as well. See the specific sections for more details about bootstrapping scenarii.
+
+
+
+*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.
 
@@ -39,3 +46,49 @@
 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.
 
 
+
+*Bootstrapping*
+
+The purpose of bootstrapping is to provide the keying material to the ER server. This keying material is rRK (directly derived from EMSK) when the ER server is in the peer's home domain. The keying material is rDSRK (derived from DSRK, itself derived from EMSK) when the ER server is in the visited domain.
+
+
+*Scenario 1: explicit bootstrapping*
+
+As described in [RFC5296], an explicit bootstrapping exchange can be initiated by the peer.
+
+{TODO: not sure what happens when the DER with ERP app id reaches the ER server; do we change the app id to EAP to reach the home EAP server?}
+
+
+*Scenario 2: peer in its home domain*
+
+{Should be quite similar to scenario 1...}
+
+
+*Scenario 3: implicit bootstrapping during full EAP authentication*
+
+{TODO: here we reuse what is described in draft-ietf-dime-erp-00. Maybe add a note on unconditional bootstrapping even for peers not supporting ERP?}
+
+
+*Scenario 4: Case of MIP6 ?*
+
+{TODO: study this case}
+
+
+*Scenario 5: Other possibilities*
+
+{In case implementation-specific solution is retained, list here the constraints?}
+
+
+
+
+
+*Pending question on accounting and sessions.*
+
+During initial full EAP authentication, the identity of the peer is used to create the Session-Id AVP, which is then used during accounting.
+When the peer attaches to a new authenticator and performs ERP, its identity is not disclosed to the authenticator. Instead, the peer presents the Keyname-NAI. This identifiers contains the EMSKName as user part.
+The new authenticator will therefore derive the new Session-Id from this EMSKName and use this for accounting purpose.
+Although the home EAP server is able to link EMSKName with the peer's identity, the other Diameter entities do not have this mapping. In particular, the realm part of Keyname-NAI is the visited network. How does the authenticator figures out that the account records must be sent to the home domain of the peer?
+
+
+
+