21. DHCP 消息的认证
- DHCP 消息的认证
某些网络管理员可能希望对 DHCP 消息的源和内容的认证. 例如, 客户端可能由于伪造的 DHCP 服务器而 遭受拒绝服务 (denial of service) 攻击, 或者仅仅由于无意中部署的 DHCP 服务器而被错误配置. 网络 管理员可能希望约束地址分配给经授权的主机, 以避免在 "敌对" 环境中 (网络介质未做物理保护, 如无线 网络或大学宿舍) 的拒绝服务攻击.
DHCP 认证机制基于 DHCPv4 [4] 的认证设计.
21.1. 服务器与中继代理之间所发送消息的安全性
安全地交换消息的中继代理与服务器使用 IPv6 的 IPsec 机制 [7]. 如果一条客户端消息经由多个中继代理 中继, 则每个中继代理都必须建立独立的、两两之间的信任关系. 也就是说, 如果从客户端 C 发出的消息将 由中继代理 A 中继给中继代理 B, 再发往服务器, 则中继代理 A 与 B 必须被配置为对它们所交换的消息使用 IPSec, 且中继代理 B 与服务器必须被配置为对它们所交换的消息使用 IPSec.
支持安全的中继代理到服务器、或中继代理到中继代理通信的中继代理与服务器, 在以下条件下使用 IPsec:
Selectors (选择器)
中继代理被手动配置以拥有向其转发 DHCP 消息的中继代理或服务器
的地址. 每个将使用 IPsec 来保护 DHCP 消息的中继代理和服务器,
还必须被配置以一份将向其返回消息的中继代理的列表. 用于中继
代理和服务器的选择器, 将是定义在中继代理和服务器之间交换
DHCP 消息的地址对, 其端口为 DHCPv6 的 UDP 端口 546 和 547.
Mode (模式) 中继代理和服务器使用传输模式 (transport mode) 与 ESP. DHCP 消息中的
信息通常不被认为是机密, 因此不需要使用加密 (即可以使用 NULL
加密).
Key management 由于中继代理和服务器都在一个组织内部使用, 因此不需要公钥方案.
(密钥管理) 由于中继代理和服务器必须被手动配置, 手动配置的密钥管理可能足够,
但不能防御重放 (replayed) 消息. 因此, 应当 (SHOULD) 支持使用
预共享密钥的 IKE. 可以 (MAY) 支持使用公钥的 IKE.
Security policy 中继代理与服务器之间的 DHCP 消息, 应当只被接受来自本地配置中所
(安全策略) 标识的 DHCP 对等方.
Authentication 在这个应用中, 以所收到的 DHCP 消息的源 IP 地址为索引的共享密钥
(认证) 就足够了.
Availability 在企业网络和核心 ISP 网络中使用的、功能更丰富的设备里, 适当的
(可用性) IPsec 实现很可能可用于服务器和中继代理. 而在主要面向家庭或小型
办公室市场、低端设备中的中继代理上, IPsec 则不太可能可用.
21.2. DHCP 认证概述
DHCP 消息的认证通过使用认证 (Authentication) 选项 (见 22.11 节) 来实现. 认证选项中携带的认证信息 可用于可靠地识别 DHCP 消息的源, 并确认 DHCP 消息的内容未被篡改.
认证选项为多种认证协议提供了框架. 此处定义了其中两种协议. 未来定义的其他协议将在单独的文档中 规定.
任何 DHCP 消息不得 (MUST NOT) 包含多于一条认证选项.
认证选项中的 protocol 字段标识了用于在选项中生成认证信息的具体协议. algorithm 字段标识该认证 协议内的特定算法; 例如, algorithm 字段指定了用于生成认证选项中的消息认证码 (MAC) 的哈希算法. RDM (重放检测方式, Replay Detection Method) 字段指定了重放检测 (replay detection) 字段中所使用 的重放检测类型.
21.3. 重放检测
RDM 字段决定了重放检测字段中所使用的重放检测类型.
如果 RDM 字段包含 0x00, 则重放检测字段必须 (MUST) 被设置为一个单调递增计数器的值. 使用计数器值 (例如当前时间 (如 NTP 格式的时间戳 [9])) 可以降低重放攻击的危险. 所有协议必须 (MUST) 支持这种 方式.
21.4. 延迟认证协议 (Delayed Authentication Protocol)
如果 protocol 字段为 2, 则消息正在使用 "延迟认证" 机制. 在延迟认证中, 客户端在其 Solicit 消息中 请求认证, 服务器以一条包含认证信息的 Advertise 消息作为响应. 该认证信息包含一个由源生成的、作为 消息认证码 (MAC) 的 nonce 取值, 用以提供消息认证与实体认证.
此处定义了基于 HMAC 协议 [8] 并使用 MD5 哈希 [16] 的特定技术.
21.4.1. 在延迟认证协议中使用认证选项
在 Solicit 消息中, 客户端在认证选项的 protocol、algorithm 和 RDM 字段中填入客户端的偏好. 客户端将 重放检测字段设置为 0, 并省略认证信息字段. 客户端将 option-len 字段设置为 11.
在所有其他消息中, protocol 和 algorithm 字段标识了用于构造认证信息字段内容的方法. RDM 字段标识了 用于构造重放检测字段内容的方法.
认证信息的格式如下:
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 域.
key ID 标识用于生成 HMAC-MD5 取值的密钥的密钥标识符.
HMAC-MD5 通过对 DHCP 消息应用 MD5、使用由 DHCP realm、客户端 DUID 和 key ID 所标识的
密钥而生成的消息认证码.
发送方使用 HMAC 生成算法 [8] 和 MD5 哈希函数 [16] 来计算 MAC. 整个 DHCP 消息 (将认证选项的 MAC 字段 置为 0), 包括 DHCP 消息头部和 options 字段, 都被用作 HMAC-MD5 计算函数的输入.
讨论 (DISCUSSION):
算法 1 指定了 HMAC-MD5 的使用. 使用不同的技术 (如 HMAC-SHA) 将被规定为一个单独的协议.
用于标识认证密钥的 DHCP realm 被选择为在不同管理域之间唯一. 使用 DHCP realm 使 DHCP 管理员能够
避免在密钥标识符使用上的冲突, 并允许使用 DHCP 的、在多个 DHCP 管理域之间漫游的主机使用经认证的
DHCP.
21.4.2. 消息验证
任何包含多于一条认证选项的 DHCP 消息必须 (MUST) 被丢弃.
为了验证一条收到的消息, 接收方首先根据 RDM 字段所指定的重放检测方式, 检查重放检测字段中的取值是否 可接受. 接着, 接收方按 [8] 所述计算 MAC. 整个 DHCP 消息 (将认证选项的 MAC 字段置为 0) 被用作 HMAC-MD5 计算函数的输入. 如果接收方计算得到的 MAC 与认证选项中包含的 MAC 不匹配, 接收方必须 (MUST) 丢弃该 DHCP 消息.
21.4.3. 密钥使用
每个 DHCP 客户端都拥有一组密钥. 每个密钥由 <DHCP realm, 客户端 DUID, key id> 标识. 每个密钥 还具有一个生存期. 该密钥在其生存期结束之后不得使用. 客户端的密钥最初通过某种带外 (out-of-band) 机制分发给客户端. 每个密钥的生存期随该密钥一起分发. 密钥分发和生存期指定的机制不在本文档范围内.
客户端和服务器在一次会话期间 (直到客户端发送的下一条 Solicit 消息为止) 使用客户端的其中一个密钥来 认证 DHCP 消息.
21.4.4. 延迟认证协议中的客户端考量
客户端通过在其 Solicit 消息中包含一个认证选项, 来宣告其使用 DHCP 认证的意图. 服务器基于客户端的 DUID 为客户端选择一个密钥. 客户端和服务器使用该密钥来认证会话期间交换的所有 DHCP 消息.
21.4.4.1. 发送 Solicit 消息
当客户端发送 Solicit 消息且希望使用认证时, 它包含一个认证选项, 其中带有期望的 protocol、algorithm 和 RDM, 如 21.4 节所述. 客户端不在认证选项中包含任何重放检测或认证信息.
21.4.4.2. 接收 Advertise 消息
客户端使用 21.4.2 节所述的验证测试, 验证任何包含指定延迟认证协议的认证选项的 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 消息
如果消息未通过验证测试, 客户端必须 (MUST) 丢弃该 Reconfigure 消息, 并可以 (MAY) 记录验证失败.
21.4.5. 延迟认证协议中的服务器考量
在收到一条包含认证选项的 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 Authentication Protocol)
重配置密钥认证协议提供对由恶意 DHCP 服务器发送的 Reconfigure 消息所导致客户端错误配置的保护. 在此 协议中, DHCP 服务器在 DHCP 消息的初始交换中向客户端发送一个 Reconfigure Key (重配置密钥). 客户端 记录该 Reconfigure Key, 用于认证来自该服务器的后续 Reconfigure 消息. 服务器随后在后续的 Reconfigure 消息中包含一条由该 Reconfigure Key 计算出的 HMAC.
从服务器发往客户端的 Reconfigure Key 以及后续 Reconfigure 消息中的 HMAC, 都作为认证选项中的认证信息 来携带. 认证信息的格式在下一节定义.
重配置密钥协议 (由服务器发起) 仅当客户端和服务器未使用任何其他认证协议、且客户端和服务器已协商使用 Reconfigure 消息时才使用.
21.5.1. 在重配置密钥认证协议中使用认证选项
在重配置密钥认证协议的认证选项中, 设置以下字段:
protocol 3
algorithm 1
RDM 0
重配置密钥认证协议的认证信息格式如下:
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 Value 字段中携带的数据的类型:
1 Reconfigure Key 取值 (用于 Reply 消息中).
2 消息的 HMAC-MD5 摘要 (用于 Reconfigure 消息中).
Value 由字段定义的数据.
21.5.2. 重配置密钥协议中的服务器考量
服务器在 Request/Reply、Solicit/Reply 或 Information-request/Reply 消息交换期间, 为客户端选择一个 Reconfigure Key. 服务器记录该 Reconfigure Key, 并在 Reply 消息的认证选项中将该密钥传输给客户端.
该 Reconfigure Key 长 128 比特, 且必须 (MUST) 是一个不易被预测的、密码学意义上强的随机或伪随机数.
为了给一条 Reconfigure 消息提供认证, 服务器根据它所选择的 RDM 选择一个重放检测取值, 并使用该客户端的 Reconfigure Key 计算该 Reconfigure 消息的 HMAC-MD5. 服务器对整条 DHCP Reconfigure 消息 (包括认证选项) 计算 HMAC-MD5; 在计算 HMAC-MD5 时, 认证选项中的 HMAC-MD5 字段被置为 0. 服务器将 HMAC-MD5 包含在其 发往客户端的 Reconfigure 消息所含的认证选项的认证信息字段中.
21.5.3. 重配置密钥协议中的客户端考量
客户端将从服务器发来的初始 Reply 消息中收到一个 Reconfigure Key. 客户端记录该 Reconfigure Key, 用于 认证后续的 Reconfigure 消息.
为了认证一条 Reconfigure 消息, 客户端使用从服务器收到的 Reconfigure Key, 对 DHCP Reconfigure 消息 计算 HMAC-MD5. 如果计算得到的 HMAC-MD5 与认证选项中的取值匹配, 客户端接受该 Reconfigure 消息.