DHCP working Group Baiju V. Patel
INTERNET DRAFT Intel Corporation
July 11, 1997 Expires in 6 months
Securing DHCP
<draft-ietf-dhc-securing-dhc-00.txt >
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]
