Diameter Maintenance and                                      L. Dondeti
Extensions (DIME)                                         QUALCOMM, Inc.
Internet-Draft                                              J. Bournelle (Editor)
Intended status: Standards Track                               L. Morand
Expires: July 18, 2009 March 1, 2010                                       Orange Labs
                                                         S. Decugis Decugis, Ed.
                                                        January 14,
                                                                   Q. Wu
                                                         August 28, 2009

       Diameter Support support for EAP Re-authentication Protocol
                       draft-ietf-dime-erp-00.txt (ERP)

Status of this This Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on July 18, 2009. March 1, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.


   EAP Re-authentication Protocol (ERP) defines extensions to the
   Extensible Authentication Protocol (EAP) to support efficient re-
   authentication between the EAP peer and an EAP re-authentication
   server through any an EAP/ERP authenticator.  This document specifies
   Diameter support for ERP.  The  It defines a new Diameter EAP ERP application is re-used
   for encapsulating the newly defined EAP codes specified in the
   to transport ERP
   specification.  Additionally, this document also defines specific
   Diameter processing rules relevant messages between authenticator and ERP server, and a
   set of new AVPs that can be used to ERP. transport the cryptographic
   material needed by ERP server.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Assumptions  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  3
     2.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   3.  Diameter Support for ERP  Assumptions  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  DSRK Request and Delivery .  4
   5.  Bootstrapping the ER server  . . . . . . . . . . . . . . . . 4
   4.  Command Codes .  6
     5.1.  Bootstrapping during initial EAP authentication  . . . . .  6
     5.2.  Bootstrapping during first re-authentication . . . . . . .  8
   6.  Re-Authentication  . . . . . . . . . . . . 4
   5.  Attribute Value Pair Definitions . . . . . . . . . .  9
   7.  Application Id . . . . . 5
     5.1.  EAP-DSRK-Request AVP . . . . . . . . . . . . . . . . . . . 5
     5.2.  EAP-DSRK AVP 11
   8.  AVPs . . . . . . . . . . . . . . . . . . . . . . . 5
     5.3.  EAP-DSRK-Name . . . . . . 12
     8.1.  ERP-RK-Request AVP . . . . . . . . . . . . . . . . . . . . 12
     8.2.  ERP-Realm AVP  . 5
     5.4.  EAP-DSRK-Lifetime . . . . . . . . . . . . . . . . . . . . . 12
     8.3.  ERP-RK-Answer AVP  . . . . . . . . . . . . . . . . . . . 5
   6. . 12
     8.4.  ERP-RK AVP Occurrence Table . . . . . . . . . . . . . . . . . . . . . 5
   7. . . . 13
     8.5.  ERP-RK-Name AVP Flag Rules  . . . . . . . . . . . . . . . . . . . . . 13
     8.6.  ERP-RK-Lifetime AVP  . . . 6
   8.  Security Considerations . . . . . . . . . . . . . . . . 13
   9.  Commands . . . . . 6
   9.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 13
   10. Acknowledgments Open issues  . . . . . . . . . . . . . . . . . . . . . . . . 7 . 14
   11. References Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
   12. IANA Considerations  . . . 7
     11.1. Normative References . . . . . . . . . . . . . . . . . . 15
     12.1. Diameter ERP application . 7
     11.2. Informative References . . . . . . . . . . . . . . . . 15
     12.2. New AVPs . . 8
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
   13. Security Considerations  . 8

1.  Introduction

   RFC 4072 [1] specifies a Diameter application that carries EAP
   packets between a Diameter client and the Diameter Server/EAP server.
   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
   material obtained during a previous EAP exchange.  This keying
   material is derived from the . . . . . . . . . . . . . . . . . . 15
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 16
     14.2. Informative References . . . . . . . . . . . . . . . . . . 16

