跳到主要内容

21. DHCP 消息认证 (Authentication of DHCP Messages)

一些网络管理员可能希望对 DHCP 消息的来源和内容进行认证. 例如, 客户端可能因伪造的 DHCP 服务器而遭受拒绝服务攻击, 或者可能因无意中启动的 DHCP 服务器而被错误配置. 在网络介质没有物理安全保护的 "敌对" 环境中, 如无线网络或大学宿舍, 网络管理员可能希望将地址分配限制给授权主机, 以避免拒绝服务攻击.

DHCP 认证机制基于 DHCPv4 认证的设计 [4].

21.1. 服务器与中继代理之间发送消息的安全性 (Security of Messages Sent Between Servers and Relay Agents)​

以安全方式交换消息的中继代理和服务器使用 IPv6 的 IPsec 机制 [7]. 如果客户端消息经过多个中继代理转发, 每个中继代理都必须建立独立的成对信任关系. 也就是说, 如果来自客户端 C 的消息将由中继代理 A 转发到中继代理 B, 再转发到服务器, 则必须将中继代理 A 和 B 配置为对它们交换的消息使用 IPSec, 并且必须将中继代理 B 和服务器配置为对它们交换的消息使用 IPSec.

支持安全的中继代理到服务器通信或中继代理到中继代理通信的中继代理和服务器, 在以下条件下使用 IPsec:

Selectors : 中继代理被手工配置为具有 DHCP 消息要转发到的中继代理或服务器地址. 每个将使用 IPsec 保护 DHCP 消息的中继代理和服务器, 还必须配置一个消息将返回到的中继代理列表. 中继代理和服务器的 selectors 是在 DHCPv6 UDP 端口 546 和 547 上交换 DHCP 消息的中继代理和服务器地址对.

Mode : 中继代理和服务器使用 transport mode 和 ESP. DHCP 消息中的信息通常不被认为是机密的, 因此不必使用加密 (即, 可以使用 NULL encryption).

Key management : 因为中继代理和服务器在一个组织内部使用, 所以不需要公钥方案. 因为中继代理和服务器必须手工配置, 手工配置的密钥管理可能已经足够, 但它不能防御重放消息. 因此, SHOULD 支持带预共享秘密的 IKE. MAY 支持带公钥的 IKE.

Security policy : 中继代理和服务器之间的 DHCP 消息只应从本地配置中标识的 DHCP 对等体接收.

Authentication : 在此应用中, 以接收 DHCP 消息的源 IP 地址为索引的共享密钥已经足够.

Availability : 对于服务器以及企业和核心 ISP 网络中功能较完整设备上的中继代理, 很可能有适当的 IPsec 实现可用. 对于主要用于家庭或小型办公室市场的低端设备中的中继代理, IPsec 可用的可能性较低.

21.2. DHCP 认证概要 (Summary of DHCP Authentication)​

DHCP 消息认证通过使用 Authentication option (见第 22.11 节) 完成. Authentication option 中携带的认证信息可用于可靠地标识 DHCP 消息来源, 并确认 DHCP 消息内容没有被篡改.

Authentication option 为多种认证协议提供框架. 本文定义了其中两种协议. 未来定义的其他协议将在独立文档中规定.

任何 DHCP 消息 MUST NOT 包含多个 Authentication option.

Authentication option 中的 protocol 字段标识用于生成该选项所携带认证信息的具体协议. algorithm 字段标识认证协议内的具体算法; 例如, algorithm 字段指定用于在 authentication option 中生成 message authentication code (MAC) 的哈希算法. replay detection method (RDM) 字段指定 replay detection 字段中使用的重放检测类型.

21.3. 重放检测 (Replay Detection)​

Replay Detection Method (RDM) 字段决定 Replay Detection 字段中使用的重放检测类型.

