<?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. -->
<!ENTITY RFC2119 SYSTEM "reference.RFC.2119.xml">
<!ENTITY RFC2131 SYSTEM "reference.RFC.2131.xml">
<!ENTITY RFC2132 SYSTEM "reference.RFC.2132.xml">
<!ENTITY RFC3748 SYSTEM "reference.RFC.3748.xml">
<!ENTITY RFC3118 SYSTEM "reference.RFC.3118.xml">
<!ENTITY I-D.pruss-dhcp-auth-dsl
  SYSTEM "reference.I-D.draft-pruss-dhcp-auth-dsl-06.xml">
<!ENTITY RFC3315 SYSTEM "reference.RFC.3315.xml">
<!ENTITY RFC4014 SYSTEM "reference.RFC.4014.xml">
<!ENTITY RFC5505 SYSTEM "reference.RFC.5505.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-jjmb-dhc-eap-auth-analysis-02"
     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="4" month="February" year="2010" />

    <!-- 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>dhc</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 evaluates a proposal
      by Ric Pruss, et al., to implement end-user EAP-based authentication
      as a part of a DHCP protocol transaction in DSL networks.</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
          style="symbols">
          <t>DHCPv4 - "Dynamic Host Configuration Protocol" <xref
          target="RFC2131"></xref><xref target="RFC2132"></xref></t>

          <t>DHCPv6 - "Dynamic Host Configuration Protocol for IPv6" <xref
          target="RFC3315"></xref></t>

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

    <section title="Message and Option Definition">
      <t>In this section considerations pertaining to how the DHCPEAP messages
      have been defined in <xref target="I-D.pruss-dhcp-auth-dsl"/> are
      discussed. Recommendations as to how messages may be defined are also
      documented in this section.</t>

      <section title="Message Type Overloading">
	<t><xref target="I-D.pruss-dhcp-auth-dsl"></xref> defines a DHCP
	single EAP message to support end-user DHCP-based
	authentication. However, the DHC working group has found that
	using the same DHCP message type for more than one leg of a
	packet exchange creates confusion, and we recommend instead
	that a different message type be used for each leg of the
	transaction.  In this case a four message model may better
	satisfy the requirements, similar, for example, to the
	DISCOVER/OFFER/REQUEST/ACK cycle in the standard DHCPv4
	bootstrapping exchange.</t>
      </section>

      <section title="Differences in Message and Option Names">
	<t><xref target="I-D.pruss-dhcp-auth-dsl"></xref>
	mingles DHCPv4 and DHCPv6 message types.  This is not
	valid. DHCPv4 messages and options must be clearly defined and
	referenced to for IPv4.   DHCPv6 messages and options must be
	defined and referenced for IPv6.</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="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><xref target="I-D.pruss-dhcp-auth-dsl"></xref> introduces a
        DHCP Capability Vendor-specific Suboption for DHCPv4 and
        DHCPv6 which is specified to carry authentication
        information. This information is required to support the
        desired protocol behavior.  However, including this data in a
        DHCP greatly increases the size of the DHCP option
        payload. While <xref target="I-D.pruss-dhcp-auth-dsl"></xref>
        specifies how large options are to be handled, this large
        option payload still has the potential to create problems;
        there is the potential for this option to squeeze out other
        DHCP options required for correct DHCP configuration</t>

        <!--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.-->

        <t>Additionally, the authors of <xref
        target="I-D.pruss-dhcp-auth-dsl"></xref> should mention that
        in practice the Maximum Message Size option is rarely used by
        DHCP clients and as such 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.</t>
      </section>

      <section title="RADIUS Message Requirements">
        <t>Section 5.1 and 5.2 of <xref
        target="I-D.pruss-dhcp-auth-dsl"></xref> mention RADIUS
        attributes required to support this behavior.  These are not
        included as part of <xref target="RFC4014"></xref>. These
        messages still 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><xref target="I-D.pruss-dhcp-auth-dsl"></xref> requires that
      end-user DHCP-based authentication must be handled independently
      in the case where both IPv4 and IPv6 service are present. <xref
      target="I-D.pruss-dhcp-auth-dsl"></xref> is not clear as to how
      clients and servers handle conflicts where both IPv4 and IPv6
      are used simultaneously and further how conflicts are resolved
      when such scenarios arise. See the beginning of section 5 of
      <xref target="I-D.pruss-dhcp-auth-dsl"></xref>.</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.-->

	<section title="Packet Size">
	  <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, however, this alone will not
	  ensure that intermediate elements like DHCP relay agents will support
	  the same or adversely impact exchanges between DHCP clients and
	  servers. DHCP clients in this case include but are not limited to
	  those include with operating systems and home networking
	  equipment.</t>
	</section>

	<section title="Standalone Client Behavior">
	  <t>The behavior for home gateway (HG) as defined in <xref
	  target="I-D.pruss-dhcp-auth-dsl"></xref> has been
	  specified, however, specification of standalone client
	  behavior remains absent. In order for this proposal to be
	  complete it must be specified how standalone client are to
	  behave to support end-user authentication using DHCP.</t>
	</section>

	<!-- this doesn't make sense: the client indicates that it supports
	authentication, not the NAS.

        <t>If a NAS client does not support DHCP-based authentication, support
        of the same by the home gateway (HG) client MUST be considered.
        Specifically, if the NAS client indicates positively to the HG client
        that DHCP Authentication is supported but is truly not support this
        will cause the HG client to attempt DHCP Authentication
        erroneously.</t> -->

	<section title="Handling of non-EAP responses">
	  <t>Section 5 of <xref
	  target="I-D.pruss-dhcp-auth-dsl"></xref> also indicates that
	  a client may receive one or more DHCP OFFER/ADVERTISE
	  messages some of which may or may not support DHCP EAP
	  authentication. It is unclear and unspecified how or if the
	  client is to wait for DHCPEAP messages if it has already
	  received a DHCPOFFER or DHCP Advertise message.  An
	  EAP-capable client could accept a DHCPOFFER or DHCP
	  Advertise message and consequently miss a subsequent DHCPEAP
	  message, which would prevent it from authenticating.</t>

	  <t>This is further complicated in the case where the DHCP
	  client is not a home gateway, and may in fact be a portable
	  device such as a laptop computer.  When the DHCP/EAP capable
	  client is connected to a provider network supporting DHCP/EAP,
	  the client may wait for a DHCPEAP message from the server.
	  When the client is connected to some other network, where
	  DHCP/EAP is not supported, it may still wait for such a
	  message.  This would create a delay in the availability of the
	  network for the end user when not connecting to the provider
	  network.</t>
	</section>

	<section title="Protocol State Machine is Only in Client">
	  <t><xref target="I-D.pruss-dhcp-auth-dsl"></xref> proposes
	  that if the relay agent or server decides to do DHCP/EAP, the
	  original DHCPDISCOVER message from the DHCP client will be
	  cached.  Once the EAP authentication has succeeded, the
	  DHCPDISCOVER will be forwarded to the server or, in the case
	  where the server does the EAP authentication, the server will
	  take the cached DHCPDISCOVER and send a DHCPOFFER in response
	  to it.</t>

	  <t>However, this proposal ignores the fact that the DHCP
	  client, not the DHCP server, drives the DHCP protocol.  The
	  DHCP client determines when to send the DHCPDISCOVER, and the
	  DHCP server responds.  The DHCP client determines when to send
	  the DHCPREQUEST, and the DHCP server responds.  The DHCP
	  client determines when to renew, and so on.</t>

	  <t>Hence, we strongly recommend that the proposed protocol be
	  changed so that, after a successful DHCP/EAP exchange, the
	  DHCP client restarts its state machine at the INIT state and
	  sends a new DHCPDISCOVER, with a new transaction ID.  This
	  eliminates three problems:
	  <list>
	    <t>- the need for the DHCP server or relay to cache the
	    DHCPDISCOVER</t>
	    <t>- the problem of how to retransmit if the DHCP server
	    doesn't send a response to the DHCPDISCOVER cached and
	    eventually forwarded by the relay agent</t>
	    <t>- the problem that the DHCP client state machine would have
	    to remember the xid in the original DHCPDISCOVER packet, even
	    though it's gone through several state transitions since the
	    DHCPDISCOVER was sent.</t>
	  </list>
	  </t>
	  <t>Needless to say, the same suggestion applies for the DHCPv6
	  protocol, although the names of the packets are different and
	  DHCPv6 doesn't name the client's states.</t>
	</section>
	<section title="Transaction IDs">
	  <t>The proposed protocol extension does not document the handling
	  of the DHCP client's transaction IDs during the processing of
	  EAP-specific messages.   We recommend that each EAP message sourced
	  by the client have a new transaction ID, which should then be
	  returned in the response from the server.</t>
	</section>
	<section title="EAP Protocol Direction">
	  <t>The proposed protocol extension attempts to replace
	  PPPoE/EAP with a new protocol based on DHCP.  However, the
	  DHCP protocol is client-initiated, whereas EAP is
	  server-initiated.  For example, consider <xref
	  target="RFC3748">PPP Extensible Authentication
	  Protocol</xref>.  In this document, the authenticator
	  initiates the packet exchange after the layer two (PPPoE)
	  connection is established.</t>
	  <t>The proposal does not explain how this incompatibility is
	  resolved.  Either the proposal needs to turn the DHCP client
	  state machine on its head, or it needs to turn the EAP state
	  machine on its head.  The document proposes neither
	  solution, so we can't evaluate the impact the solution to
	  this problem would have on the DHCP protocol.</t>
	</section>
	<section title="Reliable Delivery of EAP messages">
	  <t>The proposal doesn't talk about retransmission for
	  DHCPEAP messages.  This is a particularly important omission
	  because of the reversal of roles implicit in doing DHCP over
	  EAP, as discussed in the previous section, "EAP Protocol
	  Direction."  Since DHCP is a UDP-based protocol with no
	  guaranteed delivery, retransmission is not optional, and the
	  way in which the DHCP client or EAP authenticator does
	  retransmission must be specified explicitly, or this
	  proposal does not in any way guarantee interoperability.</t>
	</section>
	<section title="Re-Authentication">
	  <t>The proposal doesn't cover re-authentication.  Although
	  section 2, "Problem Statement," mentions user authentication
	  and connection liveness probing, the actual protocol
	  document never proposes a method whereby this requirement is
	  satisfied.</t>
	  <t>We theorize that it might be possible to somehow
	  accomplish this using DHCPFORCERENEW in DHCPv4 and DHCP
	  Reconfigure in DHCPv6, but nowhere in the document is this
	  solution discussed.  So again, there is no way to evaluate
	  how the solution to this problem would interact with
	  DHCP.</t>
	</section>
	<section title="Authorization lifetime versus lease time">
	  <t>The underlying authentication protocol may assign a
	  lifetime to the authorization, after which time the
	  authorization must be renewed.   DHCP clients also have
	  a lease interval, which might be different than the
	  authorization interval.   The proposal should specify that
	  the lease must expire before the authorization expires,
	  in cases where the authorization expires.   The proposal
	  should also cover re-authentication, so that a new
	  authorization with a new expiration is acquired each time
	  the lease is renewed.</t>
	</section>
      </section>

      <section title="DHCP Servers">
	<t>In the DHCP protocol, the state machine is in the client,
	not the server.  The server retains information about the
	client's IP address allocation, but from the perspective of
	the protocol, the DHCP server only sends messages in response
	to messages sent by the DHCP client.  So <xref
	target="I-D.pruss-dhcp-auth-dsl"></xref> places a new
	requirement on DHCP servers that they retain DHCPDISCOVER
	messages sent by clients during the EAP authentication
	process.   This problem would be solved by following the
	related recommendations in the earlier section on DHCP clients.</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><xref target="I-D.pruss-dhcp-auth-dsl"></xref> does not say whether
	or not the relay agent should append a relay agent information option
	to EAP-specific messages.   We think that a non-EAP-aware relay agent
	would have to do so, but the draft should talk about this issue.</t>

        <t><xref target="I-D.pruss-dhcp-auth-dsl"></xref> proposes a
        mode in which the DHCP relay agent implements the EAP protocol
        itself, rather than relying on the DHCP server to do so.  In
        order to do this, the relay agent, which in the normal DHCP
        protocol is completely stateless, must now retain state
        regarding the progress of the DHCP protocol. There are two
        different ways in which this protocol extension adds state to
        the relay agent:
	<list>
	  <t>- The relay agent must retain the initial DHCPDISCOVER packet
	  sent by the client.</t>
	  <t>- Once the EAP authentication has succeeded, the relay
	  agent must remember that the authentication has succeeded,
	  so that if the DHCP client must retransmit its DHCPDISCOVER,
	  the relay agent does not attempt to redo the entire EAP
	  authentication process.  This state must be retained for the
	  entire duration of the DHCP protocol from that point on, so
	  that the initial four-way handshake can complete, and so
	  that any subsequent renewals, rebinds, and INIT-REBOOT
	  renewals can complete.  In order to avoid caching this state
	  forever, the relay agent would have to retain lease timing
	  information so that it could time out cached information as
	  the leases associated with that information expire.</t>
	</list></t>
	<t>For this reason, we strongly recommend that the authors
	abandon the idea of implementing this protocol extension in
	the relay agent.  Also, please note that this is true for the
	DHCPv6 exchange as well as the DHCPv4 exchange; we only
	document the DHCPv4 exchange for brevity.</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
          style="numbers">
          <t>DHCP client support for authentication</t>

          <t>DHCP relay agent support for authentication</t>

          <t>DHCP server support for authentication</t>

          <t>DHCP client, server, and relay agent support for
          authentication</t>
        </list></t>
    </section>

    <section title="Dual-Stack issues">
      <t>The proposed DHCP extension performs authentication in a way that
      is linked with the DHCP transaction.   The legacy authentication
      protocol may only support a single authentication per connection.
      In a dual-stack environment, both the DHCPv4 and DHCPv6 clients
      might attempt to authenticate.   The underlying authentication
      protocol might then succeed for DHCPv4 and fail for DHCPv6, or
      vice versa.</t>
      <t>The proposal should account for this issue, either specifying
      that in a dual-stack situation, one or the other DHCP clients
      should do the authentication, or specifying that this protocol
      does not work in a dual-stack environment, or specifying how
      the underlying EAP authentication works in the presence of
      parallel authentications.</t>
    </section>

    <section title="Appropriateness">
      <t>The proposed DHCP extension embeds the network authentication
      process into the network configuration process, which, it could
      be argued, goes against the recommendation in<xref
      target="RFC5505">Principles of Internet Host
      Configuration</xref>, which states:<list><t>Network access
      authentication and authorization is a distinct problem from
      Internet host configuration.  Therefore, network access
      authentication and authorization is best handled independently
      of the Internet and higher-layer configuration mechanisms.</t></list></t>
      <t>There are two aspects to this objection.   The first is that
      of course there are reasons why strict adherence to this provision
      of RFC5505 was not followed.   Second, does this provision
      actually apply?</t>
      <section title="Motivation">
	<t>To address the first point, the motivation stated by the authors
	for embedding an authentication protocol into a configuration
	protocol is essentially economic: it allows ISPs implementing the
	protocol to continue using network infrastructure they have already
	deployed and paid for, while providing a substantial benefit by
	allowing them to move away from using PPPoE as, essentially, a
	gatekeeper protocol and toward running native (non-tunneled) IP.</t>
	<t>A second motivation is that existing protocols for authenticating
	at layer two aren't applicable to the DSL environment - 802.1x, for
	instance, can't work, because the device doing the authentication
	has no connectivity to the node being authenticated until layer three
	(IP) configuration has occurred.   And yet authentication is required
	before decisions can be made as to how to configure the client.
	The DHCPv4 and DHCPv6 protocols provide a mechanism for doing the
	authentication despite the lack of a layer three configuration.</t>
      </section>
      <section title="Applicability">
	<t>As to the question of applicability of the statement in question,
	it is not really the case that configuration and authentication are
	being done by the same protocol.   Configuration is being done by
	DHCP.   Authentication is being done by EAP.   True, DHCP
	is being used as a transport for the EAP protocol, but it is not
	the case that DHCP itself is being used for authentication and
	authorization.</t>
	<t>In addition, existing network access authentication
	protocols that work over layer three do use DHCP to configure
	the node prior to authentication in cases, such as this, where
	the authentication agent is not available on the local
	link.</t>
	<t>Once the node is configured, in order to get new DHCP
	configuration information based on the authentication and
	authorization results, a second DHCP transaction must be done.
	In order for this to work, essentially the same mechanisms
	being proposed in <xref
	target="I-D.pruss-dhcp-auth-dsl">Authentication Extensions for
	the Dynamic Host Configuration Protocol</xref> are needed -
	the DHCP server or DHCP relay agent must have access to the
	results of the authentication.  And the DHCP protocol itself
	provides no mechanism for reconfiguring subsequent to a
	successful layer three authentication.  Hence the difference
	between such a protocol and the one being proposed is minor,
	and largely serves to make the configuration/authentication
	process slower and more awkward.</t>
      </section>
    </section>

    <?rfc needLines="8"?>

    <section anchor="Acknowledgements" title="Acknowledgements">
      <t>Thanks to Alper Yegin, Ric Pruss, Glen Zorn, Alan DeKok,
      Yoshihiro Ohba, Miles David, Alan Kavanaugh, Steinar Haug and
      Alfred Hoenes for the review and feedback.</t>
    </section>

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

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</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>The current version of <xref target="I-D.pruss-dhcp-auth-dsl"></xref>
      indicates that <xref target="RFC3118"></xref> likely cannot be
      seamlessly integrated with existing RADIUS-based AAA infrastructure used
      in Broadband DSL environments. <xref
      target="I-D.pruss-dhcp-auth-dsl"></xref> must elaborate on how DHCP EAP
      can be secured if not by leveraging <xref target="RFC3118"></xref>.
      While 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. However, existing <xref target="RFC3118"></xref> authentication
      schemes use relatively short signatures and keys, so in practice this is
      probably not a serious concern.</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.RFC5226.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. -->

      &RFC2131;
      &RFC2132;
      &RFC3748;
      &RFC3118;

      &I-D.pruss-dhcp-auth-dsl;

      &RFC3315;

      &RFC4014;

      &RFC5505;

    </references>

    <!--Change Log

	00 September-2008 Created
	00 March 2009 Initial draft posted
	00 November 11, 2009 Updated draft posted, name changed
	01 November 19, 2009 Updated draft posted
	02 February 4, 2009 Updated draft posted
    -->
  </back>
</rfc>
