[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07

Dynamic Host Configuration WG                                   R. Pruss
Internet-Draft                                             Cisco Systems
Intended status: Informational                                   G. Zorn
Expires: May 22, 2008
                                                             R. Maglione
                                                          Telecom Italia
                                                                   Y. Li
                                                     Huawei Technologies
                                                       November 19, 2007


 Authentication Extensions for the Dynamic Host Configuration Protocol
                      draft-pruss-dhcp-auth-dsl-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on May 22, 2008.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines Dynamic Host Configuration Protocol (DHCP)
   extensions that provide for end-user authentication prior to
   configuration of the host.  The primary applicability is within a



Pruss, et al.             Expires May 22, 2008                  [Page 1]


Internet-Draft             DHCP Authentication             November 2007


   Digital Subscriber Line (DSL) Broadband network environment in order
   to enable a smooth migration from the Point to Point Protocol (PPP).

Requirements Language

   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 [RFC2119].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Network Architecture and Terminology . . . . . . . . . . . . .  5
   4.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  6
   5.  Protocol Operation Alternatives  . . . . . . . . . . . . . . .  6
     5.1.  Protocol Operation with Existing Messages  . . . . . . . .  7
     5.2.  Protocol Operation with DHCPEAP MessageType  . . . . . . . 10
   6.  DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 13
     6.1.  DHCP Authentication Protocol Option  . . . . . . . . . . . 13
     6.2.  CHAP Authentication Data Option  . . . . . . . . . . . . . 14
       6.2.1.  Challenge and Response . . . . . . . . . . . . . . . . 15
       6.2.2.  Success and Failure  . . . . . . . . . . . . . . . . . 16
     6.3.  EAP-Message Option . . . . . . . . . . . . . . . . . . . . 17
   7.  Compatibility Considerations . . . . . . . . . . . . . . . . . 17
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
     8.1.  On Mutual Authentication . . . . . . . . . . . . . . . . . 19
     8.2.  Message Authentication . . . . . . . . . . . . . . . . . . 20
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   10. Message for EAP operation  . . . . . . . . . . . . . . . . . . 20
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     12.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23
   Intellectual Property and Copyright Statements . . . . . . . . . . 25














Pruss, et al.             Expires May 22, 2008                  [Page 2]


Internet-Draft             DHCP Authentication             November 2007


1.  Introduction

   This document defines DHCP Options and procedures that allow for at
   least a Challenge-Handshake Authentication Protocol (CHAP)-based
   authentication exchange to occur in DHCP in order to enable smooth
   migration from Point-to-Point Protocol (PPP)[RFC1661] sessions to IP
   sessions in a DSL Broadband network environment.  Primary goals are
   integration of authentication in such a way that it will operate
   seamlessly with existing RADIUS-based Authentication, Authorization
   and Accounting (AAA) infrastructure and Asynchronous Transfer Mode
   (ATM) or Ethernet based DSL Networks.  As such, only the termination
   points of PPP in the DSL network are affected, both of which are
   devices that would logically need to be updated in any transition
   from PPP to IP sessions.

   It should be noted that [RFC3118] defines a mechanism that provides
   authentication of individual DHCP messages.  While this mechanism
   does provide a method of authentication for a DHCP Client based on a
   shared secret, it does not do so in a manner that can be seamlessly
   integrated with existing RADIUS-based AAA infrastructure built around
   PPP CHAP authentication models.


2.  Problem Statement

   Digital Subscriber Line (DSL) broadband service providers are
   witnessing a shift in the "last-mile" aggregation technologies and
   protocols which have traditionally been relied upon.  Two primary
   transitions are from ATM to Ethernet in the access network, and from
   the PPP for multi-protocol framing and dynamic endpoint configuration
   to direct encapsulation of IP and DHCP for dynamic endpoint
   configuration for some devices.  The term used by the DSL Forum for
   the network state associated with an authorized subscriber (that is
   using DHCP and IP rather than PPP) is "IP session" [WT-146].  While
   these trends can be readily witnessed, neither are occurring
   overnight.  In addition, they are not necessarily implemented in
   lock-step.  Thus, one may find ATM-based and Ethernet-based access
   networks running a combination of PPP sessions and IP sessions at any
   given time, particularly during transition periods.  These
   coexistences will even occur for the same service subscriber.

   Removing PPP, Point-to-Point Protocol over ATM (PPPoA) [RFC2364], and
   Point-to-Point Protocol over Ethernet (PPPoE) [RFC2516] from the
   subscriber access network is relatively straightforward in that most
   of the properties that DSL providers are interested in going forward
   are already present in DHCP and IP sessions.  Luckily, there are some
   capabilities of PPP which the market does not continue to demand.
   For example, the Dynamic configuration in PPP for IPX or NETBEUI, for



Pruss, et al.             Expires May 22, 2008                  [Page 3]


Internet-Draft             DHCP Authentication             November 2007


   example, is no longer of concern.  Neither are the multi-link bonding
   capabilities of PPP [RFC1990] commonly used on separate ISDN
   B-channels, and the myriad of other features that PPP developed as
   the "dial-based" access protocol of choice for framing,
   authentication, and dynamic configuration for IP and other network
   layer protocols.  Missing from IP sessions and DHCP [RFC2131],
   however, are isomorphic methods for user authentication and session
   liveness probing (sometimes referred to as a session "keepalive").
   For the latter, existence of a client using a given IP address can be
   detected by a number of means, including Address Resolution Protocol
   (ARP) [RFC1433], ICMP Echo/Echo Response [RFC0792], or Bidirectional
   Forwarding Detection (BFD) [I-D.ietf-bfd-base].  This leaves
   authentication as an open issue needing resolution.  Specifically,
   authentication based on a username and secret password must be
   covered.  This is something that in PPP always occurs before dynamic
   configuration of an IP address and associated parameters.

   While most DSL deployments utilize a username and password to
   authenticate a subscriber and authorize access today, this is not the
   only method for authentication that has been adopted when moving to
   DHCP and IP sessions.  "Option 82" [RFC3046] is commonly used with
   DHCP as a credential to authenticate a given subscriber line and
   authorize service.  In this model, the DSL Access Node, which always
   sits between the DHCP Client and Server, snoops DHCP messages as they
   pass, and inserts pre-configured information for a given line (e.g.,
   an ATM VPI/VCI, Ethernet VLAN, or other tag).  That information,
   while provided in clear text, traverses what is considered a
   physically secured portion of the access network and is used to
   determine (typically via a request to an AAA server) whether the DHCP
   exchange can continue.  This fits quite well with current DSL network
   architecture, as long as the subscriber line itself is all that needs
   be authorized.  However, in some service models it is still necessary
   for the subscriber to provide credentials directly.

   From the perspective of the Network Access Server (NAS) where the
   DHCP Server resides, the extensions defined in this document are
   analogous to the commonly available "Option 82" method.  The primary
   difference between using Option 82 line configuration and a username
   and password is that the authentication credentials are provided by
   the subscriber rather than inserted by intervening network equipment.
   Providing credentials from the subscriber rather than intervening
   network equipment is particularly important for cases where
   subscriber line information is unavailable, untrusted, or due to the
   terms of the service changing at any time.  Further, different
   devices in the home may have different policies and require different
   credentials.  Migration scenarios where PPPoE and DHCP operate on the
   same network for a period of time lend well to models which utilize
   identical authentication and authorization credentials across the



Pruss, et al.             Expires May 22, 2008                  [Page 4]


Internet-Draft             DHCP Authentication             November 2007


   different data plane encapsulations.


3.  Network Architecture and Terminology

   The DSL Forum defines its ATM-based network architecture in [TR-059]
   and Ethernet-based network architecture in [TR-101].  The extensions
   for DHCP defined in this document are designed to work identically on
   Ethernet or ATM architectures.  The diagram in Figure 1 and following
   terminology will be used throughout:


                                +-----------+  +------------+
                                |   DHCP    |  | AAA/RADIUS |
                                |  Server   |  |   Server   |
                                +-----------+  +------------+
                                        |            |
                                        |            |
    Sub.     +-----+   +--------+       |         +-----+   +----------+
    Home  ---| HGW |---|        |       +---------|     |   |          |
   Network   +-----+   | Access |                 |     |   |          |
                       |  Node  |--/Aggregation\--| NAS |---| Internet |
    Sub.     +-----+   |        |--\  Network  /--|     |   |          |
    Home  ---| HGW |---|        |                 |     |   |          |
   Network   +-----+   +--------+                 +-----+   +----------+
                |                                     |
                |----------DSL Access Network --------|

                    Figure 1: DSL Network Architecture

   o  Access Node (AN): Network device, usually located at a service
      provider central office or street cabinet, that terminates Access
      Loop connections from Subscribers.  In case the Access Loop is a
      Digital Subscriber Line (DSL), this is often referred to as a DSL
      Access Multiplexer (DSLAM).  The AN may support one or more Access
      Loop technologies and allow them to inter-work with a common
      aggregation network technology.

   o  Network Access Server (NAS): Network device that aggregates
      multiplexed Subscriber traffic from a number of Access Nodes.  The
      NAS plays a central role in per-subscriber policy enforcement and
      QoS.  Often referred to as a Broadband Network Gateway (BNG) or
      Broadband Remote Access Server (BRAS).  A detailed definition of
      the NAS is given in [RFC2881].

   o  The Home Gateway (HGW) connects the different Customer Premises
      Equipment (CPE) to the Access Node and the access network.  In
      case of DSL, the HGW is a DSL Network Termination (NT) that could



Pruss, et al.             Expires May 22, 2008                  [Page 5]


Internet-Draft             DHCP Authentication             November 2007


      either operate as a layer 2 bridge or as a layer 3 router.  In the
      latter case, such a device is also referred to as a Routing
      Gateway (RG).

   o  Referring to the DSL network architecture depicted in Figure 1,
      PPP (via PPPoA [RFC2364] or PPPoE [RFC2516]) operates over the DSL
      Access Network between the NAS and a device behind the HGW, or
      between the NAS and the HGW itself.  The DHCP Client resides
      either on a home network device or the HGW, and the DHCP Server
      protocol state machine may reside fully on the NAS.  The NAS
      obtains per-subscriber client configuration information either
      locally, relayed from a DHCP server or from the AAA infrastructure
      (which itself may consult external DHCP servers if necessary)
      after authentication is successfully completed.


4.  Applicability Statement

   The primary target for this extension is for DSL service provider
   networks where PPP is being phased out to be replaced by native IP
   and DHCP, or where new devices are being added which will not utilize
   PPP.  Very specific assumptions have been made with respect to the
   security model, operational methods, and integration requirements for
   existing AAA mechanisms during the design.  It is understood that
   this mechanism may not be generally applicable in this form for all
   network environments where DHCP is deployed, though perhaps elements
   of it may be used to develop a more generic approach while still
   meeting the specific requirements set out by the DSL network
   architecture.  For example, it is conceivable that EAP [RFC3748]
   could be carried in order to provide a more extensible and secure set
   of authentication methods.


5.  Protocol Operation Alternatives

   In this draft two alternatives for the protocol operation are offered
   for consideration.  The first in the section Protocol Operation with
   Existing Messages (Section 5.1), uses the existing message set, with
   small liberties taken on behavior.  It has the downside that reverse
   authentication and other authentication protocols like EAP are not
   possible in the constraints.  The second in the section Protocol
   Operation with New Messages (Section 5.2), extends the existing
   message set and should be read coupled with the section on Messages
   for operation choice with new messages (Section 10).  This
   alternative has the downside of requiring a new message type.

   Both of these alternatives use new DHCP options, they both use DHCP
   Authentication Protocol Option from the client in the DHCPDISCOVER to



Pruss, et al.             Expires May 22, 2008                  [Page 6]


Internet-Draft             DHCP Authentication             November 2007


   specify which authentication the client supports.

   Additionally alternative 1 uses CHAP Authentication Data Option to
   carry CHAP challenge and response data.

   Alternative 2 uses EAP-Message Option to carry EAP messages.

5.1.  Protocol Operation with Existing Messages

   In order to integrate with RADIUS CHAP, it is necessary to send a
   CHAP Challenge to the DHCP Client, hash that Challenge along with an
   Identifier (ID), Name, and Secret, and return the result in a CHAP
   Response to the NAS.  The NAS, in turn, must send the CHAP Name, ID,
   Challenge and Response to the RADIUS server to verify the
   credentials.  The Secret is never sent in the clear, and is known
   only to the AAA server and DHCP Client.  The Client's configuration
   information (IP address, etc) is typically returned in a successful
   response from the AAA server, which is used to construct the DHCP
   OFFER.  A typical message flow for the NAS allocating address or AAA
   server allocating address proceeds as shown in Figure 2:































Pruss, et al.             Expires May 22, 2008                  [Page 7]


Internet-Draft             DHCP Authentication             November 2007


           (HGW)                (NAS)                   (AAA)
        DHCP Client          DHCP Server/            RADIUS Server
                             AAA Client

       DHCPDISCOVER ------->
       (w/DHCP-auth-proto chap)

                    <------- DHCPOFFER
                             (w/CHAP Challenge, Name)

       DHCPREQUEST ------->
       (w/CHAP Response, Name, ID)

                             RADIUS Access-Request ------->
                             (w/CHAP Name, ID, Challenge,
                              Response)

                                                   <-------- RADIUS
                                                      Access-Accept
                                                     (Access-Reject
                                                    if unsuccessful)

                    <------- DHCPACK
                             (w/yiaddr)

       or
                   <------- DHCPNAK
                            (w/CHAP Failure if unsuccessful)


             Figure 2: Message Flow for CHAP and NAS as server

   It is necessary to "restart" the state machine via the DHCPNAK with
   CHAP Failure option if the Access-Reject is received.

   The message flow with the NAS as a relay proceeds as shown in
   Figure 3:














Pruss, et al.             Expires May 22, 2008                  [Page 8]


Internet-Draft             DHCP Authentication             November 2007


        (HGW)                (NAS)                (AAA)           (DHCP)
     DHCP Client           AAA Client        RADIUS Server   DHCP Server


    DHCPDISCOVER ------->
    (w/DHCP-auth-proto chap)

                          DHCPDISCOVER ------------------------------>
                          (w/DHCP-auth-proto chap)

                               <------------------------------ DHCPOFFER

                 <------- DHCPOFFER
                          (w/CHAP Challenge, Name)

    DHCPREQUEST ------->
    (w/CHAP Response, Name, ID)

                          RADIUS Access-Request ------->
                          (w/CHAP Name, ID, Challenge,
                           Response)

                                                <-------- RADIUS
                                                   Access-Accept
                                                  (Access-Reject
                                                 if unsuccessful)
                          DHCPREQUEST ------------------------------>
                          (w/RADIUS attributes suboption)

                 <------- DHCPACK
                          (w/yiaddr)

    or
                 <------- DHCPNAK
                          (w/CHAP Failure if unsuccessful)


             Figure 3: Message Flow for CHAP and NAS as relay

   When the DHCP relay agent receives a DHCP message from the client, it
   MAY append a DHCP Relay Agent Information option containing the
   RADIUS Attributes suboption, along with any other suboptions it is
   configured to supply.  The RADIUS Attributes suboption is defined in
   [RFC4014]

   Note that the configuration information like IP address is not in the
   DHCPOFFER but only in the DHCPACK.




Pruss, et al.             Expires May 22, 2008                  [Page 9]


Internet-Draft             DHCP Authentication             November 2007


   This alternative uses two new DHCP options:

   o  DHCP Authentication Protocol Option in the DHCPDISCOVER to specify
      the type of authentication exchange.

   o  CHAP Authentication Data Option to carry the CHAP Challenge and
      Response in the DHCPOFFER and DHCPREQUEST respectively.

5.2.  Protocol Operation with DHCPEAP MessageType

   It is desirable that user/node authentication occurs before the
   assignment of an IP address and, further, that the assignment of the
   address depend upon details of the successful authentication.  DHCP
   [RFC2131] is widely used as an address assignment method (among other
   things); EAP [RFC3748] has been widely adapted for authentication
   purposes, especially in those types of networks where DHCP is also
   used.  It seems to make some sense, then, to combine the two in order
   to provide both strong authentication and authenticated address
   assignment in an efficient manner.

   This alternative has the advantage that it supports authentication
   methods other than CHAP and allows mutual authentication.  A new DHCP
   message, DHCPEAP is used to support the new EAP phase which occurs
   before a DHCPOFFER is sent by the Server.

   This message is used to integrate authentication methods supported by
   EAP, including CHAP and any other "in the clear" password mechanisms
   (for example, to support One-Time-Password mechanisms), or to carry
   other EAP methods.  EAP is widely used in other environments, outside
   of DSL Broadband, including 802.11 "Wi-Fi" access networks but could
   be used in future DSL Broadband deployments.

   The message following this exchange is a DHCP Offer, sent unchanged
   by the Server.  A typical message flow proceeds as shown in Figure 4:

















Pruss, et al.             Expires May 22, 2008                 [Page 10]


Internet-Draft             DHCP Authentication             November 2007


           (HGW)                (NAS)                   (AAA)
        DHCP Client          DHCP Server/            RADIUS Server

       DHCPDISCOVER ------->
       (w/DHCP-auth-proto EAP)

                    <------- DHCPEAP
                             (w/EAP Message)

       DHCPEAP ------->
       (w/EAP Message)

                             RADIUS Access-Request ------->
                             (w/EAP Message)

                                                   <-------- RADIUS
                                       Access-Accept (w/EAP Message)
                                      (Access-Reject (w/EAP Message)
                                                    if unsuccessful)

                  (DHCP messages continue normally from
                  this point forward if successful)

                    <------- DHCPOFFER (w/EAP Success Message)
                             (w/yiaddr)

       DHCPREQUEST  ------->

                    <------- DHCPACK

                Figure 4: Message Flow with DHCPEAP message

   The retransmittion is handled by EAP as per Section 4.1 in [RFC3748].

   The message exchange presented in the figure offers simple one-way
   user authentication, e.g. the Server verifies the credentials of the
   HGW Client.  The client indicates the ability to have an EAP exchange
   and the NAS (which take the EAP authenticator role) initiates the
   first EAP request to the DHCP Client (which takes the EAP supplicant
   role).  Although the transport is unidirectional with EAP requests
   always coming from the NAS a method, the messages can be repeated
   until the EAP method completes, this allows a method like EAP-TLS in
   [RFC2716] which can provide mutual authentication.

   The identity hint information from [RFC4284] may be sent inside an
   EAP-Request/Identity before the authentication conversation begins.
   This allows replacement of PPPoE scenarios where PPPoE server
   responds with a PPPoE Active Discovery Offer (PADO) packet that



Pruss, et al.             Expires May 22, 2008                 [Page 11]


Internet-Draft             DHCP Authentication             November 2007


   advertises a list of available services.

   The message following this exchange is a DHCP Offer, sent unchanged
   by the Server.  A typical message flow proceeds as shown in Figure 5:


        (HGW)                (NAS)                (AAA)           (DHCP)
     DHCP Client           AAA Client        RADIUS Server   DHCP Server
                          AAA Client

    DHCPDISCOVER ------->
    (w/DHCP-auth-proto EAP)

                 <------- DHCPEAP
                          (w/EAP Message)

    DHCPEAP ------->
    (w/EAP Message)

                          RADIUS Access-Request ------->
                          (w/EAP Message)

                                                <-------- RADIUS
                                    Access-Accept (w/EAP Message)
                                   (Access-Reject (w/EAP Message)
                                                 if unsuccessful)

               (DHCP messages continue normally from
               this point forward if successful)
                          DHCPDISCOVER ------------------------------>
                          (w/RADIUS attributes suboption)

                               <----------------------------- DHCPOFFER

                 <------- DHCPOFFER (w/EAP Success Message)
                          (w/yiaddr)

    DHCPREQUEST  ------->

                 <------- DHCPACK

         Figure 5: Message Flow with new message and a DHCP relay

   The DHCP relay agent receives a DHCP message from the client, it MAY
   append a DHCP Relay Agent Information option containing the RADIUS
   Attributes suboption, along with any other suboptions it is
   configured to supply.  The RADIUS Attributes suboption is defined in
   [RFC4014]



Pruss, et al.             Expires May 22, 2008                 [Page 12]


Internet-Draft             DHCP Authentication             November 2007


   This alternative uses two DHCP options:

   o  DHCP Authentication Protocol Option in the DHCPDISCOVER to specify
      the type of authentication exchange.

   o  EAP-Message Option to carry the EAP data in the DHCPEAP message.


6.  DHCP Options

   Three new DHCP Options are defined in this section.  The first DHCP
   Authentication Protocol Option is originated from the client in the
   DHCPDISCOVER to specify which authentication the client supports.

   CHAP Authentication Data Option to carry CHAP challenge and response
   data.  This is modelled strictly on PPP CHAP [RFC1994] with text
   lifted liberally from its specification.

   Protocol Operation with DHCPEAP MessageType uses EAP-Message Option
   to carry EAP messages.

6.1.  DHCP Authentication Protocol Option

   The following diagram defines the format of the DHCPAUTH-Protocol
   option, which is sent from the DHCP Client to the DHCP Server to
   indicate the authentication algorithm the client prefers.  This
   option MUST be sent in the DHCPDISCOVER if the Client supports DHCP
   Authentication.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   DHCP Code   |    Length     |     Authentication-Protocol   |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Algorithm   |
     +-+-+-+-+-+-+-+-+

               Figure 6: DHCP Authentication Protocol Option

      DHCP Code: TBA-1 (DHCPAUTH-Protocol)

      Length: 3

      Authentication-Protocol

         C223 (HEX) for Challenge-Handshake Authentication Protocol.

         C227 (HEX) for Extensible Authentication Protocol (EAP)




Pruss, et al.             Expires May 22, 2008                 [Page 13]


Internet-Draft             DHCP Authentication             November 2007


      Algorithm

         The Algorithm field is one octet and indicates the
         authentication method to be used with CHAP.

         5 CHAP with MD5

6.2.  CHAP Authentication Data Option

   This option is used between the Client and DHCP Server to exchange
   CHAP authentication Data in OFFER, REQUEST and NAK messages.  This is
   used in Section 5.1.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   DHCP Code   |  Length     |  CHAP Code   |   Identifier     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Data ....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                 Figure 7: CHAP Authentication Data Option

      DHCP Code: TBA-2 (DHCPAUTH-Data)

      CHAP Code

         The Code field is one octet and identifies the type of CHAP
         option and format of data that follow.  CHAP Codes are assigned
         as follows:

         1 Challenge

         2 Response

         3 Success

         4 Failure

      Identifier

         The Identifier field is one octet and aids in matching
         challenges, responses and replies.

      Length

         The Length field is one octet and indicates the length of the
         Data plus 2 (the length of CHAP Code plus Identifier).




Pruss, et al.             Expires May 22, 2008                 [Page 14]


Internet-Draft             DHCP Authentication             November 2007


      Data

         The Data field is zero or more octets.  The format of the Data
         field is determined by the CHAP Code field.

6.2.1.  Challenge and Response

   A summary of the Challenge and Response packet format is shown below.
   The DHCP Code and Length are described above and repeated here only
   for reference.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   DHCP Code   |  Length     |  CHAP Code   |   Identifier     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Value-Size   |  Value ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Name ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 8: Challenge and Response

      CHAP Code

         1 for Challenge;

         2 for Response.

      Identifier

         The Identifier field is one octet.  The Identifier field MUST
         be changed each time a Challenge is sent.

         The Response Identifier MUST be copied from the Identifier
         field of the Challenge which caused the Response.

      Value-Size

         This field is one octet and indicates the length of the Value
         field.

      Value

         The Value field is one or more octets.

         The Challenge Value is a variable stream of octets.  The
         importance of the uniqueness of the Challenge Value and its
         relationship to the secret is described above.  The Challenge



Pruss, et al.             Expires May 22, 2008                 [Page 15]


Internet-Draft             DHCP Authentication             November 2007


         Value MUST be changed each time a Challenge is sent.  The
         length of the Challenge Value depends upon the method used to
         generate the octets, and is independent of the hash algorithm
         used.

         The Response Value is the one-way hash calculated over a stream
         of octets consisting of the Identifier, followed by
         (concatenated with) the "secret", followed by (concatenated
         with) the Challenge Value.  The length of the Response Value
         depends upon the hash algorithm used.

      Name

         The Name field is one or more octets representing the
         identification of the system transmitting the packet.  There
         are no limitations on the content of this field.  For example,
         it MAY contain ASCII character strings or globally unique
         identifiers in ASN.1 syntax.  The Name should not be NUL or
         CR/LF terminated.  The size is determined from the Length and
         Value-Size fields.

6.2.2.  Success and Failure

   If Authentication is successful, the DHCP Server SHOULD transmit the
   subsequent DHCPACK including a DHCPAUTH-Data Option with the CHAP
   Code set to 3 (Success) and the configuration Options.

   If Authentication is unsuccessful, the DHCP Server SHOULD transmit a
   DHCPNAK including a DHCPAUTH-Data Option with the CHAP Code set to 4
   (Failure).

   A summary of the Success and Failure packet format is shown below.
   The DHCP Code and Length are described above and repeated here only
   for reference.


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   DHCP Code   |  Length     |  CHAP Code   |   Identifier     |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   Message....
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       Figure 9: Success and Failure

      Code

         3 for Success;




Pruss, et al.             Expires May 22, 2008                 [Page 16]


Internet-Draft             DHCP Authentication             November 2007


         4 for Failure.

      Identifier

         The Identifier field is one octet and aids in matching requests
         and replies.  The Identifier field MUST be copied from the
         Identifier field of the Response which caused this reply.

6.3.  EAP-Message Option

   The format of the EAP-Message option used in Protocol Operation with
   DHCPEAP MessageType is as follows:


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |   DHCP Code   |  Length     |  m...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


                       Figure 10: EAP-Message Option

   The maximum size of a DHCP option is 255 octets.  While in some cases
   (e.g., EAP MD5-Challenge [RFC3748]) a complete EAP message may fit in
   a single DHCP option, in general this is not the case.  If an EAP
   message is too large to fit into a single DHCP option, the method
   defined in [RFC3396] MUST be used to split the EAP message into
   separate options for transmission.  Similarly, EAP assumes a minimum
   MTU of 1020 octets while the minimum DHCP packet size is 576 octets,
   including 312 octets reserved for options.  A DHCP client including
   the EAP-Message option SHOULD also include the 'maximum DHCP message
   size' option [RFC2132] to set a suitable DHCP message size.

   If a DHCP message is received containing more than one EAP-Message
   option, the method defined in [RFC3396] MUST be used to reassemble
   the separate options into the original EAP message.  A DHCP server
   receiving an EAP message MAY forward it via a AAA protocol (such as
   RADIUS [RFC2865] [RFC3579] or Diameter [RFC3588]] [RFC4072]).


