摘要

  • RFC 9966 的 TLS-POK 让服务器证明它知道设备 BSK 的公钥，也让设备证明它持有配对的私钥，从而为后续 EAP 凭证配置创造条件。
  • 服务器如何取得该公钥、实物保管是否可信、设备是否有权接入，均不由这次握手自动证明，必须保留为独立证据链。

没有界面或界面有限的设备常被困在一个循环里：企业网络先要 EAP 凭证才给接入，而设备又需要接入才能获得凭证。Owen Friel 与 Dan Harkins 在 RFC 9966 中处理的是这一循环的有线侧起点。它定义 TLS Proof of Knowledge，即 TLS-POK，借助一对椭圆曲线引导密钥（Bootstrap Key，BSK）在 TLS 1.3 中先建立双方可验证的关系。

这个关系并不对称混乱。设备独占 BSK 私钥；公钥由设备及其所有者或持有人知悉，并由 TLS 服务器的运营者配置到服务器中。随后，服务器向设备证明自己知道该公钥；设备向服务器证明自己掌握相应私钥。EPSK 从 BSK 公钥导出，客户端再以原始公钥完成约定的认证步骤。技术上，这是一个可记录的密钥知识关系，而不是关于资产、产权或管理授权的总账。

规范把前置环节明确留在边界外。服务器究竟如何得知 BSK 公钥，RFC 9966 说不在本文范围内。扫描 QR 标签、上传包含该信息的 BOM 都只是例子。若标签贴在设备上，模型会假设实际持有设备意味着合法拥有设备。这个假设可能足以启动流程，却不是 TLS 握手对采购、交接、标签完整性、库存记录或所有人身份做出的审计结论。

安全章节因此值得逐句看待。客户端对服务器的信任依赖一个条件：它的 BSK 公钥没有被广泛泄露。攻击者若获知公钥，并能把客户端诱导到自己的服务器，就可能完成 TLS-POK，使设备向攻击者网络引导。更早的环节也会出错：如果引导方法把诚实设备的公钥替换为恶意设备的公钥，服务器可能接纳后者。握手仍会准确验证自己收到的材料；它却无法发现材料在进入握手前已被错误关联。

RFC 9966 并未把这些风险藏进一句“自动化”。客户端必须先处理 ServerHello 并验证 TLS 密钥计划，才可发送 BSK 公钥；PSK 验证失败时，必须终止而不能泄露该公钥。制造商应为每台设备使用唯一 BSK。多台设备共用一把 BSK 时，网络运营者无法区分设备，也不能确保只有特定获授权设备连接。这些约束改善了协议内可观察性，却没有把 QR 标签变成保管权文件。

握手完成后，服务器可以为设备配置供后续 EAP 认证使用的凭证；BSK 只用于引导阶段。因而，公钥取得、服务器配置、TLS 成功、凭证签发、策略评估和实际执行应是相互连接但不能相互替代的记录。一条成功握手日志既不能证明设备没有被替换，也不能证明后来准入决策已落地。

Harkins 的公开 IETF 资料页将他与该 RFC 相连，IEEE 802.11 的公开表彰照片仅为人物肖像提供身份参照。它们都不说明他控制任何部署。真正有价值的是标准划出的责任边界：初始密钥证明可以很强，却不该被包装成已解决保管链和准入权的万能结论。

来源