Figure 1: DHCP model
Kazumasa Kobayashi <kazu-k@is.aist-nara.ac.jp>
Suguru Yamaguchi <suguru@is.aist-nara.ac.jp>
Nara Institute of Science and Technology
Japan
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.
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.
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
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).
It is necessary to satisfy the following three conditions between receiver R and sender S with a general digital signature:
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].
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.
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
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.
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:
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.
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.
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 message authentication in DHCP. If the message from the DHCP server can be protected from malicious hosts, the DAG gateway is also protected. It is necessary to share the secret key for MAC information in the DAG gateway in addition to the authenticated DHCP server and the client.
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.
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.
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.
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.