[Docs] [txt|pdf] [Tracker] [Email] [Nits] [IPR]

Versions: 00 01 02 03 04 05 06 07

Dynamic Host Configuration WG                                   R. Pruss
Internet-Draft                                             Cisco Systems
Intended status: Experimental                          February 26, 2007
Expires: August 30, 2007


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

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 August 30, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This document defines Dynamic Host Configuration Protocol (DHCP)
   extensions that provide for a Challenge Handshake Authentication
   Protocol (CHAP) exchange in DHCP prior to configuration of the host.
   The primary applicability is within a Digital Subscriber Line (DSL)
   Broadband network environment in order to enable a smooth migration
   from the Point to Point Protocol (PPP).





Pruss                    Expires August 30, 2007                [Page 1]


Internet-Draft             DHCP Authentication             February 2007


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.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Network Architecture and Terminology . . . . . . . . . . . . .  5
     3.1.  Where the DHCP Client and DHCP Server reside . . . . . . .  6
   4.  Applicability Statement  . . . . . . . . . . . . . . . . . . .  6
   5.  Protocol Operation Alternatives  . . . . . . . . . . . . . . .  6
     5.1.  Protocol Operation with Existing Messages  . . . . . . . .  7
     5.2.  Protocol Operation with New Messages . . . . . . . . . . .  8
   6.  DHCP Options . . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.1.  DHCP Authentication Protocol Option  . . . . . . . . . . . 11
     6.2.  DHCP Authentication Data Option  . . . . . . . . . . . . . 12
       6.2.1.  Challenge and Response . . . . . . . . . . . . . . . . 13
       6.2.2.  Success and Failure  . . . . . . . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Messages for operation choice with new messages  . . . . . . . 15
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
   Intellectual Property and Copyright Statements . . . . . . . . . . 20




















Pruss                    Expires August 30, 2007                [Page 2]


Internet-Draft             DHCP Authentication             February 2007


1.  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 Point to Point Protocol (PPP) [RFC1661] 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 occuring overnight.  In addition, they are not
   necessarily implimented 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.  This coexitances will even occur for the same
   service subscriber.

   Removing PPP, PPPoA [RFC2364], and 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
   capabilties of PPP which the markert does not continue to demand.
   For example, the Dynamic configuration in PPP for IPX or NETBEUI, for
   example, is no longer of concern.  Neither are the multi-link bonding
   capabilities of PPP [RFC1990] commonly used on separate ISDN
   B-channels, ar 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 ARP [RFC1433], ICMP Ping [RFC0792], or 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



Pruss                    Expires August 30, 2007                [Page 3]


Internet-Draft             DHCP Authentication             February 2007


   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 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 may change 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
   different data plane encapsulations.


2.  Introduction

   This document defines DHCP Options and procedures that allow for a
   CHAP-based authentication exchange to occur in DHCP in order to
   enable smooth migration from PPP 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 AAA infrastructure and 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.






Pruss                    Expires August 30, 2007                [Page 4]


Internet-Draft             DHCP Authentication             February 2007


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:


                                               +------------+
                                               | AAA/RADIUS |
                                               |   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
      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).



Pruss                    Expires August 30, 2007                [Page 5]


Internet-Draft             DHCP Authentication             February 2007


3.1.  Where the DHCP Client and DHCP Server reside

   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
   resides fully on the NAS.  The NAS obtains per-subscriber client
   configuration information either locally or from the AAA
   infrastructure (which itself may consult external DHCP servers if
   necessary) after authentication is successfully completed.  The
   details of how the NAS obtains dynamic configuration to be offered to
   the DHCP Client are outside the scope of this specification.


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 first 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
   protcols 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 9) This alternative has the downside of requiring four new
   messages.  Both of these alternatives use common DHCP options.






Pruss                    Expires August 30, 2007                [Page 6]


Internet-Draft             DHCP Authentication             February 2007


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 proceeds as shown in Figure 2:







































Pruss                    Expires August 30, 2007                [Page 7]


Internet-Draft             DHCP Authentication             February 2007


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

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

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

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

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

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

                  (DHCP continues normally from
                  this point forward if successful)

                    <------- DHCPOFFER
                             (w/yiaddr)
                             (w/CHAP Failure if unsuccessful)

       DHCPREQUEST  ------->

                    <------- DHCPACK

                      Figure 2: Typical Message Flow

   It is necessary to "restart" the state machine via the DHCPOFFER with
   CHAP Failure option if the Access-Reject is received.  A CHAP
   Challenge could also be added to this DHCP offer.  Then a
   DHCPDISCOVER is always answered with a DHCPOFFER with a CHAP
   Challenge until Access-Accept or the client stops trying.

