*Status of this Memo*

This is a work document intended to present ideas for a possible future 
Internet-Draft in the DIME working-group.
The copyright for this memo is writen by the end of the document (same as 
Internet-Drafts)



*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 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.



*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 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 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 |
                                                    +--------+
(*) Several protocols can be used between ER server and home EAP server to 
transport bootstrapping material. Diameter EAP is one of the possibilities.

    Figure 1. Diameter applications used in the ERP mechanism.



*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. 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, 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] 
and ERP will fail.



*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.

                                                           ER server
                                                         (bootstrapped)
 Peer                 Authenticator                  (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 
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. 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.

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
=============            =========             ===============
      ----------------------->
          Diameter ERP/DER
           (EAP-Initiate)
                              ------------------------>
                                    Diameter EAP/DER
                                     (EAP-Initiate)
                                    (ERP-RK-Request)

                              <------------------------
                                    Diameter EAP/DEA
                                      (EAP-Finish)
                                     (ERP-RK-Answer)
                                         (rMSK)
      <----------------------
          Diameter ERP/DEA
            (EAP-Finish)
               (rMSK)

    Figure 3. ERP explicit bootstrapping message flow.



*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.

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
=============            ===========              ===============
     ------------------------->
         Diameter EAP/DER
          (EAP-Response)
                               ------------------------->
                                  Diameter EAP/DER
                                   (EAP-Response)
                                  (ERP-RK-Request)

     <==================================================>
        Multi-round Diameter EAP exchanges, unmodified

                               <-------------------------
                                   Diameter EAP/DEA
                                    (EAP-Success)
                                        (MSK)
                                   (ERP-RK-Answer)
     <-------------------------
         Diameter EAP/DEA
           (EAP-Success)
               (MSK)

    Figure 4. Implicit ERP bootstrapping during full EAP authentication.



*Scenario 3: Case of MIP6*

{TODO: study this case ?}



*Scenario 4: Other possibilities*

{In case implementation-specific solution is retained, list here the 
constraints?}



*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.*

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?

It is possible to cache the necessary information at the ER server level. Is it 
useful to specify this mechanism in this document?



*Full Copyright Statement*

   Copyright (C) The IETF Trust (2008).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


=====================
  History:
changeset:   17:8b6e98eec7ef
parent:      14:1c2d1b7327af
user:        Sebastien Decugis <sdecugis@nict.go.jp>
date:        Thu Mar 19 10:46:29 2009 +0900
summary:     Added copyright and status before publishing.

changeset:   13:aa31cf892b1b
parent:      11:c8dd0bdbd9e6
user:        Sebastien Decugis <sdecugis@nict.go.jp>
date:        Wed Mar 18 14:21:19 2009 +0900
summary:     Yet more cleanups...

changeset:   11:c8dd0bdbd9e6
user:        Sebastien Decugis <sdecugis@nict.go.jp>
date:        Wed Mar 18 14:16:22 2009 +0900
summary:     More cleanups.

changeset:   9:5fdd3345477f
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>
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)

=====================