7.  Compatibility Considerations

   This section is aimed at describing interoperability scenarios
   involving HGW and NAS with or without DHCP Authentication mechanism
   support in order to analyze compatibility issues that could be faced
   between newer and older products during the introduction of the DHCP
   Authentication functionally in current implemented network
   environments.




Pruss, et al.             Expires May 22, 2008                 [Page 17]


Internet-Draft             DHCP Authentication             November 2007


   Scenario 1: Both HGW and NAS do not support DHCP Authentication

   In this case the authentication process does not start, thus
   traditional DHCP message flow applies.

   Scenario 2: HGW does not support DHCP Authentication and NAS supports
   DHCP Authentication

   In this case the DHCP client does not start DHCP Authentication
   transaction, NAS MAY decide to respond to HGW without using DHCP
   Authentication, falling back to traditional DHCP message flow and
   assigning different network resources.

   Scenario 3: HGW supports the DHCP Authentication and NAS does not
   support DHCP Authentication.

   In this case the DHCP client inserts in the DHCPDISCOVER message sent
   to NAS, the DHCP Authentication Protocol Option described in the
   draft in order to communicate the NAS that it is able to perform
   authentication and for indicating the authentication algorithm
   preferred by the client.  NAS on receiving a DHCPDISCOVER with
   unknown option silently discards unknown message.  Alternatively NAS
   MAY ignore the unknown option, but still process the message and then
   reply to the DHCP client with traditional response.  The HGW, that
   has upgraded software, realizes that the NAS does not support DHCP
   Authentication and can reverts back to normal DHCP message flow.

   Scenario 4 Both HGW and NAS support DHCP Authentication

   In this case DHCP client inserts in the DHCPDISCOVER message sent to
   NAS, the DHCP Authentication Protocol Option in order to communicate
   the NAS that it is able to perform authentication and for indicating
   the authentication algorithm preferred by the client, NAS replies
   according to the message flow described in this draft.

   The following table summarizes the behavior in the 4 described
   scenarios:














