摘要

  • RFC 5387 允许网络层与应用层采取单向或分层认证，但通道绑定必须在通信两端交换并验证；谁需要证明身份，与谁需要确认同一通道，是两项不同决策。
  • 如果缺少双端核验，中间代理可以把两条各自加密、各自完整的 IPsec 安全关联拼接起来。密码学没有失效，失效的是“应用两端直接共享同一通道”这一推断。

换钥时消失的那张收据

一条长连接运行数小时后达到安全关联寿命。系统建立新的 SA，流量没有中断，仪表盘仍显示加密。最容易作出的判断是：这只是换了一把钥匙，原有对端关系自然延续。

RFC 5387 不允许把这种连续外观当作证明。BTNS 所说的“关联连续性”只在一个 SA 内成立。新 SA 可以保护同一组地址和端口，也可以由路径上的攻击者趁换钥窗口接管。新握手成功，只说明新的局部关联建立了；它没有自动继承旧关联关于对端的全部含义。

这正是 connection latch 与 channel binding 分工的地方。前者把应用流量锁定到可接受的对端身份、保护类型和保护质量，后者让应用层认证包含能够识别具体 SA 对的信息。换钥后若这些性质得到可验证保留，通道可以继续；若性质改变而无法解释，应用必须在继续接收数据前得到断裂信号。

领导者应把换钥看成证据转移，而不是设备维护。任何接任者——新证书、新代理、新服务商或新自动化主体——都必须证明继承的是同一范围内的授权，而不是借用前任的绿色状态。

两条安全链路并不等于一条安全通道

设想一个路径中间人分别与客户端和服务器建立 IPsec SA。客户端看到一条具备机密性、完整性与防重放能力的关联；服务器也看到一条。中间人解开一端流量，再在另一端重新保护，并原样转发上层认证。

这里不需要攻破算法。两条 SA 都可以完全合规。错误发生在组合层：应用把两个网络层端点误认为自己的两个应用端点之间存在一条直接通道。

RFC 5387 指出，IPsec 通道的端点在高层协议那里，范围超出单个 SA 的端点。因此每个 SA 都要绑定到具体高层会话及其端点。RFC 5056 给出一般原则：双方通过应用层认证验证自己观察到相同的通道绑定数据。若代理拼接了两条 SA，双方所见的实例不同，绑定认证应当失败。

“已经启用 IPsec”只能证明能力。“两端为本次会话核对了同一 SA 对”才是执行收据。协议名称、IP 地址或通用证书可能出现在许多会话中，不能代替实例级标识。

认证可以单向，核验不能单边

很多服务有意采用不对称认证。公共服务器证明服务器身份，却不要求所有访客先有网络层证书。存储系统可能在应用层认证客户端，在 IKE 层认证服务器。不同层认识的主体本来就不同。

RFC 5387 因此区分对称与非对称的 SAB、CBB 模式。A-CBB 甚至可以把两个方向分放在不同层：客户端身份由上层证明，服务器身份由 IKE 证明，从整体上形成相互认证。

但这不意味着绑定只做一边。RFC 5387 明确要求，为抵御中间人，channel binding 必须在两端应用。双方都要交换和验证绑定值。某一端声称“我在加密通道里”不能证明另一端处在同一条通道里。

这里有一条可迁移的制度原则：授权方向可以由业务选择，共同事实的证据拓扑不能由单个观察者决定。一本账可以真实记录自己收到什么，却不能单方面宣布另一方也收到同一对象。

晚发现仍然是发现得晚

完全认证的 IKE 应在建立网络层关联时阻止中间人。CBB 的时序不同：未认证的 IKE 可能成功，两条 SA 先被创建，直到上层认证把自身绑定到通道时才发现不一致。

这个失败很重要，它阻止系统最终承认伪造通道。但失败并不会抹掉此前发生的事情。系统已经分配 CPU、内存与状态，也可能发送了认证材料。若上层机制暴露密码或可离线猜测的派生数据，“最终登录失败”并不等于“秘密从未泄露”。

因此验收不能只问攻击是否被检测。还要测量从 SA 建立到绑定失败之间分配了多少资源、发送了哪些凭据、接受了多少应用数据、何时提升权限。网络关联建立、通道绑定成功、应用主体获权，应是三个独立状态。

安全界面越喜欢一个绿色图标，这种时间差越容易消失。治理责任恰恰是保留这些中间状态，让失败发生在哪一层可以被看见。

把不变量锁到流上

RFC 5387 对 IPsec 通道的描述包含两个持续条件：流量生命周期内，对端身份相同；每个数据包获得的 IPsec 保护质量相同。RFC 5660 后来把 connection latching 具体化为对 SPD、SAD 变化的监视。

锁定内容包括保护类型、传输或隧道模式、算法与密钥质量、防重放、主体本地身份与对端身份。当底层状态变化不再满足应用起始要求时，latch 要同步通知上层，而不是让数据在新的条件下静默通过。

这不是要求底层永远不变。它要求变化具备解释。换钥可以合法，路径迁移可以合法，策略升级也可以合法；每次变化都要表明哪些性质保持、谁批准差异、失败时如何停机。

跨多个上层会话时还要区分缓存与重验。为防止会话间冒充，latch 可能需要保留；每个新会话的 channel binding 认证仍应重新执行。保存旧关系不是批准新行为。

用三台机器验收

先让客户端与服务器直接连接。两端记录绑定值、上层会话标识、对端身份、保护质量与认证结果。验收者证明双方看到的是同一个通道事实。

再加入受控代理，让它分别建立两条强 SA，并原样转发上层交换。不降低算法，不注入畸形包。测试的重点是：局部控制全部正确而拓扑错误时，绑定能否失败。

随后分别测试仅服务器认证、仅客户端认证、双向认证，以及两个方向分布在 IKE 与应用层的情形。身份政策可以变化，双端绑定核验不能消失。

最后在长连接中换钥。一次保持全部锁定属性，证明通道连续；另一次改变对端身份或保护质量，证明 latch 在更多应用数据被接收前断开。报告要列出检测端、销毁状态、应用错误、失败前字节数与资源消耗。

若系统只能证明成功路径，而无法区分“绑定失败”和“普通登录失败”，运营闭环还没有完成。

组合本身需要权威收据

RFC 5387 的价值不在于否定局部控制，而在于限制局部控制的权力。两条正确记录不能自行生成第三条更大的事实。组合处必须有自己的证据对象。

这张收据应写明底层实例、高层会话与端点、各层认证方向、双方核验结果、锁定属性和转换历史。值缺失、值不同或属性未经批准变化时，系统应关闭而不是补猜。

这也回应了“记账者何时变成权威”的问题。中间人可以管理两条漂亮的加密链路，却没有权力宣称两个主体已经同意一条共同通道。真实的端到端关系来自主体之间可核验的连接，不来自中介拥有的技术外观。

来源