Mercurial > hg > ietf

changeset 28:e067e505c18d

Find changesets by keywords (author, files, the commit message), revision number or hash, or revset expression.
Update to version -01
author Sebastien Decugis <sdecugis@nict.go.jp>
date Fri, 17 Jul 2009 12:10:12 +0900
parents 348f1e9e5f73
children 90102a60e943
files draft-sdecugis-dime-diameter-erp.xml
diffstat 1 files changed, 152 insertions(+), 96 deletions(-) [+]
line wrap: on
line diff
--- a/draft-sdecugis-dime-diameter-erp.xml	Fri Jul 17 11:44:42 2009 +0900
+++ b/draft-sdecugis-dime-diameter-erp.xml	Fri Jul 17 12:10:12 2009 +0900
@@ -4,11 +4,15 @@
 <!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 RFC4187 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4187.xml">
+<!ENTITY RFC5247 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5247.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 I-D.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.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.gaonkar-radext-erp-attrs SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-gaonkar-radext-erp-attrs-03.xml">
+<!ENTITY I-D.ietf-dime-erp SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-dime-erp-00.xml">
+<!ENTITY I-D.wu-dime-local-keytran SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-wu-dime-local-keytran-00.xml">
 <!ENTITY nbsp "&#160;">
 ]>
 <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
@@ -26,7 +30,7 @@
 <?rfc rfcedstyle="yes"?>
 <?rfc rfcprocack="no"?>
 <?rfc tocindent="yes"?>
-<rfc category="std" docName="draft-sdecugis-dime-diameter-erp-00"
+<rfc category="std" docName="draft-sdecugis-dime-diameter-erp-01"
      ipr="trust200902">
   <front>
     <title abbrev="Diameter ERP support">Diameter support for EAP
@@ -75,36 +79,6 @@
       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>
@@ -130,38 +104,71 @@
       <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>.
+      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 title="Differences with other documents">
+        <t>This document differs from <xref target="I-D.ietf-dime-erp"></xref>
+        in its design and scope. 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 (<xref
+        target="I-D.ietf-dime-erp"></xref> and <xref
+        target="I-D.wu-dime-local-keytran"></xref>) was focused on the
+        bootstrapping of the mechanism. In particular, these documents did not
+        consider the routing of Diameter message for re-authentication
+        exchanges (ERP exchange, and also <xref target="RFC4187"></xref> for
+        the second document). By re-using the Diameter EAP application, they
+        create implicit constraints on routing of messages that cannot be met
+        by standard Diameter routing algorithm, as defined in the <xref
+        target="RFC3588">Diameter Base Protocol</xref>.</t>
+
+        <t>A separate Diameter application solves this routing issue, and can
+        also allow the authenticator to dynamically discover if the local
+        domain supports re-authentication or not.</t>
+      </section>
     </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>We re-use in this document the terminology from <xref
+      target="RFC5296"></xref>. In particular, unless specified otherwise, the
+      EAP server has implicit support for ERP extensions for generation of ERP
+      keying material and its transmission to ER server. These terms
+      "authenticator", "ER server", "EAP server" designate 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>"Root key" (RK) or "bootstrapping material" refer to the rRK or rDSRK
+      derived from an EMSK, depending on the location of the ER server in home
+      or foreign domain.</t>
 
       <t>We re-use also some terminology and abbreviations from <xref
       target="RFC4072"></xref>, for example DER/DEA.</t>
+
+      <section 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>
+      </section>
     </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>