Pruss, et al.             Expires May 22, 2008                 [Page 18]


Internet-Draft             DHCP Authentication             November 2007


   +---------------+---------------+-----------------------------------+
   | DHCP Auth     | DHCP Auth     | Result                            |
   | support on    | support on    |                                   |
   | HGW           | NAS           |                                   |
   +---------------+---------------+-----------------------------------+
   | without       | without       | No Authentication                 |
   | support       | support       |                                   |
   | without       | with support  | Client does not start auth, thus  |
   | support       |               | no authentication transaction     |
   | with support  | without       | NAS silently discards unknown     |
   |               | support       | message/option                    |
   | with support  | with support  | Draft works as outlined           |
   +---------------+---------------+-----------------------------------+

                     Table 1: Compatibility Scenarios


8.  Security Considerations

8.1.  On Mutual Authentication

   The DHCP authentication mechanism described is optimal in catering to
   a unilateral authentication of the client by the NAS, with the
   authentication based on a one-way hash algorithm used in CHAP.  In
   general, it claims to be no better than the existing security offered
   by PPPoE [RFC2516].  Given the assumption that the DSL Aggregation
   Network is trusted, and that direct Layer 2 subscriber-subscriber
   communication is restricted to only occur via the NAS.  The CHAP
   alternative makes no attempt at protecting from "man in the middle"
   attacks.  However, unlike with PPP, IP DHCP packets including
   DHCPAUTH messages may be freely routed across multiple IP hops.  It
   is thus conceivable that a remote rogue user may try to exploit known
   hash weaknesses to derive the secret key of another user through the
   use of a brute force attack.  To keep the relative security
   equivalent in threat to today's PPPoE environment, the DHCPAUTH
   traffic must be constrained by the access network.  The simplest
   mechanism for doing this is by blocking any DHCP traffic from
   traversing the NAS.  In common DSL deployments the access-node
   provides protection against direct communication between HGW at Layer
   2 as well as IP/MAC address spoofing based on snooped DHCP messages
   sent to the HGW client from the NAS.

   The vast majority of PPPoE and PPPoA wire-line deployments utilize
   one-way authentication.  The mechanism defined in Protocol Operation
   with Existing Messages is strictly one-way.  Mutual authentication is
   possible with the mechanism in Protocol Operation with DHCPEAP
   MessageType.