5.2.  Protocol Operation with New Messages

   Four new DHCP messages are defined:

   o  DHCPAUTH-Challenge





Pruss                    Expires August 30, 2007                [Page 8]


Internet-Draft             DHCP Authentication             February 2007


   o  DHCPAUTH-Response

   o  DHCPAUTH-Success

   o  DHCPAUTH-Failure

   to support the new authentication phase which occurs before a
   DHCPOFFER is sent by the Server.  These messages may also be used to
   integrate other authentication methods, including "in the clear";
   password mechanisms (for example, to support One-Time-Password
   mechanisms), or to carry other types of authentication, including EAP
   which, unlike DSL Broadband, is widely used in other environments,
   including 802.11 "Wi-Fi" access networks.

   In order to facilitate simple deployment on millions of operational
   Clients, this protocol extension is designed, from the perspective of
   the client, to be a simple, event driven, "request received, response
   sent" type exchange with no persistent state necessary.  Put simply,
   any DHCPAUTH-Challenge that is received at any time (as long as
   conditions are met to thwart malicious attackers, see Security
   Consideration (Section 7) section for more information) by the DHCP
   Client Software is responded to with a DHCPAUTH-Response.

   Any DHCPAUTH-Failure that is received is responded to by relaying to
   the user (via a GUI or other human-computer interaction) that a
   failure occurred (e.g., an incorrect password was entered).
   Reinitializing or halting of the DHCP state machine should follow a
   DHCPAUTH-Result indicating a failure.

   A DHCPAUTH-Success message is optional, but SHOULD be sent.  The
   message following this exchange is a DHCP Offer, sent unchanged by
   the Server.  A typical message flow proceeds as shown in Figure 3:



















Pruss                    Expires August 30, 2007                [Page 9]


Internet-Draft             DHCP Authentication             February 2007


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

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

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

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

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

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

                    <------- DHCPAUTH-Success/Failure

                  (DHCP continues normally from
                  this point forward if successful)

                    <------- DHCPOFFER
                             (w/yiaddr)

       DHCPREQUEST  ------->

                    <------- DHCPACK

             Figure 3: Typical Message Flow with new messages

   The Client always responds to DHCPAUTH-Challenge messages sent by the
   BRAS with a DHCPAUTH-Response message.  If no DHCPAUTH-Success or
   DHCPAUTH-Failure message is received after a short period of time the
   DHCPAUTH-Response is retransmitted (3 seconds is a recommended
   initial default, exponentially increasing for each retransmit to a
   maximum of 12 seconds, and timing out after 8 retries, though all
   values SHOULD be configurable).  Each DHCPAUTH-Response messages
   received by the Server MUST be responded to.  The same retransmit
   procedure is used by the Server for the DHCPAUTH-Challenge message.

   This message exchange in the figure offers simply one-way user
   authentication, e.g. the Server verifies the identity of the User at



Pruss                    Expires August 30, 2007               [Page 10]


Internet-Draft             DHCP Authentication             February 2007


   the PC Client.  It is assumed that the Ethernet access network
   restricts packets sent to/from the BRAS at the MAC level, providing
   some trust that DHCPAUTH messages received at the Client are not from
   a rogue BRAS.  In situations where this is not the case, the same set
   of messages may be sent in reverse for mutual authentication.


6.  DHCP Options

   Two new DHCP Options are defined in this section.  The first is used
   to advertise the support for DHCP Authentication in general and the
   type of authentication supported.  The second is the format used for
   carrying necessary elements for the CHAP authentication protocol.
   This is modeled strictly on PPP CHAP [RFC1994] with text lifted
   liberally from its specification.

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 4: DHCP Authentication Protocol Option

      DHCP Code: TBA-1 (DHCPAUTH-Protocol)

      Length: 3

      Authentication-Protocol

         c223 (hex) for Challenge-Handshake Authentication Protocol.

      Algorithm

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

         5 CHAP with MD5




Pruss                    Expires August 30, 2007               [Page 11]


Internet-Draft             DHCP Authentication             February 2007


         6 CHAP with SHA-1

