draft-ietf-dhc-authentication-14.txt

DHCP服务器源码

5.2 Format

   The format of the authentication request in a DHCPDISCOVER message
   for protocol 1 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. |
   +-+-+-+-+-+-+-+-+


   The format of the authentication information for protocol 1 is:













Droms, Arbaugh                                                  [Page 6]

DRAFT               Authentication for DHCP Messages          March 2000


   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. | Secret ID (32 bits)                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | secret id cont| HMAC-MD5 (128 bits) ....
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   This document defines one technique for use with protocol 1, which is
   identified by setting the algorithm field to 1.  Other techniques
   that use different algorithms may be defined by future
   specifications, see section 6.  The following definitions will be
   used in the description of the authentication information for
   protocol 1, algorithm 1:

   Replay Detection       - as defined by the RDM field
   K                      - a secret value shared between the source and
                            destination of the message; each secret has a
                            unique identifier (not shown in figures)
   secret ID              - the unique identifier for the secret value
                            used to generate the MAC for this message
   HMAC-MD5               - the MAC generating function [3, 2].

   The sender computes the MAC using the HMAC generation algorithm [3]
   and the MD5 hash function [2].  The entire DHCP message (except as
   noted below), including the DHCP message header and the options
   field, is used as input to the HMAC-MD5 computation function.  The
   'secret ID' field MUST be set to the identifier of the secret used to
   generate the MAC.

   DISCUSSION:

      Algorithm 1 specifies the use of HMAC-MD5.  Use of a different
      technique, such as HMAC-SHA, will be specified as a separate
      protocol.

      Protocol 1 requires a shared secret key for each client on each
      DHCP server with which that client may wish to use the DHCP
      protocol.  Each secret key has a unique identifier that can be
      used by a receiver to determine which secret was used to generate
      the MAC in the DHCP message.  Therefore, protocol 1 may not scale
      well in an architecture in which a DHCP client connects to
      multiple administrative domains.



Droms, Arbaugh                                                  [Page 7]

DRAFT               Authentication for DHCP Messages          March 2000


      Note that the meaning of an authentication option can be changed
      by removing the secret ID, and MAC, transforming an authentication
      option with authentication information into a request for
      authentication.  Therefore, the authentication request form of
      this option can only appear in a DHCPDISCOVER message or a
      DHCPINFORM message.

5.3 Message validation

      To validate an incoming message, the receiver first checks that
      the value in the replay detection field is acceptable according to
      the replay detection method specified by the RDM field.  Next, the
      receiver computes the MAC as described in [3]. The receiver MUST
      set the 'MAC' field of the authentication option to all 0s for
      computation of the MAC, and 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 also be set to zero for the
      computation of the MAC. If the MAC computed by the receiver does
      not match the MAC contained in the authentication option, the
      receiver MUST discard the DHCP message.

      Section 3 provides additional information on handling messages
      that include option 82 (Relay Agents).

5.4 Key utilization

      Each DHCP client has a key, K.  The client uses its key to encode
      any messages it sends to the server and to authenticate and verify
      any messages it receives from the server.  The client's key SHOULD
      be initially distributed to the client through some out-of-band
      mechanism, and SHOULD be stored locally on the client for use in
      all authenticated DHCP messages.  Once the client has been given
      its key, it SHOULD use that key for all transactions even if the
      client's configuration changes; e.g., if the client is assigned a
      new network address.

      Each DHCP server MUST know, or be able to obtain in a secure
      manner, the keys for all authorized clients.  If all clients use
      the same key, clients can perform both entity and message
      authentication for all messages received from servers.  However,
      the sharing of keys is strongly discouraged as it allows for
      unauthorized clients to masquerade as authorized clients by
      obtaining a copy of the shared key. To authenticate the identity
      of individual clients, each client MUST be configured with a
      unique key.  Appendix A describes a technique for key management.

5.5 Client considerations




Droms, Arbaugh                                                  [Page 8]

DRAFT               Authentication for DHCP Messages          March 2000


      This section describes the behavior of a DHCP client using
      authentication protocol 1.