Pruss, et al.             Expires May 22, 2008                 [Page 19]


Internet-Draft             DHCP Authentication             November 2007


8.2.  Message Authentication

   RFC 3118 provides a mechanism to cryptographically protect DHCP
   messages using a key, K, shared between a DHCP client and Server,
   however no mechanism is defined to manage these keys.  Authentication
   exchanges based on EAP have been built into authentication portions
   of network access protocols such as PPP, 802.1X, PANA, IKEv2, and now
   DHCP.  EAP methods may provide for the derivation of shared key
   material, the MSK and the EMSK, on the EAP peer and EAP server.  This
   dynamic key generation enables [RFC3118] protection and allows modes
   of operation where messages are protected from DHCP client to DHCP
   relay which previously would be difficult to manage.

   A seperate draft by Joe Saloway and Ric Pruss describes how to derive
   the key, K, from the EMSK resulting from an EAP exchange and it looks
   at how this mechnasim interacts with the DHCP authentication or any
   EAP authentication prior to DHCP.


9.  IANA Considerations

   This specification requires three values to be assigned by IANA.

   Two are "BOOTP Vendor Extensions and DHCP Options"



      TBA-1:  (DHCPAUTH-Protocol)

      TBA-2:  (DHCPAUTH-Data)

   One is a DHCP Message Type 53 Values - per [RFC2132], for DHCPEAP
   message type.


