--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/draft-sdecugis-dime-diameter-erp.xml	Wed Jun 03 18:24:36 2009 +0900
@@ -0,0 +1,320 @@
+<?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>