6.2.  DHCP Authentication Data Option


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

                 Figure 5: DHCP 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).

      Data

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








Pruss                    Expires August 30, 2007               [Page 12]


Internet-Draft             DHCP Authentication             February 2007


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 6: 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
         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.




Pruss                    Expires August 30, 2007               [Page 13]


Internet-Draft             DHCP Authentication             February 2007


         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 DHCPOFFER including a DHCPAUTH-Data Option with the CHAP
   Code set to 3 (Success).

   If Authentication is unsuccessful, the DHCP Server SHOULD transmit a
   DHCPOFFER 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 7: Success and Failure

      Code

         3 for Success;

         4 for Failure.

      Identifier





Pruss                    Expires August 30, 2007               [Page 14]


Internet-Draft             DHCP Authentication             February 2007


         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.


7.  Security Considerations

   The DHCP authentication mechanism described is optimal in catering to
   a uni-lateral authentication of the client to 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 restricted to only occur via the NAS, this mechanism
   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 DHCP Auth traffic must be constrained
   by the access network.  The simplest mechanism for doing this is by
   blocking any DHCP traffic from traversing the NAS.

   The vast majority of PPPoE and PPPoA wire-line deployments utilize
   one-way authentication.  The mechanism defined in this document is
   strictly one-way.  Mutual authentication is possible, but brings
   complexity and may ultimately require a new DHCP message type and
   phase.


8.  IANA Considerations

   This specification requires two values to be assigned by IANA.  Both
   are "BOOTP Vendor Extensions and DHCP Options"



      TBA-1:  (DHCPAUTH-Protocol)

      TBA-2:  (DHCPAUTH-Data)


9.  Messages for operation choice with new messages

   The DHCPAUTH messages follow the format for DHCP messages defined in
   RFC 2131 [RFC2131].  These new messages are identified by the
   presence of a DHCP Message Type option, which encodes DHCPAUTH



Pruss                    Expires August 30, 2007               [Page 15]


Internet-Draft             DHCP Authentication             February 2007


   message type.  DHCPAUTH message use the xid field to match DHCPAUTH-
   Challenge, DHCPAUTH-Response and DHCPAUTH-Success/DHCPAUTH-Failure
   messages.  Other fields in the DHCP message header, such as siaddr
   and fname, are left unused.

   The data in a DHCPAUTH message, such as the challenge or response, is
   carried in a DHCPAUTH-Data option.  The format for this option is:


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Length    |            Data...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        Figure 8: DHCPAUTH Messages

      Type DHCPAUTH-Data

         Length number of octets of data carried in the option

         Data The Data field is zero or more octets carrying the data
         specific to the m essage

   The following diagrams defines the data carried in a DHCPAUTH-
   Challenge or DHCPAUTH-Response message:


     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Value-Size   |  Value ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Name ...
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     Figure 9: DHCPAUTH Messages Data

      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 most significant octet is transmitted first.

   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 Value MUST be changed each



Pruss                    Expires August 30, 2007               [Page 16]


Internet-Draft             DHCP Authentication             February 2007


   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
   (16 octets for MD5).

   CHAP 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 field.

   If the existing DHCP client software may be modified, the CHAP Name
   may also be sent before the authentication phase, either as an
   additional DHCP Option in the DHCPDISCOVER message, or in the Client
   ID field that is sent in all DHCP messages.  This is an option that
   may be available even if the DHCP Client software may not be modified
   directly, as an API to set this value should be readily available
   even for existing DHCP Client software.


10.  Acknowledgements

   Many thanks to Carlos Pignataro for help editing this document.

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


11.  References

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






Pruss                    Expires August 30, 2007               [Page 17]


Internet-Draft             DHCP Authentication             February 2007


11.2.  Informative References

   [I-D.ietf-bfd-base]
              Katz, D. and D. Ward, "Bidirectional Forwarding
              Detection", draft-ietf-bfd-base-05 (work in progress),
              June 2006.

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

   [RFC2364]  Gross, G., Kaycee, M., Lin, A., Malis, A., and J.
              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.

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

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

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




Pruss                    Expires August 30, 2007               [Page 18]


Internet-Draft             DHCP Authentication             February 2007


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


Author's Address

   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

































Pruss                    Expires August 30, 2007               [Page 19]


Internet-Draft             DHCP Authentication             February 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                    Expires August 30, 2007               [Page 20]


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