10.  Message for EAP operation

   The DHCPEAP messages follow the format for DHCP messages defined in
   RFC 2131 [RFC2131].  This new message is identified by the presence
   of a DHCP Message Type option, which encodes DHCPEAP message type.
   Other fields in the DHCP message header, such as siaddr and fname,
   are left unused.

   The authentication data in a DHCPAUTH message is carried in a EAP-
   Messsage option EAP-Message Option.






Pruss, et al.             Expires May 22, 2008                 [Page 20]


Internet-Draft             DHCP Authentication             November 2007


11.  Acknowledgements

   Many thanks to Carlos Pignataro for help editing this document.

   Thanks to Wojciech Dec, Eric Voit, Mark Townsley and Ralph Droms for
   help with this document.

   Thanks to Amy Zhao for her draft on DHCP Authentication and helping
   with laying the ground for this document.


12.  References

12.1.  Normative References

   [RFC1994]  Simpson, W., "PPP Challenge Handshake Authentication
              Protocol (CHAP)", RFC 1994, August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [I-D.ietf-bfd-base]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-06 (work in progress),
              March 2007.

   [RFC0792]  Postel, J., "Internet Control Message Protocol", STD 5,
              RFC 792, September 1981.

   [RFC1433]  Garrett, J., Hagan, J., and J. Wong, "Directed ARP",
              RFC 1433, March 1993.

   [RFC1661]  Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
              RFC 1661, July 1994.

   [RFC1990]  Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T.
              Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
              August 1996.

   [RFC2131]  Droms, R., "Dynamic Host Configuration Protocol",
              RFC 2131, March 1997.

   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
              Extensions", RFC 2132, March 1997.

   [RFC2364]  Gross, G., Kaycee, M., Lin, A., Malis, A., and J.



