--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/New_ERP_draft.txt	Tue Mar 17 17:23:13 2009 +0900
@@ -0,0 +1,166 @@
+=====================
+changeset:   5:5fc766d71da4
+parent:      3:e7bcb9ee39b5
+user:        Sebastien Decugis <sdecugis@nict.go.jp>
+date:        Tue Mar 17 17:22:52 2009 +0900
+summary:     Temporary status, scenarios must be developped a little more. The basic ideas are present already. For early comments.
+
+changeset:   3:e7bcb9ee39b5
+user:        Sebastien Decugis <sdecugis@nict.go.jp>
+date:        Tue Mar 17 14:20:38 2009 +0900
+summary:     Document to present alternative design for Diameter ERP, initial commit (incomplete work)
+
+=====================
+*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 server. [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 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.
+
+
+
+*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.
+
+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.
+
+
+
+*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?
+
+
+
+