Mercurial > hg > ietf
changeset 8:45a13fe6e0be
Completed initial description of the mechanism for explicit bootstrapping and implicit during Diameter EAP authentication.
| author | Sebastien Decugis <sdecugis@nict.go.jp> |
|---|---|
| date | Wed, 18 Mar 2009 13:21:39 +0900 |
| parents | 9ffe45ad7651 |
| children | 5fdd3345477f |
| files | New_ERP_draft_src.txt |
| diffstat | 1 files changed, 175 insertions(+), 19 deletions(-) [+] |
line wrap: on
line diff
--- a/New_ERP_draft_src.txt Tue Mar 17 17:23:13 2009 +0900 +++ b/New_ERP_draft_src.txt Wed Mar 18 13:21:39 2009 +0900 @@ -12,26 +12,18 @@ *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. +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, 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. +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 authenticator and ER server. This document specifies how the re-authentication exchange is transported using Diameter. It also contains 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 them. -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. @@ -41,12 +33,44 @@ 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 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 domain 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 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 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 local 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 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. @@ -54,19 +78,88 @@ *Scenario 1: explicit bootstrapping* -As described in [RFC5296], an explicit bootstrapping exchange can be initiated by the peer. +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 rDSRK-Request AVP if ER server is in visited domain, or rRK-Request AVP if ER server is in home domain.@These grouped AVP are described 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 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 AVPs 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 bellow: -{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?} +Authenticator ER server Home EAP server +============= ========= =============== + -----------------------> + ERP, DER + (EAP-Initiate) + ------------------------> + EAP, DER + (EAP-Initiate) + (rDSRK-Request or rRK-Request) + + <------------------------ + EAP, DEA + (EAP-Finish) + (rDSRK or rRK) + (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 the 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. -{Should be quite similar to scenario 1...} +In this situation, ERP key material is derived and cached regardless of the peer support and willingness for ERP, which may lead to scalability or 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 rDSRK-Request or rRK-request to the DER message. +If the home EAP server supports ERP extensions, it caches this request and continues the normal EAP authentication until completion. +When the authentication is successful and EMSK is generated, the home EAP server will also derive the rRK or rDSRK as requested, and add this material to the final DEA in the new AVPs 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 a DEA containing ERP AVPs, it extracts these 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) + (rDSRK-Request or rRK-Request) -*Scenario 3: implicit bootstrapping during full EAP authentication* + <==================================================> + Multi-round EAP unmodified exchanges -{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?} + <------------------------- + EAP, DEA + (EAP-Success) + (MSK) + (rDSRK or rRK) + <------------------------- + EAP, DEA + (EAP-Success) + (MSK) + + Figure 4. Implicit ERP bootstrapping during full EAP authentication. + *Scenario 4: Case of MIP6 ?* @@ -80,15 +173,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 + +*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. + + + +*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 feature 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? + +