RFC 1446：密钥先于回执改变

摘要

RFC 1446 把修改现有秘密值写成一组有顺序的动作。负责的管理站生成新值，发送受保护的 setRequest；接收方处理请求并回复；管理站只有在收到回复后，才更新自己的本地数据库。

两端顺利时，这串动作像一次完整操作。自行换钥时，时间差露了出来。目标先在本地写入新秘密，再构造响应；响应使用新秘密保护。管理器尚未确认，仍拿旧秘密验证。若没有为这种过渡保留专门路径，它会把正确的回复判成“不真实”。

发出命令、送达请求、远端提交、生成响应、送达响应、接受响应，是六条记录。消息拥有合法摘要，不能把六条压成一个“成功”。

如果回复没到，RFC 1446 没有把沉默解释成失败。第一种可能是请求根本没到，两边仍用旧密钥。第二种可能是请求到了、代理已换钥，只是回程响应丢了，此时两边的真实状态已经分叉。

盲目重试无法修复这个区别。管理器若继续用旧密钥发请求，失败反而可能说明上一次写入成功。一次验证失败也不能自动证明攻击、网络中断或代理宕机。

更棘手的是，私密值不能被读取。直接查询远端密钥本来最容易对账，却会破坏保密设计。系统主动关闭了这一观察面，就必须提供另一条不泄露秘密的证据路径。

RFC 1446 的档案页将它列为 Historic。文中的 MD5 与 DES 是 1993 年的历史设计，不是今天的部署建议。这里仍值得保留的，是远程状态转换的次序与证据问题。

规范建议在换钥时，同时写入一个新颖、可识别的公开值。修改认证秘密时配套改 partyAuthPublic；修改隐私秘密时配套改 partyPrivPublic。若响应消失，管理器可以读取这个公开字段，判断目标是否处理过那次变更。

RFC 1447 的 Party MIB 把公开字段、私密字段、认证时钟与有效期分别建模。公开标记不是弱化版密钥，也不会泄露秘密。它只是给不可读状态配上一枚可读的交易见证。

这枚见证也有边界。标记吻合，可以支持“目标已应用那次事务”；它不能证明管理器已完成本地更新，不能证明重启后仍保存，不能证明后续请求获授权，更不能证明网络效果已经发生。

从请求发出到结果确认，管理站必须同时记录旧秘密与新秘密。网络故障可能让等待拉长，因此 RFC 1446 明确要求做好跨重启保留两者的准备。

控制器不能只持久化自己希望发生的未来。如果请求未到而旧值被删，控制权丢失；如果请求已提交而新值被删，同样可能再也进不去。未决事务不是一条待重试的队列项，而是两个仍有可能为真的远端状态。

崩溃恢复把要求推得更远。规范要求一方的身份、认证时钟、私有认证密钥与私有隐私密钥拥有非易失、不可破坏的表示。时钟还要在断电后保持单调推进，因为消息是否“新近”取决于它。

所以，进程重新启动不等于管理关系恢复。身份、时间、两把候选密钥、有效期与公开见证必须重新汇合，双方才回到同一事实。

RFC 1446 用共享秘密摘要保护来源与完整性，用一方专属的时钟和有效期限制过度延迟与重放。它同时承认，这套机制不防止消息被删除或抑制。认证响应缺席，也不能直接证明代理或网络失败；时钟偏差或秘密不一致，甚至会让认证失败通知本身丢失。

SNMP 对状态修改消息没有普遍的顺序保证。规范建议，在收到前一条修改的正面确认或等到它过期之前，不要发送下一条。RFC 1450 的 SNMPv2 MIB 还定义了 snmpSetSerialNo 作为单独的 Set 排序机制。它解决次序，不替代持久化证明和结果观察。

RFC 1445 的管理模型又把通信放进一方、上下文与访问策略。摘要验证能支持来源和完整性判断，不能单独证明对某个对象的授权，也不能证明修改落盘或影响服务。

1993 年的 party 模型没有成为最终形态。RFC 1910 试验了以用户、代理身份、启动计数、时间窗和访问策略组织安全状态。RFC 2574 与后来的 RFC 3414 则定义了 SNMPv3 的 USM。

身份与换钥算法变化了，公开见证仍然存在。后续模型用单向 KeyChange 对象改变不可读密钥，用自旋锁协调并发写入，并把随机值写进 usmUserPublic。成功响应到达，表明新密钥生效；响应没有到，就读公开值，分清丢的是请求还是回复。

这不是对旧密码算法的背书。它说明，只要不可读秘密通过不可靠通道远程更新，回执之外就必须保留独立、可核验的状态证据。