<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3748 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3748.xml">
<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY RFC4072 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4072.xml">
<!ENTITY RFC5295 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5295.xml">
<!ENTITY RFC5296 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5296.xml">
<!ENTITY I-D.draft-ietf-hokey-key-mgm SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-hokey-key-mgm-06.xml">
<!ENTITY I-D.draft-ietf-dime-app-design-guide SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-app-design-guide-08.xml">
<!ENTITY I-D.draft-gaonkar-radext-erp-attrs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gaonkar-radext-erp-attrs-03.xml">
<!ENTITY nbsp "&#160;">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc editing="no"?>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc rfcedstyle="yes"?>
<?rfc rfcprocack="no"?>
<?rfc tocindent="yes"?>
<rfc category="std" docName="draft-sdecugis-dime-diameter-erp"
     ipr="trust200902">
  <front>
    <title abbrev="Diameter ERP support">Diameter support for EAP
    Re-authentication Protocol (ERP)</title>

    <author fullname="Sebastien Decugis" initials="S." role="editor"
            surname="Decugis">
      <organization abbrev="NICT">NICT</organization>

      <address>
        <postal>
          <street>4-2-1 Nukui-Kitamachi</street>

          <city>Koganei, Tokyo</city>

          <code>184-8795</code>

          <country>JP</country>
        </postal>

        <email>sdecugis@nict.go.jp</email>
      </address>
    </author>

    <date year="2009" />

    <area>Operations &amp; Management</area>

    <workgroup>Diameter Maintenance and Extensions (DIME)</workgroup>

    <keyword>Internet-Draft</keyword>

    <keyword>ERP</keyword>

    <keyword>Diameter</keyword>

    <keyword>Re-authentication</keyword>

    <abstract>
      <t>The EAP Re-authentication Protocol (ERP) provides a mechanism to
      optimize EAP authentication delay in the case of re-authentication,
      which can be significant in roaming mobile situation. This mechanism
      assumes that a protocol for Authentication, Authorization and Accounting
      (AAA) is available to transport ERP between the authenticator(s) and the
      EAP/ERP server. draft-gaonkar-radext-erp-attrs-03 specifies the
      transport of ERP using RADIUS. This document specifies the transport of
      ERP using Diameter.</t>
    </abstract>

    <note title="Foreword">
      <t>This document differs from <eref
      target="http://tools.ietf.org/html/draft-ietf-dime-erp-00">draft-ietf-dime-erp-00</eref>
      in its design and scope.</t>

      <t>In this new version, we use a new Diameter application id for
      messages with ERP payload exchanged between authenticator and ER server.
      This simplifies the routing of Diameter messages to the appropriate
      server, and allows more flexibility in the deployment of ERP.</t>

      <t>The scope of previous documents (<eref
      target="http://tools.ietf.org/html/draft-ietf-dime-erp-00">draft-ietf-dime-erp-00</eref>
      and <eref
      target="http://tools.ietf.org/html/draft-wu-dime-local-keytran-00">draft-wu-dime-local-keytran-00</eref>)
      was focused on the implicit bootstrapping scenario described in <xref
      target="RFC5296"></xref>. By re-using the Diameter EAP application,
      these documents create implicit constraints on routing of messages that
      cannot be met by standard Diameter routing algorithm defined in the
      <xref target="RFC3588">Diameter Base Protocol</xref>. A separate
      Diameter Id may also allow the authenticator to dynamically discover if
      the local domain supports ERP or not.</t>
    </note>

    <note title="Requirements Language">
      <t>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 <xref
      target="RFC2119"></xref>.</t>
    </note>
  </front>

  <middle>
    <section anchor="Introduction" title="Introduction">
      <t><xref target="RFC5296"></xref> defines the EAP Re-authentication
      Protocol (ERP) and mechanism that consists in the two following
      steps:<list style="numbers">
          <t>Bootstrapping: creation of a root key for re-authentication,
          after initial EAP authentication of the peer. This root key is
          distributed from the EAP server to the ER server. How this key is
          tranported is not specified in the ERP mechanism.</t>

          <t>Re-authentication: one-round-trip exchange between the peer and
          the ER server, functionally equivalent to a full EAP
          authentication.</t>
        </list></t>

      <t>This document specifies how Diameter is used to carry the
      re-authentication exchange (second step). For this purpose, we define a
      new Application Id for ERP, and re-use the Diameter EAP commands
      (DER/DEA).</t>

      <t>We also discuss the key distribution (first step, bootstrapping) and
      propose some solutions for different architectures. Anyway, implementors
      are free to choose a different mechanism for key distribution, as for
      example using RADIUS<xref target="I-D.ietf-hokey-key-mgm"></xref>.
      Security considerations for key distribution are explained in <xref
      target="RFC5295"></xref>.</t>
    </section>

    <section title="Terminology">
      <t>We re-use here the terminology from <xref target="RFC5296"></xref>.
      In particular, the EAP server implicitely supports ERP extensions to
      generate the ERP keying material and send it to the ER server. These
      terms "authenticator", "ER server", "EAP server" denote logical
      functional entities and make no assumption on the real implementation
      and deployment.</t>

      <t>"root key" or "bootstrapping material" refer to the rRK (home ER
      server) or rDSRK (foreign ER server) derived from an EMSK, depending on
      the context.</t>

      <t>We re-use also some terminology and abbreviations from <xref
      target="RFC4072"></xref>, for example DER/DEA.</t>
    </section>

    <section anchor="Overview" title="Overview">
      <t>During the lifetime of an EMSK (derived during a full EAP
      authentication), a peer may attach to several authenticators. In this
      case, re-authentication is more efficient than full authentication,
      especially in the case of roaming. ERP provides a mechanism for
      re-authentication independent of the link layer, as opposed to IEEE
      802.11r-2008 for example, so it can be used in case of multihoming or
      horizontal handovers. The following figure shows the components involved
      in ERP, and their interactions. When the peer attaches to a new
      authenticator, the ER server involved in the transaction may change, for
      example in the case of inter-domain roaming.</t>

      <figure title="Diameter applications used in the ERP mechanism.">
        <artwork><![CDATA[                        Diameter                    +--------+
        +-------------+   ERP   +-----------+  (*)  |  Home  |
Peer <->|Authenticator|<=======>| ER server | <---> |  EAP   |
        +-------------+         +-----------+       | server |
                                                    +--------+
    (*) Several protocols can be used between ER server and 
       home EAP server to transport bootstrapping material.
]]></artwork>
      </figure>

      <t>The ER server may be located in the home domain (same as EAP server)
      or the visited domain (same as authenticator, when it differs from the
      home domain). <cref>TBD: Can the ER server be located in a third domain
      (ex: broker's)?</cref></t>

      <t>The bootstrapping of the ER server has to occur sometime between the
      initial EAP authentication and the first ERP re-authentication with this
      ER server. See section <xref target="Bootstrapping"></xref> for detail
      on this process. Then, the peer re-authenticates, for example after a
      movement that makes it attach to a new authenticator. The following
      figure describes this re-authentication, and shows how Diameter is used
      in this context. See section <xref target="Re-authentication"></xref>
      for a detailed description, and following sections for details on the
      Diameter messages format.</t>

      <figure title="Diameter ERP exchange. ">
        <artwork><![CDATA[                                                        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
]]></artwork>
      </figure>
    </section>

    <section anchor="ApplicationId" title="Application Id">
      <t>We define a Diameter ERP Application in this document, with an
      Application Id value of <cref>TBD</cref>. Diameter nodes conforming to
      this specification (in the role of ER server or authenticator) MUST
      advertise support by including the Diameter ERP Application ID value in
      the Auth-Application-Id AVP of the Capabilities-Exchange-Request and
      Capabilities-Exchange-Answer command <xref target="RFC3588"></xref>.</t>

      <t>The primary use of the Diameter ERP Application Id is to ensure
      proper routing of the messages, and that the nodes that advertise the
      support for this application do understand the new AVPs defined in the
      next section (although these AVP have the 'M' flag cleared).</t>
    </section>

    <section anchor="AVPs" title="AVPs">
      <t>This specification defines the following new AVPs.</t>

      <section title="ERP-RK-Request AVP">
        <t>The ERP-RK-Request AVP (AVP Code <cref>TBD</cref>) is of type
        grouped AVP. It is used by the ER server to request root key material
        used in ERP.</t>

        <t>This AVP has the M and V bits cleared.</t>

        <figure title="ERP-RK-Request ABNF">
          <artwork><![CDATA[      ERP-RK-Request ::= < AVP Header: TBD >
                         { ERP-Realm }
                       * [ AVP ]
]]></artwork>
        </figure>
      </section>

      <section title="ERP-Realm AVP">
        <t>The ERP-Realm AVP (AVP Code <cref>TBD</cref>) is of type
        <cref>{DiameterIdentity? OctetString?}</cref>. It contains the name of
        the realm in which the ER server is located.</t>

        <t><cref>FFS: We may re-use Origin-Realm here instead? On the other
        hand, ERP-Realm may be useful in CER/CEA with a NAS...</cref></t>

        <t>This AVP has the M and V bits cleared.</t>
      </section>

      <section title="ERP-RK-Answer AVP">
        <t>The ERP-RK-Answer AVP (AVP Code <cref>TBD</cref>) is of type
        grouped AVP. It is used by the home EAP server to provide ERP root key
        material to the ER server.</t>

        <t>This AVP has the M and V bits cleared.</t>

        <figure title="ERP-RK-Answer ABNF">
          <artwork><![CDATA[       ERP-RK-Answer ::= < AVP Header: TBD >
                         { ERP-RK }
                         { ERP-RK-Name }
                         { ERP-RK-Lifetime }
                       * [ AVP ]
]]></artwork>
        </figure>
      </section>

      <section title="ERP-RK AVP">
        <t>The ERP-RK AVP (AVP Code <cref>TBD</cref>) is of type OctetString.
        It contains the root key (either rRK or rDSRK) to be used for ERP with
        the peer to which the current session belongs. How this material is
        derived and used is specified in <xref target="RFC5296"></xref>.</t>

        <t><cref>Can we re-use EAP-Master-Session-Key here?</cref></t>

        <t>This AVP has the M and V bits cleared.</t>
      </section>

      <section title="ERP-RK-Name AVP">
        <t>The ERP-RK AVP (AVP Code <cref>TBD</cref>) 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 <xref target="RFC5296"></xref>.</t>

        <t><cref>Can we re-use EAP-Key-Name here?</cref></t>

        <t>This AVP has the M and V bits cleared.</t>
      </section>

      <section title="ERP-RK-Lifetime AVP">
        <t>The ERP-RK-Lifetime AVP (AVP Code <cref>TBD</cref>) is of type
        <cref>Unsigned64? 32?</cref> 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. <cref>FFS: is it
        better to pass an absolute value here, for example expiration date?
        How to express it then (TZ, ...)? Synchronization problems?</cref></t>

        <t>This AVP has the M and V bits cleared.</t>
      </section>
    </section>

    <section anchor="Commands" title="Commands">
      <t>We do not define any new command in this specification. We reuse the
      Diameter-EAP-Request and Diameter-EAP-Answer commands defined in <xref
      target="RFC4072"></xref>.</t>

      <t>The Application Id field in the command header <cref>and the value in
      Auth-Application-Id AVP which is redundant???</cref> can be set to
      Diameter EAP application or Diameter ERP application, depending on the
      situation, as explained in the next sections.</t>

      <t>Since the original ABNF of these commands allow other optional AVPs
      ("* [ AVP ]"), and the new AVPs defined in this specification do not
      have the 'M' flag set, the ABNF does not need any change. Anyway, a
      Diameter node that advertize support for the Diameter ERP application
      MUST support the ERP-RK-Request and ERP-RK-Answer AVP <cref>Therefore,
      in DER/DEA with Diameter ERP application ID, do we set the 'M' flag to
      these AVPs?</cref>.</t>

      <figure title="Command Codes">
        <artwork><![CDATA[   Command-Name          Abbrev. Code Reference Application
   ---------------------------------------------------------
   Diameter-EAP-Request  DER     268  RFC 4072  Diameter ERP
   Diameter-EAP-Answer   DEA     268  RFC 4072  Diameter ERP
]]></artwork>
      </figure>
    </section>

    <section anchor="Bootstrapping" title="Bootstrapping options">
      <t>Bootstrapping involves the ER server and the EAP server directly, but
      also indirectly the peer and the authenticator. For ERP to be
      successful, the peer must derive the same keying material as the ER
      server. To make this possible, it must learn the domain name of the ER
      server. How this is achieved is outside the scope of this specification,
      but it usually involves that the authenticator is configured to
      advertize this domain name. This could be achieved for example by
      including the ERP-Realm AVP in a CER/CEA exchange.</t>

      <t>As stated in the <xref target="Overview"></xref>, the bootstrapping
      of an ER server has to happen between the initial EAP authentication of
      the peer, when the EMSK is created, and the moment the peer
      re-authenticates with this ER server, when the bootstrapping material is
      needed. While asynchrounous solutions are perfectly possible, it is
      usually easier to bootstrap the ER server during one of these
      events.</t>

      <section title="Bootstrapping during initial EAP authentication">
        <t>Bootstrapping an ER server during the initial EAP authentication
        offers the advantage that the server is immediatly available for
        re-authentication of the peer, thus minimizing the re-authentication
        delay.</t>

        <t>On the other hand, re-authentication may only concern a small
        number of peers in the visited domain. Deriving and caching key
        material for all the peers (for example, for the peers that do not
        support ERP, or that are not mobile) is a waste of resources and
        SHOULD be avoided. In addition, bootstrapping ERP during full EAP
        authentication may prevent re-authentication in case of inter-domain
        roaming. Hence, while this mecanism is useful in some situations, it
        should be deployed with care.</t>

        <t>In the case where ER server is collocated with the Home EAP server,
        ER bootstrapping is transparent with regards to this specification,
        although some sort of communication might be needed inside the node.
        In this case, the server MUST advertise support of both the Diameter
        EAP application and the Diameter ERP application, but the new AVPs
        defined in this specification are not used.</t>

        <t>When ER server and EAP server are different entities with regards
        to Diameter, one or more Diameter EAP proxy(ies) is(are) needed in the
        same domain as the ER server. While this(these) proxy(ies) might be
        separate entity(ies) with secure communication channel with the ER
        server, it is functionally equivalent to consider that the ER server
        acts as a Diameter EAP proxy. In the rest of this section, we consider
        that the ER server acts as a Diameter EAP proxy in its domain.</t>

        <t>In order to bootstrap the ER server during full EAP authentication,
        this server must be on the route, and act as a proxy, for the first
        and last round of exchanges of the full EAP authentication, as
        captured in the figure bellow.</t>

        <figure title="ERP bootstrapping during full EAP authentication">
          <artwork><![CDATA[                         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]
]]></artwork>
        </figure>

        <t>The ER server proxies the first DER of the full EAP authentication
        and adds the ERP-RK-Request AVP inside, if this AVP is not already in
        the message, then forwards the request.</t>

        <t>If the EAP server does not support ERP extensions, it will simply
        ignore this grouped AVP and continue as specified in <xref
        target="RFC4072"></xref>. 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 <xref target="RFC5296"></xref>, and add an ERP-RK-Answer
        AVP in the Diameter-EAP-Request message, in addition to the MSK and
        EAP-Success payload. <cref>FFS: is it important to check that the
        server that added the ERP-RK-Request is in the path of the answer?
        What's the worst that can happen?</cref></t>

        <t>When the ER server proxies a Diameter-EAP-Answer message with a
        Session-Id corresponding to a message to which it added an
        ERP-RK-Answer, and the Result-Code is DIAMETER_SUCCESS, it MUST
        examine the message and remove any ERP-RK-Answer AVP, and save its
        content. If the message does not contain an ERP-RK-Answer AVP, the ER
        server MAY save this information to avoid possible attempts later for
        this session. In any case, the information stored SHOULD NOT have a
        lifetime greater than the EMSK lifetime <cref>FFS: how does the ER
        server knows the EMSK lifetime, if there is no ERP-RK-Answer? What is
        the lifetime of the MSK for example?</cref></t>

        <t>If the ER server is successfully bootstrapped, it MAY also add the
        ERP-Realm AVP after removing the ERP-RK-Answer AVP in the
        Diameter-EAP-Answer message. This could be used by the authenticator
        to notify the peer that ERP is bootstrapped, with the ER domain
        information. How this information can be transmitted to the peer is
        outside the scope of this document. <cref>Is it possible? It would be
        useful...</cref></t>
      </section>

      <section title="Bootstrapping during first re-authentication">
        <t>Bootstrapping the ER server during the first re-authentication
        offers several advantages: it saves resources, since we generate and
        cache only useful keying material, it can also accomodate inter-domain
        roaming or ER servers that loose their state (for example after
        reboot).</t>

        <t>On the other hand, the first re-authentication with the ER server
        requires a one-round-trip with the home EAP server, which adds some
        delay to the process (but it is more efficient than a full EAP
        authentication in any case). Note that following re-authentications
        for the same session with the same ER server will not have this
        additional delay.</t>

        <t><xref target="RFC5296"></xref> describes two types of bootstrapping
        for ERP: implicit bootstrapping and explicit bootstrapping. In
        implicit bootstrapping, the peer knows the domain it is located in,
        and assumes that the ER server already possess the keying material for
        the session. In this case, the peer uses a Keyname-NAI in the form
        "EMSKname@localdomain". In explicit bootstrapping, the Keyname-NAI is
        in the form "EMSKname@homedomain". As we will see in next section
        <xref target="Re-authentication"></xref>, the domain part of the
        Keyname-NAI becomes the Destination-Realm of the Diameter message, and
        the Application Id is set to Diameter ERP application.</t>

        <t>In the case of implicit bootstrapping (how the peer learns that the
        ER server is bootstrapped is outside the scope of this specification)
        or after a first succesful re-authentication in the visited domain,
        the message is routed to the local ER server following normal Diameter
        routing. If the ER server does not have key information corresponding
        to this EMSKname, <cref>return an error to the peer? proxy the request
        and send ERP-RK-Request to the home EAP server? How do we learn which
        is the home domain?</cref>. See the next section <xref
        target="Re-authentication"></xref> for detail.</t>

        <t>In the case of explicit bootstrapping (the ERP message has its 'B'
        flag set), if an ER server exists in the visited domain, it SHOULD be
        configured for and act as a Diameter ERP proxy, and process the
        messages as described below. If not, the ER server in the home domain
        will be used, which is less efficient. The description that follow for
        the ER server in the visited domain is also valid for the ER server in
        the home domain.</t>

        <t><cref>What should we do if the ER server receives an explicit
        bootstrapping request but already possess the rDSRK?</cref></t>

        <t>The ER server proxies the request (DER with Diameter ERP
        application code) as follow, in addition to standard proxy
        operations:<list>
            <t>Change the Application Id in the header of the message to
            Diameter EAP Application (code 5). <cref>What about the
            Application-Auth-Id AVP?</cref></t>

            <t>Add the ERP-RK-Request AVP, which contains the name of the
            domain the ER server is located in (with regards to ERP).</t>
          </list>Then the request is forwarded as usual. With its Diameter EAP
        application id and Destination-Realm set to the home domain of the
        peer, the request reaches the home EAP server. If this server does not
        support ERP extensions, it replies with an error since the
        encapsulated EAP-Initiate/Re-auth command is not understood.
        Otherwise, it processes the ERP request as described in <xref
        target="RFC5296"></xref>. In particular, it includes the Domain-Name
        TLV attribute with the content from the ERP-Realm AVP. It creates the
        DEA reply message following standard processing from <xref
        target="RFC4072"></xref> (in particular EAP-Master-Session-Key AVP is
        used to transport the rMSK), and includes the ERP-RK-Answer AVP.</t>

        <t>The ER server receives this DEA and proxies it as follow, in
        addition to standard proxy operations:<list>
            <t>Set the Application Id back to Diameter ERP (code
            <cref>TBD</cref>)</t>

            <t>Extract and cache the content of the ERP-RK-Answer.</t>
          </list>The DEA is then forwarded to the authenticator, that can use
        the rMSK as described in <xref target="RFC5296"></xref>.</t>

        <t>The figure below captures this Diameter ERP Proxy behavior:</t>

        <figure title="ERP explicit bootstrapping message flow">
          <artwork><![CDATA[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)
]]></artwork>
        </figure>
      </section>
    </section>

    <section anchor="Re-authentication" title="Re-Authentication">
      <t>This section describes a re-authentication exchange with a
      bootstrapped ER server. The peer is assumed to know the domain of the
      bootstrapped ER server in advance. See previous section <xref
      target="Bootstrapping"></xref> for more information.
      EAP-Initiate/Re-auth-start with Domain-Name TLV is a possibility for the
      peer to learn the domain of the ER server attached to the
      authenticator.</t>

      <t>The following figure describes the re-authentication exchange.
      Explication follow.</t>

      <figure title="Diameter ERP exchange">
        <artwork><![CDATA[                                                 Bootstrapped ER server
 Peer                 Authenticator             (in local or home domain)
 ====                 =============             =========================
 [ <------------------------         ]               
 [optional EAP-Initiate/Re-auth-start]               

   ----------------------->
     EAP-Initiate/Re-auth
                           =================================>
                               Diameter ERP, cmd code DER
                                 User-Name: Keyname-NAI
                            EAP-Payload: EAP-Initiate/Re-auth
 
                           <=================================
                               Diameter ERP, cmd code DEA
                             EAP-Payload: EAP-Finish/Re-auth
                              EAP-Master-Session-Key: rMSK
    <----------------------
      EAP-Finish/Re-auth

]]></artwork>
      </figure>

      <t>The authenticator that does not support ERP <xref
      target="RFC4072"></xref> discards EAP packets with unknown ERP-specific
      code (EAP-Initiate). The peer falls back to full EAP authentication in
      that case.</t>

      <t>When the ERP-compatible authenticator receives an
      EAP-Initiate/Re-auth message from the peer (or after having sent a
      EAP-Initiate/Re-auth-start packet), it process as described in <xref
      target="RFC5296"></xref> with regards to the EAP state machine, and
      similarly to <xref target="RFC4072">Diameter EAP</xref>, with regards to
      Diameter, with the following differences:<list>
          <t>The application id is set to Diameter ERP instead of Diameter
          EAP.</t>

          <t>The User-Name and Destination-Realm are derived from the
          Keyname-NAI.</t>

          <t><cref>How do we create / retrieve the Session-Id?</cref></t>
        </list></t>

      <t>The ER server receives this request and process the ERP payload as
      described in <xref target="RFC5296"></xref>. If re-authentication is
      successful, it creates a DEA answer as described in Diameter EAP, with
      the following differences:<list>
          <t>The application id is set to Diameter ERP.</t>

          <t>The EAP-Payload AVP contains the ERP message:
          EAP-Finish/Re-auth</t>

          <t>The EAP-Master-Session-Key AVP contains the rMSK</t>

          <t>The Result-Code AVP contains DIAMETER_SUCCESS.</t>
        </list>In case the re-authentication fails, the Result-Code AVP
      contains an error code, and no EAP-Master-Session-Key AVP is
      included.</t>

      <t>When the authenticator receives this answer, it processes it as
      described in Diameter EAP: forwards the EAP payload to the peer, and use
      the rMSK as a shared secret in Secure Association Protocol.</t>
    </section>

    <section anchor="Sessions" title="Sessions">
      <t>This section describes how sessions are handled in case of
      re-authentication.</t>

      <t><cref>See guidelines in I-D.ietf-dime-app-design-guide</cref></t>

      <t><cref>During initial full EAP authentication, the identity of the
      peer is used to create the Session-Id AVP, which is then used during
      accounting. When the peer attaches to a new authenticator and performs
      ERP, its identity is not disclosed to the authenticator. Instead, the
      peer presents the Keyname-NAI. This identifiers contains the EMSKName as
      user part. </cref></t>

      <t><cref>The new authenticator will therefore derive the new Session-Id
      from this EMSKName and use this for accounting purpose. </cref></t>

      <t><cref>Although the home EAP server is able to link EMSKName with the
      peer's identity, the other Diameter entities do not have this mapping.
      In particular, the realm part of Keyname-NAI is the visited network. How
      does the authenticator figures out that the account records must be sent
      to the home domain of the peer? </cref></t>

      <t><cref>It is possible to cache the necessary information at the ER
      server level. Is it useful to specify this mechanism in this
      document?</cref> </t>
    </section>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t><cref>Remember, it's important to acknowledge people who have
      contributed to the work</cref></t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t><cref>Request a new Application Id for Diameter ERP.</cref></t>

      <t><cref>Request new AVP Codes for ERP-* AVPs</cref></t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t><cref>Security considerations from RFC3588 (+bis), RFC4072, RFC5247,
      RFC5295, and RFC5296 apply</cref></t>

      <t><cref>Is it safe to use ERP-RK-Request / Answer AVPs? What is the
      worst case?</cref></t>
    </section>
  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;

      &RFC3588;

      &RFC4072;

      &RFC5295;

      &RFC5296;
    </references>

    <references title="Informative References">
      &RFC3748;

      &I-D.draft-ietf-hokey-key-mgm;

      &I-D.draft-gaonkar-radext-erp-attrs;

      &I-D.draft-ietf-dime-app-design-guide;
    </references>
  </back>
</rfc>