--- a/New_ERP_draft.txt	Wed Mar 18 14:06:05 2009 +0900
+++ b/New_ERP_draft.txt	Wed Mar 18 14:04:55 2009 +0900
@@ -1,4 +1,15 @@
 =====================
+changeset:   9:5fdd3345477f
+tag:         tip
+user:        Sebastien Decugis <sdecugis@nict.go.jp>
+date:        Wed Mar 18 14:06:05 2009 +0900
+summary:     Cleanups.
+
+changeset:   8:45a13fe6e0be
+user:        Sebastien Decugis <sdecugis@nict.go.jp>
+date:        Wed Mar 18 13:21:39 2009 +0900
+summary:     Completed initial description of the mechanism for explicit bootstrapping and implicit during Diameter EAP authentication.
+
 changeset:   5:5fc766d71da4
 parent:      3:e7bcb9ee39b5
 user:        Sebastien Decugis <sdecugis@nict.go.jp>
@@ -25,9 +36,9 @@
 *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.
+messages transporting ERP exchanges between authenticator and ER server. We 
+re-use the mechanism described in [draft-ietf-dime-erp-00] as an option 
+available to provide implicit bootstrapping to the ER server.
 
 
 
@@ -37,49 +48,27 @@
 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.
+When the peer re-authenticates using ERP, a one round-trip exchange occurs 
+between the authenticator and the ER server, where 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.
+There are two types of exchanges between AAA entities 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 transport of ERP 
+messages and rMSK material between ER server and authenticator. This document 
+specifies how the re-authentication exchange is transported using Diameter. It 
+also provides information on how bootstrapping can be achieved in several 
+situations.
 
                         Diameter                    +--------+
         +-------------+   ERP   +-----------+  (*)  |  Home  |
 Peer <->|Authenticator|<=======>| ER server | <---> |  EAP   |
         +-------------+         +-----------+       | server |
                                                     +--------+
-(*) The protocol used here depends on situation.
-
-
-
-*Overview*
+(*) Several protocols can be used between ER server and home EAP server to 
+transport bootstrapping material. Diameter EAP is one of the possibilities.
 
-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.
+    Figure 1. Diameter applications used in the ERP mechanism.
 
 
 
@@ -87,17 +76,19 @@
 
 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.
+back to full EAP authentication if one of these conditions is not met. These 
+assumptions are implicit from [RFC5296].
 
 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.
+exchange, for example using L2-dependent mechanism. If this condition is not 
+met, the peer cannot assume that an ER server is available and bootstrapped in 
+the realm of this authenticator. It should start an ERP 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), an ERP 
+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] 
@@ -105,6 +96,54 @@
 
 
 
+*Overview*
+
+We define a new Diameter Application ID for ERP. When the authenticator 
+receives an EAP-Initiate/Re-auth message, it encapsulates it in a DER message 
+following the rules described in [RFC4072]. The application id of the DER 
+message is set to the Diameter 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 other cases, 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 bootstrapped ER 
+server. 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}. This exchange is described in 
+Figure 2 bellow.
+
+There are several options to bootstrap the ER server. This document discusses 
+some of the options, but a different mechanism not described here may be 
+deployed as well. See the following sections for more details about 
+bootstrapping scenarii.
+
+
+ Peer                 Authenticator                        ER server
+ ====                 =============                      (bootstrapped)
+ [ <------------------------         ]               (local or home domain)
+ [optional EAP-Initiate/Re-auth-start]               ======================
+
+   ----------------------->
+     EAP-Initiate/Re-auth
+                           =====================================>
+                                 Diameter ERP, cmd code DER
+                                   User-Name: Keyname-NAI
+                               EAP-Payload: EAP-Initiate/Re-auth
+ 
+                           <=====================================
+                                 Diameter ERP, cmd code DEA
+                               EAP-Payload: EAP-Finish/Re-auth
+                                EAP-Master-Session-Key: rMSK
+    <----------------------
+      EAP-Finish/Re-auth
+
+    Figure 2. Diameter ERP exchange.
+
+
+
 *Bootstrapping*
 
 The purpose of bootstrapping is to provide the keying material to the ER 
