Network Access Control for DHCP
Environment
Kazumasa Kobayashi <kazu-k@is.aist-nara.ac.jp>
Suguru Yamaguchi <suguru@is.aist-nara.ac.jp>
Nara Institute of Science and Technology
Japan
Abstract
In the Internet Engineering Task Force (IETF), several authentication
methods for Dynamic Host Configuration Protocol (DHCP) messages have been
proposed. These were published and circulated as the IETF Internet Drafts.
However, they have several drawbacks. One is that users can reuse addresses
illegally by using an expired address that was allocated to a host. This
may cause serious security problems. We propose a new access control method
to be used as the DHCP message authentication mechanism.
We designed and developed the DAG (DHCP Access Control Gateway) as an
example of the proposed method. The DAG is a gateway program that passes
network accesses only by clients with addresses formally allocated from
the DHCP server. In order to determine the address allocation formally,
the DAG observes DHCP interactions between servers and clients and gathers
information on address allocations made by the observed servers. The DAG
can authenticate the DHCP server based on the message authentication code
(MAC), which is included in the DHCP message. When the new address is
allocated to the client, the DAG resets the gateway filters.
The gateway made by this method can be used even with DHCP servers lacking
authentication mechanisms. Even if a regular DHCP server and the DAG are
combined, network security can be improved. By combining a DHCP server and
a DHCP client that supports authentication schemes such as IETF Internet
Draft, the DAG can offer a mechanism whereby only a specific client may
access the network.
Contents

Introduction

Related technology

Authentication of the DHCP message


o
Digital signature
o
Authentication mechanism in the IETF Internet Draft
Design of the access control mechanism
o
Fundamental idea
o
Authentication of the DHCP message
o
Implementation of the DAG
Evaluation
o
Safety
o
Performance
o
Problems

Conclusion

References

Authors' Information
Introduction
Notebook computers and portable systems have become popular. They enable
people to access the Internet from anywhere in the world. Desktop systems
are wired and considered immobile, but notebook computers can move with
users. In this sense, we call these systems "mobile hosts." However, when
mobile hosts move from one network to another, users have to change system
configuration, including host IP (Internet Protocol) address, default
gateway, and name servers. In order to support the automatic configuration
changes on these hosts, several technologies such as dynamic host
configuration mechanisms or mobility support in the IP layer have been
developed.
The Dynamic Host Configuration Protocol (DHCP)[1][2][3] was developed to
support automatic host configuration. In the DHCP framework, a host moved
from another network can obtain IP address assignment and other related
information from the DHCP server running on the network. This technology
has been adopted for Microsoft Windows95 and Windows/NT platforms.
Furthermore, DHCP client packages have been available for other platforms,
such as BSD UNIX, connected to IP networks. However, security in the DHCP
framework is not sufficient, because security considerations around the
DHCP were intentionally omitted in the IETF standardization process. The
security function that many DHCP users consider necessary is access control.
With the current framework, a DHCP server tries to assign IP addresses to
any clients requesting an assignment. The current version of the DHCP server
permits everyone access to the network. Hence, many network operators
consider that providing DHCP service is a serious security hole. In order
to solve this problem, some suggestions, including IETF Internet Drafts
[4], have been made. Moreover, several methods for processing
authentication with DHCP have been proposed [5].
However, these methods are not effective against clients attempting illegal
access. When clients try to connect to the network using address information
allocated in the past, there is no way to prohibit them from masquerading
as the host that had the IP address from the DHCP server. This situation
is not addressed in the IETF Internet Drafts and related proposals, but
should be eliminated because it enables malicious hosts to install tapping
on the network. We have developed a method called DAG whereby only clients
with information allocated by the DHCP server can access the network.
Related technology
For the IP suite, several protocols for supporting host mobility have been
proposed, and some of them are on the standardization track of the IETF.
In the IP layer, Mobile-IP [6] is on the standardization track for mobility
support. The protocol used in our mobile test bed is a VIP [7][8] developed
by the WIDE Project. In these protocols, each mobile host has its own IP
address and is never changed, even when the host moves around. However,
local IP address allocation is required to establish IP datagram forwarding,
such as IP tunneling in the Mobile-IP architecture or the locator assignment
in the VIP architecture. For this purpose, the IP address allocation
mechanism is also vital for host mobility support on the Internet. BOOTP
[9] was once used for IP address allocation. However, because of BOOTP's
lack of capability, a new address allocation protocol was desired. In 1993,
DHCP was proposed as an upward-compatible protocol of BOOTP; it was
standardized by IETF in 1996.
This paper focuses on the DHCP protocol as the resource allocation mechanism.
The DHCP is composed of the DHCP client, DHCP server, and DHCP relay agent.
The DHCP client asks the DHCP server for an allocation of resources. The
DHCP server allocates the network resource according to the request from
the DHCP client. The DHCP relay agent relays the request and the reply
packets between the DHCP client and the DHCP server (shown in Fig. 1).
Figure 1: DHCP model
Authentication of the DHCP message
Message interaction between DHCP servers and clients should be protected
from any interference by malicious hosts. In order to establish secure
associations between DHCP servers and clients, adding digital signatures
to the DHCP message was proposed in the IETF DHCP working group (WG). The
authentication information added to the DHCP message is called a message
authentication code (MAC).
Digital signature
It is necessary to satisfy the following three conditions between receiver
R and sender S with a general digital signature:

