# HG changeset patch # User Sebastien Decugis # Date 1237352695 -32400 # Node ID 4f4591406a24fc1407eaf924430e506755bd5503 # Parent 5fdd3345477f294ad32eb028dfc49355956dd87b Update to latest diff -r 5fdd3345477f -r 4f4591406a24 New_ERP_draft.txt --- 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 +date: Wed Mar 18 14:06:05 2009 +0900 +summary: Cleanups. + +changeset: 8:45a13fe6e0be +user: Sebastien Decugis +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 @@ -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? +