+      authentication by compatible EAP methods), 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, so it can
+      be used in case of multihoming or handovers between different access
+      technologies. 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. The home EAP server is assumed to be
+      constant for a given peer.</t>
 
       <figure title="Figure 1. Diameter applications used in the ERP mechanism.">
         <artwork><![CDATA[
@@ -579,8 +586,7 @@
       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>
+      <t>The following figure describes the re-authentication exchange.</t>
 
       <figure title="Figure 8. Diameter ERP exchange">
         <artwork><![CDATA[
@@ -652,65 +658,107 @@
       <t>This section describes how sessions are handled in case of
       re-authentication.</t>
 
-      <t><cref anchor="Editor17">See guidelines in
-      I-D.ietf-dime-app-design-guide</cref></t>
+      <t><cref anchor="Editor17">The content of this section is to be written,
+      I am just listing the ideas here.</cref></t>
+
+      <t>See guidelines in <xref
+      target="I-D.ietf-dime-app-design-guide"></xref>.</t>
 
-      <t><cref anchor="Editor18">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>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. The new authenticator will therefore derive the new Session-Id
+      from this EMSKName and use this for accounting purpose.</t>
 
-      <t><cref anchor="Editor19">The new authenticator will therefore derive
-      the new Session-Id from this EMSKName and use this for accounting
-      purpose. </cref></t>
+      <t>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?</t>
 
-      <t><cref anchor="Editor20">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>It is possible to cache the necessary information at the ER server
+      level. Is it useful to specify this mechanism in this document? It would
+      involve:<list>
+          <t>An additional AVP during bootstrapping of ER server, in the
+          ERP-RK-Answer, to pass the real User-Name and Session-Id (only in
+          case of explicit bootstrapping)</t>
 
-      <t><cref anchor="Editor21">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>
+          <t>An additional AVP in Diameter ERP/DEA (EAP-Finish/Re-Auth) to
+          pass the real Session-Id and User-Name and Destination-Realm of the
+          re-authenticated peer, for accounting messages.</t>
+        </list></t>
+    </section>
+
+    <section title="Contributors">
+      <t>Hannes Tschofenig, Lakshminath Dondeti, Julien Bournelle, and Lionel
+      Morand wrote the initial Diameter ERP draft document.</t>
     </section>
 
     <section anchor="Acknowledgements" title="Acknowledgements">
-      <t><cref anchor="Editor22">Remember, it's important to acknowledge
-      people who have contributed to the work</cref></t>
+      <t>Vidya Narayanan reviewed a rough draft version of the previous
+      document and found some errors.</t>
+
+      <t>Qin Wu and Glen Zorn actively participated in the discussions on the
+      design for Diameter ERP, providing the point of view and experience from
+      HOKEY workgroup.</t>
+
+      <t>Hannes Tschofenig provided useful advices for the writing of this
+      document.</t>
+
+      <t>Many thanks to these people!</t>
     </section>
 
     <section anchor="IANA" title="IANA Considerations">
-      <t><cref anchor="IANA9">Request a new Application Id for Diameter
-      ERP.</cref></t>
+      <t>This document requires IANA registration of the following new
+      elements in the <eref
+      target="http://www.iana.org/assignments/aaa-parameters/">Authentication,
+      Authorization, and Accounting (AAA) Parameters</eref> registries.</t>
 
-      <t><xref target="IANA1">Application Id</xref></t>
+      <section title="Diameter ERP application">
+        <t>This specification requires IANA to allocate a new value "Diameter
+        ERP" in the "Application IDs" registry created by in <xref
+        target="RFC3588"></xref>.</t>
 
-      <t><xref target="IANA8">Reference</xref></t>
-
-      <t><cref anchor="IANA10">Request new AVP Codes for ERP-* AVPs</cref></t>
+        <figure title="IANA consideration for Diameter ERP application">
+          <artwork><![CDATA[
+   Application Identifier             | Value
+   -----------------------------------+------
+   Diameter ERP                       | TBD
+]]></artwork>
+        </figure>
+      </section>
 
-      <t><xref target="IANA2">AVP</xref></t>
+      <section title="New AVPs">
+        <t>This specification requires IANA to allocate new values from the
+        "AVP Codes" registry defined in <xref target="RFC3588"></xref> for the
+        following AVPs:<list>
+            <t>ERP-RK-Request</t>
 
-      <t><xref target="IANA3">AVP</xref></t>
-
-      <t><xref target="IANA4">AVP</xref></t>
+            <t>ERP-Realm</t>
 
-      <t><xref target="IANA5">AVP</xref></t>
+            <t>ERP-RK-Answer</t>
+
+            <t>ERP-RK</t>
 
-      <t><xref target="IANA6">AVP</xref></t>
+            <t>ERP-RK-Name</t>
 
-      <t><xref target="IANA7">AVP</xref></t>
+            <t>ERP-RK-Lifetime</t>
+          </list>These AVPs are defined in section <xref
+        target="AVPs"></xref>.</t>
+      </section>
     </section>
 
     <section anchor="Security" title="Security Considerations">
-      <t><cref anchor="Editor23">Security considerations from RFC3588 (+bis),
-      RFC4072, RFC5247, RFC5295, and RFC5296 apply</cref></t>
+      <t>The security considerations from the following RFC apply here: <xref
+      target="RFC3588"></xref>, <xref target="RFC4072"></xref>, <xref
+      target="RFC5247"></xref>, <xref target="RFC5295"></xref>, and <xref
+      target="RFC5296"></xref>.</t>
 
-      <t><cref anchor="Editor24">Is it safe to use ERP-RK-Request / Answer
-      AVPs? What is the worst case?</cref></t>
+      <t><cref anchor="Editor18">FFS: Do we really respect these security
+      considerations with the mechanism we describe here? Is it safe to use
+      ERP-RK-Request / Answer AVPs? What is the worst case?</cref></t>
     </section>
   </middle>
 
@@ -730,11 +778,19 @@
     <references title="Informative References">
       &RFC3748;
 
-      &I-D.draft-ietf-hokey-key-mgm;
+      &RFC4187;
+
+      &RFC5247;
+
+      &I-D.ietf-hokey-key-mgm;
 
-      &I-D.draft-gaonkar-radext-erp-attrs;
+      &I-D.gaonkar-radext-erp-attrs;
+
+      &I-D.ietf-dime-erp;
 
-      &I-D.draft-ietf-dime-app-design-guide;
+      &I-D.wu-dime-local-keytran;
+
+      &I-D.ietf-dime-app-design-guide;
     </references>
   </back>
 </rfc>
"Welcome to our mercurial repository"