如果 RDM 字段包含 0x00, replay detection 字段 MUST 被设置为单调递增计数器的值. 使用计数器值, 如当前日间时间 (例如, NTP 格式时间戳 [9]), 可以降低重放攻击的危险. 所有协议 MUST 支持此方法.

21.4. 延迟认证协议 (Delayed Authentication Protocol)​

如果 protocol 字段为 2, 消息使用 "delayed authentication" 机制. 在 delayed authentication 中, 客户端在其 Solicit 消息中请求认证, 服务器以包含认证信息的 Advertise 消息响应. 此认证信息包含由来源生成的 nonce 值, 作为 message authentication code (MAC), 用于提供消息认证和实体认证.

本文定义了一种具体技术, 该技术基于 HMAC 协议 [8] 并使用 MD5 哈希 [16].

21.4.1. Delayed Authentication Protocol 中 Authentication Option 的使用​

在 Solicit 消息中, 客户端按其偏好填写 Authentication option 中的 protocol, algorithm 和 RDM 字段. 客户端将 replay detection 字段设置为零, 并省略 authentication information 字段. 客户端将 option-len 字段设置为 11.

在所有其他消息中, protocol 和 algorithm 字段标识用于构造 authentication information 字段内容的方法. RDM 字段标识用于构造 replay detection 字段内容的方法.

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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                          DHCP realm                           |
 |                      (variable length)                        |
 .                                                               .
 .                                                               .
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                            key ID                             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                                                               |
 |                           HMAC-MD5                            |
 |                          (128 bits)                           |
 |                                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

DHCP realm : 标识用于生成 HMAC-MD5 值的密钥的 DHCP realm.

key ID : 标识用于生成 HMAC-MD5 值的密钥的 key identifier.

HMAC-MD5 : 使用由 DHCP realm, client DUID 和 key ID 标识的密钥, 对 DHCP 消息应用 MD5 后生成的 message authentication code.

发送方使用 HMAC 生成算法 [8] 和 MD5 哈希函数 [16] 计算 MAC. 整个 DHCP 消息 (将 authentication option 的 MAC 字段设置为零), 包括 DHCP 消息头和 options 字段, 都作为 HMAC-MD5 计算函数的输入.

DISCUSSION:

Algorithm 1 指定使用 HMAC-MD5. 使用不同技术, 如 HMAC-SHA, 将作为独立协议另行规定.

用于标识认证密钥的 DHCP realm 被选择为在管理域之间唯一. 使用 DHCP realm 可让 DHCP 管理员避免 key identifier 使用上的冲突, 并允许使用 DHCP 的主机在 DHCP 管理域之间漫游时使用经过认证的 DHCP.

21.4.2. 消息验证 (Message Validation)​

任何包含多个 authentication option 的 DHCP 消息 MUST 被丢弃.

为了验证传入消息, 接收方首先检查 replay detection 字段中的值根据 RDM 字段指定的 replay detection method 是否可接受. 然后, 接收方按 [8] 所述计算 MAC. 整个 DHCP 消息 (将 authentication option 的 MAC 字段设置为 0) 都作为 HMAC-MD5 计算函数的输入. 如果接收方计算出的 MAC 与 authentication option 中包含的 MAC 不匹配, 接收方 MUST 丢弃该 DHCP 消息.

21.4.3. 密钥使用 (Key Utilization)​

每个 DHCP 客户端都有一组密钥. 每个密钥由 <DHCP realm, client DUID, key id> 标识. 每个密钥还有一个 lifetime. 密钥不得在其 lifetime 结束后使用. 客户端的密钥最初通过某种带外机制分发给客户端. 每个密钥的 lifetime 随密钥一起分发. 密钥分发和 lifetime 指定机制超出本文档范围.

客户端和服务器在一个会话期间 (直到客户端发送下一条 Solicit 消息为止) 使用客户端密钥之一来认证 DHCP 消息.

21.4.4. Delayed Authentication Protocol 的客户端考虑事项​