@@ -116,26 +155,129 @@
 *Scenario 1: explicit bootstrapping*
 
 As described in [RFC5296], an explicit bootstrapping exchange can be initiated 
-by the peer.
+by the peer. In this case, the realm part of the Keyname-NAI is the home domain 
+of the peer.
+
+The authenticator processes the ERP as described in the overview: encapsulate 
+the ERP message in a DER command with application-id set to Diameter ERP. The 
+Destination-Realm extracted from Keyname-NAI is the home domain.
+
+If an ER server is located in the local domain, it should proxy the request and 
+process as described bellow. Otherwise the request is sent to the ER server in 
+the home domain.
+
+When the ER server (in local or home domain) receives the ERP/DER request, it 
+must process as follow:
+- Check in the local key store if a key with same name is available. If such 
+key is found, process the request locally and answer.
+- Check if the EAP-Initiate/Re-auth message has the [B] (bootstrapping) flag 
+set. If this flag is not set, relay the message without altering it (except 
+adding the Route-Record information) or reply with an error if no other 
+Diameter node is available to handle the request, following the rules of 
+Diameter Base Protocol.
+- If the [B] flag was set, the message is proxied locally and modified as 
+follow:
+ * Change the application-id of the message from Diameter ERP to Diameter EAP 
+(so that the message will reach the Home EAP server).
+ * Add the ERP-RK-Request AVP, defined in this document.
+ * Send the new message. It will reach the Home EAP server.
 
-{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?}
+If the home EAP server does not support ERP extensions, it replies with an 
+error since encapsulated EAP-Initiate/Re-auth command is not understood. 
+Otherwise, it processes the EAP-Initiate/Re-auth message as described in 
+[RFC5296] and derives the requested rDSRK or rRK, and new rMSK. It sends this 
+material using the new ERP-RK-Answer AVP described in this document. It also 
+includes the realm of the ER server in the EAP-Finish/Re-auth message to inform 
+the peer of the location of the ER server.
+
+The ER server receives this DEA, extracts and cache the rRK or rDSRK material, 
+restores the application-id to Diameter ERP and forwards the message to the 
+authenticator.
+
+This flow is captured figure 3.
+
+Authenticator            ER server             Home EAP server
+=============            =========             ===============
+      ----------------------->
+            ERP/DER
+         (EAP-Initiate)
+                              ------------------------>
+                                        EAP/DER
+                                     (EAP-Initiate)
+                                    (ERP-RK-Request)
+
+                              <------------------------
+                                        EAP/DEA
+                                      (EAP-Finish)
+                                     (ERP-RK-Answer)
+                                         (rMSK)
+      <----------------------
+           ERP/DEA
+         (EAP-Finish)
+            (rMSK)
+
+    Figure 3. ERP explicit bootstrapping message flow.
 
 
-*Scenario 2: peer in its home domain*
+
+*Scenario 2: implicit bootstrapping during full EAP authentication*
+
+In some deployment scenarii, the ER server may be collocated with an EAP proxy 
+or server. In that case, the optional ERP AVPs defined in this document may be 
+used during initial full EAP authentication to provide implicit bootstrapping 
+(section 5.1 of [RFC5296]) as described bellow. 
+
+In this scenario, the ERP key material is derived and cached regardless of the 
+peer support and willingness for ERP. This may lead to scalability and other 
+issues. Implementors may provide other ways to select which sessions should use 
+implicit bootstrapping.
+
+In the first round of full EAP exchange, the ER server adds the ERP-RK-Request 
+AVP to the DER message. 
+If the home EAP server supports ERP extensions, it caches this request and 
+continues the normal EAP authentication until completion. Otherwise, the 
+optional AVP is simply ignored.
+When the authentication is successful and EMSK is generated, the home EAP 
+server derives the rRK or rDSRK as requested, and adds this material to the 
+last DEA in the ERP-RK-Answer AVP defined in this document. The server may 
+check that the ER server that requested the material is in the Route-Record 
+list of the last DER, but this is not mandatory.
 
