rfc3118.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 956 行 · 第 1/3 页

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


   3. Limit state required by the server.
   4. Limit complexity (complexity breeds design and implementation
      errors).

1.3 Requirements Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [5].

1.4 DHCP Terminology

   This document uses the following terms:

      o  "DHCP client"

         A DHCP client or "client" is an Internet host using DHCP to
         obtain configuration parameters such as a network address.

      o  "DHCP server"

         A DHCP server or "server" is an Internet host that returns
         configuration parameters to DHCP clients.

2. Format of the authentication option

   The following diagram defines the format of the DHCP authentication
   option:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |  Protocol     |   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   +-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The code for the authentication option is 90, and the length field
   contains the length of the protocol, RDM, algorithm, Replay Detection
   fields and authentication information fields in octets.



Droms & Arbaugh             Standards Track                     [Page 3]

RFC 3118            Authentication for DHCP Messages           June 2001


   The protocol field defines the particular technique for
   authentication used in the option.  New protocols are defined as
   described in Section 6.

   The algorithm field defines the specific algorithm within the
   technique identified by the protocol field.

   The Replay Detection field is per the RDM, and the authentication
   information field is per the protocol in use.

   The Replay Detection Method (RDM) field determines the type of replay
   detection used in the Replay Detection field.

   If the RDM field contains 0x00, the replay detection field MUST be
   set to the value of a monotonically increasing counter.  Using a
   counter value such as the current time of day (e.g., an NTP-format
   timestamp [4]) can reduce the danger of replay attacks.  This method
   MUST be supported by all protocols.

3. Interaction with Relay Agents

   Because a DHCP relay agent may alter the values of the 'giaddr' and
   'hops' fields in the DHCP message, the contents of those two fields
   MUST be set to zero for the computation of any hash function over the
   message header.  Additionally, a relay agent may append the DHCP
   relay agent information option 82 [7] as the last option in a message
   to servers.  If a server finds option 82 included in a received
   message, the server MUST compute any hash function as if the option
   were NOT included in the message without changing the order of
   options.  Whenever the server sends back option 82 to a relay agent,
   the server MUST not include the option in the computation of any hash
   function over the message.

4. Configuration token

   If the protocol field is 0, the authentication information field
   holds a simple configuration token:














Droms & Arbaugh             Standards Track                     [Page 4]

RFC 3118            Authentication for DHCP Messages           June 2001


   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0 0 0 0 0 0 0 0| Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |                                               |
   |-+-+-+-+-+-+-+-+                                               |
   |                                                               |
   |           Authentication Information                          |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The configuration token is an opaque, unencoded value known to both
   the sender and receiver.  The sender inserts the configuration token
   in the DHCP message and the receiver matches the token from the
   message to the shared token.  If the configuration option is present
   and the token from the message does not match the shared token, the
   receiver MUST discard the message.

   Configuration token may be used to pass a plain-text configuration
   token and provides only weak entity authentication and no message
   authentication.  This protocol is only useful for rudimentary
   protection against inadvertently instantiated DHCP servers.

   DISCUSSION:

      The intent here is to pass a constant, non-computed token such as
      a plain-text password.  Other types of entity authentication using
      computed tokens such as Kerberos tickets or one-time passwords
      will be defined as separate protocols.

5. Delayed authentication

   If the protocol field is 1, the message is using the "delayed
   authentication" mechanism.  In delayed authentication, the client
   requests authentication in its DHCPDISCOVER message and the server
   replies with a DHCPOFFER message that includes authentication
   information.  This authentication information contains a nonce value
   generated by the source as a message authentication code (MAC) to
   provide message authentication and entity authentication.

   This document defines the use of a particular technique based on the
   HMAC protocol [3] using the MD5 hash [2].




Droms & Arbaugh             Standards Track                     [Page 5]

RFC 3118            Authentication for DHCP Messages           June 2001


5.1 Management Issues

   The "delayed authentication" protocol does not attempt to address
   situations where a client may roam from one administrative domain to
   another, i.e., interdomain roaming.  This protocol is focused on
   solving the intradomain problem where the out-of-band exchange of a
   shared secret is feasible.

5.2 Format

   The format of the authentication request in a DHCPDISCOVER or a
   DHCPINFORM message for delayed authentication is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     RDM       | Replay Detection (64 bits)                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont.                                                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Replay cont. |
   +-+-+-+-+-+-+-+-+

   The format of the authentication information in a DHCPOFFER,
   DHCPREQUEST or DHCPACK message for delayed authentication is:

   0                   1                   2                   3
   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Code      |    Length     |0 0 0 0 0 0 0 1|   Algorithm   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+