Cisco Knowledge Suite Cisco SystemsCisco Press
   

   
Home
MyCKS
Cutting Edge
Certification
Core Reference
Guided Learning
   
Networking Architecture
LAN
WAN
Switching
Internet Protocols (IP)
Network Protocols
Transport and Application Protocols
Desktop Protocols
Security and Troubleshooting
Network Resources and Management
Integrated Services
 

Authentication of DHCP Clients and Servers

   

< Back Contents Next >

Authentication of DHCP Clients and Servers

  

21.1. -

Reasons for Authenticating the DHCP Protocol

  

21.2. -

Objectives the DHCP Authentication Protocol Cannot Accomplish

  

21.3. -

Protocol Design

  

21.4. -

Status

  

 

Summary

Save to MyCKS

 
The DHCP Handbook

From: The DHCP Handbook
Author: Ralph Droms; Ted Lemon
Publisher: MTP
More Information

21. Authentication of DHCP Clients and Servers

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.

21.1. Reasons for Authenticating the DHCP Protocol

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.

21 1.1. Protecting the Client from Attack

Consider a 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.

21.1.2. Protecting Clients from Errors

DHCP servers 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 server.

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 organization.

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 share.

21.1.3. Protecting Servers from Attacks by Clients

Without authentication, 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 succeed.

21.1.4. Reliably Restricting Address Allocation

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.

21.1.5. Authenticating Client Assertions

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.

21.1.6. Securing Other Services

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.

   

< Back Contents Next >

Save to MyCKS

 

Breaking News

One of the primary architects of OpenCable, Michael Adams, explains the key concepts of this initiative in his book OpenCable Architecture.

Expert Advice

Ralph Droms, Ph.D., author of The DHCP Handbook and chair of the IETF Dynamic Host Configuration Working Group, guides you to his top picks for reliable DHCP-related information.

Just Published

Residential 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.

             
     

From the Brains at InformIT

|

Contact Us

|

Copyright, Terms & Conditions

|

Privacy Policy

 

© Copyright 2000 InformIT. All rights reserved.