5.5.1 INIT state

      When in INIT state, the client uses protocol 1 as follows:

      1. The client MUST include the authentication request option in
         its DHCPDISCOVER message along with option 61 [6] to identify
         itself uniquely to the server.

      2. The client MUST validate any DHCPOFFER messages that include
         authentication information using the mechanism specified in
         section 5.3.  The client MUST discard any messages which fail
         to pass validation and MAY log the validation failure.  The
         client selects one DHCPOFFER message as its selected
         configuration.  If none of the DHCPOFFER messages received by
         the client include authentication information, the client MAY
         choose an unauthenticated message as its selected
         configuration.  The client SHOULD be configurable to accept or
         reject unauthenticated DHCPOFFER messages.
      3. The client replies with a DHCPREQUEST message that MUST include
         authentication information encoded with the same secret used by
         the server in the selected DHCPOFFER message.
      4. The client MUST validate the DHCPACK message from the server.
         The client MUST discard the DHCPACK if the message fails to
         pass validation and MAY log the validation failure.  If the
         DHCPACK fails to pass validation, the client MUST revert to
         INIT state and returns to step 1.  The client MAY choose to
         remember which server replied with a DHCPACK message that
         failed to pass validation and discard subsequent messages from
         that server.

5.5.2 INIT-REBOOT state

      When in INIT-REBOOT state, the client MUST use the secret it used
      in its DHCPREQUEST message to obtain its current configuration to
      generate authentication information for the DHCPREQUEST message.
      The client MAY choose to accept unauthenticated DHCPACK/DHCPNAK
      messages if no authenticated messages were received.  The client
      MUST treat the receipt (or lack thereof) of any DHCPACK/DHCPNAK
      messages as specified in section 3.2 of [1].

5.5.3 RENEWING state

      When in RENEWING state, the client uses the secret it used in its
      initial DHCPREQUEST message to obtain its current configuration to
      generate authentication information for the DHCPREQUEST message.



Droms, Arbaugh                                                  [Page 9]

DRAFT               Authentication for DHCP Messages          March 2000


      If client receives no DHCPACK messages or none of the DHCPACK
      messages pass validation, the client behaves as if it had not
      received a DHCPACK message in section 4.4.5 of the DHCP
      specification [1].

5.5.4 REBINDING state

      When in REBINDING state, the client uses the secret it used in its
      initial DHCPREQUEST message to obtain its current configuration to
      generate authentication information for the DHCPREQUEST message.
      If client receives no DHCPACK messages or none of the DHCPACK
      messages pass validation, the client behaves as if it had not
      received a DHCPACK message in section 4.4.5 of the DHCP
      specification [1].

5.5.5 DHCPINFORM message

      Since the client already has some configuration information, the
      client may also have established a shared secret value, K, with a
      server. Therefore, the client SHOULD use the authentication
      request as in a DHCPDISCOVER message when a shared secret value
      exists. The client MUST treat any received DHCPACK messages as it
      does DHCPOFFER messages, see section 5.5.1.

5.5.6 DHCPRELEASE message

      Since the client is already in the BOUND state, the client will
      have a security association already established with the server.
      Therefore, the client MUST include authentication information with
      the DHCPRELEASE message.

5.6 Server considerations

      This section describes the behavior of a server in response to
      client messages using authentication protocol 1.

5.6.1 General considerations

      Each server maintains a list of secrets and identifiers for those
      secrets that it shares with clients and potential clients.  This
      information must be maintained in such a way that the server can:

      * Identify an appropriate secret and the identifier for that
        secret for use with a client that the server may not have
        previously communicated with
      * Retrieve the secret and identifier used by a client to which the
        server has provided previous configuration information




Droms, Arbaugh                                                 [Page 10]

DRAFT               Authentication for DHCP Messages          March 2000


      Each server MUST save the counter from the previous authenticated
      message.  A server MUST discard any incoming message which fails
      the replay detection check as defined by the RDM avoid replay
      attacks.

      DISCUSSION:

         The authenticated DHCPREQUEST message from a client in INIT-
         REBOOT state can only be validated by servers that used the
         same secret in their DHCPOFFER messages.  Other servers will
         discard the DHCPREQUEST messages.  Thus, only servers that used
         the secret selected by the client will be able to determine
         that their offered configuration information was not selected
         and the offered network address can be returned to the server's
         pool of available addresses.  The servers that cannot validate
         the DHCPREQUEST message will eventually return their offered
         network addresses to their pool of available addresses as
         described in section 3.1 of the DHCP specification [1].

5.6.2 After receiving a DHCPDISCOVER message

      The server selects a secret for the client and includes
      authentication information in the DHCPOFFER message as specified
      in section 5, above. The server MUST record the identifier of the
      secret selected for the client and use that same secret for
      validating subsequent messages with the client.

5.6.3 After receiving a DHCPREQUEST message

      The server uses the secret identified in the message and validates
      the message as specified in section 5.3.  If the message fails to
      pass validation or the server does not know the secret identified
      by the 'secret ID' field, the server MUST discard the message and
      MAY choose to log the validation failure.

      If the message passes the validation procedure, the server