客户端通过在其 Solicit 消息中包含 Authentication option 来声明其使用 DHCP 认证的意图. 服务器基于客户端的 DUID 为客户端选择一个密钥. 客户端和服务器使用该密钥认证会话期间交换的所有 DHCP 消息.

21.4.4.1. 发送 Solicit 消息​

当客户端发送 Solicit 消息并希望使用认证时, 它包含一个 Authentication option, 其中带有所需的 protocol, algorithm 和 RDM, 如第 21.4 节所述. 客户端不在 Authentication option 中包含任何 replay detection 或 authentication information.

21.4.4.2. 接收 Advertise 消息​

客户端使用第 21.4.2 节所述的验证测试, 验证任何包含 Authentication option 且该 option 指定 delayed authentication protocol 的 Advertise 消息.

如果没有 Advertise 消息包含认证信息或通过验证测试, 客户端行为由客户端上的本地策略控制. 根据客户端策略, 客户端 MAY 选择响应一条未认证的 Advertise 消息.

设置本地策略以接受未认证消息的决定应谨慎作出. 接受未认证的 Advertise 消息可能使客户端易受欺骗和其他攻击. 如果未明确告知本地用户客户端已接受未认证的 Advertise 消息, 用户可能会错误地认为客户端已收到经过认证的地址, 且不会受到通过未认证消息发起的 DHCP 攻击.

客户端 MUST 可配置为丢弃未认证消息, 并且如果客户端已配置认证密钥或其他认证信息, SHOULD 默认配置为丢弃未认证消息. 客户端 MAY 选择区分没有认证信息的 Advertise 消息和未通过验证测试的 Advertise 消息; 例如, 客户端可能接受前者并丢弃后者. 如果客户端确实接受未认证消息, 客户端 SHOULD 通知任何本地用户, 并 SHOULD 记录该事件.

21.4.4.3. 发送 Request, Confirm, Renew, Rebind, Decline 或 Release 消息​

如果客户端认证了其选择服务器所依据的 Advertise 消息, 客户端 MUST 按第 21.4 节所述, 为随后发送给服务器的 Request, Confirm, Renew, Rebind 或 Release 消息生成认证信息. 当客户端发送后续消息时, 它 MUST 使用服务器用于生成认证信息的同一密钥.

21.4.4.4. 发送 Information-request 消息​

如果服务器已在先前消息交换中为客户端选择密钥 (见第 21.4.5.1 节), 客户端 MUST 在整个会话中使用同一密钥生成认证信息.

21.4.4.5. 接收 Reply 消息​

如果客户端认证了其接受的 Advertise, 客户端 MUST 验证来自服务器的关联 Reply 消息. 如果消息未能通过验证测试, 客户端 MUST 丢弃 Reply, 并 MAY 记录验证失败. 如果 Reply 未能通过验证测试, 客户端 MUST 通过发送 Solicit 消息重新启动 DHCP 配置过程.

如果客户端接受了不包含认证信息或未通过验证测试的 Advertise 消息, 客户端 MAY 接受来自服务器的未认证 Reply 消息.

21.4.4.6. 接收 Reconfigure 消息​

如果 Reconfigure 消息未能通过验证测试, 客户端 MUST 丢弃该 Reconfigure, 并 MAY 记录验证失败.

21.4.5. Delayed Authentication Protocol 的服务器考虑事项​

在收到包含 Authentication option 的 Solicit 消息后, 服务器基于客户端的 DUID 以及服务器配置的密钥选择策略, 为客户端选择一个密钥. 服务器在 Advertise 消息中标识所选密钥, 并使用该密钥验证客户端和服务器之间的后续消息.

21.4.5.1. 接收 Solicit 消息并发送 Advertise 消息​

服务器为客户端选择一个密钥, 并按第 21.4 节规定, 在返回给客户端的 Advertise 消息中包含认证信息. 服务器 MUST 记录为客户端选择的密钥的标识符, 并使用同一密钥验证与客户端的后续消息.