It should be confirmed that the message that R received is what S transmitted.

Any third party T, including R, should not be able to counterfeit the message of
S.

The fact that S transmitted a message addressed to R should be denied after S
sent it.
Authentication mechanism in the IETF Internet Draft
One of the authentication methods uses a secret key shared by the DHCP server
and the DHCP client. The server and the client authenticate each other by
the MAC included with the DHCP message. The following information is
included in the DHCP message actually transmitted:
DHCP message, counter, MAC
The DHCP message is information about the network resource allocation
exchanged between the client and the server. A value such as the current
time in NTP [10] format is set in the counter. This is used to prevent replay
attacks. The MAC information is a digital signature for authentication.
Several other methods have also been proposed. Discussions about the
authentication of the DHCP messages are ongoing in the IETF WG. The MAC
algorithm discussed within IETF is called HMAC [11].
Design of the access control mechanism
In our access control mechanism, a gateway is set up between a service
segment and an internal network. The access control on this gateway is
called DAG (DHCP Access Control Gateway). The service segment is a network
with which the client could be connected. The DHCP server allocates the
network resource to the client there.
Fundamental idea
Fig. 2 shows the flow of DHCP authentication processing. To look for DHCP
servers, a client sends the DHCPDISCOVER message using datalink-level
broadcasting. If the server has the allocated network resources (such as
an IP address), the DHCP server that receives the DHCPDISCOVER message
transmits a DHCPOFFER message to the client. Then the client selects a
server (if the client receives replies from more than one server) and
transmits a DHCPREQUEST message. The DHCP server that receives this
DHCPREQUEST message sends back a DHCPACK message with the allocated
resource information to the client. Finally, the client can be connected
to the network using the received information.
Figure 2: DHCP message flow
The main purpose of the DAG is to direct accesses from the DHCP client to
the proper networks or hosts. The DHCP server notifies the client about
resource allocation by transmitting DHCPACK messages. Because this message
is also received by the DAG connected to the same network, the DAG obtains
sufficient information to configure its access control mechanism (shown
in Fig. 3). The IP address allocated from the DHCP server to the client
can be obtained from the DHCPACK message received at the DAG. If the
authentication information is included in the DHCP message, the
authentication processing of the client and the server can be executed
according to the obtained information. The access control gateway DAG does
the authentication processing, permits accessing, and relays the packet
for the formal clients. The DAG gateway executes the access control of the
client by information on the DHCP message that is transmitted from the DHCP
server to the client.
Therefore, in the allocation of network resources, there is no need for
transmitting information allocated from the DHCP server to the access
control gateway. The access control gateway can obtain accurate information
through the usual allocation processing.
Figure 3: DHCP access control gateway
Authentication of the DHCP message
In the IETF Internet Draft titled "Authentication for the DHCP Message (work
in progress)," the digital signature (the MAC) is included in the DHCP
message. It can be specified in the DHCP option field with the MAC
information. In our method, the MAC is located in the Class-identifier
option field. Because this field is currently assigned for site-specific
purposes, we use it for authentication. However, in the future specific
fields in the DHCP message are likely to be provided for this purpose.
Implementation of the DAG
Because almost all of the DHCP implementations available on the current
Internet do not have authentication mechanisms, the DAG is also designed
for environments where only ordinary DHCP servers are operated. The DAG
also observes DHCP messages without authenticators, and may manage the
access control using such messages.
The access control gateway DAG is composed of four parts:

Detection of DHCP packets,

Access control (filtering function),

Management of the database, and

