摘要

  • RFC 5349 允许 KDC 在拒绝客户端 ECDH 参数后，通过 KDC_ERR_DH_KEY_PARAMETERS_NOT_ACCEPTED 返回按偏好排序的 TD-DH-PARAMETERS。客户端可据此重试，但承载这份清单的 Kerberos 错误消息没有完整性保护，因而它只是协商输入，不是授权凭据。
  • X.509 路径和 CMS 签名验证不能替代椭圆曲线公钥点验证。接收方仍需确认公钥确实是正确曲线上的有效点，再让它接触私钥运算。
  • 长期 ECDH 私钥一旦反复处理无效点，单次漏检就可能演化成逐次泄露。成功派生共享秘密、签发 Kerberos 票据和允许业务动作也必须分别记账，不能互相代替。

一张绿色证书不能覆盖下一道边界

证书验证很容易成为操作界面上唯一醒目的绿色标记。它可以说明签名验证成功、链条通向受信任锚点、有效期与约束满足既定规则，也可以把一个公钥编码绑定到主体与算法标识。

然而 ECDH 真正要使用的是一个数学对象。系统必须确认收到的公钥点属于预期的椭圆曲线，并满足相应的有效性条件，之后才能把它送入标量乘法。证书容器经过认证，并不会自动使容器内每一种可解析的位串都适合参与运算。

这两类检查失败时，处置原因也不同。证书路径失败可能指向签发者、名称、用途或期限；公钥点失败则指向曲线归属与数学有效性。把它们都压成“证书失败”，既不利于修复，也掩盖了私钥是否已经接触危险输入。

因此运行证据至少要分列：编码解析、证书路径、签名、算法政策、公钥点、共享秘密。只有第一列通过，不能推断后面各列。

未认证错误可以改变动作，却不能创造权限

客户端先在 PA-PK-AS-REQ 中提出 ECDH 参数。KDC 若不接受，可返回拒绝码及一份按自身偏好排列的参数清单。客户端从中选择一个参数再试，协议流程因而发生改变。

关键在于，这个错误消息没有完整性保护。中间人可以删改或重排清单。消息的确具有操作影响力，却没有资格扩大客户端原有的许可集合。

正确做法是求交集：本地政策先定义允许集合，收到的清单只提供候选和顺序。只有同时出现在本地允许集合中的项目才可能进入重试。如果交集为空，停止就是控制结果，不是需要兼容模式绕过的障碍。

KDC 也要守同样的边界。密码库实现某条曲线，只证明能力存在；配置允许、策略接受和本次执行都需要另外的事实。

成功重试不能倒签前一份清单

设想中间人删掉双方最偏好的共同曲线，只保留客户端政策仍然允许的次选项。客户端选中次选项，第二次 PKINIT 顺利完成。最终密码交换可以是正确的，本地政策也确实阻止了不可接受的曲线。

但这次成功不能证明先前清单真实来自 KDC，更不能证明 KDC 的实际偏好就是最终选择。它最多证明：在被改变后的候选集合里，仍存在一个得到双方接受并正确执行的交集。

因此审计必须同时问两个问题：最终曲线是否得到许可并被正确执行？协商路径是否忠实反映 KDC 的真实偏好？前者为真，后者仍可以未知。

如果遥测只保存最终曲线，组织就会把“结果合规”和“输入可信”误写成同一个结论。成功票据也无法补回已经丢失的清单原貌。

排序本身就是治理信息

TD-DH-PARAMETERS 不只是若干曲线的集合，它带有从高到低的 KDC 偏好。元素相同、顺序不同的两份清单可能产生不同选择。

记录系统应保留客户端原始提案、拒绝码、收到时的完整顺序、本地政策版本、计算后的交集、选择算法、重试参数和结果。原始清单与过滤后清单要分开保存，不能让后者覆盖前者。

本地政策日后可能变化，所以仅凭当前配置无法复原过去决定。把政策版本或内容摘要绑定到当次选择，才能说明当时为何接受或拒绝。

这种证据也能区分两种情况：攻击者只改变了偏好但没有越过安全底线，或者远端输入事实上把系统推到了本地从未允许的位置。两者的响应优先级不同。

长期私钥让一次漏检变成多轮提取

RFC 5349 特别指出，当接收方使用长期 ECDH 私钥时，如果没有验证收到的公钥是正确曲线上的有效点，就可能在计算中泄露该私钥的信息。攻击反复进行，最终可能暴露完整私钥。

风险大小不只取决于算法名称，还取决于三个运行变量：同一私钥存活多久、多少对手输入能够触达它，以及攻击者能观察到什么响应差异。

一次正常认证日志不能证明此前的无效点都被拒绝。密钥清单也不能说明同一个私值曾被多少解析或计算路径调用。只有把输入验证结果与密钥身份、生命周期和每次运算相连，才能看见累积风险。

