One document matched: draft-zhou-emu-ch-tunnel-00.xml

<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="std" docName="draft-zhou-emu-ch-tunnel-00" ipr="trust200902">
  <!-- category values: std, bcp, info, exp, and historic
     ipr values: full3667, noModification3667, noDerivatives3667
     you can add the attributes updates="NNNN" and obsoletes="NNNN" 
     they will automatically be output with "(if approved)" -->

  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="draft-zhou-emu-ch-tunnel-00">Combination of Channel Binding
    and Tunnel Method</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <!-- Another author who claims to be an editor -->

    <author fullname="Sujing Zhou" initials="S.Z." surname="Zhou">
      <organization>ZTE Corporation</organization>

      <address>
        <postal>
          <street>No.68 Zijinghua Rd. Yuhuatai District</street>

          <!-- Reorder these if your country does things differently -->

          <city>Nanjing</city>

          <region>Jiang Su</region>

          <code>210012</code>

          <country>R.R.China</country>
        </postal>

        <email>zhou.sujing@zte.com.cn</email>

        <!-- uri and facsimile elements may also be added -->
      </address>
    </author>

    <date day="6" month="July" year="2012"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Security Area</area>

    <workgroup>EAP Method Update</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>template</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>This document proposes to incorporate channel binding as defined in
      [I-D.ietf-emu-chbind ] into EAP tunnel method as soon as possible.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>Channel binding as define in <xref target="I-D.ietf-emu-chbind"/> is
      used to imitigate lying authenticator , and is implemented as part of
      the ongoing EAP method, because the assertion transported from the EAP
      server to EAP peer is authenticated by the resluting key (TEK, to be
      more specific) derived from the EAP method. Although it is a bit late to
      know the contacting authenticator is a liar after the peer has completed
      the EAP method, it is a rather reasonable compromise to the legacy EAP
      methods.</t>

      <t>EAP Tunnel methods, e.g., defined in <xref target="RFC4851"/><xref
      target="RFC5281"/><xref target="I-D.ietf-emu-eap-tunnel-method"/>, are
      used to protect weak EAP methods, especially some legacy EAP methods.
      When it comes to using channel binding in tunnel methods, it is more
      complex. To maximise the compatibility , channel binding may still be
      carried out with the inner EAP method, using the inner TEK, or some key
      derived from tunnel key (output from tunnel method) and inner EAP method
      key, which has not been specified. This way, a peer is assured of the
      honesty of the contacting authenticator only after both the tunnel
      establishement and the completement of the inner EAP method.</t>

      <t>Since tunnel methods are used to protect the inner method, it might
      be desirebale to provide channel binding simultaneously with or right
      after the tunnel establishment.</t>

      <t/>

      <t/>

      <t/>

      <t/>

      <section title="Terminology ">
        <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"/>.</t>
      </section>
    </section>

    <!--  -->

    <section title="Channel Binding after Tunnel Establishment">
      <t>When there is no inner EAP method after the tunnel
      establishement,which is not ruled out in the current tunnel method
      specification, or the inner method does not output key, channel binding
      is carried out immediately after the tunnel establishment according to
      the procedure defined in <xref target="I-D.ietf-emu-chbind"/>, the key
      used to authenticate the CB_Success or CB-Failure is derived from the
      tunnel key TK and some shared secret (TEK) between EAP server and the
      peer. TEK could be NULL if no shared secret can be provided at this
      time.</t>

      <t>In this case, when TEK is NULL, the certificate verification of the
      EAP server (i.e., the tunnel server) is crucial, as pointed out in <xref
      target="I-D.ietf-emu-crypto-bind"/>.</t>

      <t/>

      <t/>

      <t/>
    </section>

    <section title="Channel Binding after the First Inner Method">
      <t>When some inner methods are carried out after the tunnel
      establishment, and the first inner method outputs key, channel binding
      is executed along with the first inner method, as defined in <xref
      target="I-D.ietf-emu-chbind"/>,the key used to authenticate the
      CB-Success or CB_Failure is derived from the tunnel key TK and one of
      the outputs of the first inner method , i.e., TEK.</t>

      <t/>

      <t/>
    </section>

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

      <t/>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>This document proposes to carry out channel binding as soon as
      possible, in the case of EAP tunnel method is involved, to detect
      rogueauthenticator as early as possible.</t>
    </section>
  </middle>

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

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

    <!-- There are 2 ways to insert reference entries from the citation libraries:
     1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
     2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
        (for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")

     Both are cited textually in the same manner: by using xref elements.
     If you use the PI option, xml2rfc will, by default, try to find included files in the same
     directory as the including file. You can also define the XML_LIBRARY environment variable
     with a value containing a set of directories to search.  These can be either in the local
     filing system or remote ones accessed by http (http://domain/dir/... ).-->

    <references title="Normative References">
      <?rfc include='reference.RFC.2119.xml'?>

      <?rfc include='reference.RFC.4851.xml'?>

      <?rfc include='reference.RFC.5281.xml'?>

      <?rfc include='reference.I-D.ietf-emu-crypto-bind.xml'?>

      <?rfc include='reference.I-D.ietf-emu-chbind.xml'?>

      <?rfc include='reference.I-D.ietf-emu-eap-tunnel-method.xml'?>

      <?rfc include='reference.I-D.josefsson-pppext-eap-tls-eap.xml'?>
    </references>

    <!-- -->
  </back>
</rfc>