摘要

  • RFC 5349 说明如何在 PKINIT 中使用 ECC 证书、ECC 签名与 ECDH，并强调它没有改变 RFC 4556 消息的语法或语义。客户端提出曲线参数；KDC 拒绝后可通过错误 65 返回按偏好排列的 TD-DH-PARAMETERS。
  • 错误与附带清单没有完整性保护，攻击者可以把选择推向更弱或并非双方真实偏好的参数。因此客户端与 KDC 都必须拥有本地可接受参数政策，收到的顺序不能成为新的 allow-list。
  • 曲线标识、证书验证、公开点验证、共享秘密、KDC 回复、票据、服务授权与用户会话是不同证据。只记录“PKINIT 成功”会丢失最关键的授权与降级路径。

正确错误码不等于可信附带数据

客户端选择 ECDH 时，会把公开值和域参数放入 PA-PK-AS-REQ 的 clientPublicValue。KDC 若不接受，可以返回错误 65，并在 typed data 中给出自己声称支持的参数集合。

这项设计解决互操作发现问题。客户端不必盲目遍历所有曲线，可以从对方列表中寻找共同项。但它没有解决消息真实性。RFC 5349 明说 Kerberos error messages 没有完整性保护，清单可能被篡改为更弱的集合，或者改变双方原本的共同偏好。

因此必须把“错误码处理正确”与“附带建议可信”分开。协议栈可以准确解析 code 65，却仍在执行攻击者改写后的重试方向。日志若只保存整数错误码，就无法证明客户端实际看到了什么。

充分记录应包含：初次提议、错误原始字节或摘要、收到的完整顺序、重试选择、本地政策版本与命中规则、第二次请求及其认证结果。顺序只是来自网络的声明，政策才是本地授权。

本地政策不能从协商流量中学习

客户端与 KDC 各有一个可接受集合。真正可用的参数位于两者交集。清单可以缩小搜索，却不能扩大任何一侧的集合。

自动学习会破坏这条边界。若客户端发现某个重试成功，就把曲线永久写进缓存；缓存又被后续版本当成“既有配置”。一条未认证消息便经过成功率与时间沉淀，被洗成长期政策。

应把三种状态拆开：观察到对端支持、当前工作负载获准使用、临时兼容例外。第一种来自运行证据，第二种来自责任主体，第三种需要范围、所有者与失效日期。三者不能共用一个布尔值。

政策还需绑定 assurance tier。能够为普通设备兼容旧 KDC 的参数，不应自动进入管理员身份、长期凭据或高价值服务的允许集。

曲线名称不能替公开点完成验证

双方就 P-256 或 P-384 达成一致后，仍要处理对端发来的公开点。RFC 5349 要求接收者执行 IEEE P1363 所述检查，特别警告长期 ECDH 私钥：若不确认公开值是正确曲线上的有效点，反复攻击可逐步泄露私钥信息，最终完全暴露。

这不是同一控制的两个名字。算法标识表明预期群组；点验证判断收到的字节是否真属于该群组。监控界面显示 secp256r1，并不证明验证器已经运行。

密钥生命周期决定影响范围。临时密钥与长期复用密钥面对同一无效点，后果不同。事件记录需要密钥实例、复用状态、nonce、点验证结果与失败原因，才能计算轮换范围。

冻结的 NIST SP 800-56A Rev. 3 为当前 ECDH 密钥建立与验证提供参考；SP 800-186 与 FIPS 186-5 提供当前曲线和签名背景。NIST 已宣布更新 SP 800-56A，但并未撤销当前版本。RFC 5349 的 2008 表格不能代替 2026 政策。

算出共享秘密还没完成认证

参数获准后，KDC 在 PA-PK-AS-REP 返回自己的 ECDH 公开值。双方计算共享点，把 x 坐标转换成 DHSharedSecret，再按 PKINIT 与 Kerberos 继续。

共享值证明的是这组输入能产生相同密码材料。它没有自动证明证书链属于预期主体、key purpose 正确、请求新鲜、KDC 属于预期 realm、票据已签发、服务接受票据，或者用户进入了正确会话。

事件链至少应分别保存 curve_allowed、peer_point_valid、shared_secret_derived、kdc_reply_verified、ticket_issued、service_authorized 与 session_established。把这些压成一个绿色结果，只能服务可用性统计，不能服务事故归因。

证书携带参数，仍不携带全部决定权

RFC 5349 提到，客户端或 KDC 证书中的 ECC 参数可以免去单独预配置。这能减少配置漂移，是实际优势。

但证书仍需路径、用途、有效期、撤销状态与主体绑定检查；其参数仍需满足本地政策；本次会话的公开点仍需验证。证书提供候选来源，不是把每个服务的判断统一消除。

自动化设计尤其容易误读这一点。“无需额外配置”不等于“无需本地政策”。当预先知识不存在时，RFC 5349 恰恰要求双方都定义本地可接受集合。

互操作基线也会形成共同故障面

RFC 5349 要求实现支持 P-256 与 P-384，并讨论命名曲线、自定义曲线、代数结构、效率和集中风险。它没有报告这些曲线已被攻破，而是在记录权衡。

共同基线减少测试组合与连接失败，也会让实现缺陷或未来密码变化影响更大范围。增加多样性可以降低某些共同风险，却增加解析器与验证路径。领导层需要的是资产清单、明确允许集、退役条件和影响映射，而不是抽象地选择“统一”或“多样”。

RFC 8636 在 PKINIT 算法敏捷性上延续同一规则：缺失 KDF 字段可能是旧对端，也可能是 downgrade，本地政策决定是否继续。2026 年的 PKINIT 后量子草案再次出现提示与重试，但仍是 work in progress，不能当作现行部署事实。

这份 RFC 不是部署普查

RFC 5349 是 Informational。IANA 表格证明编号分配，不证明启用比例。冻结证据没有给出现网普及率、攻击发生率或厂商一致行为。

Lu Heng 的 Minimum Initial Specification 只能作为后来披露的类比：共同层定义最低互操作语言，未来接受决定留在运行代码的一方。Reality Layers 则提醒我们不要把符号、文件偏好、密码验证与运营结果合并。两篇笔记都不是 RFC 的历史来源。