=====================
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?