1.  Introduction

   [RFC5296] defines the EAP Re-authentication Protocol (ERP).  It
   consists in the following steps:

   1.  Bootstrapping: a root key for re-authentication is derived from
       the Extended Master Session Key (EMSK) as
   defined in created during EAP
       authentication [RFC5295].  This root key is transported from the RFC 5295 [5].
       EAP server to the ER server.

   2.  Re-authentication: a one-round-trip exchange between the peer and
       the ER server, resulting in mutual authentication.  To accomplish
       the EAP reauthentication functionality, ERP defines two new EAP
       codes - EAP-Initiate and EAP
   Finish. EAP-Finish.

   This document specifies the reuse of defines how Diameter EAP
   Application to carry these transports the ERP messages (Re-
   authentication step).  For this purpose, we define a new Application
   Id for ERP, and re-use the Diameter EAP messages.

   ERP is executed between commands (DER/DEA).

   This document also discusses the peer and a server located distribution of the root key
   (bootstrapping step), either in during the
   peer's home domain initial EAP authentication
   (implicit bootstrapping) or in the local domain visited by during the peer.  In first ERP exchange (explicit
   bootstrapping).  Security considerations for this key distribution
   are detailed in [RFC5295].

2.  Terminology

   This document uses terminology defined in [RFC3748], [RFC5295],
   [RFC5296], and [RFC4072].

   "Root key" (RK) or "bootstrapping material" refer to the latter case, a Domain Specific Root Key (DSRK) is rRK or rDSRK
   derived from
   the an EMSK, as defined in depending on the RFC 5295 [5], and is provided by location of the Home
   EAP ER server to the local domain server.  For that purpose, in
   home or foreign domain.

   We note in this document specifies the transport of the DSRK using ERP/DER a Diameter-EAP-Request command with
   the Application Id set to Diameter EAP

2.  Assumptions

   This document defines only additional optional AVPs for usage with
   the Diameter EAP ERP application.  This document does not define a new
   Diameter application  On the same
   model, we use ERP/DEA, EAP/DER and therefore a new Application ID is not
   required, EAP/DEA.

2.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in [RFC2119].

3.  Assumptions

   This document makes the Diameter Base protocol [3].

   In this document, when following assumptions.

   The Home EAP re-authentication server of a peer that wants to use ERP is performed in extended to

      Cryptographic operations needed to derive the
   domain visited by ERP root key from
      the peer, it is assumed that EMSK.  By deriving the local ER server is
   co-located with ERP root key for a Diameter agent in the visited domain present in the
   path of specific domain, the full
      home EAP exchange.  (Editor's Note: it is not clear at server implicitly authorizes the time use of writing wether ERP within this document must require

      Diameter operations to include this local AAA
   server root key inside an appropriate
      AVP as defined in this document, in an answer message
      corresponding to be on the path.)

3.  Diameter Support 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

