draft-ietf-dime-erp-02.txt   draft-ietf-dime-erp-03.txt 
Diameter Maintenance and J. Bournelle Network Working Group J. Bournelle
Extensions (DIME) L. Morand Internet-Draft L. Morand
Internet-Draft Orange Labs Intended status: Standards Track Orange Labs
Intended status: Standards Track S. Decugis, Ed. Expires: September 8, 2010 S. Decugis, Ed.
Expires: April 11, 2010 NICT NICT
Q. Wu Q. Wu
Huawei Huawei
G. Zorn, Ed. G. Zorn, Ed.
Network Zen Network Zen
October 8, 2009 March 7, 2010
Diameter support for EAP Re-authentication Protocol (ERP) Diameter support for the EAP Re-authentication Protocol (ERP)
draft-ietf-dime-erp-02.txt draft-ietf-dime-erp-03.txt
Abstract
The EAP Re-authentication Protocol (ERP) defines extensions to the
Extensible Authentication Protocol (EAP) to support efficient re-
authentication between the peer and an EAP Re-authentication (ER)
server through a compatible authenticator. This document specifies
Diameter support for ERP. It defines a new Diameter ERP application
to transport ERP messages between an ER authenticator and the ER
server, and a set of new AVPs that can be used to transport the
cryptographic material needed by the re-authentication server.
Status of This Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 38 skipping to change at page 1, line 49
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on April 11, 2010. This Internet-Draft will expire on September 8, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
EAP Re-authentication Protocol (ERP) defines extensions to the described in the BSD License.
Extensible Authentication Protocol (EAP) to support efficient re-
authentication between the peer and an EAP Re-authentication (ER)
server through a compatible authenticator. This document specifies
Diameter support for ERP. It defines a new Diameter ERP application
to transport ERP messages between ER authenticator and ER server, and
a set of new AVPs that can be used to transport the cryptographic
material needed by the re-authentication server.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
5. Bootstrapping the ER server . . . . . . . . . . . . . . . . . 6 5. Bootstrapping the ER Server . . . . . . . . . . . . . . . . . 6
5.1. Bootstrapping during initial EAP authentication . . . . . 6 5.1. Bootstrapping During the Initial EAP authentication . . . 6
5.2. Bootstrapping during first re-authentication . . . . . . . 8 5.2. Bootstrapping During the First Re-authentication . . . . . 8
6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 9 6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 10
7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 13
8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12 8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 13
8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12 8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 13
8.3. ERP-RK-Answer AVP . . . . . . . . . . . . . . . . . . . . 12 8.3. Key AVP . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.4. ERP-RK AVP . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3.1. Key-Type AVP . . . . . . . . . . . . . . . . . . . . . 14
8.5. ERP-RK-Name AVP . . . . . . . . . . . . . . . . . . . . . 13 8.3.2. Keying-Material AVP . . . . . . . . . . . . . . . . . 14
8.6. ERP-RK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13 8.3.3. Key-Name AVP . . . . . . . . . . . . . . . . . . . . . 14
9. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8.3.4. Key-Lifetime AVP . . . . . . . . . . . . . . . . . . . 14
10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 14 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. Diameter ERP application . . . . . . . . . . . . . . . . . 15 11.1. Diameter Application Identifier . . . . . . . . . . . . . 15
12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 15 11.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15 12. Security Considerations . . . . . . . . . . . . . . . . . . . 16
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . . 17
1. Introduction 1. Introduction
[RFC5296] defines the EAP Re-authentication Protocol (ERP). It RFC 5296 [RFC5296] defines the EAP Re-authentication Protocol (ERP).
consists in the following steps: It consists of the following steps:
1. Bootstrapping: a root key for re-authentication is derived from Bootstrapping
the Extended Master Session Key (EMSK) created during EAP A root key for re-authentication is derived from the Extended
authentication [RFC5295]. This root key is transported from the Master Session Key (EMSK) created during EAP authentication
EAP server to the ER server. [RFC5295]. This root key is transported from the EAP server to
the ER server.
2. Re-authentication: a one-round-trip exchange between the peer and Re-authentication
the ER server, resulting in mutual authentication. To accomplish A one-round-trip exchange between the peer and the ER server,
the EAP reauthentication functionality, ERP defines two new EAP resulting in mutual authentication. To support the EAP
codes - EAP-Initiate and EAP-Finish. reauthentication functionality, ERP defines two new EAP codes -
EAP-Initiate and EAP-Finish.
This document defines how Diameter transports the ERP messages (Re- This document defines how Diameter transports the ERP messages during
authentication step). For this purpose, we define a new Application the re-authentication process. For this purpose, we define a new
Id for ERP, and re-use the Diameter EAP commands (DER/DEA). Application Identifier for ERP, and re-use the Diameter EAP commands
(DER/DEA).
This document also discusses the distribution of the root key This document also discusses the distribution of the root key during
(bootstrapping step), either during the initial EAP authentication bootstrapping, in conjunction with either the initial EAP
(implicit bootstrapping) or during the first ERP exchange (explicit authentication (implicit bootstrapping) or the first ERP exchange
bootstrapping). Security considerations for this key distribution (explicit bootstrapping). Security considerations for this key
are detailed in [RFC5295]. distribution are detailed in RFC 5295 [RFC5295].
2. Terminology 2. Terminology
This document uses terminology defined in [RFC3748], [RFC5295], This document uses terminology defined in RFC 3748 [RFC3748], RFC
[RFC5296], and [RFC4072]. 5295 [RFC5295], RFC 5296 [RFC5296], and RFC 4072 [RFC4072].
"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK "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 derived from an EMSK, depending on the location of the ER server in
home or foreign domain. home or foreign domain.
We use the notation "ERP/DER" in this document to refer to a We use the notation "ERP/DER" in this document to refer to a
Diameter-EAP-Request command with its Application Id set to Diameter Diameter-EAP-Request command with its Application Id set to Diameter
ERP application. Similarly, we use the "ERP/DEA", "EAP/DER", and ERP application. Similarly, we use the "ERP/DEA", "EAP/DER", and
"EAP/DEA". "EAP/DEA".
2.1. Requirements Language 2.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Assumptions 3. Assumptions
This document makes the following assumptions. This document assumes the existence of at most one logical ER server
entity in a domain. If several physical servers are deployed for
The Home EAP server of a peer that wants to use ERP is extended to robustness, a replication mechanism must be deployed to synchronize
support: the ERP states (root keys) between these servers. This replication
mechanism is out of the scope of this document. If multiple ER
Cryptographic operations needed to derive the ERP root key from servers are deployed in the domain, we assume that they can be used
the EMSK. By deriving the ERP root key for a specific domain, the interchangeably.
home EAP server implicitly authorizes the use of ERP within this
domain.
Diameter operations needed to include this root key in a response
message, when a request for this root key was received in a
request message. The two AVP that contain the request for and the
root key material are defined in this document.
(recommended) Ability to answer a DER message with EAP-Payload
containing an explicit bootstrapping ERP message.
The Authenticator (NAS) is extended to support:
Allow the new ERP command codes (EAP-Initiate and EAP-Finish) in
its EAP pass-through mode.
(optional) Send the EAP-Initiate/Re-Auth-Start message
(optional) Provide the local domain name via lower layer specific
mechanism or via TLV in the EAP-Initiate/Re-Auth-Start message.
Encapsulate ERP message and receive corresponding Diameter answer,
as described in this document.
If one of the components does not match these assumptions, the ERP
mechanism will fail. In such situation, a full EAP authentication
may be attempted as a fallback mechanism.
We consider at most one logical ER server entity in a domain. If
several physical servers are deployed for robustness, a replication
mechanism must be deployed to synchronize the ERP states (root keys )
between these servers. This replication mechanism is out of the
scope of this document. If several ER servers are deployed in the
domain, we assume that they can be used interchangeably.
4. Protocol Overview 4. Protocol Overview
The following figure shows the components involved in ERP, and their The following figure shows the components involved in ERP, and their
interactions. interactions.
Diameter +--------+ Diameter +--------+
+-------------+ ERP +-----------+ (*) | Home | +-------------+ ERP +-----------+ (*) | Home |
Peer <->|Authenticator|<=======>| ER server | <---> | EAP | Peer <->|Authenticator|<=======>| ER server | <---> | EAP |
+-------------+ +-----------+ | server | +-------------+ +-----------+ | server |
+--------+ +--------+
(*) Diameter EAP application, (*) Diameter EAP application, explicit bootstrapping scenario only.
explicit bootstraping scenario only.
Figure. Diameter ERP overview. Figure 1: Diameter ERP Overview
The ER server is located either in the home domain (same as EAP The ER server is located either in the home domain (same as EAP
server) or in the visited domain (same as authenticator, when it server) or in the visited domain (same as authenticator, when it
differs from the home domain). differs from the home domain).
QUESTION:
Can the ER server be located in a third domain (ex: broker's)
according to ERP mechanism?
When the peer initiates an ERP exchange, the authenticator creates a When the peer initiates an ERP exchange, the authenticator creates a
Diameter-EAP-Request message, as described in Diameter EAP Diameter-EAP-Request message, as described in Diameter EAP
application [RFC4072]. The Application Id of the message is set to application [RFC4072]. The Application Id of the message is set to
Diameter ERP application (code: TBD ) in the message. The exact that of the Diameter ERP application (code: TBD) in the message. The
processing to generate the ERP/DER message is detailed in section generation of the ERP/DER message is detailed in section Section 6.
Section 6.
If there is an ER server in the same domain as the authenticator If there is an ER server in the same domain as the authenticator
(local domain), Diameter routing MUST be configured so that this ERP/ (local domain), Diameter routing MUST
DER message reachs this server, even if the Destination-Realm is not
the local domain. QUESTION:
Should this say "SHOULD: instead of "MUST"?
be configured so that this ERP/DER message reachs this server, even
if the Destination-Realm is not the local domain.
If there is no local ER server, the message is routed according to If there is no local ER server, the message is routed according to
its Destination-Realm AVP content, extracted from the realm component its Destination-Realm AVP content, extracted from the realm component
of the keyName-NAI attribute. As specified in [RFC5296], this realm of the keyName-NAI attribute. As specified in RFC 5296 [RFC5296],
is the home domain of the peer in case of bootstrapping exchange ('B' this realm is the home domain of the peer in case of a bootstrapping
flag is set in ERP message) or the domain of the bootstrapped ER exchange (the 'B' flag is set in the ERP message) or the domain of
server otherwise . the bootstrapped ER server otherwise.
NOTE:
This actually might allow the ER server to be in a third party
realm.
If no ER server is available in the home domain either, the ERP/DER If no ER server is available in the home domain either, the ERP/DER
message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER
is generated as specified in [RFC3588] and returned to the is generated [RFC3588] and returned to the authenticator. The
authenticator. The authenticator may cache this information (with authenticator may cache this information (with limited duration) to
limited duration) to avoid further attempts for ERP with this realm. avoid further attempts for ERP with this realm. It may also fallback
It may also fallback to full EAP authentication to authenticate the to full EAP authentication to authenticate the peer.
peer.
When an ER server receives the ERP/DER message, it searches its local When an ER server receives the ERP/DER message, it searches its local
database for a root key matching the keyName part of the User-Name database for a root key
AVP. If such key is found, the ER server processes the ERP message
as described in [RFC5296] then creates the ERP/DEA answer as FFS:
described in Section 6. The rMSK is included in this answer. and authorization state?
matching the keyName part of the User-Name AVP. If such key is
found, the ER server processes the ERP message as described in RFC
5296 [RFC5296] then creates the ERP/DEA answer as described in
Section 6. The rMSK is included in this answer.
Finally, the authenticator extracts the rMSK from the ERP/DEA as Finally, the authenticator extracts the rMSK from the ERP/DEA as
described in [RFC5296], and forwards the content of the EAP-Payload described in RFC 5296 [RFC5296], and forwards the content of the EAP-
AVP, the EAP-Finish/Re-Auth message, to the peer. Payload AVP, the EAP-Finish/Re-Auth message, to the peer.
If the EAP-Initiate/Re-Auth message has its 'B' flag set If the EAP-Initiate/Re-Auth message has its 'B' flag set
(Bootstrapping exchange), the ER server should not possess the root (Bootstrapping exchange), the ER server should not possess the root
key in its local database . In this case, the ER server acts as a key in its local database
proxy, and forwards the message to the home EAP server after changing
its Application Id to Diameter EAP and adding an AVP to request the
root key. See section Section 5 for more detail on this process.
5. Bootstrapping the ER server COMMENT:
This may not be true in future RFC5296bis?
In this case, the ER server acts as a proxy, and forwards the message
to the home EAP server after changing its Application Id to Diameter
EAP and adding an AVP to request the root key. See section Section 5
for more detail on this process.
5. Bootstrapping the ER Server
The bootstrapping process involves the home EAP server and the ER The bootstrapping process involves the home EAP server and the ER
server, but also impacts the peer and the authenticator. In ERP, the server, but also impacts the peer and the authenticator. In ERP, the
peer must derive the same keying material as the ER server. To peer must derive the same keying material as the ER server. To
achieve this, it must learn the domain name of the ER server. How achieve this, it must learn the domain name of the ER server. How
this information is acquired is outside the scope of this this information is acquired is outside the scope of this
specification, but it may involves that the authenticator is specification, but it may involves that the authenticator is
configured to advertize this domain name, especially in the case of configured to advertize this domain name, especially in the case of
re-authentication after a handover. re-authentication after a handover.
The bootstrapping of an ER server with a given root key happens The bootstrapping of an ER server with a given root key happens
either during the initial EAP authentication of the peer when the either during the initial EAP authentication of the peer when the
EMSK -- from which the root key is derived -- is created, during the EMSK -- from which the root key is derived -- is created, during the
first re-authentication, or sometime between those events. We only first re-authentication, or sometime between those events. We only
consider the first two possibilities in this specification, in the consider the first two possibilities in this specification, in the
following subsections. following subsections.
5.1. Bootstrapping during initial EAP authentication 5.1. Bootstrapping During the Initial EAP authentication
Bootstrapping the ER server during the initial EAP authentication Bootstrapping the ER server during the initial EAP authentication
(also known as implicit bootstrapping) offers the advantage that the (also known as implicit bootstrapping) offers the advantage that the
server is immediatly available for re-authentication of the peer, server is immediatly available for re-authentication of the peer,
thus minimizing the re-authentication delay. On the other hand, it thus minimizing re-authentication delay. On the other hand, it is
is possible that only a small number of peers will use re- possible that only a small number of peers will use re-authentication
authentication in the visited domain. Deriving and caching key in the visited domain. Deriving and caching key material for all the
material for all the peers (for example, for the peers that do not peers (for example, for the peers that do not support ERP) is a waste
support ERP) is a waste of resources and SHOULD be avoided. of resources and SHOULD be avoided.
To achieve implicit bootstrapping, the ER server must act as a To achieve implicit bootstrapping, the ER server must act as a
Diameter EAP Proxy as defined in Diameter Base Protocol [RFC3588], Diameter EAP Proxy as defined in the Diameter Base Protocol
and routing must be configured so that Diameter messages of a full [RFC3588], and routing must be configured so that Diameter messages
EAP authentication are routed through this proxy. The figure bellow of a full EAP authentication are routed through this proxy. The
captures this mechanism. figure bellow illustrates this mechanism.
ER server & ER server &
Authenticator EAP Proxy Home EAP server Authenticator EAP Proxy Home EAP server
============= =========== =============== ============= =========== ===============
-------------------------> ------------------------->
Diameter EAP/DER Diameter EAP/DER
(EAP-Response) (EAP-Response)
-------------------------> ------------------------->
Diameter EAP/DER Diameter EAP/DER
(EAP-Response) (EAP-Response)
(ERP-RK-Request) (ERP-RK-Request)
<==================================================> <==================================================>
Multi-round Diameter EAP exchanges, unmodified Multi-round Diameter EAP exchanges, unmodified
<------------------------- <-------------------------
Diameter EAP/DEA Diameter EAP/DEA
(EAP-Success) (EAP-Success)
(MSK) (MSK)
(ERP-RK-Answer) (Key AVP (rRK))
<------------------------- <-------------------------
Diameter EAP/DEA Diameter EAP/DEA
(EAP-Success) (EAP-Success)
(MSK) (MSK)
[ERP-Realm] [ERP-Realm]
Figure. ERP bootstrapping during full EAP authentication Figure 2: ERP Bootstrapping During Full EAP Authentication
The ER server proxies the first DER of the 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 and adds the ERP-RK-Request AVP inside, if this AVP is not already in
the message (which might happen if there are ER servers in the the message (which might happen if there are ER servers in the
visited and the home domains), then forwards the request. visited and the home domains), then forwards the request.
If the EAP server does not support ERP extensions, it will simply If the EAP server does not support the ERP extensions, it will simply
ignore this grouped AVP and continue as specified in [RFC4072]. If ignore this grouped AVP and continue as specified in RFC 4072
the server supports the ERP extensions, it caches the ERP-Realm value [RFC4072]. If the server supports the ERP extensions, it caches the
with the session, and continues the EAP authentication. When the ERP-Realm value with the session data, and continues the EAP
authentication is complete, if it is successful and the EAP method authentication. When the authentication is complete, if it is
generated an EMSK, the server MUST compute the rRK or rDSRK successful and the EAP method generated an EMSK, the server MUST
(depending on the value of ERP-Realm) as specified in [RFC5296], and derive the rRK as specified in RFC 5296 [RFC5296], and include an
add an ERP-RK-Answer AVP in the Diameter-EAP-Request message, in instance of the Key AVP Section 8.3 in the Diameter-EAP-Answer
addition to the MSK and EAP-Success payloads. message.
When the ER server proxies a Diameter-EAP-Answer message with a 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- 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 Answer, and the Result-Code is DIAMETER_SUCCESS, it MUST examine the
message, extract and remove any ERP-RK-Answer AVP from the message, message, extract and remove any Key AVP Section 8.3 from the message,
and save its content. If the message does not contain an ERP-RK- 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 Answer AVP, the ER server MAY cache this information to avoid
subsequent re-authentication attempts for this session. In any case, possible subsequent re-authentication attempts for this session. In
the information stored SHOULD NOT have a lifetime greater than the any case, the information stored SHOULD NOT have a lifetime greater
EMSK lifetime than the EMSK lifetime
QUESTION:
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 If the ER server is successfully bootstrapped, it MAY also add the
ERP-Realm AVP after removing the ERP-RK-Answer AVP in the EAP/DEA ERP-Realm AVP after removing the ERP-RK-Answer AVP in the EAP/DEA
message. This could be used by the authenticator to notify the peer message. This could be used by the authenticator to notify the peer
that ERP is bootstrapped, with the ER domain information. How this that ERP is bootstrapped, with the ER domain information. How this
information can be transmitted to the peer is outside the scope of information can be transmitted to the peer is outside the scope of
this document. this document.
5.2. Bootstrapping during first re-authentication QUESTION:
Is this possible? It might be useful...
5.2. Bootstrapping During the First Re-authentication
Bootstrapping the ER server during the first re-authentication (also Bootstrapping the ER server during the first re-authentication (also
known as explicit bootstrapping) offers several advantages: it saves known as explicit bootstrapping) offers several advantages: it saves
resources, since we generate and cache only root key that we actually resources, since we generate and cache only root keys that we
need, and it can accomodate inter-domain handovers or ER servers that actually need, and it can accomodate inter-domain handovers or ER
loose their state (for example after reboot) . On the other hand, servers that lose their state (for example after reboot).
the first re-authentication with the ER server requires a one-round-
trip exchange with the home EAP server, which adds some delay to the COMMENT:
process (but it is more efficient than a full EAP authentication in This last point might not be true currently, since the peer would
any case). It also requires some synchronization between the peer not issue a bootstrapping exchange... But this might change also
and the visited domain: since the ERP message is different for with RFC5296bis AFAIU
explicit bootstrapping exchange and for normal re-authentication,
explicit bootstrapping should not be used if implicit bootstrapping On the other hand, the first re-authentication with the ER server
was already performed. requires a one-round-trip exchange 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). It also requires some
synchronization between the peer and the visited domain: since the
ERP message used is different
QUESTION:
and the root key used also?
for the explicit bootstrapping exchange than for normal re-
authentication; explicit bootstrapping should not be used if implicit
bootstrapping was already performed.
QUESTION:
What should we do if the ER server receives an explicit
bootstrapping request but already possess the rDSRK? Can it
answer without going to the home server? That would be simpler --
planned in rfc5296bis ?
The ER server receives the ERP/DER message containing the EAP- The ER server receives the ERP/DER message containing the EAP-
Initiate/Re-Auth message with the 'B' flag set. It proxies this Initiate/Re-Auth message with the 'B' flag set. It proxies this
message, and do the following processing in addition to standard message, and performs the following processing in addition to
proxy operations: standard proxy operations:
Change the Application Id in the header of the message to Diameter Changes the Application Id in the header of the message to
EAP Application (code 5). Diameter EAP Application (code 5).
Change the content of Application-Auth-Id accordingly. Change the content of Application-Auth-Id accordingly.
QUESTION:
Is t better to leave it unmodified?
Add the ERP-RK-Request AVP, which contains the name of the domain Add the ERP-RK-Request AVP, which contains the name of the domain
where the ER server is located. where the ER server is located.
QUESTION:
Add the Destination-Host to reach the appropriate EAP server,
the one with the EMSK. How does the ER server know this
information?
Then the server forwards the EAP/DER request, which is routed to the Then the server forwards the EAP/DER request, which is routed to the
home EAP server. home EAP server.
If the home EAP server does not support ERP extensions, it replies If the home EAP server does not support the ERP extensions, it
with an error since the encapsulated EAP-Initiate/Re-auth command is replies with an error since the encapsulated EAP-Initiate/Re-auth
not understood. Otherwise, it processes the ERP request as described command is not understood. Otherwise, it processes the ERP request
in [RFC5296]. In particular, it includes the Domain-Name TLV as described in [RFC5296]. In particular, it includes the Domain-
attribute with the content from the ERP-Realm AVP. It creates the Name TLV attribute with the content from the ERP-Realm AVP. It
EAP/DEA reply message following standard processing from [RFC4072] creates the EAP/DEA reply message [RFC4072]. including an instance of
(in particular EAP-Master-Session-Key AVP is used to transport the the Key AVP Section 8.3.
rMSK), and includes the ERP-RK-Answer AVP.
The ER server receives this EAP/DEA and proxies it as follow, in QUESTION:
What about authorization AVPs?
The ER server receives this EAP/DEA and proxies it as follows, in
addition to standard proxy operations: addition to standard proxy operations:
Set the Application Id back to Diameter ERP (code TBD) Set the Application Id back to Diameter ERP (code TBD)
Extract and cache the content of the ERP-RK-Answer. Extract and cache the content of the Key AVP.
QUESTION:
And authorization AVPs ?
The DEA is then forwarded to the authenticator, that can use the rMSK The DEA is then forwarded to the authenticator, that can use the rMSK
as described in [RFC5296]. as described in RFC 5296 [RFC5296].
The figure below captures this proxy behavior: The figure below captures this proxy behavior:
Authenticator ER server Home EAP server Authenticator ER server Home EAP server
============= ========= =============== ============= ========= ===============
-----------------------> ----------------------->
Diameter ERP/DER Diameter ERP/DER
(EAP-Initiate) (EAP-Initiate)
------------------------> ------------------------>
Diameter EAP/DER Diameter EAP/DER
(EAP-Initiate) (EAP-Initiate)
(ERP-RK-Request) (ERP-RK-Request)
<------------------------ <------------------------
Diameter EAP/DEA Diameter EAP/DEA
(EAP-Finish) (EAP-Finish)
(ERP-RK-Answer) (Key AVP)
(rMSK) <----------------------
<---------------------- Diameter ERP/DEA
Diameter ERP/DEA (EAP-Finish)
(EAP-Finish) (Key AVP)
(rMSK)
Figure. ERP explicit bootstrapping message flow Figure 3: ERP Explicit Bootstrapping Message Flow
6. Re-Authentication 6. Re-Authentication
This section describes in detail a re-authentication exchange with a This section describes in detail a re-authentication exchange with a
(bootstrapped) ER server. The following figure summarizes the re- (bootstrapped) ER server. The following figure summarizes the re-
authentication exchange. authentication exchange.
ER server ER server
(bootstrapped) (bootstrapped)
Peer Authenticator (local or home domain) Peer Authenticator (local or home domain)
==== ============= ====================== ==== ============= ======================
[ <------------------------ ] [ <------------------------ ]
[optional EAP-Initiate/Re-auth-start] [optional EAP-Initiate/Re-auth-start]
-----------------------> ----------------------->
EAP-Initiate/Re-auth EAP-Initiate/Re-auth
==================================> ===============================>
Diameter ERP, cmd code DER Diameter ERP, cmd code DER
User-Name: Keyname-NAI User-Name: Keyname-NAI
EAP-Payload: EAP-Initiate/Re-auth EAP-Payload: EAP-Initiate/Re-auth
<================================== <===============================
Diameter ERP, cmd code DEA Diameter ERP, cmd code DEA
EAP-Payload: EAP-Finish/Re-auth EAP-Payload: EAP-Finish/Re-auth
EAP-Master-Session-Key: rMSK Key AVP: rMSK
<---------------------- <----------------------
EAP-Finish/Re-auth EAP-Finish/Re-auth
Figure. Diameter ERP exchange. Figure 4: Diameter ERP Re-authentication Exchange
In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER
server via the authenticator. Alternatively, the NAS may send an server via the authenticator. Alternatively, the authenticator may
EAP-Initiate/Re-auth-Start message to the peer to trigger the start send an EAP-Initiate/Re-auth-Start message to the peer to trigger the
of ERP. In this case, the peer responds with an EAP-Initiate/Re-auth start of ERP. In this case, the peer responds with an EAP-Initiate/
message to the NAS. Re-auth message.
If the authenticator does not support ERP (pure [RFC4072] support), If the authenticator does not support ERP (pure [RFC4072] support),
it discards the EAP packets with unknown ERP-specific code (EAP- it discards the EAP packets with an unknown ERP-specific code (EAP-
Initiate). The peer may fallback to full EAP authentication in such Initiate). The peer may fallback to full EAP authentication in this
case. case.
When the authenticator receives an EAP-Initiate/Re-auth message from When the authenticator receives an EAP-Initiate/Re-auth message from
the peer, it process as described in [RFC5296] with regards to the the peer, it process as described in [RFC5296] with regards to the
EAP state machine. It creates a Diameter EAP Request message EAP state machine. It creates a Diameter EAP Request message
following the general process of Diameter EAP [RFC4072], with the following the general process of DiameterEAP [RFC4072], with the
following differences: following differences:
The Application Id in the header is set to Diameter ERP (code TBD The Application Id in the header is set to Diameter ERP (code
). TBD).
The value in Auth-Application-Id AVP is also set to Diameter ERP The value in Auth-Application-Id AVP is also set to Diameter ERP
Application. Application.
The keyName-NAI attribute from ERP message is used to create the The keyName-NAI attribute from ERP message is used to create the
content of User-Name AVP and Destination-Realm AVP. content of User-Name AVP and Destination-Realm AVP.
FFS:
What about Session-ID AVP -- in case of re-auth at the same
place, and in case of handover?
The Auth-Request-Type AVP content is set to [Editor's note: FFS]. The Auth-Request-Type AVP content is set to [Editor's note: FFS].
QUESTION:
Do we really do authorization with Diameter ERP ? -- need to
pass the authorization attrs to the ER server in that case.
Idea FFS: we do authorization only for explicit bootstrapping
exchanges...
The EAP-Payload AVP contains the ERP message, EAP-Initiate/ The EAP-Payload AVP contains the ERP message, EAP-Initiate/
Re-Auth. Re-Auth.
Then this ERP/DER message is sent as described in Section 4. Then this ERP/DER message is sent as described in Section 4.
The ER server receives and processes this request as described in The ER server receives and processes this request as described in
Section 4. It then creates a Diameter answer ERP/DEA, following the Section 4. It then creates an ERP/DEA message following the general
general processing described in [RFC4072], with the following processing described in RFC 4072 [RFC4072], with the following
differences: differences:
The Application Id in the header is set to Diameter ERP (code The Application Id in the header is set to Diameter ERP (code
TBD). TBD).
The value in Auth-Application-Id AVP is also set to Diameter ERP The value of the Auth-Application-Id AVP is also set to Diameter
Application. ERP Application.
The Result-Code AVP is set to an error value in case ERP
authentication fails, or to DIAMETER_SUCCESS if ERP is successful.
The EAP-Payload AVP contains the ERP message, EAP-Finish/Re-auth. The EAP-Payload AVP contains the ERP message, EAP-Finish/Re-auth.
In case of successful authentication, the EAP-Master-Session-Key In case of successful authentication, an instance of the Key AVP
AVP contains the Re-authentication Master Session Key (rMSK) containing the Re-authentication Master Session Key (rMSK) derived
derived by ERP. by ERP is included.
QUESTION:
What about all the authorization attributes? If we want to
include them, they have to be present on the ER server...
When the authenticator receives this ERP/DEA answer, it processes it When the authenticator receives this ERP/DEA answer, it processes it
as described in Diameter EAP [RFC4072] and [RFC5296]: the content of as described in Diameter EAP [RFC4072] and RFC 5296 [RFC5296]: the
EAP-Payload AVP content is forwarded to the peer, and the content of content of EAP-Payload AVP content is forwarded to the peer, and the
EAP-Master-Session-Key AVP is used as a shared secret for Secure contents of the Keying-Material AVP [I-D.ietf-dime-local-keytran] is
Association Protocol. used as a shared secret for Secure Association Protocol.
7. Application Id 7. Application Id
We define a new Diameter application in this document, Diameter ERP We define a new Diameter application in this document, Diameter ERP
Application, with an Application Id value of TBD. Diameter nodes Application, with an Application Id value of TBD. Diameter nodes
conforming to this specification in the role of ER server MUST conforming to this specification in the role of ER server MUST
advertise support by including an Auth-Application-Id AVP with a advertise support by including an Auth-Application-Id AVP with a
value of Diameter ERP Application in the of the Capabilities- value of Diameter ERP Application in the of the Capabilities-
Exchange-Request and Capabilities-Exchange-Answer commands, as Exchange-Request and Capabilities-Exchange-Answer commands [RFC3588].
described in [RFC3588].
The primary use of the Diameter ERP Application Id is to ensure The primary use of the Diameter ERP Application Id is to ensure
proper routing of the messages, and that the nodes that advertise the proper routing of the messages, and that the nodes that advertise the
support for this application do understand the new AVPs defined in support for this application do understand the new AVPs defined in
section Section 8 , although these AVP have the 'M' flag cleared. section Section 8, although these AVP have the 'M' flag cleared.
8. AVPs 8. AVPs
This specification defines the following new AVPs. This section discusses the AVPs used by the Diameter ERP application.
8.1. ERP-RK-Request AVP 8.1. ERP-RK-Request AVP
The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This
AVP is used by the ER server to indicate its willingness to act as ER AVP is used by the ER server to indicate its willingness to act as ER
server for a particular session. server for a particular session.
This AVP has the M and V bits cleared. This AVP has the M and V bits cleared.
ERP-RK-Request ::= < AVP Header: TBD > ERP-RK-Request ::= < AVP Header: TBD >
{ ERP-Realm } { ERP-Realm }
* [ AVP ] * [ AVP ]
Figure. ERP-RK-Request ABNF Figure 5: ERP-RK-Request ABNF
8.2. ERP-Realm AVP 8.2. ERP-Realm AVP
The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It
contains the name of the realm in which the ER server is located. contains the name of the realm in which the ER server is located.
This AVP has the M and V bits cleared. FFS:
We may re-use Origin-Realm here instead? On the other hand, ERP-
8.3. ERP-RK-Answer AVP Realm may be useful if the ER server is in a third-party realm, if
this is possible.
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. This AVP has the M and V bits cleared.
ERP-RK-Answer ::= < AVP Header: TBD > 8.3. Key AVP
{ ERP-RK }
{ ERP-RK-Name }
{ ERP-RK-Lifetime }
* [ AVP ]
Figure. ERP-RK-Answer ABNF
8.4. ERP-RK AVP The Key AVP [I-D.ietf-dime-local-keytran] is of type "Grouped" and is
used to carry the rMSK and associated attributes. The usage of the
Key AVP and its constituent AVPs in this application is specified in
the following sub-sections.
The ERP-RK AVP (AVP Code TBD) is of type OctetString. It contains 8.3.1. Key-Type AVP
the root key (either rRK or rDSRK) sent by the home EAP server to the
ER server, in answer to request containing an ERP-RK-Request AVP.
How this material is derived and used is specified in [RFC5296].
This AVP has the M and V bits cleared. The value of the Key-Type AVP MUST be set to 3 for rRK.
8.5. ERP-RK-Name AVP 8.3.2. Keying-Material AVP
The ERP-RK-Name AVP (AVP Code TBD) is of type OctetString. This AVP The Keying-Material AVP contains rRK sent by the home EAP server to
contains the EMSKname which identifies the keying material. How this the ER server, in answer to a request containing an ERP-RK-Request
name is derived is beyond the scope of this document and defined in AVP. How this material is derived and used is specified in RFC 5296
[RFC5296]. [RFC5296].
This AVP has the M and V bits cleared. 8.3.3. Key-Name AVP
8.6. ERP-RK-Lifetime AVP
The ERP-RK-Lifetime AVP (AVP Code TBD) is of type Unsigned32 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.
This AVP has the M and V bits cleared.
9. 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].
Since the original ABNF of these commands allow other optional AVPs This AVP contains the EMSKname which identifies the keying material.
("* [ AVP ]"), and the new AVPs defined in this specification do not The derivation of this name is specified in RGC 5296 [RFC5296].
have the 'M' flag set, the ABNF does not need any change. Anyway, a
Diameter node that advertizes support for the Diameter ERP
application MUST support the new AVPs defined in this specification.
Command-Name Abbrev. Code Reference Application 8.3.4. Key-Lifetime AVP
---------------------------------------------------------
Diameter-EAP-Request DER 268 RFC 4072 Diameter ERP
Diameter-EAP-Answer DEA 268 RFC 4072 Diameter ERP
Figure. Command Codes The Key-Lifetime AVP contains the lifetime of the keying material in
seconds. It MUST NOT be greater than the remaining lifetime of the
EMSK from which the material was derived.
10. Open issues 9. Open issues
This document does not address some known issues in Diameter ERP This document does not address some known issues in Diameter ERP
mechanism. The authors would like to hear ideas about how to address mechanism. The authors would like to hear ideas about how to address
them. them.
The main issue is the use of ERP for authentication after a handover The main issue is the use of ERP for authentication after a handover
of the peer to a new authenticator (or different authenticator port). of the peer to a new authenticator (or different authenticator port).
Diameter ERP is not meant to be a mobility protocol. A number of Diameter ERP is not meant to be a mobility protocol. A number of
issues appear when we try to do handover in Diameter ERP (alone): how issues appear when we try to do handover in Diameter ERP (alone): how
to manage the Session-Id AVP; how does the ER server provide the to manage the Session-Id AVP; how does the ER server provide the
skipping to change at page 14, line 40 skipping to change at page 15, line 20
therefore be able to reach the correct server to request the DSRK. A therefore be able to reach the correct server to request the DSRK. A
solution might consist in saving the Origin-Host AVP of all solution might consist in saving the Origin-Host AVP of all
successful EAP/DEA in the ER server, which is a bit similar to the successful EAP/DEA in the ER server, which is a bit similar to the
implicit bootstrapping scenario described here -- only we save the implicit bootstrapping scenario described here -- only we save the
server name instead of the root key, and we must then be able to server name instead of the root key, and we must then be able to
match the DSRK with the user name. match the DSRK with the user name.
Finally, this document currently lacks a description of what happens Finally, this document currently lacks a description of what happens
when a Re-Auth-Request is received for a peer on the authenticator. when a Re-Auth-Request is received for a peer on the authenticator.
11. Acknowledgements 10. Acknowledgements
Hannes Tschofenig wrote the initial draft for this document and Hannes Tschofenig wrote the initial draft for this document and
provided useful reviews. provided useful reviews.
Vidya Narayanan reviewed a rough draft version of the document and Vidya Narayanan reviewed a rough draft version of the document and
found some errors. found some errors.
Lakshminath Dondeti contributed to the early versions of the Lakshminath Dondeti contributed to the early versions of the
document. document.
Many thanks to these people! Many thanks to these people!
12. IANA Considerations 11. IANA Considerations
This document requires IANA registration of the following new This document requires IANA registration of the following new
elements in the Authentication, Authorization, and Accounting (AAA) elements in the Authentication, Authorization, and Accounting (AAA)
Parameters [1] registries. Parameters [1] registries.
12.1. Diameter ERP application 11.1. Diameter Application Identifier
This specification requires IANA to allocate a new value "Diameter This specification requires IANA to allocate a new value "Diameter
ERP" in the "Application IDs" registry created by in [RFC3588]. ERP" in the "Application IDs" registry using the policy specified in
Section 11.3 of RFC 3588 [RFC3588].
Application Identifier | Value
-----------------------------------+------
Diameter ERP | TBD
IANA consideration for Diameter ERP application
12.2. New AVPs 11.2. New AVPs
This specification requires IANA to allocate new values from the "AVP This specification requires IANA to allocate new values from the "AVP
Codes" registry defined in [RFC3588] for the following AVPs: Codes" registry according to the policy specified in Section 11.1 of
RFC 3588 [RFC3588] for the following AVPs:
ERP-RK-Request ERP-RK-Request
ERP-Realm ERP-Realm
ERP-RK-Answer These AVPs are defined in section Section 8.
ERP-RK 12. Security Considerations
ERP-RK-Name The security considerations from the following documents also apply
here:
ERP-RK-Lifetime o RFC 3588 [RFC3588]
These AVPs are defined in section Section 8. o RFC 4072 [RFC4072]
13. Security Considerations o RFC 5247 [RFC5247]
The security considerations from the following RFC apply here: o RFC 5295 [RFC5295]
[RFC3588], [RFC4072], [RFC5247], [RFC5295], and [RFC5296].
o [RFC5296]
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?
EAP channel bindings may be necessary to ensure that the Diameter EAP channel bindings may be necessary to ensure that the Diameter
client and the server are in sync regarding the key Requesting client and the server are in sync regarding the key Requesting
Entity's Identity. Specifically, the Requesting Entity advertises Entity's Identity. Specifically, the Requesting Entity advertises
its identity through the EAP lower layer, and the user or the EAP its identity through the EAP lower layer, and the user or the EAP
peer communicates that identity to the EAP server (and the EAP server peer communicates that identity to the EAP server (and the EAP server
communicates that identity to the Diameter server) via the EAP method communicates that identity to the Diameter server) via the EAP method
for user/peer to server verification of the Requesting Entity's for user/peer to server verification of the Requesting Entity's
Identity. Identity.
14. References QUESTION:
What does this paragraph actually mean?
14.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, 13. References
E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588,
September 2003.
[RFC3748] Aboba, B., Blunk, L., Vollbrecht, 13.1. Normative References
J., Carlson, J., and H. Levkowetz,
"Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[RFC4072] Eronen, P., Hiller, T., and G. [I-D.ietf-dime-local-keytran] Zorn, G., Wu, W., and V. Cakulev,
Zorn, "Diameter Extensible "Diameter Attribute-Value Pairs for
Authentication Protocol (EAP) Cryptographic Key Transport",
Application", RFC 4072, draft-ietf-dime-local-keytran-02 (work
August 2005. in progress), March 2010.
[RFC5295] Salowey, J., Dondeti, L., [RFC2119] Bradner, S., "Key words for use in
Narayanan, V., and M. Nakhjiri, RFCs to Indicate Requirement Levels",
"Specification for the Derivation BCP 14, RFC 2119, March 1997.
of Root Keys from an Extended
Master Session Key (EMSK)",
RFC 5295, August 2008.
[RFC5296] Narayanan, V. and L. Dondeti, "EAP [RFC3588] Calhoun, P., Loughney, J., Guttman,
Extensions for EAP Re- E., Zorn, G., and J. Arkko, "Diameter
authentication Protocol (ERP)", Base Protocol", RFC 3588,
RFC 5296, August 2008. September 2003.
14.2. Informative References [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J.,
Carlson, J., and H. Levkowetz,
"Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
[I-D.ietf-dime-app-design-guide] Fajardo, V., Asveren, T., [RFC4072] Eronen, P., Hiller, T., and G. Zorn,
Tschofenig, H., McGregor, G., and "Diameter Extensible Authentication
J. Loughney, "Diameter Applications Protocol (EAP) Application", RFC 4072,
Design Guidelines", August 2005.
draft-ietf-dime-app-design-guide-08
(work in progress), November 2008.
[I-D.ietf-hokey-key-mgm] Hoeper, K. and Y. Ohba, [RFC5295] Salowey, J., Dondeti, L., Narayanan,
"Distribution of EAP based keys for V., and M. Nakhjiri, "Specification
handover and re-authentication", for the Derivation of Root Keys from
draft-ietf-hokey-key-mgm-06 (work an Extended Master Session Key
in progress), April 2009. (EMSK)", RFC 5295, August 2008.
[I-D.wu-dime-local-keytran] Wu, W., "Diameter support for local [RFC5296] Narayanan, V. and L. Dondeti, "EAP
key transport protocol between Extensions for EAP Re-authentication
local server and home AAA server", Protocol (ERP)", RFC 5296,
draft-wu-dime-local-keytran-00 August 2008.
(work in progress), May 2009.
[RFC4187] Arkko, J. and H. Haverinen, 13.2. Informative References
"Extensible Authentication Protocol
Method for 3rd Generation
Authentication and Key Agreement
(EAP-AKA)", RFC 4187, January 2006.
[RFC5247] Aboba, B., Simon, D., and P. [RFC5247] Aboba, B., Simon, D., and P. Eronen,
Eronen, "Extensible Authentication "Extensible Authentication Protocol
Protocol (EAP) Key Management (EAP) Key Management Framework",
Framework", RFC 5247, August 2008. RFC 5247, August 2008.
URIs URIs
[1] <http://www.iana.org/assignments/aaa-parameters/> [1] <http://www.iana.org/assignments/aaa-parameters/>
Authors' Addresses Authors' Addresses
Julien Bournelle Julien Bournelle
Orange Labs Orange Labs
38-40 rue du general Leclerc 38-40 rue du general Leclerc
skipping to change at page 18, line 22 skipping to change at page 18, line 41
Qin Wu Qin Wu
Huawei Technologies Co., Ltd Huawei Technologies Co., Ltd
Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd. Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
Nanjing 210001 Nanjing 210001
China China
EMail: sunseawq@huawei.com EMail: sunseawq@huawei.com
Glen Zorn (editor) Glen Zorn (editor)
Network Zen Network Zen
1310 East Thomas Street 1463 East Republican Street
#306 Seattle, Washington 98112
Seattle, Washington 98102
USA USA
Phone: +1 (206) 377-9035 Phone: +1 206 931 0768
EMail: gwz@net-zen.net EMail: gwz@net-zen.net
 End of changes. 107 change blocks. 
415 lines changed or deleted 407 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/