Network Working Group M. Stapp
Request for Comments: 4030 Cisco Systems, Inc.
Category: Standards Track T. Lemon
Nominum, Inc.
March 2005
Network Working Group M. Stapp
Request for Comments: 4030 Cisco Systems, Inc.
Category: Standards Track T. Lemon
Nominum, Inc.
March 2005
The Authentication Suboption for the Dynamic Host Configuration Protocol (DHCP) Relay Agent Option
动态主机配置协议（DHCP）中继代理选项的身份验证子选项
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.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
The Dynamic Host Configuration Protocol (DHCP) Relay Agent Information Option (RFC 3046) conveys information between a DHCP Relay Agent and a DHCP server. This specification defines an authentication suboption for that option, containing a keyed hash in its payload. The suboption supports data integrity and replay protection for relayed DHCP messages.
动态主机配置协议（DHCP）中继代理信息选项（RFC 3046）在DHCP中继代理和DHCP服务器之间传送信息。该规范为该选项定义了一个身份验证子选项，在其有效负载中包含一个键控哈希。子选项支持中继DHCP消息的数据完整性和重播保护。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 4
4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4
5. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5
6. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5
7. Computing Authentication Information . . . . . . . . . . . . 6
7.1. The HMAC-SHA1 Algorithm . . . . . . . . . . . . . . . 6
8. Procedures for Sending Messages . . . . . . . . . . . . . . 7
8.1. Replay Detection . . . . . . . . . . . . . . . . . . . 7
8.2. Packet Preparation . . . . . . . . . . . . . . . . . . 8
8.3. Checksum Computation . . . . . . . . . . . . . . . . . 8
8.4. Sending the Message . . . . . . . . . . . . . . . . . 8
9. Procedures for Processing Incoming Messages . . . . . . . . 8
9.1. Initial Examination . . . . . . . . . . . . . . . . . 8
9.2. Replay Detection Check . . . . . . . . . . . . . . . . 9
9.3. Testing the Checksum . . . . . . . . . . . . . . . . . 9
10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9
10.1. Receiving Messages from Other Relay Agents . . . . . . 10
10.2. Sending Messages to Servers . . . . . . . . . . . . . 10
10.3. Receiving Messages from Servers . . . . . . . . . . . 10
11. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10
11.1. Receiving Messages from Relay Agents . . . . . . . . . 10
11.2. Sending Reply Messages to Relay Agents . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . 11
13.1. The Key ID Field . . . . . . . . . . . . . . . . . . . 12
13.2. Protocol Vulnerabilities . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Terminology . . . . . . . . . . . . . . . . . . 3
3. DHCP Terminology . . . . . . . . . . . . . . . . . . . . . . 4
4. Suboption Format . . . . . . . . . . . . . . . . . . . . . . 4
5. Replay Detection . . . . . . . . . . . . . . . . . . . . . . 5
6. The Relay Identifier Field . . . . . . . . . . . . . . . . . 5
7. Computing Authentication Information . . . . . . . . . . . . 6
7.1. The HMAC-SHA1 Algorithm . . . . . . . . . . . . . . . 6
8. Procedures for Sending Messages . . . . . . . . . . . . . . 7
8.1. Replay Detection . . . . . . . . . . . . . . . . . . . 7
8.2. Packet Preparation . . . . . . . . . . . . . . . . . . 8
8.3. Checksum Computation . . . . . . . . . . . . . . . . . 8
8.4. Sending the Message . . . . . . . . . . . . . . . . . 8
9. Procedures for Processing Incoming Messages . . . . . . . . 8
9.1. Initial Examination . . . . . . . . . . . . . . . . . 8
9.2. Replay Detection Check . . . . . . . . . . . . . . . . 9
9.3. Testing the Checksum . . . . . . . . . . . . . . . . . 9
10. Relay Agent Behavior . . . . . . . . . . . . . . . . . . . . 9
10.1. Receiving Messages from Other Relay Agents . . . . . . 10
10.2. Sending Messages to Servers . . . . . . . . . . . . . 10
10.3. Receiving Messages from Servers . . . . . . . . . . . 10
11. DHCP Server Behavior . . . . . . . . . . . . . . . . . . . . 10
11.1. Receiving Messages from Relay Agents . . . . . . . . . 10
11.2. Sending Reply Messages to Relay Agents . . . . . . . . 11
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . 11
13. Security Considerations . . . . . . . . . . . . . . . . . . 11
13.1. The Key ID Field . . . . . . . . . . . . . . . . . . . 12
13.2. Protocol Vulnerabilities . . . . . . . . . . . . . . . 12
14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
15.1. Normative References . . . . . . . . . . . . . . . . . 13
15.2. Informative References . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 15
DHCP (RFC 2131 [6]) provides IP addresses and configuration information for IPv4 clients. It includes a relay-agent capability (RFC 951 [7], RFC 1542 [8]) in which processes within the network infrastructure receive broadcast messages from clients and forward them to servers as unicast messages. In network environments such as DOCSIS data-over-cable and xDSL, for example, it has proven useful for the relay agent to add information to the DHCP message before forwarding it, by using the relay-agent information option (RFC 3046 [1]). The kind of information that relays add is often used in the
DHCP（RFC 2131[6]）为IPv4客户端提供IP地址和配置信息。它包括中继代理功能（RFC 951[7]，RFC 1542[8]），其中网络基础设施内的进程从客户端接收广播消息，并将其作为单播消息转发给服务器。例如，在网络环境中，如电缆上的DOCSIS数据和xDSL，中继代理在转发DHCP消息之前，通过使用中继代理信息选项（RFC 3046[1]），向DHCP消息添加信息已被证明是有用的。继电器添加的信息类型通常用于
server's decision-making about the addresses and configuration parameters that the client should receive. The way that the relay-agent data is used in server decision-making tends to make that data very important, and it highlights the importance of the trust relationship between the relay agent and the server.
服务器关于客户端应接收的地址和配置参数的决策。中继代理数据在服务器决策中的使用方式往往使该数据变得非常重要，并突出了中继代理和服务器之间信任关系的重要性。
The existing DHCP Authentication specification (RFC 3118) [9] only covers communication between the DHCP client and server. Because relay-agent information is added after the client has sent its message, the DHCP Authentication specification explicitly excludes relay-agent data from that authentication.
现有的DHCP身份验证规范（RFC 3118）[9]仅涵盖DHCP客户端和服务器之间的通信。由于中继代理信息是在客户端发送其消息后添加的，因此DHCP身份验证规范明确将中继代理数据排除在该身份验证之外。
The goal of this specification is to define methods that a relay agent can use to
本规范的目标是定义中继代理可以用来
1. protect the integrity of relayed DHCP messages, 2. provide replay protection for those messages, and 3. leverage existing mechanisms, such as DHCP Authentication.
1. 保护中继DHCP消息的完整性，2。为这些消息提供重播保护，以及3。利用现有机制，如DHCP身份验证。
In order to meet these goals, we specify a new relay-agent suboption, the Authentication suboption. The format of this suboption is very similar to the format of the DHCP Authentication option, and the specification of its cryptographic methods and hash computation is also similar.
为了实现这些目标，我们指定了一个新的中继代理子选项，即身份验证子选项。此子选项的格式与DHCP身份验证选项的格式非常相似，其加密方法和哈希计算的规范也非常相似。
The Authentication suboption is included by relay agents that seek to ensure the integrity of the data they include in the Relay Agent option. These relay agents are configured with the parameters necessary for generating cryptographic checksums of the data in the DHCP messages that they forward to DHCP servers. A DHCP server configured to process the Authentication suboption uses the information in the suboption to verify the checksum in the suboption and continues processing the relay agent information option only if the checksum is valid. If the DHCP server sends a response, it includes an Authentication suboption in its response message. Relay agents test the checksums in DHCP server responses to decide whether to forward the responses.
中继代理包括身份验证子选项，这些中继代理试图确保其包含在中继代理选项中的数据的完整性。这些中继代理配置了生成转发到DHCP服务器的DHCP消息中数据的加密校验和所需的参数。配置为处理身份验证子选项的DHCP服务器使用子选项中的信息验证子选项中的校验和，并且仅当校验和有效时才继续处理中继代理信息选项。如果DHCP服务器发送响应，则在其响应消息中包含身份验证子选项。中继代理测试DHCP服务器响应中的校验和，以决定是否转发响应。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[2]中的说明进行解释。
This document uses the terms "DHCP server" (or "server") and "DHCP client" (or "client") as defined in RFC 2131 [6]. The term "DHCP relay agent" refers to a "BOOTP relay agent" as defined in RFC 2131.
本文件使用RFC 2131[6]中定义的术语“DHCP服务器”（或“服务器”）和“DHCP客户端”（或“客户端”）。术语“DHCP中继代理”指RFC 2131中定义的“BOOTP中继代理”。
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 | Algorithm | MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Authentication Information |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | Algorithm | MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Authentication Information |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The code for the suboption is 8. The length field includes the lengths of the algorithm, the RDM, and all subsequent suboption fields in octets.
子选项的代码是8。长度字段包括算法的长度、RDM和所有后续子选项字段（以八位字节为单位）。
The Algorithm field defines the algorithm used to generate the authentication information.
算法字段定义用于生成身份验证信息的算法。
Four bits are reserved for future use. These bits SHOULD be set to zero and MUST NOT be used when the suboption is processed.
保留四位供将来使用。这些位应设置为零，并且在处理子选项时不得使用。
The Replay Detection Method (RDM) field defines the method used to generate the Replay Detection Data.
重播检测方法（RDM）字段定义用于生成重播检测数据的方法。
The Replay Detection field contains a value used to detect replayed messages, which are interpreted according to the RDM.
重播检测字段包含用于检测重播消息的值，这些消息根据RDM进行解释。
The Relay Identifier field is used by relay agents that do not set giaddr, as described in RFC 3046 [1], section 2.1.
中继标识符字段由未设置giaddr的中继代理使用，如RFC 3046[1]第2.1节所述。
The Authentication Information field contains the data required to communicate algorithm-specific parameters, as well as the checksum. The checksum is usually a digest of the data in the DHCP packet computed by using the method specified by the Algorithm field.
身份验证信息字段包含通信算法特定参数所需的数据以及校验和。校验和通常是使用算法字段指定的方法计算的DHCP数据包中数据的摘要。
The replay-detection mechanism is designed on the notion that a receiver can determine whether a message has a valid replay token value. The default RDM, with value 1, specifies that the Replay Detection field contains an increasing counter value. The receiver associates a replay counter with each sender and rejects any message containing an authentication suboption with a Replay Detection counter value less than or equal to the last valid value. DHCP servers MAY identify relay agents by giaddr value or by other data in the message (e.g., data in other relay agent suboptions). Relay agents identify DHCP servers by source IP address. If the message's replay detection value, and the checksum are valid, the receiver updates its notion of the last valid replay counter value associated with the sender.
重播检测机制的设计理念是，接收方可以确定消息是否具有有效的重播令牌值。值为1的默认RDM指定Replay检测字段包含递增的计数器值。接收方将重播计数器与每个发送方关联，并拒绝包含重播检测计数器值小于或等于最后一个有效值的验证子选项的任何消息。DHCP服务器可以通过giaddr值或消息中的其他数据（例如，其他中继代理子选项中的数据）来识别中继代理。中继代理通过源IP地址标识DHCP服务器。如果消息的重播检测值和校验和有效，则接收方更新其与发送方关联的最后一个有效重播计数器值的概念。
All implementations MUST support the default RDM. Additional methods may be defined in the future, following the process described in section 12.
所有实现都必须支持默认RDM。以后可能会按照第12节中描述的过程定义其他方法。
Receivers SHOULD perform the replay-detection check before testing the checksum. The keyed hash calculation is likely to be much more expensive than the replay-detection value check.
接收机应在测试校验和之前执行回放检测检查。键控哈希计算可能比重播检测值检查昂贵得多。
DISCUSSION: This places a burden on the receiver to maintain some run-time state (the most-recent valid counter value) for each sender, but the number of members in a DHCP agent-server system is unlikely to be unmanageably large.
讨论：这给接收方带来了为每个发送方维护一些运行时状态（最新的有效计数器值）的负担，但DHCP代理服务器系统中的成员数量不太可能大到无法管理。
The Relay Agent Information Option [1] specification permits a relay agent to add a relay agent option to relayed messages without setting the giaddr field. In this case, the eventual receiver of the message needs a stable identifier to use in order to associate per-sender state such as Key ID and replay-detection counters.
中继代理信息选项[1]规范允许中继代理向中继消息添加中继代理选项，而无需设置giaddr字段。在这种情况下，消息的最终接收者需要使用一个稳定的标识符，以便关联每个发送者的状态，例如密钥ID和重播检测计数器。
A relay agent that adds a relay agent information option and sets giaddr MUST NOT set the Relay ID field. A relay agent that does not set giaddr MAY be configured to place a value in the Relay ID field. If the relay agent is configured to use the Relay ID field, it MAY be configured with a value to use, or it MAY be configured to generate a
添加中继代理信息选项并设置giaddr的中继代理不得设置中继ID字段。未设置giaddr的中继代理可以配置为在中继ID字段中放置一个值。如果中继代理配置为使用中继ID字段，则可以将其配置为要使用的值，也可以将其配置为生成
value based on some other data, such as its MAC or IP addresses. If a relay generates a Relay ID value, it SHOULD select a value that it can regenerate reliably; e.g., across reboots.
基于某些其他数据的值，例如其MAC或IP地址。如果继电器生成继电器ID值，则应选择一个能够可靠再生的值；e、 例如，跨重启。
Servers that process an Authentication Suboption SHOULD use the giaddr value to identify the sender if the giaddr field is set. Servers MAY be configured to use some other data in the message to identify the sender. If giaddr is not set, the server SHOULD use the Relay ID field if it is nonzero. If neither the giaddr nor the Relay ID field is set, the server MAY be configured to use some other data in the message, or it MAY increment an error counter.
如果设置了giaddr字段，则处理身份验证子选项的服务器应使用giaddr值来标识发送方。服务器可以配置为使用消息中的某些其他数据来标识发送者。如果未设置giaddr，则服务器应使用中继ID字段（如果该字段不为零）。如果既没有设置giaddr也没有设置中继ID字段，则服务器可以配置为使用消息中的某些其他数据，或者可能会增加错误计数器。
The Authentication Information field contains a keyed hash generated by the sender. All algorithms are defined to process the data in the DHCP messages in the same way. The sender and receiver compute a hash across a buffer containing all of the bytes in the DHCP message, including the fixed DHCP message header, the DHCP options, and the relay agent suboptions, with the following exceptions. The value of the 'hops' field MUST be set to zero for the computation because its value may be changed in transmission. The value of the 'giaddr' field MUST also be set to zero for the computation because it may be modified in networks where one relay agent adds the relay agent option but another relay agent sets 'giaddr' (see RFC 3046, section 2.1). In addition, because the relay agent option is itself included in the computation, the 'authentication information' field in the Authentication suboption is set to all zeros. The relay agent option length, the Authentication suboption length and other Authentication suboption fields are all included in the computation.
身份验证信息字段包含由发送方生成的密钥散列。所有算法都定义为以相同的方式处理DHCP消息中的数据。发送方和接收方跨包含DHCP消息中所有字节的缓冲区计算哈希，包括固定DHCP消息头、DHCP选项和中继代理子选项，但以下情况除外。计算时必须将“hops”字段的值设置为零，因为其值在传输过程中可能会发生变化。对于计算，“giaddr”字段的值也必须设置为零，因为在一个中继代理添加中继代理选项，而另一个中继代理设置“giaddr”的网络中，可能会对其进行修改（请参阅RFC 3046，第2.1节）。此外，由于中继代理选项本身包含在计算中，因此身份验证子选项中的“身份验证信息”字段设置为全零。中继代理选项长度、身份验证子选项长度和其他身份验证子选项字段都包含在计算中。
All implementations MUST support Algorithm 1, the HMAC-SHA1 algorithm. Additional algorithms may be defined in the future, following the process described in section 12.
所有实现都必须支持算法1，即HMAC-SHA1算法。按照第12节中描述的过程，将来可能会定义其他算法。
Algorithm 1 is assigned to the HMAC [3] protocol by using the SHA-1 [4] hash function. This algorithm requires that a shared secret key be configured at the relay agent and the DHCP server. A 32-bit Key Identifier is associated with each shared key, and this identifier is carried in the first 4 bytes of the Authentication Information field of the Authentication suboption. The HMAC-SHA1 computation generates a 20-byte hash value, which is placed in the Authentication Information field after the Key ID.
算法1通过使用SHA-1[4]散列函数分配给HMAC[3]协议。此算法要求在中继代理和DHCP服务器上配置共享密钥。32位密钥标识符与每个共享密钥相关联，并且该标识符携带在认证子选项的认证信息字段的前4个字节中。HMAC-SHA1计算生成一个20字节的散列值，该散列值位于密钥ID之后的身份验证信息字段中。
When Algorithm 1 is used, the format of the Authentication suboption is as follows:
使用算法1时，验证子选项的格式如下：
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 | 38 |0 0 0 0 0 0 0 1| MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-SHA1 (160 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | 38 |0 0 0 0 0 0 0 1| MBZ | RDM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection (64 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Replay Detection cont. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Relay Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key ID (32 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| HMAC-SHA1 (160 bits) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The suboption length is 38. The RDM and Replay Detection fields are as specified in section 5. The Relay ID field is set as specified in section 6. The Key ID is set by the sender to the ID of the key used in computing the checksum, as an integer value in network byte order. The HMAC result follows the Key ID.
子选项长度为38。RDM和Replay检测字段如第5节所述。按照第6节的规定设置继电器ID字段。密钥ID由发送方设置为用于计算校验和的密钥ID，作为网络字节顺序的整数值。HMAC结果位于密钥ID之后。
The Key ID exists only to allow the sender and receiver to specify a shared secret in cases where more than one secret is in use among a network's relays and DHCP servers. The Key ID values are entirely a matter of local configuration; they only have to be unique locally. This specification does not define any semantics or impose any requirements on this algorithm's Key ID values.
密钥ID的存在仅允许发送方和接收方在网络的中继和DHCP服务器之间使用多个密钥的情况下指定共享密钥。密钥ID值完全是本地配置的问题；它们只需要在本地是唯一的。本规范未定义任何语义，也未对该算法的密钥ID值提出任何要求。
The sender obtains a replay-detection counter value to use based on the RDM it is using. If the sender is using RDM 1, the default RDM, the value MUST be greater than any previously sent value.
发送方根据其使用的RDM获取要使用的重播检测计数器值。如果发送方使用RDM 1（默认RDM），则该值必须大于以前发送的任何值。
The sender sets the 'giaddr' field and the 'hops' field to all zeros. The sender appends the relay agent information option to the client's packet, including the Authentication suboption. The sender selects an appropriate Replay Detection value. The sender places its identifier into the Relay ID field, if necessary, or sets the field to all zeros. The sender sets the suboption length, places the Replay Detection value into the Replay Detection field of the suboption, and sets the algorithm to the algorithm number that it is using. If the sender is using HMAC-SHA1, it sets the Key ID field to the appropriate value. The sender sets the field that will contain the checksum to all zeros. Other algorithms may specify additional preparation steps.
发送方将“giaddr”字段和“hops”字段设置为全零。发送方将中继代理信息选项附加到客户端的数据包，包括身份验证子选项。发送方选择适当的重播检测值。如有必要，发送方将其标识符放入中继ID字段，或将该字段设置为全零。发送方设置子选项长度，将重播检测值放入子选项的重播检测字段，并将算法设置为其使用的算法编号。如果发送方使用HMAC-SHA1，它会将密钥ID字段设置为适当的值。发送方将包含校验和的字段设置为全零。其他算法可以指定额外的准备步骤。
The sender computes the checksum across the entire DHCP message, using the algorithm it has selected. The sender places the result of the computation into the Authentication Information field of the Authentication suboption.
发送方使用其选择的算法计算整个DHCP消息的校验和。发送方将计算结果放入“身份验证”子选项的“身份验证信息”字段中。
The sender restores the values of the 'hops' and 'giaddr' fields and sends the message.
发送方恢复“hops”和“giaddr”字段的值并发送消息。
The receiver examines the message for the value of the giaddr field and determines whether the packet includes the relay agent information option. The receiver uses its configuration to determine whether it should expect an Authentication suboption. The receiver MUST support a configuration that allows it to drop incoming messages that do not contain a valid relay agent information option and Authentication suboption.
接收器检查消息中giaddr字段的值，并确定数据包是否包含中继代理信息选项。接收方使用其配置来确定是否应预期身份验证子选项。接收器必须支持允许其丢弃不包含有效中继代理信息选项和身份验证子选项的传入消息的配置。
If the receiver determines that the Authentication suboption is present and that it should process the suboption, it uses the data in the message to determine which algorithm, key, and RDM to use in validating the message. If the receiver cannot determine which algorithm, key, and RDM to use, or if it does not support the value indicated in the message, it SHOULD drop the message. Because this situation could indicate a misconfiguration that could deny service to clients, receivers MAY attempt to notify their administrators or to log an error message.
如果接收方确定存在身份验证子选项并且应该处理该子选项，则它将使用消息中的数据来确定在验证消息时使用哪个算法、密钥和RDM。如果接收方无法确定使用哪种算法、密钥和RDM，或者不支持消息中指示的值，则应删除消息。因为这种情况可能表明配置错误，可能会拒绝向客户端提供服务，所以接收方可能会尝试通知其管理员或记录错误消息。
The receiver examines the RDM field. Receivers MUST discard messages containing RDM values that they do not support. Because this may indicate a misconfiguration at the sender, an attempt SHOULD be made to indicate this condition to the administrator by incrementing an error counter or writing a log message. If the receiver supports the RDM, it examines the value in the Replay Detection field by using the procedures in the RDM and in section 5. If the Replay value is not valid, the receiver MUST drop the message.
接收器检查RDM字段。接收者必须丢弃包含他们不支持的RDM值的消息。由于这可能表示发送方配置错误，因此应尝试通过增加错误计数器或写入日志消息向管理员指示此情况。如果接收器支持RDM，它将使用RDM和第5节中的过程检查Replay Detection字段中的值。如果重播值无效，则接收方必须丢弃消息。
Note that at this point the receiver MUST NOT update its notion of the last valid Replay Detection value for the sender. Until the checksum has been tested, the Replay Detection field cannot be trusted. If the receiver trusts the Replay Detection value without testing the checksum, a malicious host could send a replayed message with a Replay Detection value that was very high, tricking the receiver into rejecting legitimate values from the sender.
请注意，此时，接收方不得更新其对发送方的最后有效重播检测值的概念。在对校验和进行测试之前，无法信任Replay检测字段。如果接收方信任重播检测值而不测试校验和，则恶意主机可能发送重播检测值非常高的重播消息，从而诱使接收方拒绝发送方的合法值。
The receiver prepares the packet in order to test the checksum by setting the 'giaddr' and 'hops' fields to zero, and by setting the Authentication Information field of the suboption to all zeros. Using the algorithm and key associated with the sender, the receiver computes a hash of the message. The receiver compares the result of its computation with the value sent. If the checksums do not match, the receiver MUST drop the message. Otherwise, the receiver updates its notion of the last valid Replay Detection value associated with the sender and processes the message.
接收机通过将“giaddr”和“hops”字段设置为零，并将子选项的身份验证信息字段设置为全零，准备数据包以测试校验和。使用与发送方关联的算法和密钥，接收方计算消息的散列。接收器将其计算结果与发送的值进行比较。如果校验和不匹配，接收方必须删除消息。否则，接收方更新其与发送方关联的最后有效重播检测值的概念，并处理消息。
DHCP Relay agents are typically configured with the addresses of one or more DHCP servers. A relay agent that implements this suboption requires an algorithm number for each server, as well as appropriate credentials (i.e., keys). Relay implementations SHOULD support a configuration that indicates that all relayed messages should include the authentication suboption. Use of the authentication suboption SHOULD be disabled by default. Relay agents MAY support configuration that indicates that certain destination servers support the authentication suboption and that other servers do not. Relay agents MAY support configuration of a single algorithm number and key to be used with all DHCP servers, or they MAY support configuration of different algorithms and keys for each server.
DHCP中继代理通常配置有一个或多个DHCP服务器的地址。实现此子选项的中继代理需要每个服务器的算法编号以及适当的凭据（即密钥）。中继实现应支持一种配置，该配置指示所有中继消息应包括身份验证子选项。默认情况下，应禁用“身份验证”子选项的使用。中继代理可能支持指示某些目标服务器支持身份验证子选项而其他服务器不支持的配置。中继代理可以支持配置用于所有DHCP服务器的单个算法编号和密钥，也可以支持为每个服务器配置不同的算法和密钥。
There are network configurations in which one relay agent adds the relay agent option and then forwards the DHCP message to another relay agent. For example, a layer-2 switch might be directly connected to a client, and it might forward messages to an aggregating router, which sets giaddr and then forwards the message to a DHCP server. When a DHCP relay that implements the Authentication suboption receives a message, it MAY use the procedures in section 9 to verify the source of the message before forwarding it.
有一些网络配置，其中一个中继代理添加中继代理选项，然后将DHCP消息转发给另一个中继代理。例如，第2层交换机可能直接连接到客户端，它可能将消息转发到聚合路由器，聚合路由器设置giaddr，然后将消息转发到DHCP服务器。当实现认证子选项的DHCP中继接收到消息时，它可以使用第9节中的过程在转发消息之前验证消息源。
When the relay agent receives a broadcast packet from a client, it determines which DHCP servers (or other relay agents) should receive copies of the message. If the relay agent is configured to include the Authentication suboption, it determines which Algorithm and RDM to use, and then it performs the steps in section 8.
当中继代理从客户端接收广播数据包时，它确定哪些DHCP服务器（或其他中继代理）应接收消息副本。如果中继代理被配置为包含身份验证子选项，它将确定要使用的算法和RDM，然后执行第8节中的步骤。
When the relay agent receives a message, it determines from its configuration whether it expects the message to contain a relay agent information option and an Authentication suboption. The relay agent MAY be configured to drop response messages that do not contain the Authentication suboption. The relay agent then follows the procedures in section 9.
当中继代理接收到消息时，它根据其配置确定是否希望消息包含中继代理信息选项和身份验证子选项。中继代理可以配置为丢弃不包含认证子选项的响应消息。中继代理随后遵循第9节中的程序。
DHCP servers may interact with multiple relay agents. Server implementations MAY support a configuration that associates the same algorithm and key with all relay agents. Servers MAY support a configuration that specifies the algorithm and key to use with each relay agent individually.
DHCP服务器可以与多个中继代理交互。服务器实现可能支持将同一算法和密钥与所有中继代理关联的配置。服务器可能支持一种配置，该配置指定要单独与每个中继代理一起使用的算法和密钥。
When a DHCP server that implements the Authentication suboption receives a message, it performs the steps in section 9.
当实现身份验证子选项的DHCP服务器收到消息时，它将执行第9节中的步骤。
When the server has prepared a reply message, it uses the incoming request message and its configuration to determine whether it should include a relay agent information option and an Authentication suboption. If the server is configured to include the Authentication suboption, it determines which Algorithm and RDM to use and then performs the steps in section 8.
当服务器准备好回复消息时，它将使用传入的请求消息及其配置来确定是否应包括中继代理信息选项和身份验证子选项。如果服务器配置为包含身份验证子选项，它将确定要使用的算法和RDM，然后执行第8节中的步骤。
DISCUSSION: This server behavior represents a slight variance from RFC 3046 [1], section 2.2. The Authentication suboption is not echoed back from the server to the relay; the server generates its own suboption.
讨论：此服务器行为与RFC 3046[1]第2.2节略有不同。认证子选项不会从服务器回显到中继；服务器生成自己的子选项。
Section 4 defines a new suboption for the DHCP relay agent option called the Authentication Suboption. IANA has allocated a new suboption code from the relay agent option suboption number space.
第4节为DHCP中继代理选项定义了一个新的子选项，称为身份验证子选项。IANA已从中继代理选项子选项编号空间分配了新的子选项代码。
This specification introduces two new number spaces for the Authentication suboption's 'Algorithm' and 'Replay Detection Method' fields. These number spaces have been created and will be maintained by IANA.
本规范为认证子选项的“算法”和“重播检测方法”字段引入了两个新的数字空间。这些数字空间已创建，将由IANA维护。
The Algorithm identifier is a one-byte value. The Algorithm value 0 is reserved. The Algorithm value 1 is assigned to the HMAC-SHA1 keyed hash, as defined in section 7.1. Additional algorithm values will be allocated and assigned through IETF consensus, as defined in RFC 2434 [5].
算法标识符是一个单字节值。保留算法值0。算法值1分配给HMAC-SHA1键控哈希，如第7.1节所定义。根据RFC 2434[5]中的定义，额外的算法值将通过IETF共识进行分配和分配。
The RDM identifier is a four-bit value. The RDM value 0 is reserved. The RDM value 1 is assigned to the use of a monotonically increasing counter value, as defined in section 5. Additional RDM values will be allocated and assigned through IETF consensus, as defined in RFC 2434 [5].
RDM标识符是一个四位值。保留RDM值0。RDM值1指定用于使用单调递增的计数器值，如第5节所定义。按照RFC 2434[5]中的定义，额外的RDM值将通过IETF共识进行分配和分配。
This specification describes a protocol that adds source authentication and message integrity protection to the messages between DHCP relay agents and DHCP servers.
本规范描述了一种协议，该协议为DHCP中继代理和DHCP服务器之间的消息添加源身份验证和消息完整性保护。
The use of this protocol imposes a new computational burden on relay agents and servers, because they must perform cryptographic hash calculations when they send and receive messages. This burden may add latency to DHCP message exchanges. Because relay agents are
此协议的使用给中继代理和服务器带来了新的计算负担，因为它们在发送和接收消息时必须执行加密哈希计算。这种负担可能会增加DHCP消息交换的延迟。因为中继代理是
involved when clients reboot, periods of very high reboot activity will result in the largest number of messages that have to be processed. During a cable MSO head-end reboot event, for example, the time required for all clients to be served may increase.
当客户端重新启动时，非常高的重新启动活动周期将导致必须处理的消息数量最大。例如，在电缆MSO前端重新启动事件期间，为所有客户端提供服务所需的时间可能会增加。
The Authentication suboption contains a four-byte Key ID, following the example of the DHCP Authentication RFC. Other authentication protocols, such as DNS TSIG [10], use a key name. A key name is more flexible and potentially more human readable than a key id. DHCP servers may well be configured to use key names for DNS updates using TSIG, so it might simplify DHCP server configuration if some of the key management for both protocols could be shared.
身份验证子选项包含一个四字节密钥ID，如下DHCP身份验证RFC示例所示。其他身份验证协议（如DNS TSIG[10]）使用密钥名。密钥名称比密钥id更灵活，并且可能更容易被人读取。DHCP服务器可以很好地配置为使用TSIG使用密钥名称进行DNS更新，因此，如果两个协议的某些密钥管理可以共享，则可能会简化DHCP服务器配置。
On the other hand, it is crucial to minimize the size expansion caused by the introduction of the relay agent information option. Named keys would require more physical space and would entail more complex suboption encoding and parsing implementations. These considerations have led us to specify a fixed-length Key ID instead of a variable-length key name.
另一方面，将引入中继代理信息选项导致的大小扩展降至最低至关重要。命名密钥需要更多的物理空间，并且需要更复杂的子选项编码和解析实现。这些考虑导致我们指定一个固定长度的键ID，而不是可变长度的键名。
Because DHCP is a UDP protocol, messages between relays and servers may be delivered in an order different from that in which they were generated. The replay-detection mechanism will cause receivers to drop packets that are delivered 'late', leading to client retries. The retry mechanisms that most clients implement should not cause this to be an enormous issue, but it will cause senders to do computational work which will be wasted if their messages are re-ordered.
由于DHCP是一种UDP协议，中继和服务器之间的消息传递顺序可能与生成它们的顺序不同。重播检测机制将导致接收器丢弃“延迟”交付的数据包，从而导致客户端重试。大多数客户端实现的重试机制不应该导致这一问题，但它会导致发送者进行计算工作，如果消息被重新排序，这些工作将被浪费。
The DHC WG has developed two documents describing authentication of DHCP relay agent options to accommodate the requirements of different deployment scenarios: this document and "Authentication of Relay Agent Options Using IPsec" [11]. As we note in section 11, the Authentication suboption can be used without pairwise keys between each relay and each DHCP server. In deployments where IPsec is readily available and pairwise keys can be managed efficiently, the use of IPsec as described in that document may be appropriate. If IPsec is not available or there are multiple relay agents for which multiple keys must be managed, the protocol described in this document may be appropriate. As is the case whenever two alternatives are available, local network administration can choose whichever is more appropriate. Because the relay agents and the DHCP
DHC工作组开发了两份文档，描述了DHCP中继代理选项的身份验证，以适应不同部署场景的要求：本文档和“使用IPsec对中继代理选项进行身份验证”[11]。正如我们在第11节中所注意到的，可以在每个中继和每个DHCP服务器之间不使用成对密钥的情况下使用身份验证子选项。在IPsec随时可用且可以有效管理成对密钥的部署中，使用该文档中描述的IPsec可能是合适的。如果IPsec不可用或存在多个中继代理，必须为其管理多个密钥，则本文档中描述的协议可能适用。无论何时只要有两个备选方案，本地网络管理部门都可以选择更合适的方案。因为中继代理和DHCP
server are all in the same administrative domain, the appropriate mechanism can be configured on all interoperating DHCP server elements.
服务器都在同一管理域中，可以在所有互操作的DHCP服务器元素上配置适当的机制。
The need for this specification was made clear by comments made by Thomas Narten and John Schnizlein, and the use of the DHCP Authentication option format was suggested by Josh Littlefield, at IETF 53.
Thomas Narten和John Schnizlein的评论明确了本规范的必要性，Josh Littlefield在IETF 53上建议使用DHCP身份验证选项格式。
[1] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, January 2001.
[1] Patrick，M.，“DHCP中继代理信息选项”，RFC 3046，2001年1月。
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[3] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[3] Krawczyk，H.，Bellare，M.和R.Canetti，“HMAC：用于消息身份验证的键控哈希”，RFC 2104，1997年2月。
[4] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[4] Eastlake 3rd，D.和P.Jones，“美国安全哈希算法1（SHA1）”，RFC 31742001年9月。
[5] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[5] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[6] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.
[6] Droms，R.，“动态主机配置协议”，RFC 2131，1997年3月。
[7] Croft, W. and J. Gilmore, "Bootstrap Protocol", RFC 951, September 1985.
[7] Croft，W.和J.Gilmore，“引导协议”，RFC 9511985年9月。
[8] Wimer, W., "Clarifications and Extensions for the Bootstrap Protocol", RFC 1542, October 1993.
[8] Wimer，W.“引导协议的澄清和扩展”，RFC 1542，1993年10月。
[9] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", RFC 3118, June 2001.
[9] Droms，R.和W.Arbaugh，“DHCP消息的身份验证”，RFC31182001年6月。
[10] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. Wellington, "Secret Key Transaction Authentication for DNS (TSIG)", RFC 2845, May 2000.
[10] Vixie，P.，Gudmundsson，O.，Eastlake 3rd，D.，和B.Wellington，“DNS秘密密钥交易认证（TSIG）”，RFC 28452000年5月。
[11] Droms, R., "Authentication of Relay Agent Options Using IPsec", Work in Progress, February 2004.
[11] Droms，R.，“使用IPsec认证中继代理选项”，正在进行的工作，2004年2月。
Authors' Addresses
作者地址
Mark Stapp Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
Mark Stapp Cisco Systems，Inc.美国马萨诸塞州Boxborough大道1414号，邮编01719
Phone: 978.936.0000 EMail: mjs@cisco.com
电话：978.936.0000电子邮件：mjs@cisco.com
Ted Lemon Nominum, Inc. 950 Charter St. Redwood City, CA 94063 USA
Ted Lemon Nominum，Inc.美国加利福尼亚州红杉市特许街950号，邮编94063
EMail: Ted.Lemon@nominum.com
EMail: Ted.Lemon@nominum.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。