限速能够增加攻击成本，却不能替代验证。缩短密钥寿命能够缩小暴露窗口，也不能使无效点合法。首要控制仍是在私钥运算之前明确拒绝。

重用许可由上下文承载

RFC 5349 延续 RFC 4556 的设计：客户端和 KDC 可以通过 clientDHNonce 与 serverDHNonce 参与允许 ECDH 密钥重用。这不是软件可以任意长期复用密钥的一般授权。

nonce 是许可上下文的一部分。只留下派生密钥或最终票据，会丢掉双方在什么条件下同意重用、重用了哪一对密钥以及重用了多久。

重用可能降低计算量与时延，却也让更多外部输入接触同一个私钥。随着重用次数增长，点验证的每一次执行都成为关键边界；偶发旁路也更可能转化为累计泄露。

审计账本应连接 nonce、政策决定、密钥实例、曲线、验证结果、重用计数与销毁事件。“ECDH 完成”不是对这些问题的回答。

小密钥不是总成本结论

RFC 5349 解释了 ECC 的历史吸引力：相较当时常见的 RSA 或 DSA 机制，它可以用更小的密钥提供大致相当的安全强度。文档引用当时的指导，列出近似对应关系，并以 P-256 说明 128 位对称强度目标。

这张表说明的是设计背景，不是当代采购评分。密钥长度没有计入证书生命周期、硬件支持、旁信道、库实现质量、参数协商、测试覆盖与迁移风险。

较短编码可能节省带宽、存储或部分计算，也可能引入新的解析器、算法标识、曲线政策和失败模式。部署总成本只能从实际平台与运行数据中得出。

历史强度映射也不能替代当前密码政策。今天的决定必须参考当前标准、平台行为和威胁评估，而非孤立复用 2008 年的表格。

强制支持只是一层能力地板

RFC 5349 要求符合文档的实现支持 P-256 与 P-384，并要求支持其所述的 ecdsa-with-Sha256。这建立了互操作的共同起点。

它没有证明某个部署启用这些能力，没有证明客户端提出它们，也没有证明它们通过本地政策、出现在 KDC 清单、被重试选中、通过点验证或实际完成计算。

“支持”是产品或实现事实，“执行”是一次事件事实。两者之间还有配置、提案、接收、许可、选择和验证等状态。

成熟的清单不应只有一个勾选框，而应展示这条状态链。否则标准一致性很容易被误读为生产证据。

命名曲线降低摩擦，也集中依赖

命名曲线用对象标识符表达一组共同参数，编码更紧凑，也便于不同实现达成共识。RFC 4556 的结构同时能够表达显式参数的定制曲线。

广泛使用同一曲线有明显操作优势：证书、库、硬件和测试更容易对齐。但它也把大量密钥放在共同的密码假设与实现路径上。一旦未来出现曲线或实现层面的系统性问题，影响会同时扩散。

增加曲线多样性并非免费保险。更多参数意味着更多代码分支、协商组合、配置差异和降级面。问题不是简单选择“集中”或“多样”，而是用证据衡量集中风险和复杂度风险。

需要观察的量包括各曲线密钥数量、实现与硬件多样性、点验证覆盖、替换所需时间以及生产中真实发生的协商选择。

证书参数只是把保管权移到别处

ECC 证书所携带的域参数可以供 ECDH 使用，从而减少单独预配置参数的需要。这种简化确实有价值。

但治理并未消失。它转移到证书签发、路径验证、算法限制、公钥解析和本地接受政策。证书里的参数不会仅因进入受签名容器，就自动获得对所有使用场景的许可。

系统应记录参数来源：本地明确配置、当前证书、KDC 错误清单或其他机制。没有来源信息，减少一个配置文件会被误解成减少一道决策，实际只是改变了谁能改变参数。

管理问题也随之变化：谁能签发带有不同参数的证书？谁能修改算法约束？撤销与轮换需要多久？这些才是转移后的控制面。

共享秘密之后仍有多道拒绝权

在接受的 ECDH 交换中，双方计算椭圆曲线点，把 x 坐标转换为八位组串，并作为 RFC 4556 流程中的 DHSharedSecret。成功完成这一步，只说明下一阶段所需的密码材料已经产生。

它没有单独证明对方的完整组织身份，没有签发 Kerberos 票据，没有获取服务票据，没有通过应用授权，也没有证明业务动作完成。每个后续阶段都保留拒绝权。

RFC 5349 于 2008 年 9 月以 Informational 发布，并声明不改变 RFC 4556 消息的语法或语义。采集时 RFC Editor 的勘误查询未显示该 RFC 的记录；这只是有时间边界的文档观察，不是实现无缺陷证明。

因此，最稳健的运行模型不是寻找一张万能凭据，而是保留证书、点、政策交集、共享秘密、票据和业务结果六张独立收据。