| TOC |
|
This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 10, 2009.
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
The EAP Re-authentication Protocol (ERP) provides a mechanism to optimize EAP authentication delay in the case of re-authentication, which can be significant in roaming mobile situation. This mechanism assumes that a protocol for Authentication, Authorization and Accounting (AAA) is available to transport ERP between the authenticator(s) and the EAP/ERP server. draft-gaonkar-radext-erp-attrs-03 specifies the transport of ERP using RADIUS. This document specifies the transport of ERP using Diameter.
1.
Introduction
1.1.
Differences with other documents
2.
Terminology
2.1.
Requirements Language
3.
Overview
4.
Application Id
5.
AVPs
5.1.
ERP-RK-Request AVP
5.2.
ERP-Realm AVP
5.3.
ERP-RK-Answer AVP
5.4.
ERP-RK AVP
5.5.
ERP-RK-Name AVP
5.6.
ERP-RK-Lifetime AVP
6.
Commands
7.
Bootstrapping options
7.1.
Bootstrapping during initial EAP authentication
7.2.
Bootstrapping during first re-authentication
8.
Re-Authentication
9.
Sessions
10.
Contributors
11.
Acknowledgements
12.
IANA Considerations
12.1.
Diameter ERP application
12.2.
New AVPs
13.
Security Considerations
14.
References
14.1.
Normative References
14.2.
Informative References
| TOC |
[RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) defines the EAP Re-authentication Protocol (ERP) and mechanism that consists in the two following steps:
This document specifies how Diameter is used to carry the re-authentication exchange (second step). For this purpose, we define a new Application Id for ERP, and re-use the Diameter EAP commands (DER/DEA).
We also discuss the key distribution (first step, bootstrapping) and propose some solutions for different architectures. Anyway, implementors are free to choose a different mechanism for key distribution, as for example using RADIUS [I‑D.ietf‑hokey‑key‑mgm] (Hoeper, K. and Y. Ohba, “Distribution of EAP based keys for handover and re-authentication,” April 2009.). Security considerations for key distribution are explained in [RFC5295] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” August 2008.).
| TOC |
This document differs from [I‑D.ietf‑dime‑erp] (Dondeti, L., Bournelle, J., Morand, L., and S. Decugis, “Diameter Support for EAP Re-authentication Protocol,” January 2009.) in its design and scope. In this new version, we use a new Diameter application id for messages with ERP payload exchanged between authenticator and ER server. This simplifies the routing of Diameter messages to the appropriate server, and allows more flexibility in the deployment of ERP.
The scope of previous documents ([I‑D.ietf‑dime‑erp] (Dondeti, L., Bournelle, J., Morand, L., and S. Decugis, “Diameter Support for EAP Re-authentication Protocol,” January 2009.) and [I‑D.wu‑dime‑local‑keytran] (Wu, W., “Diameter support for local key transport protocol between local server and home AAA server,” May 2009.)) was focused on the bootstrapping of the mechanism. In particular, these documents did not consider the routing of Diameter message for re-authentication exchanges (ERP exchange, and also [RFC4187] (Arkko, J. and H. Haverinen, “Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA),” January 2006.) for the second document). By re-using the Diameter EAP application, they create implicit constraints on routing of messages that cannot be met by standard Diameter routing algorithm, as defined in the Diameter Base Protocol (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) [RFC3588].
A separate Diameter application solves this routing issue, and can also allow the authenticator to dynamically discover if the local domain supports re-authentication or not.
| TOC |
We re-use in this document the terminology from [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.). In particular, unless specified otherwise, the EAP server has implicit support for ERP extensions for generation of ERP keying material and its transmission to ER server. These terms "authenticator", "ER server", "EAP server" designate logical functional entities and make no assumption on the real implementation and deployment.
"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK derived from an EMSK, depending on the location of the ER server in home or foreign domain.
We re-use also some terminology and abbreviations from [RFC4072] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.), for example DER/DEA.
| TOC |
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.).
| TOC |
During the lifetime of an EMSK (derived during a full EAP authentication by compatible EAP methods), a peer may attach to several authenticators. In this case, re-authentication is more efficient than full authentication, especially in the case of roaming. ERP provides a mechanism for re-authentication independent of the link layer, so it can be used in case of multihoming or handovers between different access technologies. The following figure shows the components involved in ERP, and their interactions. When the peer attaches to a new authenticator, the ER server involved in the transaction may change, for example in the case of inter-domain roaming. The home EAP server is assumed to be constant for a given peer.
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.
| Figure 1. Diameter applications used in the ERP mechanism. |
The ER server may be located in the home domain (same as EAP server) or the visited domain (same as authenticator, when it differs from the home domain). [Editor1] (Can the ER server be located in a third domain (ex: broker's)?)
The bootstrapping of the ER server has to occur sometime between the initial EAP authentication and the first ERP re-authentication with this ER server. See section Section 7 (Bootstrapping options) for detail on this process. Then, the peer re-authenticates, for example after a movement that makes it attach to a new authenticator. The following figure describes this re-authentication, and shows how Diameter is used in this context. See section Section 8 (Re-Authentication) for a detailed description, and following sections for details on the Diameter messages format.
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. |
| TOC |
We define a Diameter ERP Application in this document, with an Application Id value of [IANA1] (TBD). Diameter nodes conforming to this specification (in the role of ER server or authenticator) MUST advertise support by including the Diameter ERP Application ID value in the Auth-Application-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer command [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).
The primary use of the Diameter ERP Application Id is to ensure proper routing of the messages, and that the nodes that advertise the support for this application do understand the new AVPs defined in the next section (although these AVP have the 'M' flag cleared).
| TOC |
This specification defines the following new AVPs.
| TOC |
The ERP-RK-Request AVP (AVP Code [IANA2] (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 ]
| Figure 3. ERP-RK-Request ABNF |
| TOC |
The ERP-Realm AVP (AVP Code [IANA3] (TBD)) is of type [Editor2] (DiameterIdentity? OctetString?). It contains the name of the realm in which the ER server is located.
[Editor3] (FFS: We may re-use Origin-Realm here instead? On the other hand, ERP-Realm may be useful in CER/CEA with a NAS...)
This AVP has the M and V bits cleared.
| TOC |
The ERP-RK-Answer AVP (AVP Code [IANA4] (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 ]
| Figure 4. ERP-RK-Answer ABNF |
| TOC |
The ERP-RK AVP (AVP Code [IANA5] (TBD)) is of type OctetString. It contains the root key (either rRK or rDSRK) to be used for ERP with the peer to which the current session belongs. How this material is derived and used is specified in [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.).
[Editor4] (Can we re-use EAP-Master-Session-Key here?)
This AVP has the M and V bits cleared.
| TOC |
The ERP-RK AVP (AVP Code [IANA6] (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] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.).
[Editor5] (Can we re-use EAP-Key-Name here?)
This AVP has the M and V bits cleared.
| TOC |
The ERP-RK-Lifetime AVP (AVP Code [IANA7] (TBD)) is of type [Editor6] (Unsigned64? 32?) and contains the root key material remaining lifetime in seconds. It MUST not be greater than the remaining lifetime of the EMSK it is derived from. [Editor7] (FFS: is it better to pass an absolute value here, for example expiration date? How to express it then (TZ, ...)? Synchronization problems?)
This AVP has the M and V bits cleared.
| TOC |
We do not define any new command in this specification. We reuse the Diameter-EAP-Request and Diameter-EAP-Answer commands defined in [RFC4072] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.).
The Application Id field in the command header [Editor8] (and the value in Auth-Application-Id AVP which is redundant???) can be set to Diameter EAP application or Diameter ERP application, depending on the situation, as explained in the next sections.
Since the original ABNF of these commands allow other optional AVPs ("* [ AVP ]"), and the new AVPs defined in this specification do not have the 'M' flag set, the ABNF does not need any change. Anyway, a Diameter node that advertize support for the Diameter ERP application MUST support the ERP-RK-Request and ERP-RK-Answer AVP [Editor9] (Therefore, in DER/DEA with Diameter ERP application ID, do we set the 'M' flag to these AVPs?).
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 |
| TOC |
Bootstrapping involves the ER server and the EAP server directly, but also indirectly the peer and the authenticator. For ERP to be successful, the peer must derive the same keying material as the ER server. To make this possible, it must learn the domain name of the ER server. How this is achieved is outside the scope of this specification, but it usually involves that the authenticator is configured to advertize this domain name. This could be achieved for example by including the ERP-Realm AVP in a CER/CEA exchange.
As stated in the Section 3 (Overview), the bootstrapping of an ER server has to happen between the initial EAP authentication of the peer, when the EMSK is created, and the moment the peer re-authenticates with this ER server, when the bootstrapping material is needed. While asynchrounous solutions are perfectly possible, it is usually easier to bootstrap the ER server during one of these events.
| TOC |
Bootstrapping an ER server during the initial EAP authentication offers the advantage that the server is immediatly available for re-authentication of the peer, thus minimizing the re-authentication delay.
On the other hand, re-authentication may only concern a small number of peers in the visited domain. Deriving and caching key material for all the peers (for example, for the peers that do not support ERP, or that are not mobile) is a waste of resources and SHOULD be avoided. In addition, bootstrapping ERP during full EAP authentication may prevent re-authentication in case of inter-domain roaming. Hence, while this mecanism is useful in some situations, it should be deployed with care.
In the case where ER server is collocated with the Home EAP server, ER bootstrapping is transparent with regards to this specification, although some sort of communication might be needed inside the node. In this case, the server MUST advertise support of both the Diameter EAP application and the Diameter ERP application, but the new AVPs defined in this specification are not used.
When ER server and EAP server are different entities with regards to Diameter, one or more Diameter EAP proxy(ies) is(are) needed in the same domain as the ER server. While this(these) proxy(ies) might be separate entity(ies) with secure communication channel with the ER server, it is functionally equivalent to consider that the ER server acts as a Diameter EAP proxy. In the rest of this section, we consider that the ER server acts as a Diameter EAP proxy in its domain.
In order to bootstrap the ER server during full EAP authentication, this server must be on the route, and act as a proxy, for the first and last round of exchanges of the full EAP authentication, as captured in the figure bellow.
ER server &
Authenticator EAP Proxy 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)
[ERP-Realm]
| Figure 6. ERP bootstrapping during full EAP authentication |
The ER server proxies the first DER of the full EAP authentication and adds the ERP-RK-Request AVP inside, if this AVP is not already in the message, then forwards the request.
If the EAP server does not support ERP extensions, it will simply ignore this grouped AVP and continue as specified in [RFC4072] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.). If the server supports the ERP extensions, it caches the ERP-Realm value with the session, and continues the EAP authentication. When the authentication is complete, if it is successful and the EAP method generated an EMSK, the server MUST compute the rRK or rDSRK (depending on the value of ERP-Realm) as specified in [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.), and add an ERP-RK-Answer AVP in the Diameter-EAP-Request message, in addition to the MSK and EAP-Success payload. [Editor10] (FFS: is it important to check that the server that added the ERP-RK-Request is in the path of the answer? What's the worst that can happen?)
When the ER server proxies a Diameter-EAP-Answer message with a Session-Id corresponding to a message to which it added an ERP-RK-Answer, and the Result-Code is DIAMETER_SUCCESS, it MUST examine the message and remove any ERP-RK-Answer AVP, and save its content. If the message does not contain an ERP-RK-Answer AVP, the ER server MAY save this information to avoid possible attempts later for this session. In any case, the information stored SHOULD NOT have a lifetime greater than the EMSK lifetime [Editor11] (FFS: how does the ER server knows the EMSK lifetime, if there is no ERP-RK-Answer? What is the lifetime of the MSK for example?)
If the ER server is successfully bootstrapped, it MAY also add the ERP-Realm AVP after removing the ERP-RK-Answer AVP in the Diameter-EAP-Answer message. This could be used by the authenticator to notify the peer that ERP is bootstrapped, with the ER domain information. How this information can be transmitted to the peer is outside the scope of this document. [Editor12] (Is it possible? It would be useful...)
| TOC |
Bootstrapping the ER server during the first re-authentication offers several advantages: it saves resources, since we generate and cache only useful keying material, it can also accomodate inter-domain roaming or ER servers that loose their state (for example after reboot).
On the other hand, the first re-authentication with the ER server requires a one-round-trip with the home EAP server, which adds some delay to the process (but it is more efficient than a full EAP authentication in any case). Note that following re-authentications for the same session with the same ER server will not have this additional delay.
[RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) describes two types of bootstrapping for ERP: implicit bootstrapping and explicit bootstrapping. In implicit bootstrapping, the peer knows the domain it is located in, and assumes that the ER server already possess the keying material for the session. In this case, the peer uses a Keyname-NAI in the form "EMSKname@localdomain". In explicit bootstrapping, the Keyname-NAI is in the form "EMSKname@homedomain". As we will see in next section Section 8 (Re-Authentication), the domain part of the Keyname-NAI becomes the Destination-Realm of the Diameter message, and the Application Id is set to Diameter ERP application.
In the case of implicit bootstrapping (how the peer learns that the ER server is bootstrapped is outside the scope of this specification) or after a first succesful re-authentication in the visited domain, the message is routed to the local ER server following normal Diameter routing. If the ER server does not have key information corresponding to this EMSKname, [Editor13] (return an error to the peer? proxy the request and send ERP-RK-Request to the home EAP server? How do we learn which is the home domain?). See the next section Section 8 (Re-Authentication) for detail.
In the case of explicit bootstrapping (the ERP message has its 'B' flag set), if an ER server exists in the visited domain, it SHOULD be configured for and act as a Diameter ERP proxy, and process the messages as described below. If not, the ER server in the home domain will be used, which is less efficient. The description that follow for the ER server in the visited domain is also valid for the ER server in the home domain.
[Editor14] (What should we do if the ER server receives an explicit bootstrapping request but already possess the rDSRK?)
The ER server proxies the request (DER with Diameter ERP application code) as follow, in addition to standard proxy operations:
Change the Application Id in the header of the message to Diameter EAP Application (code 5). [Editor15] (What about the Application-Auth-Id AVP?)
Add the ERP-RK-Request AVP, which contains the name of the domain the ER server is located in (with regards to ERP).
Then the request is forwarded as usual. With its Diameter EAP application id and Destination-Realm set to the home domain of the peer, the request reaches the home EAP server. If this server does not support ERP extensions, it replies with an error since the encapsulated EAP-Initiate/Re-auth command is not understood. Otherwise, it processes the ERP request as described in [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.). In particular, it includes the Domain-Name TLV attribute with the content from the ERP-Realm AVP. It creates the DEA reply message following standard processing from [RFC4072] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) (in particular EAP-Master-Session-Key AVP is used to transport the rMSK), and includes the ERP-RK-Answer AVP.
The ER server receives this DEA and proxies it as follow, in addition to standard proxy operations:
Set the Application Id back to Diameter ERP (code [IANA8] (TBD))
Extract and cache the content of the ERP-RK-Answer.
The DEA is then forwarded to the authenticator, that can use the rMSK as described in [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.).
The figure below captures this Diameter ERP Proxy behavior:
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 7. ERP explicit bootstrapping message flow |
| TOC |
This section describes a re-authentication exchange with a bootstrapped ER server. The peer is assumed to know the domain of the bootstrapped ER server in advance. See previous section Section 7 (Bootstrapping options) for more information. EAP-Initiate/Re-auth-start with Domain-Name TLV is a possibility for the peer to learn the domain of the ER server attached to the authenticator.
The following figure describes the re-authentication exchange. Explication follow.
Bootstrapped ER server
Peer Authenticator (in 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 8. Diameter ERP exchange |
The authenticator that does not support ERP [RFC4072] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) discards EAP packets with unknown ERP-specific code (EAP-Initiate). The peer falls back to full EAP authentication in that case.
When the ERP-compatible authenticator receives an EAP-Initiate/Re-auth message from the peer (or after having sent a EAP-Initiate/Re-auth-start packet), it process as described in [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.) with regards to the EAP state machine, and similarly to Diameter EAP (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.) [RFC4072], with regards to Diameter, with the following differences:
The application id is set to Diameter ERP instead of Diameter EAP.
The User-Name and Destination-Realm are derived from the Keyname-NAI.
The ER server receives this request and process the ERP payload as described in [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.). If re-authentication is successful, it creates a DEA answer as described in Diameter EAP, with the following differences:
The application id is set to Diameter ERP.
The EAP-Payload AVP contains the ERP message: EAP-Finish/Re-auth
The EAP-Master-Session-Key AVP contains the rMSK
The Result-Code AVP contains DIAMETER_SUCCESS.
In case the re-authentication fails, the Result-Code AVP contains an error code, and no EAP-Master-Session-Key AVP is included.
When the authenticator receives this answer, it processes it as described in Diameter EAP: forwards the EAP payload to the peer, and use the rMSK as a shared secret in Secure Association Protocol.
| TOC |
This section describes how sessions are handled in case of re-authentication.
[Editor17] (The content of this section is to be written, I am just listing the ideas here.)
See guidelines in [I‑D.ietf‑dime‑app‑design‑guide] (Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. Loughney, “Diameter Applications Design Guidelines,” November 2008.).
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? It would involve:
An additional AVP during bootstrapping of ER server, in the ERP-RK-Answer, to pass the real User-Name and Session-Id (only in case of explicit bootstrapping)
An additional AVP in Diameter ERP/DEA (EAP-Finish/Re-Auth) to pass the real Session-Id and User-Name and Destination-Realm of the re-authenticated peer, for accounting messages.
| TOC |
Hannes Tschofenig, Lakshminath Dondeti, Julien Bournelle, and Lionel Morand wrote the initial Diameter ERP draft document.
| TOC |
Vidya Narayanan reviewed a rough draft version of the previous document and found some errors.
Qin Wu and Glen Zorn actively participated in the discussions on the design for Diameter ERP, providing the point of view and experience from HOKEY workgroup.
Hannes Tschofenig provided useful advices for the writing of this document.
Many thanks to these people!
| TOC |
This document requires IANA registration of the following new elements in the Authentication, Authorization, and Accounting (AAA) Parameters registries.
| TOC |
This specification requires IANA to allocate a new value "Diameter ERP" in the "Application IDs" registry created by in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.).
Application Identifier | Value -----------------------------------+------ Diameter ERP | TBD
| IANA consideration for Diameter ERP application |
| TOC |
This specification requires IANA to allocate new values from the "AVP Codes" registry defined in [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.) for the following AVPs:
ERP-RK-Request
ERP-Realm
ERP-RK-Answer
ERP-RK
ERP-RK-Name
ERP-RK-Lifetime
These AVPs are defined in section Section 5 (AVPs).
| TOC |
The security considerations from the following RFC apply here: [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.), [RFC4072] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.), [RFC5247] (Aboba, B., Simon, D., and P. Eronen, “Extensible Authentication Protocol (EAP) Key Management Framework,” August 2008.), [RFC5295] (Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” August 2008.), and [RFC5296] (Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” August 2008.).
[Editor18] (FFS: Do we really respect these security considerations with the mechanism we describe here? Is it safe to use ERP-RK-Request / Answer AVPs? What is the worst case?)
| TOC |
| TOC |
| [RFC2119] | Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” BCP 14, RFC 2119, March 1997 (TXT, HTML, XML). |
| [RFC3588] | Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” RFC 3588, September 2003 (TXT). |
| [RFC4072] | Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” RFC 4072, August 2005 (TXT). |
| [RFC5295] | Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, “Specification for the Derivation of Root Keys from an Extended Master Session Key (EMSK),” RFC 5295, August 2008 (TXT). |
| [RFC5296] | Narayanan, V. and L. Dondeti, “EAP Extensions for EAP Re-authentication Protocol (ERP),” RFC 5296, August 2008 (TXT). |
| TOC |
| [I-D.gaonkar-radext-erp-attrs] | Gaonkar, K., Dondeti, L., Narayanan, V., and G. Zorn, “RADIUS Support for EAP Re-authentication Protocol,” draft-gaonkar-radext-erp-attrs-03 (work in progress), February 2008 (TXT). |
| [I-D.ietf-dime-app-design-guide] | Fajardo, V., Asveren, T., Tschofenig, H., McGregor, G., and J. Loughney, “Diameter Applications Design Guidelines,” draft-ietf-dime-app-design-guide-08 (work in progress), November 2008 (TXT). |
| [I-D.ietf-dime-erp] | Dondeti, L., Bournelle, J., Morand, L., and S. Decugis, “Diameter Support for EAP Re-authentication Protocol,” draft-ietf-dime-erp-00 (work in progress), January 2009 (TXT). |
| [I-D.ietf-hokey-key-mgm] | Hoeper, K. and Y. Ohba, “Distribution of EAP based keys for handover and re-authentication,” draft-ietf-hokey-key-mgm-06 (work in progress), April 2009 (TXT). |
| [I-D.wu-dime-local-keytran] | Wu, W., “Diameter support for local key transport protocol between local server and home AAA server,” draft-wu-dime-local-keytran-00 (work in progress), May 2009 (TXT). |
| [RFC3748] | Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” RFC 3748, June 2004 (TXT). |
| [RFC4187] | Arkko, J. and H. Haverinen, “Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA),” RFC 4187, January 2006 (TXT). |
| [RFC5247] | Aboba, B., Simon, D., and P. Eronen, “Extensible Authentication Protocol (EAP) Key Management Framework,” RFC 5247, August 2008 (TXT). |
| TOC |
| Sebastien Decugis (editor) | |
| NICT | |
| 4-2-1 Nukui-Kitamachi | |
| Koganei, Tokyo 184-8795 | |
| JP | |
| EMail: | sdecugis@nict.go.jp |