Pruss, et al.             Expires May 22, 2008                 [Page 21]


Internet-Draft             DHCP Authentication             November 2007


              Stephens, "PPP Over AAL5", RFC 2364, July 1998.

   [RFC2516]  Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D.,
              and R. Wheeler, "A Method for Transmitting PPP Over
              Ethernet (PPPoE)", RFC 2516, February 1999.

   [RFC2716]  Aboba, B. and D. Simon, "PPP EAP TLS Authentication
              Protocol", RFC 2716, October 1999.

   [RFC2865]  Rigney, C., Willens, S., Rubens, A., and W. Simpson,
              "Remote Authentication Dial In User Service (RADIUS)",
              RFC 2865, June 2000.

   [RFC2881]  Mitton, D. and M. Beadles, "Network Access Server
              Requirements Next Generation (NASREQNG) NAS Model",
              RFC 2881, July 2000.

   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option",
              RFC 3046, January 2001.

   [RFC3118]  Droms, R. and W. Arbaugh, "Authentication for DHCP
              Messages", RFC 3118, June 2001.

   [RFC3396]  Lemon, T. and S. Cheshire, "Encoding Long Options in the
              Dynamic Host Configuration Protocol (DHCPv4)", RFC 3396,
              November 2002.

   [RFC3579]  Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication
              Dial In User Service) Support For Extensible
              Authentication Protocol (EAP)", RFC 3579, September 2003.

   [RFC3588]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
              Arkko, "Diameter Base Protocol", RFC 3588, September 2003.

   [RFC3748]  Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H.
              Levkowetz, "Extensible Authentication Protocol (EAP)",
              RFC 3748, June 2004.

   [RFC4014]  Droms, R. and J. Schnizlein, "Remote Authentication
              Dial-In User Service (RADIUS) Attributes Suboption for the
              Dynamic Host Configuration Protocol (DHCP) Relay Agent
              Information Option", RFC 4014, February 2005.

   [RFC4072]  Eronen, P., Hiller, T., and G. Zorn, "Diameter Extensible
              Authentication Protocol (EAP) Application", RFC 4072,
              August 2005.

   [RFC4284]  Adrangi, F., Lortz, V., Bari, F., and P. Eronen, "Identity