21.4.5.2. 接收 Request, Confirm, Renew, Rebind 或 Release 消息并发送 Reply 消息​

服务器使用消息中标识的密钥, 并按第 21.4.2 节规定验证消息. 如果消息未能通过验证测试, 或服务器不知道由 'key ID' 字段标识的密钥, 服务器 MUST 丢弃该消息, 并 MAY 选择记录验证失败.

如果消息通过验证测试, 服务器按第 18.2 节所述响应具体消息. 服务器 MUST 包含使用接收消息中标识的密钥生成的认证信息, 如第 21.4 节规定.

21.5. Reconfigure Key 认证协议 (Reconfigure Key Authentication Protocol)​

Reconfigure key authentication protocol 用于防止恶意 DHCP 服务器发送 Reconfigure 消息而导致客户端错误配置. 在此协议中, DHCP 服务器在 DHCP 消息的初始交换中向客户端发送 Reconfigure Key. 客户端记录 Reconfigure Key, 用于认证随后来自该服务器的 Reconfigure 消息. 然后服务器在后续 Reconfigure 消息中包含根据 Reconfigure Key 计算出的 HMAC.

从服务器发送给客户端的 Reconfigure Key 以及后续 Reconfigure 消息中的 HMAC, 都作为 Authentication option 中的 Authentication information 携带. Authentication information 的格式在下一节中定义.

仅当客户端和服务器未使用任何其他认证协议, 且客户端和服务器已协商使用 Reconfigure 消息时, 才使用 (由服务器发起) Reconfigure Key protocol.

21.5.1. Reconfigure Key Authentication Protocol 中 Authentication Option 的使用​

Reconfigure Key Authentication Protocol 的 Authentication option 中设置以下字段:

protocol : 3

algorithm : 1

RDM : 0

Reconfigure Key Authentication Protocol 的 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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |                 Value (128 bits)              |
 +-+-+-+-+-+-+-+-+                                               |
 .                                                               .
 .                                                               .
 .                                               +-+-+-+-+-+-+-+-+
 |                                               |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type : 此 option 中携带的 Value 字段中的数据类型:

  1
  : Reconfigure Key value (用于 Reply 消息).

  2
  : 消息的 HMAC-MD5 digest (用于 Reconfigure 消息).

Value : 由字段定义的数据.

21.5.2. Reconfigure Key protocol 的服务器考虑事项​

服务器在 Request/Reply, Solicit/Reply 或 Information-request/Reply 消息交换期间为客户端选择 Reconfigure Key. 服务器记录 Reconfigure Key, 并在 Reply 消息中的 Authentication option 内将该密钥传输给客户端.

Reconfigure Key 长度为 128 bits, 并且 MUST 是加密强度高的随机数或伪随机数, 不易被预测.

为了给 Reconfigure 消息提供认证, 服务器根据其选择的 RDM 选择 replay detection 值, 并使用客户端的 Reconfigure Key 计算 Reconfigure 消息的 HMAC-MD5. 服务器对整个 DHCP Reconfigure 消息计算 HMAC-MD5, 包括 Authentication option; 在 HMAC-MD5 计算中, Authentication option 中的 HMAC-MD5 字段设置为零. 服务器在发送给客户端的 Reconfigure 消息中包含的 Authentication option 的 authentication information 字段内包含 HMAC-MD5.

21.5.3. Reconfigure Key protocol 的客户端考虑事项​

客户端将在来自服务器的初始 Reply 消息中接收 Reconfigure Key. 客户端记录 Reconfigure Key, 用于认证后续 Reconfigure 消息.

为了认证 Reconfigure 消息, 客户端使用从服务器接收的 Reconfigure Key, 对 DHCP Reconfigure 消息计算 HMAC-MD5. 如果计算出的 HMAC-MD5 与 Authentication option 中的值匹配, 客户端接受该 Reconfigure 消息.

最后于 更新