draft-ietf-dime-erp-00.txt   draft-ietf-dime-erp-01.txt 
Diameter Maintenance and L. Dondeti Diameter Maintenance and L. Dondeti
Extensions (DIME) QUALCOMM, Inc. Extensions (DIME) QUALCOMM, Inc.
Internet-Draft J. Bournelle (Editor) Internet-Draft J. Bournelle
Intended status: Standards Track L. Morand Intended status: Standards Track L. Morand
Expires: July 18, 2009 Orange Labs Expires: March 1, 2010 Orange Labs
S. Decugis S. Decugis, Ed.
NICT NICT
January 14, 2009 Q. Wu
Huawei
August 28, 2009
Diameter Support for EAP Re-authentication Protocol Diameter support for EAP Re-authentication Protocol (ERP)
draft-ietf-dime-erp-00.txt draft-ietf-dime-erp-01.txt
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.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 July 18, 2009. This Internet-Draft will expire on March 1, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 Provisions Relating to IETF Documents in effect on the date of
(http://trustee.ietf.org/license-info) in effect on the date of publication of this document (http://trustee.ietf.org/license-info).
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document.
to this document.
Abstract Abstract
EAP Re-authentication Protocol (ERP) defines extensions to the EAP Re-authentication Protocol (ERP) defines extensions to the
Extensible Authentication Protocol (EAP) to support efficient re- Extensible Authentication Protocol (EAP) to support efficient re-
authentication between the EAP peer and an EAP re-authentication authentication between the EAP peer and an EAP re-authentication
server through any EAP/ERP authenticator. This document specifies server through an EAP/ERP authenticator. This document specifies
Diameter support for ERP. The Diameter EAP application is re-used Diameter support for ERP. It defines a new Diameter ERP application
for encapsulating the newly defined EAP codes specified in the ERP to transport ERP messages between authenticator and ERP server, and a
specification. Additionally, this document also defines specific set of new AVPs that can be used to transport the cryptographic
Diameter processing rules relevant to ERP. material needed by ERP server.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Diameter Support for ERP . . . . . . . . . . . . . . . . . . . 3 2.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
3.1. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 3 3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.2. DSRK Request and Delivery . . . . . . . . . . . . . . . . . 4 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4
4. Command Codes . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Bootstrapping the ER server . . . . . . . . . . . . . . . . . 6
5. Attribute Value Pair Definitions . . . . . . . . . . . . . . . 5 5.1. Bootstrapping during initial EAP authentication . . . . . 6
5.1. EAP-DSRK-Request AVP . . . . . . . . . . . . . . . . . . . 5 5.2. Bootstrapping during first re-authentication . . . . . . . 8
5.2. EAP-DSRK AVP . . . . . . . . . . . . . . . . . . . . . . . 5 6. Re-Authentication . . . . . . . . . . . . . . . . . . . . . . 9
5.3. EAP-DSRK-Name AVP . . . . . . . . . . . . . . . . . . . . . 5 7. Application Id . . . . . . . . . . . . . . . . . . . . . . . . 11
5.4. EAP-DSRK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 5 8. AVPs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 5 8.1. ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12
7. AVP Flag Rules . . . . . . . . . . . . . . . . . . . . . . . . 6 8.2. ERP-Realm AVP . . . . . . . . . . . . . . . . . . . . . . 12
8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8.3. ERP-RK-Answer AVP . . . . . . . . . . . . . . . . . . . . 12
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8.4. ERP-RK AVP . . . . . . . . . . . . . . . . . . . . . . . . 13
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 7 8.5. ERP-RK-Name AVP . . . . . . . . . . . . . . . . . . . . . 13
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 8.6. ERP-RK-Lifetime AVP . . . . . . . . . . . . . . . . . . . 13
11.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9. Commands . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
11.2. Informative References . . . . . . . . . . . . . . . . . . 8 10. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
12.1. Diameter ERP application . . . . . . . . . . . . . . . . . 15
12.2. New AVPs . . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Security Considerations . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
14.1. Normative References . . . . . . . . . . . . . . . . . . . 16
14.2. Informative References . . . . . . . . . . . . . . . . . . 16
1. Introduction 1. Introduction
RFC 4072 [1] specifies a Diameter application that carries EAP [RFC5296] defines the EAP Re-authentication Protocol (ERP). It
packets between a Diameter client and the Diameter Server/EAP server. consists in the following steps:
RFC 5296 [2] defines the EAP Re-authentication Protocol to allow
faster re-authentication of a previously authenticated peer.
In ERP, a peer is authenticated by the network thanks to keying 1. Bootstrapping: a root key for re-authentication is derived from
material obtained during a previous EAP exchange. This keying the Extended Master Session Key (EMSK) created during EAP
material is derived from the Extended Master Session Key (EMSK) as authentication [RFC5295]. This root key is transported from the
defined in the RFC 5295 [5]. To accomplish the EAP reauthentication EAP server to the ER server.
functionality, ERP defines two new EAP codes - EAP-Initiate and EAP
Finish. This document specifies the reuse of Diameter EAP
Application to carry these new EAP messages.
ERP is executed between the peer and a server located either in the 2. Re-authentication: a one-round-trip exchange between the peer and
peer's home domain or in the local domain visited by the peer. In the ER server, resulting in mutual authentication. To accomplish
the latter case, a Domain Specific Root Key (DSRK) is derived from the EAP reauthentication functionality, ERP defines two new EAP
the EMSK, as defined in the RFC 5295 [5], and is provided by the Home codes - EAP-Initiate and EAP-Finish.
EAP server to the local domain server. For that purpose, this
document specifies the transport of the DSRK using the Diameter EAP
Application.
2. Assumptions This document defines how Diameter transports the ERP messages (Re-
authentication step). For this purpose, we define a new Application
Id for ERP, and re-use the Diameter EAP commands (DER/DEA).
This document defines only additional optional AVPs for usage with This document also discusses the distribution of the root key
the Diameter EAP application. This document does not define a new (bootstrapping step), either during the initial EAP authentication
Diameter application and therefore a new Application ID is not (implicit bootstrapping) or during the first ERP exchange (explicit
required, as described in the Diameter Base protocol [3]. bootstrapping). Security considerations for this key distribution
are detailed in [RFC5295].
In this document, when EAP re-authentication is performed in the 2. Terminology
domain visited by the peer, it is assumed that the local ER server is
co-located with a Diameter agent in the visited domain present in the
path of the full EAP exchange. (Editor's Note: it is not clear at
the time of writing wether this document must require this local AAA
server to be on the path.)
3. Diameter Support for ERP This document uses terminology defined in [RFC3748], [RFC5295],
[RFC5296], and [RFC4072].
3.1. Protocol Overview "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.
The Diameter EAP Application is used to transport ERP messages We note in this document ERP/DER a Diameter-EAP-Request command with
between the NAS (authenticator) and an authentication server (ER the Application Id set to Diameter ERP application. On the same
server). model, we use ERP/DEA, EAP/DER and EAP/DEA.
2.1. 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].
3. Assumptions
This document makes the following assumptions.
The Home EAP server of a peer that wants to use ERP is extended to
support:
Cryptographic operations needed to derive the ERP root key from
the EMSK. By deriving the ERP root key for a specific domain, the
home EAP server implicitly authorizes the use of ERP within this
domain.
Diameter operations to include this root key inside an appropriate
AVP as defined in this document, in an answer message
corresponding to a request that contained a request for this
material (AVP for the request also defined in this document).
(recommanded) 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
The following figure shows the components involved in ERP, and their
interactions.
Diameter +--------+
+-------------+ ERP +-----------+ (*) | Home |
Peer <->|Authenticator|<=======>| ER server | <---> | EAP |
+-------------+ +-----------+ | server |
+--------+
(*) Diameter EAP application,
explicit bootstraping scenario only.
Figure. Diameter ERP overview.
The ER server is located either in the home domain (same as EAP
server) or in the visited domain (same as authenticator, when it
differs from the home domain).
When the peer initiates an ERP exchange, the authenticator creates a
Diameter-EAP-Request message, as described in Diameter EAP
application [RFC4072]. The Application Id of the message is set to
Diameter ERP application (code: TBD ) in the message. The exact
processing to generate the ERP/DER message is detailed in section
Section 6.
If there is an ER server in the same domain as the authenticator
(local domain), Diameter routing 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
its Destination-Realm AVP content, extracted from the realm component
of the keyName-NAI attribute. As specified in [RFC5296], this realm
is the home domain of the peer in case of bootstrapping exchange ('B'
flag is set in ERP message) or the domain of the bootstrapped ER
server otherwise .
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
is generated as specified in [RFC3588] and returned to the
authenticator. The authenticator may cache this information (with
limited duration) to avoid further attempts for ERP with this realm.
It may also fallback to full EAP authentication to authenticate the
peer.
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
AVP. If such key is found, the ER server processes the ERP message
as described in [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
described in [RFC5296], and forwards the content of the EAP-Payload
AVP, the EAP-Finish/Re-Auth message, to the peer.
If the EAP-Initiate/Re-Auth message has its 'B' flag set
(Bootstrapping exchange), the ER server should not possess the root
key in its local database . 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
server, but also impacts the peer and the authenticator. In ERP, the
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
this information is acquired is outside the scope of this
specification, but it may involves that the authenticator is
configured to advertize this domain name, especially in the case of
re-authentication after a handover.
The bootstrapping of an ER server with a given root key happens
either during the initial EAP authentication of the peer when the
EMSK -- from which the root key is derived -- is created, during the
first re-authentication, or sometime between those events. We only
consider the first two possibilities in this specification, in the
following subsections.
5.1. Bootstrapping during initial EAP authentication
Bootstrapping the ER server during the initial EAP authentication
(also known as implicit bootstrapping) 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, it
is possible that only a small number of peers will use re-
authentication in the visited domain. Deriving and caching key
material for all the peers (for example, for the peers that do not
support ERP) is a waste of resources and SHOULD be avoided.
To achieve implicit bootstrapping, the ER server must act as a
Diameter EAP Proxy as defined in Diameter Base Protocol [RFC3588],
and routing must be configured so that Diameter messages of a full
EAP authentication are routed through this proxy. The figure bellow
captures this mechanism.
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. 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 (which might happen if there are ER servers in the
visited and the home domains), 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 payloads.
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, extract and remove any ERP-RK-Answer AVP from the message,
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
subsequent re-authentication attempts for this session. In any case,
the information stored SHOULD NOT have a lifetime greater than the
EMSK lifetime
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
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.
5.2. Bootstrapping during first re-authentication
Bootstrapping the ER server during the first re-authentication (also
known as explicit bootstrapping) offers several advantages: it saves
resources, since we generate and cache only root key that we actually
need, and it can accomodate inter-domain handovers 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 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 is different for
explicit bootstrapping exchange and for normal re-authentication,
explicit bootstrapping should not be used if implicit bootstrapping
was already performed.
The ER server receives the ERP/DER message containing the EAP-
Initiate/Re-Auth message with the 'B' flag set. It proxies this
message, and do the following processing in addition to standard
proxy operations:
Change the Application Id in the header of the message to Diameter
EAP Application (code 5).
Change the content of Application-Auth-Id accordingly.
Add the ERP-RK-Request AVP, which contains the name of the domain
where the ER server is located.
Then the server forwards the EAP/DER request, which is routed to the
home EAP server.
If the home EAP 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
EAP/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 EAP/DEA and proxies it as follow, in
addition to standard proxy operations:
Set the Application Id back to Diameter ERP (code 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].
The figure below captures this 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. ERP explicit bootstrapping message flow
6. Re-Authentication
This section describes in detail a re-authentication exchange with a
(bootstrapped) ER server. The following figure summarizes the re-
authentication exchange.
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. Diameter ERP 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 NAS may send an
EAP-Initiate/Re-auth-Start message to the peer to trigger the start EAP-Initiate/Re-auth-Start message to the peer to trigger the start
of ERP. In this case, the peer responds with an EAP-Initiate/Re-auth of ERP. In this case, the peer responds with an EAP-Initiate/Re-auth
message to the NAS. message to the NAS.
The general guidelines for encapsulating EAP messages in Diameter If the authenticator does not support ERP (pure [RFC4072] support),
from RFC 4072 [1] apply to the new EAP codes defined for ERP as well. it discards the EAP packets with unknown ERP-specific code (EAP-
The EAP-Initiate/Re-auth message is encapsulated in an EAP-Payload Initiate). The peer may fallback to full EAP authentication in such
AVP of a Diameter EAP Request (DER) message by the NAS and sent to case.
the Diameter server. The NAS MUST copy the contents of the value
field of the 'KeyName-NAI' TLV or the 'peer-id' TLV (when the former
is not present) of the EAP Initiate/Re-auth message into a User-Name
AVP of the Diameter EAP-Request.
The ER server processes the EAP-Initiate/Re-auth message in When the authenticator receives an EAP-Initiate/Re-auth message from
accordance with [2] and responds with an EAP-Finish/Re-auth message. the peer, it process as described in [RFC5296] with regards to the
The Diameter server MUST encapsulate the EAP-Finish/Re-auth message EAP state machine. It creates a Diameter EAP Request message
within an EAP-Payload AVP of a Diameter EAP Answer message. In an following the general process of Diameter EAP [RFC4072], with the
EAP re-authentication successful case, an EAP-Master-Session-Key AVP following differences:
is included in the Diameter EAP Answer (DEA) message that contains
the Re-authentication Master Session Key (rMSK). The Diameter
Result-Code SHOULD be a success Result-Code. In an EAP re-
authentication failure case, the Diameter Result-Code AVP of the a
Diameter EAP Answer (DEA) message SHOULD be a failure Result-Code and
no EAP-Master-Session-Key AVP is present. (Editor's Note: it is FFS
if a SHOULD is sufficient) (2nd Editor's Note: add a figure ?)
3.2. DSRK Request and Delivery The Application Id in the header is set to Diameter ERP (code TBD
).
A local ER server, collocated with a Diameter proxy in the domain The value in Auth-Application-Id AVP is also set to Diameter ERP
visited by the peer, may request a DSRK from the home EAP/ERP server, Application.
either in the initial EAP exchange (implicit bootstrapping) or in an
ERP bootstrapping exchange (explicit bootstrapping). This is done by
including the EAP-DSRK-Request AVP in the Diameter EAP Request (DER)
message. The EAP-DSRK-Request AVP contains the domain or server
identity required to derive the DSRK.
In successful case, the DSRK is carried by the EAP-DSRK AVP in the The keyName-NAI attribute from ERP message is used to create the
Diameter EAP Answer (DEA) message. Along with the EAP-DSRK AVP, an content of User-Name AVP and Destination-Realm AVP.
EAP-DSRK-Name AVP MUST be used to send the DSRK's keyname and an EAP-
DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime.
(Editor's Note: add a figure ?).
4. Command Codes The Auth-Request-Type AVP content is set to [Editor's note: FFS].
This document re-uses the EAP application commands [1] and does not The EAP-Payload AVP contains the ERP message, EAP-Initiate/
define new command codes. Re-Auth.
5. Attribute Value Pair Definitions Then this ERP/DER message is sent as described in Section 4.
This section defines new AVPs for the ERP support within Diameter EAP The ER server receives and processes this request as described in
Section 4. It then creates a Diameter answer ERP/DEA, following the
general processing described in [RFC4072], with the following
differences:
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
Application. Application.
5.1. EAP-DSRK-Request AVP 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-DSRK Request AVP (AVP Code TBD) is of type DiameterIdentity. The EAP-Payload AVP contains the ERP message, EAP-Finish/Re-auth.
This AVP fulfills two purposes: first, it indicates that a ERP server
is located in the local domain that is willing to play the role of an
ERP server for a particular session. Second, it conveys information
about the domain name to the Diameter/EAP/ERP server. (Editor's
Note: it is FFS if DiameterIdentity is the correct type).
5.2. EAP-DSRK AVP In case of successful authentication, the EAP-Master-Session-Key
AVP contains the Re-authentication Master Session Key (rMSK)
derived by ERP.
The EAP-DSRK AVP (AVP Code TBD) is of type OctetString. This AVP When the authenticator receives this ERP/DEA answer, it processes it
contains keying material to be used by the visited domain (i.e. the as described in Diameter EAP [RFC4072] and [RFC5296]: the content of
DSRK). Exactly how this keying material is derived is beyond the EAP-Payload AVP content is forwarded to the peer, and the content of
scope of this document. EAP-Master-Session-Key AVP is used as a shared secret for Secure
Association Protocol.
5.3. EAP-DSRK-Name AVP 7. Application Id
The EAP-DSRK-Name AVP (AVP Code TBD) is of type OctetString. This We define a new Diameter application in this document, Diameter ERP
AVP contains the EMSKname which identifies the keying material. How Application, with an Application Id value of TBD. Diameter nodes
this name is derived is beyond the scope of this document and defined conforming to this specification in the role of ER server MUST
in [5]. advertise support by including an Auth-Application-Id AVP with a
value of Diameter ERP Application in the of the Capabilities-
Exchange-Request and Capabilities-Exchange-Answer commands, as
described in [RFC3588].
5.4. EAP-DSRK-Lifetime AVP 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
section Section 8 , although these AVP have the 'M' flag cleared.
The EAP-DSRK-Lifetime AVP (AVP Code TBD) is of type Unsigned64 and 8. AVPs
contains the DSRK lifetime in seconds. (Editor's Note: it is FFS if
Unsigned32 is not sufficient). (Editor's Note: it is FFS default
value)
6. AVP Occurrence Table This specification defines the following new AVPs.
The following table lists the AVPs that may optionally be present in 8.1. ERP-RK-Request AVP
the DER and DEA commands [1].
+---------------+ The ERP-RK-Request AVP (AVP Code TBD) is of type grouped AVP. This
| Command-Code | AVP is used by the ER server to indicate its willingness to act as ER
+-+-----+-----+-+ server for a particular session.
Attribute Name | DER | DEA |
-------------------------------|-----+-----+
EAP-DSRK-Request | 0-1 | 0 |
EAP-DSRK | 0 | 0-1 |
EAP-DSRK-Name | 0 | 0-1 |
EAP-DSRK-Lifetime | 0 | 0-1 |
+-----+-----+
Figure 1: DER and DEA Commands AVP Table This AVP has the M and V bits cleared.
When the EAP-DSRK AVP is present in the DEA then the EAP-DSRK-Name ERP-RK-Request ::= < AVP Header: TBD >
and the EAP-DSRK-Lifetime MUST also be present. { ERP-Realm }
* [ AVP ]
7. AVP Flag Rules Figure. ERP-RK-Request ABNF
The following table describes the Diameter AVPs, their AVP Code 8.2. ERP-Realm AVP
values, types, possible flag values, and whether the AVP MAY be
encrypted. The Diameter base [3] specifies the AVP Flag rules for
AVPs in Section 4.5.
+---------------------+ The ERP-Realm AVP (AVP Code TBD) is of type DiameterIdentity. It
| AVP Flag Rules | contains the name of the realm in which the ER server is located.
+----+-----+----+-----+----+
AVP Section | | |SHLD|MUST | |
Attribute Name Code Defined Data Type |MUST| MAY |NOT |NOT |Encr|
------------------------------------------+----+-----+----+-----+----+
EAP-DSRK-Request TBD 4.7.1 DiamIdent | | P | | V,M | Y |
EAP-DSRK TBD 4.7.2 OctetString| | P | | V,M | Y |
EAP-DSRK-Name TBD 4.7.3 OctetString| | P | | V,M | Y |
EAP-DSRK-Lifetime TBD 4.7.4 Unsigned64 | | P | | V,M | Y |
------------------------------------------+----+-----+----+-----+----+
Due to space constraints, the short form DiamIdent is used to This AVP has the M and V bits cleared.
represent DiameterIdentity.
Figure 2: AVP Flag Rules Table 8.3. ERP-RK-Answer AVP
8. Security Considerations 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.
The security considerations specified in RFC 4072 [1], and RFC 3588 This AVP has the M and V bits cleared.
[3] are applicable to this document.
ERP-RK-Answer ::= < AVP Header: TBD >
{ ERP-RK }
{ ERP-RK-Name }
{ ERP-RK-Lifetime }
* [ AVP ]
Figure. ERP-RK-Answer ABNF
8.4. ERP-RK AVP
The ERP-RK AVP (AVP Code TBD) is of type OctetString. It contains
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.
8.5. ERP-RK-Name AVP
The ERP-RK-Name AVP (AVP Code TBD) is of type OctetString. This AVP
contains the EMSKname which identifies the keying material. How this
name is derived is beyond the scope of this document and defined in
[RFC5296].
This AVP has the M and V bits cleared.
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
("* [ 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 advertizes support for the Diameter ERP
application MUST support the new AVPs defined in this specification.
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. Command Codes
10. Open issues
This document does not address some known issues in Diameter ERP
mechanism. The authors would like to hear ideas about how to address
them.
The main issue is the use of ERP for authentication after a handover
of the peer to a new authenticator (or different authenticator port).
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
to manage the Session-Id AVP; how does the ER server provide the
Authorization AVPs; how does the peer learn the ERP domain of the new
authenticator; how does the home server reachs the peer to for
example terminate the session; and so on... Therefore, the
management of the session for a mobile peer is not (yet) addressed in
this document. It must be studied how Diameter ERP can be for
example used in conjunction with a mobility application (Diameter
MIP4, Diameter MIP6) to support the optimized re-authentication in
such situation.
Another issue concerns the case where the home realm contains several
EAP servers. In multi rounds full EAP authentication, the
Destination-Host AVP provides the solution to reach the same server
across the exchanges. Only this server possess the EMSK for the
session. In case of explicit bootstrapping, the ER server must
therefore be able to reach the correct server to request the DSRK. A
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
implicit bootstrapping scenario described here -- only we save the
server name instead of the root key, and we must then be able to
match the DSRK with the user name.
Finally, this document currently lacks a description of what happens
when a Re-Auth-Request is received for a peer on the authenticator.
11. Acknowledgements
Hannes Tschofenig wrote the initial draft for this document and
provided useful reviews.
Vidya Narayanan reviewed a rough draft version of the document and
found some errors.
Glen Zorn actively participated in the discussions on the design for
Diameter ERP, providing the point of view and experience from HOKEY
workgroup.
Many thanks to these people!
12. IANA Considerations
This document requires IANA registration of the following new
elements in the Authentication, Authorization, and Accounting (AAA)
Parameters [1] registries.
12.1. Diameter ERP application
This specification requires IANA to allocate a new value "Diameter
ERP" in the "Application IDs" registry created by in [RFC3588].
Application Identifier | Value
-----------------------------------+------
Diameter ERP | TBD
IANA consideration for Diameter ERP application
12.2. New AVPs
This specification requires IANA to allocate new values from the "AVP
Codes" registry defined in [RFC3588] 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 8.
13. Security Considerations
The security considerations from the following RFC apply here:
[RFC3588], [RFC4072], [RFC5247], [RFC5295], and [RFC5296].
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.
9. IANA Considerations 14. References
This document requires IANA registration of the following new AVPs to 14.1. Normative References
the AVP registry established by RFC 3588 [3]:
o EAP-DSRK-Request [RFC2119] Bradner, S., "Key words for use in
RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119,
March 1997.
o EAP-DSRK [RFC3588] Calhoun, P., Loughney, J., Guttman,
E., Zorn, G., and J. Arkko,
"Diameter Base Protocol", RFC 3588,
September 2003.
o EAP-DSRK-Name [RFC3748] Aboba, B., Blunk, L., Vollbrecht,
J., Carlson, J., and H. Levkowetz,
"Extensible Authentication Protocol
(EAP)", RFC 3748, June 2004.
o EAP-DSRK-Lifetime [RFC4072] Eronen, P., Hiller, T., and G.
Zorn, "Diameter Extensible
Authentication Protocol (EAP)
Application", RFC 4072,
August 2005.
10. Acknowledgments [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.
Vidya Narayanan reviewed a rough draft version and found some errors. [RFC5296] Narayanan, V. and L. Dondeti, "EAP
Many thanks for her input. Extensions for EAP Re-
authentication Protocol (ERP)",
RFC 5296, August 2008.
11. References 14.2. Informative References
11.1. Normative References [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.
[1] Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible [I-D.ietf-dime-erp] Dondeti, L., Bournelle, J., Morand,
Authentication Protocol (EAP) Application", RFC 4072, L., and S. Decugis, "Diameter
August 2005. Support for EAP Re-authentication
Protocol", draft-ietf-dime-erp-00
(work in progress), January 2009.
[2] Narayanan, V. and L. Dondeti, "EAP Extensions for EAP Re- [I-D.ietf-hokey-key-mgm] Hoeper, K. and Y. Ohba,
authentication Protocol (ERP)", RFC 5296, August 2008. "Distribution of EAP based keys for
handover and re-authentication",
draft-ietf-hokey-key-mgm-06 (work
in progress), April 2009.
[3] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, [I-D.wu-dime-local-keytran] Wu, W., "Diameter support for local
"Diameter Base Protocol", RFC 3588, September 2003. key transport protocol between
local server and home AAA server",
draft-wu-dime-local-keytran-00
(work in progress), May 2009.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC4187] Arkko, J. and H. Haverinen,
Levels", BCP 14, RFC 2119, March 1997. "Extensible Authentication Protocol
Method for 3rd Generation
Authentication and Key Agreement
(EAP-AKA)", RFC 4187, January 2006.
11.2. Informative References [RFC5247] Aboba, B., Simon, D., and P.
Eronen, "Extensible Authentication
Protocol (EAP) Key Management
Framework", RFC 5247, August 2008.
[5] Salowey, J., Dondeti, L., Narayanan, V., and M. Nakhjiri, URIs
"Specification for the Derivation of Root Keys from an Extended
Master Session Key (EMSK)", RFC 5295, August 2008.
[6] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. [1] <http://www.iana.org/assignments/aaa-parameters/>
Levkowetz, "Extensible Authentication Protocol (EAP)", RFC 3748,
June 2004.
Authors' Addresses Authors' Addresses
Lakshminath Dondeti Lakshminath Dondeti
QUALCOMM, Inc. QUALCOMM, Inc.
5775 Morehouse Dr 5775 Morehouse Dr
San Diego, CA San Diego, CA
USA USA
Phone: +1 858-845-1267 Phone: +1 858-845-1267
Email: ldondeti@qualcomm.com EMail: ldondeti@qualcomm.com
Julien Bournelle Julien Bournelle
Orange Labs Orange Labs
38-40 rue du general Leclerc 38-40 rue du general Leclerc
Issy-Les-Moulineaux 92794 Issy-Les-Moulineaux 92794
France France
Email: julien.bournelle@orange-ftgroup.com EMail: julien.bournelle@orange-ftgroup.com
Lionel Morand Lionel Morand
Orange Labs Orange Labs
38-40 rue du general Leclerc 38-40 rue du general Leclerc
Issy-Les-Moulineaux 92794 Issy-Les-Moulineaux 92794
France France
Email: lionel.morand@orange-ftgroup.com EMail: lionel.morand@orange-ftgroup.com
Sebastien Decugis
Sebastien Decugis (editor)
NICT NICT
4-2-1 Nukui-Kitamachi 4-2-1 Nukui-Kitamachi
Tokyo 184-8795 Tokyo 184-8795
Koganei, Japan Koganei, Japan
Email: sdecugis@nict.go.jp EMail: sdecugis@nict.go.jp
Qin Wu
Huawei Technologies Co., Ltd
Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
Nanjing 210001
China
EMail: sunseawq@huawei.com
 End of changes. 68 change blocks. 
202 lines changed or deleted 665 lines changed or added

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