<?xml version="1.0" encoding="UTF-8"?>
<!-- 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. -->

<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC3552 SYSTEM "reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "reference.I-D.narten-iana-considerations-rfc2434bis.xml">
]>
<?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="info"
     docName="draft-brzozowski-dhcp-eap-analysis-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="DHCP Authentication Analysis">DHCP Authentication
    Analysis</title>

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

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

    <author fullname="John Jason Brzozowski" initials="J.B."
            surname="Brzozowski">
      <organization>Comcast Cable Communications</organization>

      <address>
        <postal>
          <street>1360 Goshen Parkway</street>

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

          <city>West Chester</city>

          <region>PA</region>

          <code>19473</code>

          <country>USA</country>
        </postal>

        <phone>+1-609-377-6594</phone>

        <email>john_brzozowski@cable.comcast.com</email>

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

    <author fullname="Ted Lemon" initials="T.L." surname="Lemon">
      <organization>Nominum</organization>

      <address>
        <postal>
          <street></street>

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

          <city></city>

          <region></region>

          <code></code>

          <country>USA</country>
        </postal>

        <phone></phone>

        <email>mellon@nominum.com</email>

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

    <author fullname="Geoffrey Holan" initials="G.H." surname="Hollan">
      <organization>Telus</organization>

      <address>
        <postal>
          <street></street>

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

          <city></city>

          <region></region>

          <code></code>

          <country>Canada</country>
        </postal>

        <phone></phone>

        <email>geoffrey.holan@telus.com</email>

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

    <date day="25" month="March" year="2009" />

    <!-- 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>Internet</area>

    <workgroup>Internet Engineering Task Force</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>DHCP authentication, DHCPv4 Authentication, DHCPv6
    Authentication</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 analyzes and technically evaluate the techniques
      proposed to support end-user authentication using extensions to
      DHCP.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This document provides an independent analysis of the proposal to
      support end-user authentication using extension to DHCP. While the
      current proposal largley focuses on Broadband Digital Subscriber Line
      scenarions the adhoc team that has been assembled will evaulate the
      proposal generally from a DHCP point of view. This analysis will also
      cite architectural and best practice considerations for the authors to
      consider as part of this work.</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">RFC 2119</xref>.</t>
      </section>
    </section>

    <section title="Terminology">
      <t>The following terms and acronyms are used in this document:<list>
          <t>DHCPv4 - "Dynamic Host Configuration Protocol" [RFC2131]</t>

          <t>DHCPv6 - "Dynamic Host Configuration Protocol for IPv6"
          [RFC3315]</t>

          <t>DHCP - DHCPv4 and/or DHCPv6</t>
        </list></t>
    </section>

    <section title="Message and Option Definition">
      <t>This section discusses considerations pertaining to how the DHCPEAP
      messages
      have been defined in [I-D.pruss-dhcp-auth-dsl].
      This section also makes recommendations as to how messages may be
      defined.</t>

      <t>The draft [I-D.pruss-dhcp-auth-dsl] specifies two new message types,
      DHCPEAP-REQ and
      DHCPEAP-RES, which are the primary DHCP messages required to support end-user
      DHCP-based authentication. However, based on the desired protocol
      behavior and common practices we recommend that additional DHCPEAP message  be
      specified to represent the appropriate interaction between clients,
      servers, and relay agent, because in some cases the DHCPEAP-REQ and DHCPEAP-RES messages are
      being overloaded.   A four message model would be more in keeping with standard practice as exemplified by the message types defined in [RFC3315].</t>

      <section title="Message and Option Parity">
        <t>Throughout the document [I-D.pruss-dhcp-auth-dsl] references to
        DHCPv4 and DHCPv6 messages and options DHCPv6 are intermingled in ways that are not valid. In some cases, message and option definitions for DHCPv4 or DHCPv6
        are omitted entirely. DHCPv4 messages and options
        must be referenced only for IPv4, and DHCPv6 messages and options must
        be used only for IPv6, where applicable, to support DHCP-based end-user
        authentication. Definition of the DHCP Authentication Protocol Option
        and EAP message option must be clarified and explicitly defined for both
        DHCPv4 and DHCPv6. Further, the DHCPEAP-REQ and DHCPEAP-RES messages
        along with any additional messages must be clarified and explicitly
        defined for both DHCPv4 and DHCPv6.</t>
      </section>

      <!--The proposal suggests that an option specifying the sessions authentication protocol being transmitted by the client. The semantics of this option must clearly be specified.-->

      <section title="Use of Vendor Options and Messages">
        <t>Given the very specific target of the proposal--
        Broadband Digital Subscriber Line networks--it seems
        practical for this proposal to use vendor specific options for
        DHCP options required by the draft, specifically the EAP message option.
	Furthermore,
        depending on the availability of support for DHCP Vendor Messages, and
        its standardization, the use of DHCP vendor message should also be
        considered as part of this specification for any messages required to
        support DHCP-based end-user authentication. The use of vendor messages
        and options should be considered for clients, servers, and relay
        agents to support the desired protocol behavior.</t>
      </section>

      <section title="Message and Option Sizing">
        <!--When multiple EAP message options are used it seems that performance and scaling must be considered for relay agents and servers.-->

        <t>[I-D.pruss-dhcp-auth-dsl] introduces the EAP message option, which
        is specified to carry authentication information. This information is
        necessary to support the desired protocol behavior.  However, including
        this data in a DHCP packet greatly increases the size of the options.
        [I-D.pruss-dhcp-auth-dsl] does specify how large options are
	to be handled.   However, there are a number of remaining concerns:
 <!-- , this is a concern architecturally. Further,
        performance must be considered by the authors when large options are
        used to support protocol behavior. [I don't see a performance issue here. --TED] -->

        <!--What is the effect of the increased DHCP message sizes on: - clients DHCP clients are not required to implement buffers larger than 576 bytes. - servers Servers are required not to send DHCP packets to clients that are larger than 576 bytes without prior negotiation with the client. - relay agents? Relay agents are generally assumed not to be capable of forwarding packets larger than 576 bytes, although most relay agents can probably forward packets of any size. But because the Maximum Message Size option is rarely used by DHCP clients, we have no real operational experience that tells us what percentage of relay agents will fail in the face of DHCP packets larger than 576 bytes.-->

	<list>
          <t>The Maximum Message Size option is rarely used by DHCP
            clients and as such we have no real operational experience
            to reassure us that DHCP packets larger than 576 bytes
            will be carried transparently by the infrastructure.</t>

            <t>DHCPv4 clients are not required to implement buffers larger than
            576 bytes; this draft must explicitly make such a requirement for
	    conforming DHCPv4 clients.</t>

            <t>DHCPv4 servers are required not to send DHCP packets to clients
            that are larger than 576 bytes without prior negotiation with the
            client.</t>

            <t>We have not studied how widespread support for DHCP
            packets longer than 576 bytes is among deployed DHCP relay
            agents.  We are concerned that some DHCP relay agents will
            not be capable of relaying such packets, and that this may
	    create obstacles to deploying the proposed protocol extension.</t>

	    <t>The EAP option may crowd out other options needed by the
	    DHCP client for normal operation.</t>
          </list></t>
      </section>

      <section title="RADIUS Message Requiments">
        <t>Per section 5.1 of [I-D.pruss-dhcp-auth-dsl] RADIUS attributes to
        support this behavior are required and not included as part of
        [RFC4014]. These messages do not exists and need to be specified.</t>
      </section>
    </section>

    <section title="Protocol behavior">
      <!--Does this proposal apply to WiMax as well, if yes, should the WiMax forum be engaged?-->

      <!--Protocol operation suggests that if both IPv4 and IPv6 are being used both must be handled separately. Is more language required around how conflicts here need to be resolved to ensure clients operations are not adversely impacted. See section 5 of [I-D.pruss-dhcp-auth-dsl]-->

      <t>Generally the draft [I-D.pruss-dhcp-auth-dsl] defines specific
      protocol behavior to support end-user DHCP-based authentication using
      IPv4 and IPv6; each are handled independently.
      [I-D.pruss-dhcp-auth-dsl] is not clear as to how clients and servers
      handle conflicts where both IPv4 and IPv6 are used simultaneously.
      The draft should specify how such conflicts are resolved when this
      situation arises. See section 5 of [I-D.pruss-dhcp-auth-dsl]</t>

      <section title="DHCP Clients">
        <!--One very obvious suggestion that falls out of this is that a client implementing this protocol should indicate that it can handle packets larger than 576 bytes. Although in theory this could cause problems with relay agents, in practice I think this is unlikely, because the deployment environments we are talking about do not depend on consumer-grade routers; software updates are possible in the unlikely event that a problem arises.-->

        <t>Packet size for DHCP clients that support end-user DHCP-based
        authentication remains a concern. DHCP clients MUST advertise their
        ability to support larger packet sizes. DHCP clients in this case
	include but are not limited to
        those included with operating systems and home networking
        equipment.</t>

        <t>The behavior for home gateway (HG) as defined in
        [I-D.pruss-dhcp-auth-dsl] has been specified.   However, specification
        of standalone client behavior remains absent. In order for this
        proposal to be complete it must specify how standalone client are
        to behave to support end-user authentication using DHCP.</t>

        <t>if the NAS client indicates
        to the home gateway (HG) client that DHCP Authentication is supported
	but in fact does not support it, this will cause the HG client to attempt DHCP
        Authentication erroneously.   The home gateway client's behavior
	in this case must be specified.</t>
      </section>

      <section title="DHCP Relay Agents">
        <!--How will the authentication extensions interact with relay agent options? Relay agents that implement option 82 are expected to be able to receive packets larger than 576 bytes, but are only ever expected to generate packets in the direction of the client of 576 or fewer bytes, unless the client has negotiated a larger maximum packet size.-->

        <t>The impact of the enlarged DHCP packets that contain the DHCP
        options specified in [I-D.pruss-dhcp-auth-dsl] specifically the
        formation and transmission of messages destined for the DHCP server(s)
        must be considered. DHCP relay agents that support this
        behavior must be able to generate the appropriate DHCP message
        types in addition to supporting the necessary options.</t>

        <t>[I-D.pruss-dhcp-auth-dsl] proposes that DHCP relay agent will be
        required to append information to DHCP client requests to support
        DHCP-based end-user authentication. The current text suggests that
        [RFC4014] defines the appropriate atributes that would need to be
        appended. It is not clear that [RFC4014] explicitly specifies both the
        DHCPv4 and DHCPv6 attributes to support this behavior.</t>
      </section>
    </section>

    <section title="Compatibility">
      <!--How does it accommodate backward compatibility deployed DHCP - clients The draft proposes extensions to DHCP that the client is required to support. Clients that do not support this extension will not be able to authenticate. - servers The draft proposes a new authentication protocol. Servers that do not implement this protocol will not be able to authenticate clients. - relay agents? The draft adds additional DHCP message types. Relay agents may or may not pass DHCP messages that have unknown message types. Relay agents that maintain state may snoop the contents of DHCP packets without checking message types. If they do so, they may cache bad data, negative-cache incorrect data, or clear good data from the cache.-->

      <t>The compatibility of clients, servers, and relay agents that
      implement this behavior with legacy clients, servers, and relay agents
      MUST be explicitly documented. The behavior of the remaining elements
      that do not support this behavior while others do MUST be considered,
      specifically, how will legacy element handle the presence of the
      corresponding DHCP options when present. Consider the following
      scenarios, for example:<!--This should be a matrix to represent all of the valid combinations--><list>
	  <t>Only one element among the DHCP client, DHCP server and DHCP relay agent support authentication.</t>

	  <t>Two of these elements support authentication, one does not.</t>

	  <t>All three elements support authentication.</t>
        </list></t>
    </section>

    <section title="Naming">
      <t>The draft is currently titled "Authentication Extensions for
	the Dynamic Host Configuration Protocol."  This title implies
	that the draft is a generic authentication extension for DHCP.
	Despite optimistic suggestions that it might actually turn out
	to be such a thing, really this proposed extension is fairly
	sharply targeted.  So we recommend choosing a title that
	reflects this specificity, rather than the current generic
	title.</t>
    </section>

    <?rfc needLines="8"?>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>This template was derived from an initial version written by Pekka
      Savola and contributed by him to the xml2rfc project.</t>

      <t>This document is part of a plan to make xml2rfc indispensable .</t>
    </section>

    <!-- Possibly a 'Contributors' section ... -->

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

      <t>All drafts are required to have an IANA considerations section (see
      <xref target="I-D.narten-iana-considerations-rfc2434bis">the update of
      RFC 2434</xref> for a guide). If the draft does not require IANA to do
      anything, the section contains an explicit statement that this is the
      case (as above). If there are no requirements for IANA, the section will
      be removed during conversion into an RFC by the RFC Editor.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <!--What is the impact on other DHCP security mechanisms?

Do EAP message options require encryption? Are there any concerns pertaining to the integrity of these options being compromised-->

      <t>This draft does not propose the use of RFC3118-style options.  It is
      possible to use RFC3118 in conjunction with the protocol described in
      this draft. Indeed, the draft suggests the possibility of bootstrapping
      the RFC3118 authentication key using the DHCP/EAP protocol. The use
      cases for that extension are hard to evaluate, so it seems that this
      draft is neutral toward other DHCP security mechanisms, with one small
      caveat: since it increases the DHCP message size, it is competing for
      space in the DHCP packet with other authentication options.</t>
      <!--  However,
      existing RFC3118 authentication schemes use relatively short signatures
      and keys, so in practice this is probably not a serious concern.   I
      took this bit out because I'm not entirely sure that it's true... :'}
      --Ted -->
    </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="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->

      &RFC2119;
    </references>

    <references title="Informative References">
      <!-- Here we use entities that we defined at the beginning. -->

      <reference anchor="RFC2131">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>Dynamic Host Configuration Protocol</title>

          <author fullname="R. Droms" initials="R.D." surname="Droms">
            <organization>Cisco</organization>
          </author>

          <date day="" month="March" year="1997" />
        </front>
      </reference>

      <reference anchor="RFC2132">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>DHCP Options and BOOTP Vendor Extensions</title>

          <author fullname="S. Alexander" initials="S.A." surname="Alexander">
            <organization>Cisco</organization>
          </author>

          <author fullname="R. Droms" initials="R.D." surname="Droms">
            <organization>Cisco</organization>
          </author>

          <date day="" month="March" year="1997" />
        </front>
      </reference>

      <reference anchor="I-D.pruss-dhcp-auth-dsl">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>Authentication Extensions for the Dynamic Host Configuration
          Protocol</title>

          <author fullname="R. Pruss" initials="R.P." surname="Pruss">
            <organization>Cisco</organization>
          </author>

          <author fullname="G. Zorn" initials="G.Z." surname="Zorn">
            <organization>Aruba Networks</organization>
          </author>

          <author fullname="R. Maglione" initials="R.M." surname="Maglione">
            <organization>Telecom Italia</organization>
          </author>

          <author fullname="Y. Li" initials="Y.L." surname="Li">
            <organization>Huawei Technologies</organization>
          </author>

          <date day="" month="May" year="2008" />
        </front>
      </reference>

      <reference anchor="RFC3396">
	<front>
	  <title>Encoding Long Options in the Dynamic Host Configuration
	    Protocol</title>
	  <author fullname="T. Lemon" initials="T.L." surname="Lemon">
	    <organization>Nominum, Inc.</organization></author>
	  <author fullname="S. Cheshire" initials="S.C." surname="Cheshire">
	    <organization>Apple Computer, Inc.</organization></author>
          <date day="" month="November" year="2002" />
	</front>
      </reference>

      <reference anchor="RFC3315">
        <!-- the following is the minimum to make xml2rfc happy -->

        <front>
          <title>Dynamic Host Configuration Protocol for IPv6 (DHCPv6)</title>

          <author fullname="R. Droms" initials="R.D." surname="Droms">
            <organization>Cisco</organization>
          </author>

          <author fullname="J.Bound" initials="J.B." surname="Bound">
            <organization>Hewlett Packard</organization>
          </author>

          <author fullname="B. Volz" initials="B.V." surname="Volz">
            <organization>Ericsson</organization>
          </author>

          <author fullname="T. Lemon" initials="T.L." surname="Lemon">
            <organization>Nominum</organization>
          </author>

          <author fullname="C. Perkins" initials="C.P." surname="Perkins">
            <organization>Nokia Research Center</organization>
          </author>

          <author fullname="M. Carney" initials="M.C." surname="Carney">
            <organization>Sun Microsystems</organization>
          </author>

          <date day="" month="July" year="2003" />
        </front>
      </reference>

      &RFC3552;

      &I-D.narten-iana-considerations-rfc2434bis;

      <!-- A reference written by by an organization not a person. -->
    </references>

    <!--Change Log

00 September-2008 Created
00 March 2009 Initial draft posted-->
  </back>
</rfc>
