20. Authentication of DHCP Messages
This section preserves the RFC text for DHCPv6, including message exchanges, relay behavior, DUIDs, IA_NA, IA_TA, IA_PD, DHCP options, RKAP authentication, IANA registries, normative requirements, and appendix option-appearance matrices.
Original RFC Text
20. Authentication of DHCP Messages
This document defines two security mechanisms for the authentication
of DHCP messages: (1) authentication (and encryption) of messages
sent between servers and relay agents using IPsec and (2) protection
against misconfiguration of a client caused by a Reconfigure message
sent by a malicious DHCP server.
20.1. Security of Messages Sent Between Servers and Relay Agents
Relay agents and servers that exchange messages can use IPsec as
detailed in [RFC8213].
20.2. Summary of DHCP Authentication
Authentication of DHCP messages is accomplished through the use of
the Authentication option (see Section 21.11). The authentication
information carried in the Authentication option can be used to
reliably identify the source of a DHCP message and to confirm that
the contents of the DHCP message have not been tampered with.
The Authentication option provides a framework for multiple
authentication protocols. One such protocol, RKAP, is defined in
Section 20.4. Other protocols defined in the future will be
specified in separate documents.
Any DHCP message MUST NOT include more than one Authentication
option.
The protocol field in the Authentication option identifies the
specific protocol used to generate the authentication information
carried in the option. The algorithm field identifies a specific
algorithm within the authentication protocol; for example, the
algorithm field specifies the hash algorithm used to generate the
Message Authentication Code (MAC) in the Authentication option. The
RDM field specifies the type of replay detection used in the replay
detection field.
20.3. Replay Detection
The RDM field of the Authentication option (see Section 21.11)
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 strictly monotonically increasing 64-bit
unsigned integer (modulo 2^64). Using this technique can reduce the
danger of replay attacks. This method MUST be supported by all
Authentication option protocols. One choice might be to use the
64-bit NTP timestamp format [RFC5905]).
A client that receives a message with the RDM field set to 0x00 MUST
compare its replay detection field with the previous value sent by
that same server (based on the Server Identifier option; see
Section 21.3) and only accept the message if the received value is
greater and record this as the new value. If this is the first time
a client processes an Authentication option sent by a server, the
client MUST record the replay detection value and skip the replay
detection check.
Servers that support the reconfigure mechanism MUST ensure that the
replay detection value is retained between restarts. Failing to do
so may cause clients to refuse Reconfigure messages sent by the
server, effectively rendering the reconfigure mechanism useless.
20.4. Reconfiguration Key Authentication Protocol (RKAP)
RKAP provides protection against misconfiguration of a client caused
by a Reconfigure message sent by a malicious DHCP server. In this
protocol, a DHCP server sends a reconfigure key to the client in the
initial exchange of DHCP messages. The client records the
reconfigure key for use in authenticating subsequent Reconfigure
messages from that server. The server then includes a Hashed Message
Authentication Code (HMAC) computed from the reconfigure key in
subsequent Reconfigure messages.
Both the reconfigure key sent from the server to the client and the
HMAC in subsequent Reconfigure messages are carried as the
authentication information in an Authentication option (see
Section 21.11). The format of the authentication information is
defined in the following section.
RKAP is used (initiated by the server) only if the client and server
have negotiated to use Reconfigure messages.
20.4.1. Use of the Authentication Option in RKAP
The following fields are set in an Authentication option (see
Section 21.11) for RKAP:
* protocol: 3
* algorithm: 1
* RDM: 0
The format of the authentication information for RKAP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Value (128 bits) |
+-+-+-+-+-+-+-+-+ |
. .
. .
. +-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: RKAP Authentication Information
Type: Type of data in the Value field carried in this option:
1 Reconfigure key value (used in the Reply message).
2 HMAC-MD5 digest of the message (used in the Reconfigure
message).
A 1-octet field.
Value: Data as defined by the Type field. A 16-octet field.
20.4.2. Server Considerations for RKAP
The server selects a reconfigure key for a client during the Request/
Reply, Solicit/Reply, or Information-request/Reply message exchange.
The server records the reconfigure key and transmits that key to the
client in an Authentication option (see Section 21.11) in the Reply
message.
The reconfigure key is 128 bits long and MUST be a cryptographically
strong random or pseudorandom number that cannot easily be predicted.
To provide authentication for a Reconfigure message, the server
selects a replay detection value according to the RDM selected by the
server and computes an HMAC-MD5 of the Reconfigure message using the
reconfigure key for the client. The server computes the HMAC-MD5
over the entire DHCP Reconfigure message, including the
Authentication option; the HMAC-MD5 field in the Authentication
option is set to 0 for the HMAC-MD5 computation. The server includes
the HMAC-MD5 in the authentication information field in an
Authentication option included in the Reconfigure message sent to the
client.
20.4.3. Client Considerations for RKAP
The client will receive a reconfigure key from the server in an
Authentication option (see Section 21.11) in the initial Reply
message from the server. The client records the reconfigure key for
use in authenticating subsequent Reconfigure messages.
To authenticate a Reconfigure message, the client computes an HMAC-
MD5 over the Reconfigure message, with zeroes substituted for the
HMAC-MD5 field, using the reconfigure key received from the server.
If this computed HMAC-MD5 matches the value in the Authentication
option, the client accepts the Reconfigure message.