Authentication for DHCP Messages
RFC 3118
|
| Document |
Type |
|
RFC - Proposed Standard
(June 2001; Errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3118 (Proposed Standard)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
Network Working Group R. Droms, Editor
Request for Comments: 3118 Cisco Systems
Category: Standards Track W. Arbaugh, Editor
University of Maryland
June 2001
Authentication for DHCP Messages
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Abstract
This document defines a new Dynamic Host Configuration Protocol
(DHCP) option through which authorization tickets can be easily
generated and newly attached hosts with proper authorization can be
automatically configured from an authenticated DHCP server. DHCP
provides a framework for passing configuration information to hosts
on a TCP/IP network. In some situations, network administrators may
wish to constrain the allocation of addresses to authorized hosts.
Additionally, some network administrators may wish to provide for
authentication of the source and contents of DHCP messages.
1. Introduction
DHCP [1] transports protocol stack configuration parameters from
centrally administered servers to TCP/IP hosts. Among those
parameters are an IP address. DHCP servers can be configured to
dynamically allocate addresses from a pool of addresses, eliminating
a manual step in configuration of TCP/IP hosts.
Some network administrators may wish to provide authentication of the
source and contents of DHCP messages. For example, clients may be
subject to denial of service attacks through the use of bogus DHCP
servers, or may simply be misconfigured due to unintentionally
instantiated DHCP servers. Network administrators may wish to
constrain the allocation of addresses to authorized hosts to avoid
denial of service attacks in "hostile" environments where the network
Droms & Arbaugh Standards Track [Page 1]
RFC 3118 Authentication for DHCP Messages June 2001
medium is not physically secured, such as wireless networks or
college residence halls.
This document defines a technique that can provide both entity
authentication and message authentication. The current protocol
combines the original Schiller-Huitema-Droms authentication mechanism
defined in a previous work in progress with the "delayed
authentication" proposal developed by Bill Arbaugh.
1.1 DHCP threat model
The threat to DHCP is inherently an insider threat (assuming a
properly configured network where BOOTP ports are blocked on the
enterprise's perimeter gateways.) Regardless of the gateway
configuration, however, the potential attacks by insiders and
outsiders are the same.
The attack specific to a DHCP client is the possibility of the
establishment of a "rogue" server with the intent of providing
incorrect configuration information to the client. The motivation
for doing so may be to establish a "man in the middle" attack or it
may be for a "denial of service" attack.
There is another threat to DHCP clients from mistakenly or
accidentally configured DHCP servers that answer DHCP client requests
with unintentionally incorrect configuration parameters.
The threat specific to a DHCP server is an invalid client
masquerading as a valid client. The motivation for this may be for
"theft of service", or to circumvent auditing for any number of
nefarious purposes.
The threat common to both the client and the server is the resource
"denial of service" (DoS) attack. These attacks typically involve
the exhaustion of valid addresses, or the exhaustion of CPU or
network bandwidth, and are present anytime there is a shared
resource. In current practice, redundancy mitigates DoS attacks the
best.
1.2 Design goals
These are the goals that were used in the development of the
authentication protocol, listed in order of importance:
1. Address the threats presented in Section 1.1.
2. Avoid changing the current protocol.
Droms & Arbaugh Standards Track [Page 2]
RFC 3118 Authentication for DHCP Messages June 2001
Show full document text