-{Should be quite similar to scenario 1...}
+When the ER server collocated with EAP proxy receives the DEA containing 
+ERP-RK-Answer AVP, it extracts this AVP and saves the rRK or rDSRK material for 
+later use.
+
+                         EAP Proxy /
+Authenticator             ER server               Home EAP server
+=============            ===========              ===============
+     ------------------------->
+             EAP/DER
+          (EAP-Response)
+                               ------------------------->
+                                       EAP/DER
+                                   (EAP-Response)
+                                  (ERP-RK-Request)
+
+     <==================================================>
+            Multi-round EAP exchanges, unmodified
+
+                               <-------------------------
+                                       EAP/DEA
+                                    (EAP-Success)
+                                        (MSK)
+                                   (ERP-RK-Answer)
+     <-------------------------
+              EAP/DEA
+           (EAP-Success)
+               (MSK)
+
+    Figure 4. Implicit ERP bootstrapping during full EAP authentication.
 
 
-*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*
 
-*Scenario 4: Case of MIP6 ?*
-
-{TODO: study this case}
+{TODO: study this case ?}
 
 
 *Scenario 5: Other possibilities*
@@ -145,6 +287,78 @@
 
 
 
+*Commands and AVPs*
+
+This document does not define a new command. It reuses the Diameter-EAP-Request 
+and Diameter-EAP-Answer as defined in [RFC4072]. It is also compatible with 
+extensions defined in [draft-ietf-dime-mip6-split-16].
+
+   Command-Name          Abbrev. Code Reference Application
+   ---------------------------------------------------------
+   Diameter-EAP-Request  DER     268  RFC 4072  Diameter ERP
+   Diameter-EAP-Answer   DEA     268  RFC 4072  Diameter ERP
+
+                          Figure 5: Command Codes
+The following new AVPs are defined in this document.
+
+
+
+*ERP-RK-Request AVP*
+
+The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. It is used by the 
+ER server to request root key material used in ERP.
+
+This AVP has the M and V bits cleared.
+
+      ERP-RK-Request ::= < AVP Header: TBD >
+                         { ERP-Realm }
+                       * [ AVP ]
+
+
+
+*ERP-Realm AVP*
+
+The ERP-Realm AVP (AVP Code TBD) is of type {DiameterIdentity? OctetString?}. 
+It contains the name of the realm in which the ER server is located.
+{FFS: We may re-use Origin-Realm here instead?}
+
+
+
+*ERP-RK-Answer AVP*
+
+The ERP-RK-Answer AVP (AVP Code TBD) is of type grouped AVP. It is used by the 
+home EAP server to provide ERP root key material to the ER server.
+
+This AVP has the M and V bits cleared.
+
+       ERP-RK-Answer ::= < AVP Header: TBD >
+                         { ERP-RK }
+                         { ERP-RK-Name }
+                         { ERP-RK-Lifetime }
+                       * [ AVP ]
+
+
+*ERP-RK AVP*
+
+The ERP-RK AVP (AVP Code TBD) is of type OctetString. It contains the root key 
+(either rRK or rDSRK) to be used for ERP with the peer to which this session 
+belongs. How this material is derived and used is specified in [RFC5296].
+
+
+
+*ERP-RK-Name AVP*
+
+The ERP-RK AVP (AVP Code TBD) is of type OctetString. This AVP contains the 
+EMSKname which identifies the keying material. How this name is derived is 
+beyond the scope of this document and defined in [RFC5296].
+
+
+
+*ERP-RK-Lifetime AVP*
+
+The ERP-RK-Lifetime AVP (AVP Code TBD) is of type {Unsigned64? 32?} and 
+contains the root key material lifetime in seconds.
+
 
 
 *Pending question on accounting and sessions.*
@@ -154,13 +368,18 @@
 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?
 
+It is possible to cache the necessary information at the ER server level. Is it 
+useful to specify this mechanism in this document?
 
 
 
+