Authentication of DHCP Clients and Servers
The DHCP Handbook
Author: Ralph Droms; Ted Lemon
In some circumstances, DHCP clients and servers need to reliably authenticate
each other's identities as part of the DHCP message exchange. Unfortunately,
the current DHCP protocol does not provide a way to do this. The IETF DHC
Working Group is currently working on a protocol draft to solve this problem.
Because the draft is sufficiently mature at the time of this writing, it's
worth describing in this chapter.
The DHCP authentication protocol seeks to accomplish two goals. The
first goal is to protect both the client and the server in the DHCP protocol
from attack. The second goal is to establish a trust relationship, enabling
the server to ration access only to authorized DHCP clients and to trust the
information that the client presents.
In considering potential DHCP security issues, the network administrator
must operate under the assumption that some people may harm the network either
intentionally, or otherwise. Some forms of intentional harm include simply
causing trouble, intercepting information, planting false information, or
intercepting requests for information and substituting incorrect information.
Some forms of unintentional harm include a naїve person incorrectly configuring
a DHCP client or server in such a way that it causes a disruption.
Which of these problems occurs likely depends on the context; in a school
environment, disruptive pranks by students are common, and configuration errors
by students and guests are even more common. In an environment where monetary
transactions are conducted, or where valuable information is passed, criminals
may use the computer to try to steal money or information (for example, account
balances) that they can resell.
DHCP client attached to a network. It wants to get an IP address and needs
to know the IP address of its router, name server, and possibly some other
services. Now, imagine that somebody with bad intentions (the “attacker”)
wants to prevent the client from using the network.
Such an attacker can simply set up a DHCP server that provides incorrect
addressing information. As long as this server is faster than the official
DHCP server and is configured to serve only the client being attacked, the
client almost certainly selects the invalid IP address. When the client tries
to use this address, it doesn't work, and the client cannot use the network.
A clever attacker might use a legitimate IP address but supply an incorrect
value for the name server; such an attack is less obvious to somebody looking
at the server log or at the client's network configuration.
What if the attacker wants to steal information from the client? The
easiest way to do this is to simply eavesdrop on the network. However, most
large network installations today use Ethernet switches that prevent devices
connected to the network from eavesdropping on one another. These devices
do not, however, prevent devices connected to the network from hearing broadcasts.
An attacker on such a network can set up a DHCP server, provide the client
with a legitimate IP address, but provide the client with its own IP address
in the routers option, causing the client to send all off-network
traffic to the attacker. The attacker can transparently forward this information
off the network so that the client is unaware of the attack.
Finally, what if the attacker wants to provide incorrect information
to the client? For example, imagine an attacker with a pathological dislike
for radishes. This attacker wants to prevent anybody from reading the world-famous radish.org
Web site. To do so, he sets up a DHCP service that mimics the address allocation
process of the legitimate DHCP server, but he provides a different domain
name server address. This domain name server provides incorrect information
for the radish.org domain, leading the attacked client
to a site promoting turnips.
can also unintentionally interfere with the operation of DHCP clients because
DHCP clients may not have a way to differentiate between DHCP servers in an
organization. Also, an end user can easily install a DHCP server without understanding
that this “personal” DHCP server may affect DHCP service for
all users of the network.
Unintentional Interference Between DHCP Servers
DHCP servers may unintentionally interfere
with each other because RFC2131 does not provide a mechanism through which
servers and clients can identify themselves in a reliable way. Ralph Droms
once worked with an organization whose data center used a large, bridged network
configured as a single IP subnet. Development and production groups shared
this network, and each of them ran their own DHCP servers. But because both
the production and development DHCP servers received DHCP client broadcasts,
production DHCP clients risked receiving an address assigned by the development
In this network, a DHCP client from the development group could accept
an address from the production DHCP server, and the DHCP server in the development
group processed requests from clients in both the production and development
groups. Although most DHCP clients could function with an address from either
server, some production clients received incorrect parameters such as a default
Domain Name System (DNS) server from the development server.
At the same time, the development server processed the incoming requests
from clients in the production organization, and the development server responded
to both development and production group servers. These interactions with
the production clients interfered with DHCP client-server design and implementation
experiments between development clients and servers conducted by the development
Another common source of disruption to your DHCP service can result
from the inclusion of the DHCP server with Windows NT 4.0. An NT user can
easily start up the Microsoft DHCP server, perhaps to provide DHCP service
to a few local computers, or just to explore DHCP. These DHCP servers may
be incorrectly configured so that the server hands out invalid addresses or
duplicate addresses, or sends inappropriate DHCPNAK
messages in response to client requests. Any of these situations results in
disruption of service to DHCP clients.
The authentication mechanism for DHCP enables a client to be configured
with a list of legitimate servers and with a key enabling each server to prove
its identity. The client can then be configured either to simply discard offers
from unknown servers, or to respond only to offers from unknown servers if
it does not hear any offers from known servers within a specific period of
time. By using the authentication mechanism, clients configured with a list
of legitimate servers never accept IP addresses from an unauthorized server
because the owner of that server does not know the secret key that the client
and the legitimate server
an attacker can easily exhaust a DHCP server's pool of available addresses
by repeatedly requesting and confirming leases, each time with new identification
information, until the server runs out of IP addresses to allocate. When this
happens, the server cannot provide addresses to legitimate clients. If you
can program the server to allocate addresses only to legitimate clients that
can prove their identities, or at least to reserve most addresses for such
clients, such an attack can't
Chapters 14, “Client Identification and Fixed-Address Allocation,” 17, “Conditional Behavior,” and 18, “Automatic
DHCP Client Registration” describe ways of restricting the address
allocation process to only authorized clients. Unfortunately, although the
DHCP protocol provides an identifier through which you can specify client
authorization rules, without authentication, nothing prevents a user from
configuring a client to present a false identity; the DHCP protocol doesn't
require proof of the client's identity. The DHCP authentication protocol provides
a means for imposing and enforcing such a requirement.
Some uses of the
DHCP protocol require the DHCP client to provide information to the DHCP server
that the DHCP server can't validate on its own. For example, a client may
claim that its hostname is “alice,” and the DHCP server may be
unable to decide whether this is true. With authentication, you can program
the DHCP server to accept the name “alice” if a certain identity
is proven and to reject it otherwise. You can also program it to create an
association between a name it has never seen before and a particular identity.
This means that when one client claims to be named “alice,” that
client is always believed if it subsequently claims to be named “alice.”
Other clients that subsequently claim to be “alice” are not believed.
You can use this, for example, to implement a first-come, first-served dynamic
DNS naming system.
The DHCP protocol includes a mechanism for making the client
aware of other network services. As discussed previously, an attacker can
arrange to eavesdrop on network services and steal information, or provide
incorrect information. Securing the DHCP protocol makes doing this somewhat
harder for an attacker, but it is still possible. To prevent eavesdropping
and falsification of information, you must secure all the network protocols
that a DHCP client uses. You can do this using Internet layer security (IPsec), transport
layer security (TLS
or SSL), or protocols that
are secure themselves.
One of the primary architects of OpenCable, Michael
Adams, explains the key concepts of this initiative in his book
Broadband, Second Edition
by George Abe
Introduces the topics surrounding high-speed networks
to the home. It is written for anyone seeking a broad-based familiarity
with the issues of residential broadband (RBB) including product
developers, engineers, network designers, business people, professionals
in legal and regulatory positions, and industry analysts.