<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY RFC4005 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4005.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 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="full3978">
  <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 (a.k.a. ERP, RFC5296) 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 constraining requirements on routing of Diameter
      messages, that cannot be met by standard Diameter routing algorithm
      defined in the <xref target="RFC3588">Diameter Base Protocol</xref>.
      They also introduce interoperability problems for the peer and the NAS
      that cannot be overcome easily.</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>
          <t>(bootstrapping) Creation of a root key for the session, 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) A one-round-trip ERP exchange between the
          peer and the ER server, functionally equivalent to a full EAP
          authentication.</t>
        </list>The bootstrapping of the ER server can occur before
      (asynchronous) or during (synchronous) the re-authentication.</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 DER/DEA commands.</t>

      <t>It also discusses the key distribution (bootstrapping) and proposes
      some solutions for different architectures. Anyway, a deployment that
      conforms to this specification may adopt a different mechanism for key
      distribution, such as described in <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 term "EAP server" refers to a server for EAP with
      sufficient extensions for ERP to create ERP keying material.</t>

      <t>"root key" or "bootstrapping material" refer to the rRK (for ER
      server in home domain) or the rDSRK (ER server in separate domain),
      depending on the context.</t>
    </section>

    <section anchor="Overview" title="Overview">
      <t>The following figure shows the components involved in ERP, and their
      interactions. During the lifetime of the EMSK derived from a full EAP
      authentication, a peer may attach to several authenticators, and
      eventually use different ER servers (for example in 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 the EAP
      server) or the visited domain (same as authenticator, in case 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 occurs sometime between the
      initial EAP authentication, and the first ERP re-authentication. See
      section <xref target="Bootstrapping">4</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 process, based on <xref target="RFC5296"></xref>, and
      shows how Diameter is used in this context. See section <xref
      target="Re-authentication">5</xref> for a detailed description.</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>

      <t></t>
    </section>

    <section anchor="Bootstrapping" title="Bootstrapping options">
      <t></t>
    </section>

    <section anchor="Re-authentication" title="Re-Authentication">
      <t></t>
    </section>

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

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>

      <t>(It's good - indeed pretty much mandatory now - to have an explicit
      note because otherwise IANA wastes cycles trying to figure out if
      something is needed..)</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Remember to consider security from the start.. and all drafts are
      required to have a security considerations section before they will pass
      the IESG.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <!-- References split to informative and normative -->

    <references title="Normative References">
      <reference anchor="RFC2119"
                 target="http://xml.resource.org/public/rfc/html/rfc2119.html">
        <front>
          <title abbrev="RFC Key Words">Key words for use in RFCs to Indicate
          Requirement Levels</title>

          <author fullname="Scott Bradner" initials="S." surname="Bradner">
            <organization>Harvard University</organization>

            <address>
              <postal>
                <street>1350 Mass. Ave.</street>

                <street>Cambridge</street>

                <street>MA 02138</street>
              </postal>

              <phone>- +1 617 495 3864</phone>

              <email>sob@harvard.edu</email>
            </address>
          </author>

          <date month="March" year="1997" />

          <area>General</area>

          <keyword>keyword</keyword>

          <abstract>
            <t>In many standards track documents several words are used to
            signify the requirements in the specification. These words are
            often capitalized. This document defines these words as they
            should be interpreted in IETF documents. Authors who follow these
            guidelines should incorporate this phrase near the beginning of
            their document: <list>
                <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 RFC 2119.</t>
              </list></t>

            <t>Note that the force of these words is modified by the
            requirement level of the document in which they are used.</t>
          </abstract>
        </front>

        <seriesInfo name="BCP" value="14" />

        <seriesInfo name="RFC" value="2119" />

        <format octets="4723" target="ftp://ftp.isi.edu/in-notes/rfc2119.txt"
                type="TXT" />

        <format octets="14486"
                target="http://xml.resource.org/public/rfc/html/rfc2119.html"
                type="HTML" />

        <format octets="5661"
                target="http://xml.resource.org/public/rfc/xml/rfc2119.xml"
                type="XML" />
      </reference>

      &RFC3588;

      &RFC4005;

      &RFC5295;

      &RFC5296;
    </references>

    <references title="Informative References">
      &I-D.draft-ietf-hokey-key-mgm;
    </references>

    <section anchor="app-additional" title="Additional stuff">
      <t>You can add appendices just as regular sections, the only difference
      is that they go within the "back" element, and not within the "middle"
      element. And they follow the "reference" elements.</t>
    </section>
  </back>
</rfc>