Diameter Maintenance and S. Decugis, Ed.
Extensions (DIME) NICT
Internet-Draft June 4, 2009
Intended status: Standards Track
Expires: December 6, 2009
Diameter support for EAP Re-authentication Protocol (ERP)
draft-sdecugis-dime-diameter-erp-00
Status of This Memo
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 6, 2009.
Copyright Notice
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.
Abstract
The EAP Re-authentication Protocol (ERP) provides a mechanism to
optimize EAP authentication delay in the case of re-authentication,
Decugis Expires December 6, 2009 [Page 1]
Internet-Draft Diameter ERP support June 2009
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.
Foreword
This document differs from draft-ietf-dime-erp-00 [1] 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 (draft-ietf-dime-erp-00 [1] and
draft-wu-dime-local-keytran-00 [2]) was focused on the implicit
bootstrapping scenario described in [RFC5296]. By re-using the
Diameter EAP application, these documents create implicit constraints
on routing of messages that cannot be met by standard Diameter
routing algorithm defined in the Diameter Base Protocol [RFC3588]. A
separate Diameter Id may also allow the authenticator to dynamically
discover if the local domain supports ERP or not.
Requirements Language
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].
Decugis Expires December 6, 2009 [Page 2]
Internet-Draft Diameter ERP support June 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 6
5. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
5.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 6
5.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 7
5.3. ERP-RK-Answer AVP . . . . . . . . . . . . . . . . . . . . 7
5.4. ERP-RK AVP . . . . . . . . . . . . . . . . . . . . . . . . 7
5.5. ERP-RK-Name AVP . . . . . . . . . . . . . . . . . . . . . 7
5.6. ERP-RK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 8
6. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Bootstrapping options . . . . . . . . . . . . . . . . . . . . 9
7.1. Bootstrapping during initial EAP authentication . . . . . 9
7.2. Bootstrapping during first re-authentication . . . . . . . 11
8. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 13
9. Sessions . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
13.2. Informative References . . . . . . . . . . . . . . . . . . 17
Decugis Expires December 6, 2009 [Page 3]
Internet-Draft Diameter ERP support June 2009
1. Introduction
[RFC5296] defines the EAP Re-authentication Protocol (ERP) and
mechanism that consists in the two following steps:
1. Bootstrapping: creation of a root key for re-authentication,
after initial EAP authentication of the peer. This root key is
distributed from the EAP server to the ER server. How this key
is tranported is not specified in the ERP mechanism.
2. Re-authentication: one-round-trip exchange between the peer and
the ER server, functionally equivalent to a full EAP
authentication.
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].
Security considerations for key distribution are explained in
[RFC5295].
2. Terminology
We re-use here the terminology from [RFC5296]. In particular, the
EAP server implicitely supports ERP extensions to generate the ERP
keying material and send it to the ER server. These terms
"authenticator", "ER server", "EAP server" denote logical functional
entities and make no assumption on the real implementation and
deployment.
"root key" or "bootstrapping material" refer to the rRK (home ER
server) or rDSRK (foreign ER server) derived from an EMSK, depending
on the context.
We re-use also some terminology and abbreviations from [RFC4072], for
example DER/DEA.
3. Overview
During the lifetime of an EMSK (derived during a full EAP
authentication), 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
Decugis Expires December 6, 2009 [Page 4]
Internet-Draft Diameter ERP support June 2009
mechanism for re-authentication independent of the link layer, as
opposed to IEEE 802.11r-2008 for example, so it can be used in case
of multihoming or horizontal handovers. 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.
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 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 for a detailed description, and
following sections for details on the Diameter messages format.
Decugis Expires December 6, 2009 [Page 5]
Internet-Draft Diameter ERP support June 2009
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.
4. Application Id
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].
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).
5. AVPs
This specification defines the following new AVPs.
5.1. ERP-RK-Request AVP
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.
Decugis Expires December 6, 2009 [Page 6]
Internet-Draft Diameter ERP support June 2009
ERP-RK-Request ::= < AVP Header: TBD >
{ ERP-Realm }
* [ AVP ]
Figure 3. ERP-RK-Request ABNF
5.2. ERP-Realm AVP
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.
5.3. ERP-RK-Answer AVP
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
5.4. ERP-RK AVP
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].
[[Editor4: Can we re-use EAP-Master-Session-Key here?]]
This AVP has the M and V bits cleared.
5.5. ERP-RK-Name AVP
The ERP-RK AVP (AVP Code [[IANA6: TBD]]) is of type OctetString.
This AVP contains the EMSKname which identifies the keying material.
Decugis Expires December 6, 2009 [Page 7]
Internet-Draft Diameter ERP support June 2009
How this name is derived is beyond the scope of this document and
defined in [RFC5296].
[[Editor5: Can we re-use EAP-Key-Name here?]]
This AVP has the M and V bits cleared.
5.6. ERP-RK-Lifetime AVP
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.
6. Commands
We do not define any new command in this specification. We reuse the
Diameter-EAP-Request and Diameter-EAP-Answer commands defined in
[RFC4072].
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
Decugis Expires December 6, 2009 [Page 8]
Internet-Draft Diameter ERP support June 2009
7. Bootstrapping options
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, 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.
7.1. Bootstrapping during initial EAP authentication
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
Decugis Expires December 6, 2009 [Page 9]
Internet-Draft Diameter ERP support June 2009
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]. 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], 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
Decugis Expires December 6, 2009 [Page 10]
Internet-Draft Diameter ERP support June 2009
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...]]
7.2. Bootstrapping during first re-authentication
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] 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, 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
Decugis Expires December 6, 2009 [Page 11]
Internet-Draft Diameter ERP support June 2009
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 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].
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] (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]])
Decugis Expires December 6, 2009 [Page 12]
Internet-Draft Diameter ERP support June 2009
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].
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
8. Re-Authentication
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 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.
Decugis Expires December 6, 2009 [Page 13]
Internet-Draft Diameter ERP support June 2009
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] 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] with
regards to the EAP state machine, and similarly to Diameter EAP
[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.
[[Editor16: How do we create / retrieve the Session-Id?]]
The ER server receives this request and process the ERP payload as
described in [RFC5296]. 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
Decugis Expires December 6, 2009 [Page 14]
Internet-Draft Diameter ERP support June 2009
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.
9. Sessions
This section describes how sessions are handled in case of re-
authentication.
[[Editor17: See guidelines in I-D.ietf-dime-app-design-guide]]
[[Editor18: 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.]]
[[Editor19: The new authenticator will therefore derive the new
Session-Id from this EMSKName and use this for accounting purpose.]]
[[Editor20: 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?]]
[[Editor21: It is possible to cache the necessary information at the
ER server level. Is it useful to specify this mechanism in this
document?]]
10. Acknowledgements
[[Editor22: Remember, it's important to acknowledge people who have
contributed to the work]]
11. IANA Considerations
[[IANA9: Request a new Application Id for Diameter ERP.]]
Application Id Comment IANA1
Decugis Expires December 6, 2009 [Page 15]
Internet-Draft Diameter ERP support June 2009
Reference Comment IANA8
[[IANA10: Request new AVP Codes for ERP-* AVPs]]
AVP Comment IANA2
AVP Comment IANA3
AVP Comment IANA4
AVP Comment IANA5
AVP Comment IANA6
AVP Comment IANA7
12. Security Considerations
[[Editor23: Security considerations from RFC3588 (+bis), RFC4072,
RFC5247, RFC5295, and RFC5296 apply]]
[[Editor24: Is it safe to use ERP-RK-Request / Answer AVPs? What is
the worst case?]]
13. References
13.1. Normative References
[RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
[RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588,
September 2003.
[RFC4072] Eronen, P., Hiller, T., and G.
Zorn, "Diameter Extensible
Authentication Protocol (EAP)
Application", RFC 4072,
August 2005.
[RFC5295] Salowey, J., Dondeti, L.,
Narayanan, V., and M. Nakhjiri,
"Specification for the Derivation
of Root Keys from an Extended
Decugis Expires December 6, 2009 [Page 16]
Internet-Draft Diameter ERP support June 2009
Master Session Key (EMSK)",
RFC 5295, August 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP
Extensions for EAP Re-
authentication Protocol (ERP)",
RFC 5296, August 2008.
13.2. Informative References
[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.
[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.
[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.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht,
J., Carlson, J., and H. Levkowetz,
"Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
URIs
[1] <http://tools.ietf.org/html/draft-ietf-dime-erp-00>
[2] <http://tools.ietf.org/html/draft-wu-dime-local-keytran-00>
Decugis Expires December 6, 2009 [Page 17]
Internet-Draft Diameter ERP support June 2009
Author's Address
Sebastien Decugis (editor)
NICT
4-2-1 Nukui-Kitamachi
Koganei, Tokyo 184-8795
JP
EMail: sdecugis@nict.go.jp
Decugis Expires December 6, 2009 [Page 18]