3.1.  Protocol Overview message.

   The Diameter EAP Application Authenticator (NAS) is used extended to transport ERP messages
   between support:

      Allow the NAS (authenticator) new ERP command codes (EAP-Initiate and an authentication server (ER

   In ERP, EAP-Finish) in
      its EAP pass-through mode.

      (optional) Send the peer sends an EAP-Initiate/Re-auth EAP-Initiate/Re-Auth-Start message to

      (optional) Provide the ER
   server local domain name via lower layer specific
      mechanism or via TLV in the authenticator.  Alternatively, EAP-Initiate/Re-Auth-Start message.

      Encapsulate ERP message and receive corresponding Diameter answer,
      as described in this document.

   If one of the NAS components does not match these assumptions, the ERP
   mechanism will fail.  In such situation, a full EAP authentication
   may send an
   EAP-Initiate/Re-auth-Start message 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 peer to trigger ERP states (root keys )
   between these servers.  This replication mechanism is out of the start
   scope of ERP.  In this case, document.  If several ER servers are deployed in the peer responds with an EAP-Initiate/Re-auth
   message to the NAS.
   domain, we assume that they can be used interchangeably.

4.  Protocol Overview

   The general guidelines for encapsulating EAP messages following figure shows the components involved in ERP, and their

   from RFC 4072 [1] apply to the new                    +--------+
           +-------------+   ERP   +-----------+  (*)  |  Home  |
   Peer <->|Authenticator|<=======>| ER server | <---> |  EAP codes defined for   |
           +-------------+         +-----------+       | server |
                                    (*) Diameter EAP application,
                             explicit bootstraping scenario only.

                      Figure. Diameter ERP as well. overview.

   The EAP-Initiate/Re-auth message ER server is encapsulated 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 EAP-Payload
   AVP of ERP exchange, the authenticator creates a
   Diameter-EAP-Request message, as described in Diameter EAP Request (DER)
   application [RFC4072].  The Application Id of the message by is set to
   Diameter ERP application (code: TBD ) in the NAS and sent 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 server.  The NAS routing MUST copy be configured so that this ERP/
   DER message reachs this server, even if the contents of Destination-Realm is not
   the value
   field of local domain.

   If there is no local ER server, the 'KeyName-NAI' TLV or message is routed according to
   its Destination-Realm AVP content, extracted from the 'peer-id' TLV (when realm component
   of the former keyName-NAI attribute.  As specified in [RFC5296], this realm
   is not present) the home domain of the EAP Initiate/Re-auth message into a User-Name
   AVP peer in case of bootstrapping exchange ('B'
   flag is set in ERP message) or the domain of the Diameter EAP-Request.

   The bootstrapped ER
   server processes otherwise .

   If no ER server is available in the EAP-Initiate/Re-auth home domain either, the ERP/DER
   message cannot be delivered, and an error DIAMETER_UNABLE_TO_DELIVER
   is generated as specified in
   accordance with [2] [RFC3588] and responds 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

   When an EAP-Finish/Re-auth message.
   The Diameter ER server MUST encapsulate receives the EAP-Finish/Re-auth message
   within an EAP-Payload AVP of ERP/DER message, it searches its local
   database for a Diameter EAP Answer message.  In an
   EAP re-authentication successful case, an EAP-Master-Session-Key AVP
   is included in root key matching the Diameter EAP Answer (DEA) message that contains keyName part of the Re-authentication Master Session Key (rMSK).  The Diameter
   Result-Code SHOULD be a success Result-Code.  In an EAP re-
   authentication failure case, User-Name
   AVP.  If such key is found, the Diameter Result-Code AVP of ER server processes the a
   Diameter EAP Answer (DEA) ERP 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
   as described in [RFC5296] then creates the ERP/DEA answer as
   described in Section 6.  The rMSK is sufficient) (2nd Editor's Note: add a figure ?)

3.2.  DSRK Request and Delivery

   A local ER server, collocated with a Diameter proxy included in this answer.

   Finally, the domain
   visited by authenticator extracts the peer, may request a DSRK rMSK from the home EAP/ERP server,
   either ERP/DEA as
   described in [RFC5296], and forwards the initial EAP exchange (implicit bootstrapping) or in an
   ERP bootstrapping exchange (explicit bootstrapping).  This is done by
   including content of the EAP-DSRK-Request AVP in EAP-Payload
   AVP, the Diameter EAP Request (DER)
   message.  The EAP-DSRK-Request AVP contains EAP-Finish/Re-Auth message, to the domain or peer.

   If the EAP-Initiate/Re-Auth message has its 'B' flag set
   (Bootstrapping exchange), the ER server
   identity required to derive should not possess the DSRK. root
   key in its local database .  In successful this case, the DSRK is carried by ER server acts as a
   proxy, and forwards the EAP-DSRK AVP in message to the
   Diameter home EAP Answer (DEA) message.  Along with the EAP-DSRK AVP, an
   EAP-DSRK-Name AVP MUST be used server after changing
   its Application Id to send the DSRK's keyname Diameter EAP and adding an EAP-
   DSRK-Lifetime AVP MUST be used to send the DSRK's lifetime.
   (Editor's Note: add a figure ?).

4.  Command Codes

   This document re-uses request the EAP application commands [1] and does not
   define new command codes.

5.  Attribute Value Pair Definitions

   root key.  See section defines new AVPs Section 5 for more detail on this process.

5.  Bootstrapping the ERP support within Diameter EAP

5.1.  EAP-DSRK-Request AVP ER server

   The EAP-DSRK Request AVP (AVP Code TBD) is of type DiameterIdentity.
   This AVP fulfills two purposes: first, it indicates that a ERP bootstrapping process involves the home EAP server
   is located in and the local domain that is willing to play ER
   server, but also impacts the role of an
   ERP server for a particular session.  Second, it conveys information
   about peer and the domain name to authenticator.  In ERP, the Diameter/EAP/ERP server.  (Editor's
   Note: it is FFS if DiameterIdentity is
   peer must derive the correct type).


   The EAP-DSRK AVP (AVP Code TBD) is of type OctetString.  This AVP
   contains same keying material to be used by as the ER server.  To
   achieve this, it must learn the visited domain (i.e. name of the
   DSRK).  Exactly how ER server.  How
   this keying material information is derived acquired is beyond outside the scope of this document.

5.3.  EAP-DSRK-Name AVP

   The EAP-DSRK-Name AVP (AVP Code TBD)
   specification, but it may involves that the authenticator is
   configured to advertize this domain name, especially in the case of type OctetString.  This
   AVP contains
   re-authentication after a handover.

   The bootstrapping of an ER server with a given root key happens
   either during the EMSKname initial EAP authentication of the peer when the
   EMSK -- from which identifies the keying material.  How
   this name root key is derived -- is beyond created, during the scope of
   first re-authentication, or sometime between those events.  We only
   consider the first two possibilities in this document and defined specification, in [5].

5.4.  EAP-DSRK-Lifetime AVP

   The EAP-DSRK-Lifetime AVP (AVP Code TBD) 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 type Unsigned64 and
   contains the DSRK lifetime in seconds.  (Editor's Note: it is FFS if
   Unsigned32 is not sufficient).  (Editor's Note: peer,
   thus minimizing the re-authentication delay.  On the other hand, it
   is FFS default

6.  AVP Occurrence Table

   The following table lists the AVPs possible that may optionally be present only a small number of peers will use re-
   authentication in the DER and DEA commands [1].

                                   |  Command-Code |
      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 visited domain.  Deriving and DEA Commands AVP Table

   When the EAP-DSRK AVP is present in caching key
   material for all the DEA then peers (for example, for the EAP-DSRK-Name peers that do not
   support ERP) is a waste of resources and the EAP-DSRK-Lifetime MUST also SHOULD be present.

7.  AVP Flag Rules

   The following table describes avoided.

   To achieve implicit bootstrapping, the ER server must act as a
   Diameter AVPs, their AVP Code
   values, types, possible flag values, EAP Proxy as defined in Diameter Base Protocol [RFC3588],
   and whether the AVP MAY routing must be
   encrypted. 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 base [3] specifies EAP/DER
                                     Diameter EAP/DER

           Multi-round Diameter EAP exchanges, unmodified

                                      Diameter EAP/DEA
            Diameter EAP/DEA

         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 Flag rules for
   AVPs inside, if this AVP is not already in Section 4.5.

   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 Flag Rules   |
                                            +----+-----+----+-----+----+ 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  Section           |    |     |SHLD|MUST |    |
  Attribute Name     Code Defined Data Type |MUST| 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 |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 save this information to space constraints, 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 short form DiamIdent 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
  represent DiameterIdentity.

                      Figure 2: AVP Flag Rules Table 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
                                       Diameter EAP/DER

                                       Diameter EAP/DEA
             Diameter ERP/DEA

              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
 Peer                 Authenticator               (local or home domain)
 ====                 =============               ======================
 [ <------------------------         ]
 [optional EAP-Initiate/Re-auth-start]

                                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

                      Figure. Diameter ERP exchange.

   In ERP, the peer sends an EAP-Initiate/Re-auth message to the ER
   server via the authenticator.  Alternatively, the NAS may send an
   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
   message to the NAS.

   If the authenticator does not support ERP (pure [RFC4072] support),
   it discards the EAP packets with unknown ERP-specific code (EAP-
   Initiate).  The peer may fallback to full EAP authentication in such

   When the authenticator receives an EAP-Initiate/Re-auth message from
   the peer, it process as described in [RFC5296] with regards to the
   EAP state machine.  It creates a Diameter EAP Request message
   following the general process of Diameter EAP [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

      The keyName-NAI attribute from ERP message is used to create the
      content of User-Name AVP and Destination-Realm AVP.

      The Auth-Request-Type AVP content is set to [Editor's note: FFS].

      The EAP-Payload AVP contains the ERP message, EAP-Initiate/

   Then this ERP/DER message is sent as described in Section 4.

   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

      The Application Id in the header is set to Diameter ERP (code

      The value in Auth-Application-Id AVP is also set to Diameter ERP

      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.

      In case of successful authentication, the EAP-Master-Session-Key
      AVP contains the Re-authentication Master Session Key (rMSK)
      derived by ERP.

   When the authenticator receives this ERP/DEA answer, it processes it
   as described in Diameter EAP [RFC4072] and [RFC5296]: the content of
   EAP-Payload AVP content is forwarded to the peer, and the content of
   EAP-Master-Session-Key AVP is used as a shared secret for Secure
   Association Protocol.

7.  Application Id

   We define a new Diameter application in this document, Diameter ERP
   Application, with an Application Id value of TBD.  Diameter nodes
   conforming to this specification in the role of ER server MUST
   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].

   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.

8.  AVPs

   This specification defines the following new AVPs.

8.1.  ERP-RK-Request AVP

   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
   server for a particular session.

   This AVP has the M and V bits cleared.

         ERP-RK-Request ::= < AVP Header: TBD >
                            { ERP-Realm }
                          * [ AVP ]

                        Figure. ERP-RK-Request ABNF

8.2.  ERP-Realm AVP

   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.

   This AVP has the M and V bits cleared.

8.3.  ERP-RK-Answer AVP

   The ERP-RK-Answer AVP (AVP Code TBD) is of type grouped AVP.  It is
   used by the home EAP server to provide ERP root key material to the
   ER server.

   This AVP has the M and V bits cleared.

          ERP-RK-Answer ::= < AVP Header: TBD >
                            { ERP-RK }
                            { ERP-RK-Name }
                            { ERP-RK-Lifetime }
                          * [ AVP ]

                        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

   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

   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

   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

   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:







   These AVPs are defined in section Section 8.

13.  Security Considerations

   The security considerations specified in from the following RFC 4072 [1], apply here:
   [RFC3588], [RFC4072], [RFC5247], [RFC5295], and RFC 3588
   [3] are applicable to this document. [RFC5296].

   EAP channel bindings may be necessary to ensure that the Diameter
   client and the server are in sync regarding the key Requesting
   Entity's Identity.  Specifically, the Requesting Entity advertises
   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
   communicates that identity to the Diameter server) via the EAP method
   for user/peer to server verification of the Requesting Entity's

9.  IANA Considerations

   This document requires IANA registration of the following new AVPs to
   the AVP registry established by RFC 3588 [3]:

   o  EAP-DSRK-Request

   o  EAP-DSRK

   o  EAP-DSRK-Name

   o  EAP-DSRK-Lifetime

10.  Acknowledgments

   Vidya Narayanan reviewed a rough draft version and found some errors.
   Many thanks for her input.


14.  References


14.1.  Normative References

   [1]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
        Authentication Protocol (EAP) Application", RFC 4072,
        August 2005.

   [2]  Narayanan, V. and L. Dondeti, "EAP Extensions

   [RFC2119]                         Bradner, S., "Key words for EAP Re-
        authentication Protocol (ERP)", use in
                                     RFCs to Indicate Requirement
                                     Levels", BCP 14, RFC 5296, August 2008.

   [3] 2119,
                                     March 1997.

   [RFC3588]                         Calhoun, P., Loughney, J., Guttman,
                                     E., Zorn, G., and J. Arkko,
                                     "Diameter Base Protocol", RFC 3588,
                                     September 2003.

   [4]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14,

   [RFC3748]                         Aboba, B., Blunk, L., Vollbrecht,
                                     J., Carlson, J., and H. Levkowetz,
                                     "Extensible Authentication Protocol
                                     (EAP)", RFC 2119, March 1997.

11.2.  Informative References

   [5] 3748, June 2004.

   [RFC4072]                         Eronen, P., Hiller, T., and G.
                                     Zorn, "Diameter Extensible
                                     Authentication Protocol (EAP)
                                     Application", RFC 4072,
                                     August 2005.

   [RFC5295]                         Salowey, J., Dondeti, L.,
                                     Narayanan, V., and M. Nakhjiri,
                                     "Specification for the Derivation
                                     of Root Keys from an Extended
                                     Master Session Key (EMSK)",
                                     RFC 5295, August 2008.

   [6]  Aboba, B., Blunk,

   [RFC5296]                         Narayanan, V. and L. Dondeti, "EAP
                                     Extensions for EAP Re-
                                     authentication Protocol (ERP)",
                                     RFC 5296, August 2008.

14.2.  Informative References

   [I-D.ietf-dime-app-design-guide]  Fajardo, V., Asveren, T.,
                                     Tschofenig, H., McGregor, G., and
                                     J. Loughney, "Diameter Applications
                                     Design Guidelines",
                                     (work in progress), November 2008.

   [I-D.ietf-dime-erp]               Dondeti, L., Vollbrecht, J., Carlson, Bournelle, J., Morand,
                                     L., and S. Decugis, "Diameter
                                     Support for EAP Re-authentication
                                     Protocol", draft-ietf-dime-erp-00
                                     (work in progress), January 2009.

   [I-D.ietf-hokey-key-mgm]          Hoeper, K. and Y. Ohba,
                                     "Distribution of EAP based keys for
                                     handover and re-authentication",
                                     draft-ietf-hokey-key-mgm-06 (work
                                     in progress), April 2009.

   [I-D.wu-dime-local-keytran]       Wu, W., "Diameter support for local
                                     key transport protocol between
                                     local server and  home AAA server",
                                     (work in progress), May 2009.

   [RFC4187]                         Arkko, J. and H.
        Levkowetz, Haverinen,
                                     "Extensible Authentication Protocol (EAP)",
                                     Method for 3rd Generation
                                     Authentication and Key Agreement
                                     (EAP-AKA)", RFC 3748,
        June 2004. 4187, January 2006.

   [RFC5247]                         Aboba, B., Simon, D., and P.
                                     Eronen, "Extensible Authentication
                                     Protocol (EAP) Key Management
                                     Framework", RFC 5247, August 2008.


   [1]  <http://www.iana.org/assignments/aaa-parameters/>

Authors' Addresses

   Lakshminath Dondeti
   5775 Morehouse Dr
   San Diego, CA

   Phone: +1 858-845-1267
   EMail: ldondeti@qualcomm.com
   Julien Bournelle
   Orange Labs
   38-40 rue du general Leclerc
   Issy-Les-Moulineaux  92794


   EMail: julien.bournelle@orange-ftgroup.com

   Lionel Morand
   Orange Labs
   38-40 rue du general Leclerc
   Issy-Les-Moulineaux  92794


   EMail: lionel.morand@orange-ftgroup.com

   Sebastien Decugis (editor)
   4-2-1 Nukui-Kitamachi
   Tokyo  184-8795
   Koganei, Japan


   EMail: sdecugis@nict.go.jp

   Qin Wu
   Huawei Technologies Co., Ltd
   Site B, Floor 12F, Huihong Mansion, No.91 Baixia Rd.
   Nanjing  210001

   EMail: sunseawq@huawei.com