# HG changeset patch # User Sebastien Decugis # Date 1237278193 -32400 # Node ID 9ffe45ad7651d6bf6c51824ae4cac7a73eff52fb # Parent a771a5c46d743e05ab6c79b432960fc6b46babc8 Add temporary formated document diff -r a771a5c46d74 -r 9ffe45ad7651 New_ERP_draft.txt --- /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 +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 +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? + + + +