Gateway processing of data packets.
In order to implement the DHCP packet watcher, packet monitoring utilities
and libraries such as bpf (Berkeley Packet Filter) are required. In the
current implementation of the DAG, the program ip_fil3.1.0 is used. We
implement a program dhc_fild, which observes DHCP messages transferred on
the attached network. Each allocated address is obtained from the DHCPACK
message sent from the DHCP server to the client. The dhc_fild program
invokes the access control mechanism implemented with the ip_fil program
based on this obtained IP address. Moreover, when the DHCPRELEASE message
is sent from the DHCP client to the server, the dhc_fild program deletes
the released address from filtering, then reconfigures the access control
mechanism.
When the DHCP message is authenticated with the DHCP server, authentication
can be processed by sharing the MAC information with the DHCP server and
the dhc_fild program. Moreover, the dhc_fild program can also be
implemented for an ordinary DHCP server. The presence of the authentication
scheme can be specified with the dhc_fild.conf configuration file.
Evaluation
The DAG admits network access only from DHCP clients with an address
formally allocated by the DHCP server. The mechanism proposed in this paper
is completely upward-compatible with existing DHCP systems. Therefore, the
method can also be used in an ordinary DHCP environment without any
modifications.
Safety
The DHCP option field limits the length of the DHCP message. There is also
a limitation in the method of encoding and the length of the authentication
key, because a digital signature (MAC) is specified for this DHCP message.
As proposed by IETF, the key of the MAC information is shared between the
server and the client using the DHCP message option field. Unwarranted
disclosure of the key on the client side is a problem. Therefore, it is
required to use a key that an intruder cannot decipher.
The safety of the access control mechanism proposed in this paper depends
on
be
is
in
message authentication in DHCP. If the message from the DHCP server can
protected from malicious hosts, the DAG gateway is also protected. It
necessary to share the secret key for MAC information in the DAG gateway
addition to the authenticated DHCP server and the client.
Performance
The authentication of the DHCP message and setting the filter in the DAG
can be processed in a short time compared with the allocation of the network
resource by DHCP. In the DHCP protocol, 10 seconds are necessary for the
allocation in the worst case. The processing time of our proposed method
is negligible. The DAG processing performance of this system depends on
the filtering and the routing processing performance of each packet. In
our system, the IP filter function is processed by the ip_fil3.1.0 program;
the routing function is processed by the gated program.
Problems
Clients whose network resources were already allocated when the DAG started
cannot be processed well by the proposed method. However, if the DAG gateway
does not operate, the client cannot connect from the DHCP service network
to an internal network. If the client requests reallocation to the DHCP
server, this problem can be solved. If it is difficult to capture the packet
of the DHCP message in the network, the DAG gateway cannot achieve access
control. The typical example of this situation is when the DHCP server and
the DAG are operated in a network segment (same broadcast domain) in which
switching technology such as VLAN Ether-Switch is used.
Conclusion
DHCP provides network resources to mobile hosts such as notebook computers.
In the current DHCP protocol, security is not considered. If the client
configures network resources such as IP address, each client can use the
network. In addition, current DHCP servers allocate network resources to
any client that requests them. To solve these problems, there is the
authentication method of the DHCP message proposed by IETF and also
distributed as an Internet Draft. However, this proposal only authenticates
the DHCP message between the server and clients and does not address the
need for access control for each client. DAG has been implemented and
evaluated as an access control gateway on the basis of this method. An
authenticated DHCP server allocated network resources only to the
authenticated clients. The access control of DAG depends on allocated
information for a client in the DHCP ACK message. As a result, only clients
with an IP address allocated by the DHCP server can access the network.
References

[1] R. Droms: "Dynamic Host Configuration Protocol", RFC1541 (1993).

[2] R. Droms and S. Alexander: "DHCP Options and BOOTP Vendor Extensions",
RFC1533 (1993).

[3] A. Tominaga , F. Teraoka and J. Murai: "The Implementation and Evaluation
of the Dynamic Host Configuration Protocol(DHCP)", IPSJ DPS SIG Notes
(1993).

[4] R. Droms: "Authentication for DHCP message", IETF Internet Draft (1996
"work in progress").

[5] K. Kobayashi and S. Yamaguchi: "Dynamic Host Configuration for Mobile
Host with Authentication", IPSJ DPS SIG notes (1995).

[6] C. Perkins: "IP Mobility Support", RFC2002 (1996).

[7] F. Teraoka and M. Tokoro: "Host Migration in Virtual Internet Protocol",
Proceedings of INET'92 (1992).

[8] WIDE Project: "Mobile Node", WIDE Project Report'92 (1993).

[9] B. Croft and J. Gilmore: "Bootstrap Protocol(BOOTP)", RFC951 (1985).

[10] D. Mills: "Network Time Protocol (v3)", RFC1305 (1992).

[11] H. Krawczyk, M. Bellare and R. Canetti: "HMAC: Keyed-Hashing for
Message Authentication", IETF Internet Draft (1996 "work in progress").
Authors' Information
Kazumasa Kobayashi is a Ph.D. candidate of the Graduate School of
Information Science, Nara Institute of Science and Technology. He has also
been a lecturer in the Kurashiki University of Science and the Arts since
1995. His research topics include technologies for mobile computing,
high-speed networks such as ATM, and multimedia network infrastructure.
Suguru Yamaguchi has been an associate professor in the Graduate School
of Information Science, Nara Institute of Science and Technology, since
1993. He received his Ph.D. in engineering from Osaka University in 1991.
He has also been a member of the WIDE Project since its creation in 1987,
where he has been conducting research on network security systems for a
wide area distributed computing environment. His research interests
include technologies for information sharing, multimedia communication,
network security, and network management for the Internet.