Pruss, et al.             Expires May 22, 2008                 [Page 22]


Internet-Draft             DHCP Authentication             November 2007


              Selection Hints for the Extensible Authentication Protocol
              (EAP)", RFC 4284, January 2006.

   [TR-059]   DSL Forum, "DSL Evolution - Architecture Requirements for
              the Support of QoS-Enabled IP Services", TR 059,
              September 2003.

   [TR-101]   DSL Forum, "Migration to Ethernet Based DSL Aggregation",
              TR 101, April 2006.

   [WT-146]   DSL Forum, "Internet Protocol (IP) Sessions", WT 146 (work
              in progress), April 2007.


Authors' Addresses

   Richard Pruss
   Cisco Systems
   80 Albert Street
   Brisbane, Queensland  4000
   Australia

   Phone: +61 7 3238 8228
   Fax:   +61 7 3211 3889
   Email: ric@cisco.com


   Glenn Zorn


   Phone:
   Fax:
   Email: glenzorn@comcast.net


   Roberta Maglione
   Telecom Italia
   Via G. Reiss Romoli 274
   Torino,   10148
   Italy

   Phone: +39 0112285007
   Fax:
   Email: roberta.maglione@telecomitalia.it
   URI:






Pruss, et al.             Expires May 22, 2008                 [Page 23]


Internet-Draft             DHCP Authentication             November 2007


   Li Yizhou
   Huawei Technologies
   No. 91 Baixia Rd
   Nanjing,   210001
   China

   Phone: +86-25-84565471
   Fax:
   Email: liyizhou@huawei.com
   URI:









































Pruss, et al.             Expires May 22, 2008                 [Page 24]


Internet-Draft             DHCP Authentication             November 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Pruss, et al.             Expires May 22, 2008                 [Page 25]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/