HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 01:51:25 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Tue, 17 Mar 1998 16:31:00 GMT ETag: "2e7a5f-343d-350ea544" Accept-Ranges: bytes Content-Length: 13373 Connection: close Content-Type: text/plain DHCP working Group Baiju V. Patel INTERNET DRAFT Intel Corporation July 11, 1997 Expires in 6 months Securing DHCP Status of this Memo This document is a submission to the IETF Dynamic Host Configuration Protocol (dhc) Working Group. Comments are solicited and should be addressed to the working group mailing list (dhcp-v4@bucknell.edu) or to the editor. This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Abstract This proposal describes methods of securing DHCP based on IETF DHCP and IPSEC protocols. This protocol achieves security goals for DHCP client and servers without having to define a new security protocol. Instead, it first bootstraps the DHCP client in un-trusted mode using existing DHCP protocol and then proceeds to secure configuration of the client using existing DHCP and IP protocol features. 1. Introduction In this draft, we present a method of securing DHCP protocol Patel [Page 1] INTERNET DRAFT Securing DHCP 07/30/97 and use notation DHCPSEC for the proposed method. The servers and clients that implement the proposed method are denoted by DHCPSEC servers and clients, respactively. The objective behind securing DHCP is to securely configure a DHCP client with an IP address(es) and configuration parameters. The DHCPSEC does not protect against an unauthorized client from arbitrarily selecting an address and using it. Instead, if a client obtains IP address(es) and configuration parameters using DHCPSEC protocol, it is assured that the IP address and configurations obtained using DHCPSEC are the ones provided by an authenticated DHCPSEC server and the integrity of the parameters is not compromised by an adversary in the network. The subsequent renewal of the lease, and acquiring of the additional configuration parameters, as well as release of the lease of an address(es) is authenticated as well. Thus, the protocol protects the client from an adversary who may release the lease of its IP address. The DHCPSEC server also authenticates the DHCPSEC clients. This allows an DHCPSEC server to determine if a client should be allocated an address at all, and to help determine configuration parameters for the client. Moreover, it prevents an adversary from renewing or releasing an address assigned to an authorized client. 2. Securing DHCP Protocol The DHCPSEC is comprised of several phases: 1) start-up phase, 2) trusted configuration phase, 3) trusted renew, and 4) trusted release phase. 2.1. Start-up phase In start-up phase, the DHCPSEC client brings up an un- trusted configuration using the DHCP protocol defined in [1]. The configuration supplied by the DHCP server in this phase is the minimal configuration required to execute subsequent phases of the protocol. The server MUST supply an IP address, and optionally, provide default gateway and DNS server information. If the DHCP server is not on the same subnet as the client, the default gateway information MUST be provided. The lease time (configurable) for the IP address should be relatively small for the efficient use of the addresses. The recommended duration of the lease is hundreds of milliseconds. In many environments, there may be a concern that an adversary may be able to launch a denial of service attack by quickly requesting too many addresses (short lease in this case) and thus denying a legitimate client an IP address. There are several alternatives that may be deployed to protect against some forms of such denial of attacks. For example, if the DHCPSEC server is on the same subnet as the Patel [Page 2] INTERNET DRAFT Securing DHCP 07/30/97 client, it may allocate a non-routable temporary address to a DHCP client. Since the non-routable address space is large, an authorized client is likely to get an address even when this type of attack is in progress (it may result in a fairly large short lived state in the server). Broadband cable network environment may use such configuration by deploying DHCPSEC server at the head-end. In a switch based network, the monitors may be deployed in the hubs to detect both unauthorized use of IP addresses and denial of service attacks. If the attack in progress is detected, the ports may be deactivated. This is by no means a complete list of protection mechanisms against denial of service attack and the implementers must take appropriate actions to protect against such attacks. Note that the proposed method does not attempt to protect against denial of service attack. 2.2. Trusted configuration phase In this phase, the DHCPSEC client proceeds with establishing a secure communication channel (as defined in section 2.4) between itself and a known DHCPSEC server (the address of the server is known after the start-up phase). If the DHCPSEC client fails to establish a secure channel with the DHCPSEC server, the DHCPSEC fails and MUST be terminated with appropriate messages. Naturally, the process may be repeated again as often as desired. Once the trusted channel is established, the DHCPSEC client proceeds to renew the IP address using DHCP renew message. The communication for DHCP renew phase MUST be based on the unicast messages over the secured communication channel between the DHCPSEC client and server. If the renew completes successfully, the IP address allocated to the DHCPSEC client is authenticated. Note: As suggested earlier, if the temporary address is not same as the address assigned in the trusted configuration phase, then the DHCP protocol may have to be modified so that instead of sending a NACK for the renew message, the server can ACK with an alternate address. The other approach is to modify the protocol so that instead of issuing a DHCP renew, the client can do a DHCP discover and, instead of sending a discover message as a broadcast, it is sent as a unicast message over the trusted communication channel. If the new trusted address is not identical to the un-trusted address assigned to a client, the DHCPSEC server SHOULD not automatically reclaim address before the duration of the temporary lease (it could lead to some race conditions). The client may issue an un-trusted release for the temporary address is no longer needed. 2.3. Trusted Renew and Release The DHCPSEC server MUST ignore any renew or release request over clear channel for securely allocated IP address. Lease of a securely allocated IP address may be renewed or Patel [Page 3] INTERNET DRAFT Securing DHCP 07/30/97 released only over a secure channel between the DHCPSEC server and client to whom the address was allocated in the trusted configuration phase of the DHCPSEC protocol. The identity of the client is verified by the secure channel protocol. In summary, the trusted release phase is essentially same as the trusted configuration phase. 2.4. Authenticated Secure Channel The DHCPSEC compliant servers and clients MUST implement the secure channel based on IPSEC AH [2] and ISAKMP/OAKLEY [3,4,5]. IPSEC ESP [6] MAY be used when the situation warrants. DHCPSEC clients and servers must conform to the interoperability requirements of IPSEC protocol suit (including ISAKMP/OAKLEY, IPSEC AH, and IPSEC ESP). In future other secure communication channels may be defined. The IPSEC security association is used by the DHCPSEC protocol during the trusted configuration phase. Therefore, at the end of this phase, the security association SHOULD be discarded by both the DHCPSEC client and servers. In some cases (e.g., when the temporary address is same as the securely assigned address), the same security association MAY be used for further communication between the two systems. 3. Security Considerations The proposed protocol does not address security requirements for tftp function that is part of the bootp protocol. It is assumed that the integrity of the files tftp'd will be verified using means external to this protocol. An example of such means would be to use signed files for software download using tftp so that the client would be able to authenticate and verify integrity of the copied software. The server may enforce licensing requirements on the software by external means such as a license servers. 4. Acknowledgments The author would like to thank Thomas Narten, Ralph Droms, Peter Ford, Eric Dittert, Dave Chouinard, Charlie Perkins, and Throop Wilder, Munil Shah and many others for helping improve this draft. 5. References [1] Droms, R, "Dynamic Host Configuration Protocol", RFC 1531. Bucknell University, 1993. [2] Atkinson, R., "IP Authentication Header", RFC 1826. Patel [Page 4] INTERNET DRAFT Securing DHCP 07/30/97 [3] Maughan, D., Schrtler, M. Schneider, M., and Truner, J., "Internet Security Association and Key Management Protocol (ISAKMP)". [4] Piper, D., The Internet IP Security Domain of Interpretations, Internet Draft. [5] Carel, D., Harkins, D., "The Resolution of ISAKMP with Oakley". [6] Atkinson, R., "IP Encapsulating Security Payload (ESP)", RFC 1827. 6. Authors' Address Baiju V. Patel Intel Corporation MS JF3-206 2111 NE 25th Ave. Hillsboro, OR, USA 97124 +1(503)264-2422 baiju@mailbox.jf.intel.com Patel [Page 5]