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.

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 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 (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.) [RFC2119].

Table of Contents

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

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] (Simpson, W., “The Point-to-Point Protocol (PPP),” July 1994.) 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] (Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” June 2001.) 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] (DSL Forum, “Internet Protocol (IP) Sessions,” April 2007.). 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] (Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, “PPP Over AAL5,” July 1998.), and Point-to-Point Protocol over Ethernet (PPPoE) [RFC2516] (Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, “A Method for Transmitting PPP Over Ethernet (PPPoE),” February 1999.) 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 example, is no longer of concern. Neither are the multi-link bonding capabilities of PPP [RFC1990] (Sklower, K., Lloyd, B., McGregor, G., Carr, D., and T. Coradetti, “The PPP Multilink Protocol (MP),” August 1996.) 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] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.), 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] (Garrett, J., Hagan, J., and J. Wong, “Directed ARP,” March 1993.), ICMP Echo/Echo Response [RFC0792] (Postel, J., “Internet Control Message Protocol,” September 1981.), or Bidirectional Forwarding Detection (BFD) [I‑D.ietf‑bfd‑base] (Katz, D. and D. Ward, “Bidirectional Forwarding Detection,” January 2010.). 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] (Patrick, M., “DHCP Relay Agent Information Option,” January 2001.) 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 different data plane encapsulations.

3.  Network Architecture and Terminology

The DSL Forum defines its ATM-based network architecture in [TR‑059] (DSL Forum, “DSL Evolution - Architecture Requirements for the Support of QoS-Enabled IP Services,” September 2003.) and Ethernet-based network architecture in [TR‑101] (DSL Forum, “Migration to Ethernet Based DSL Aggregation,” April 2006.). The extensions for DHCP defined in this document are designed to work identically on Ethernet or ATM architectures. The diagram in Figure 1 (DSL Network Architecture) 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 --------|

• 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.
• 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] (Mitton, D. and M. Beadles, “Network Access Server Requirements Next Generation (NASREQNG) NAS Model,” July 2000.).
• 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).
• Referring to the DSL network architecture depicted in Figure 1 (DSL Network Architecture), PPP (via PPPoA [RFC2364] (Gross, G., Kaycee, M., Lin, A., Malis, A., and J. Stephens, “PPP Over AAL5,” July 1998.) or PPPoE [RFC2516] (Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, “A Method for Transmitting PPP Over Ethernet (PPPoE),” February 1999.)) 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] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) 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 (Protocol Operation with Existing Messages), 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 (Protocol Operation with DHCPEAP MessageType), extends the existing message set and should be read coupled with the section on Messages for operation choice with new messages (Message for EAP operation). 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 (DHCP Authentication Protocol Option) from the client in the DHCPDISCOVER to specify which authentication the client supports.

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

Alternative 2 uses EAP-Message Option (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 (Message Flow for CHAP and NAS as server):

    (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)

The message flow with the NAS as a relay proceeds as shown in Figure 3 (Message Flow for CHAP and NAS as relay):

    (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)

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

This alternative uses two new DHCP options:

• DHCP Authentication Protocol Option (DHCP Authentication Protocol Option) in the DHCPDISCOVER to specify the type of authentication exchange.
• CHAP Authentication Data Option (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] (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) is widely used as an address assignment method (among other things); EAP [RFC3748] (Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, “Extensible Authentication Protocol (EAP),” June 2004.) 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 (Message Flow with DHCPEAP message):

    (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

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] (Aboba, B. and D. Simon, “PPP EAP TLS Authentication Protocol,” October 1999.) which can provide mutual authentication.

The identity hint information from [RFC4284] (Adrangi, F., Lortz, V., Bari, F., and P. Eronen, “Identity Selection Hints for the Extensible Authentication Protocol (EAP),” January 2006.) 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 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 (Message Flow with new message and a DHCP relay):

    (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

This alternative uses two DHCP options:

• DHCP Authentication Protocol Option (DHCP Authentication Protocol Option) in the DHCPDISCOVER to specify the type of authentication exchange.
• EAP-Message Option (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 (DHCP Authentication Protocol Option) is originated from the client in the DHCPDISCOVER to specify which authentication the client supports.

CHAP Authentication Data Option (CHAP Authentication Data Option) to carry CHAP challenge and response data. This is modelled strictly on PPP CHAP [RFC1994] (Simpson, W., “PPP Challenge Handshake Authentication Protocol (CHAP),” August 1996.) with text lifted liberally from its specification.

Protocol Operation with DHCPEAP MessageType (Protocol Operation with DHCPEAP MessageType) uses EAP-Message Option (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   |
+-+-+-+-+-+-+-+-+

DHCP Code: TBA-1 (DHCPAUTH-Protocol)

Length: 3

Authentication-Protocol

C223 (HEX) for Challenge-Handshake Authentication Protocol.

C227 (HEX) for Extensible Authentication Protocol (EAP)

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 (Protocol Operation with Existing Messages).

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

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.

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

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.

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

Code

3 for Success;

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 (Protocol Operation with DHCPEAP MessageType) is as follows:

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

If a DHCP message is received containing more than one EAP-Message option, the method defined in [RFC3396] (Lemon, T. and S. Cheshire, “Encoding Long Options in the Dynamic Host Configuration Protocol (DHCPv4),” November 2002.) 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] (Rigney, C., Willens, S., Rubens, A., and W. Simpson, “Remote Authentication Dial In User Service (RADIUS),” June 2000.) [RFC3579] (Aboba, B. and P. Calhoun, “RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP),” September 2003.) or Diameter [RFC3588] (Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. Arkko, “Diameter Base Protocol,” September 2003.)] [RFC4072] (Eronen, P., Hiller, T., and G. Zorn, “Diameter Extensible Authentication Protocol (EAP) Application,” August 2005.)).

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.

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:

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] (Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., and R. Wheeler, “A Method for Transmitting PPP Over Ethernet (PPPoE),” February 1999.). 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 (Protocol Operation with Existing Messages) is strictly one-way. Mutual authentication is possible with the mechanism in Protocol Operation with DHCPEAP MessageType (Protocol Operation with DHCPEAP MessageType).

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] (Droms, R. and W. Arbaugh, “Authentication for DHCP Messages,” June 2001.) 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 (Droms, R., “Dynamic Host Configuration Protocol,” March 1997.) [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 (EAP-Message Option).

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

12.2. Informative References

Authors' Addresses

Full Copyright Statement

Copyright © 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.