密码运算成功了，授权问题仍未回答

摘要

• RFC 3631 最耐久的价值不是它在 2003 年列举的算法，而是要求先说明威胁、保护对象、层级与粒度，再谈安全机制。
• 密码运算只能对确定的字节、密钥和验证输入作出结论。它不会自动确定业务主体、信任范围、权限、完整事务或实际结果。
• 可审计的安全结论必须串起软件能力、运行配置、协商参数、身份与信任路径、密钥生命周期、覆盖字节、授权规则和可观察结果。

MAC 证明了谁掌握密钥，却没有定义“谁”

开篇场景中，服务端确实可以证明请求与某个共享秘密相符。问题在于，组织没有保存这个秘密映射到哪个主体、允许代表谁、在哪些资源上有效，以及哪些字段被纳入认证计算。若十台机器共用一把长期密钥，验证结果最多说明“这十台机器中的某处掌握了秘密”，不能自己收缩成某位用户或某家公司。

目标字段也同样关键。假如 MAC 覆盖正文而没有覆盖方法、租户、资源路径或目的地，中间环节就可能在保持正文验证有效的同时改变动作对象。密码学没有承诺自己未覆盖的内容。把“MAC 有效”作为一条业务许可，是让验证器替应用做了它没有输入的信息。

RFC 3631 在 2003 年 12 月以 IAB Stream 的 Informational RFC 发布，不是 Internet Standard，也不是今天的算法选择指南。RFC Editor 信息页与 IETF Datatracker限定了它的地位；文档历史只记录出版过程，不证明部署；勘误入口也不是任何产品的合规审计。

先写攻击者，再买控制

RFC 3631 把威胁模型放在决策因素的第一位：谁可能以什么方式攻击哪项资源，目标价值又取决于什么位置和用途。这个顺序阻止安全采购从产品名倒推风险。一套强大的加密设备可能严密保护传输，却对内部滥权、端点被控或错误业务语义没有任何答案。

RFC 3552进一步把威胁模型定义为对攻击者能力的假设，并要求说明哪些威胁纳入、哪些明确排除。它提醒应用协议设计者不能假定攻击者都不在路径上，也不能确信一个原本只用于封闭环境的协议永远不会走出边界。

因此，每个控制项都应先对应一份声明：资产、动作、可能后果、路径上与路径外攻击者、内部人员、端点失陷、所需保密期，以及机密性、完整性、对端认证、来源认证、防重放、可用性和授权中究竟需要哪些属性。“启用了加密”没有回答其中任何一个主语。

RFC 2316所记录的 IAB 安全架构研讨会也要求 RFC 有意义地列出威胁、应对和限制。这是设计过程要求，不是运行证明。

“必须实现”解决共同选项，不解决生产状态

RFC 3631 解释了 mandatory-to-implement 的目的。如果不同产品各自实现一套互不重叠的可选机制，它们可能都功能丰富却无法安全互通。规定一项共同能力，是互操作底线。

底线约束的是实现者，不是每次连接。它不代表运营者必须启用，不代表默认会选中，也不代表已经过时的算法必须继续开放。RFC 3365作为 BCP 61 要求 IETF 协议提供适当的强安全机制，同时清楚区分实现义务和使用决定。

生产证据至少有五层：二进制包含能力；配置允许能力；对端发出报价；双方选中参数；具体流量确实受这些参数保护。还要有第六层：所选参数满足当时有效的本地政策。产品说明书只覆盖第一层，却经常被拿来替代后五层。

这个区分也让算法退役可以被正确描述。旧能力仍留在代码中不等于暴露，政策禁用才决定运行面；反过来，政策文件写了禁用而实例未部署，也不能算完成。合规表与流量事实必须分别保存。

保护层越低，通常越不知道应用意图

RFC 3631 比较了不同层级的保护。链路层可以覆盖链路上的多类协议，但范围止于这条链路。IPsec 可以保护主机或网关之间选中的 IP 流量，却不天然识别内层用户。TLS 可以向应用提供连接和对端证据，但应用仍要定义要连接谁、何时开始保护以及如何解释身份。对象签名可以随文件穿越转发和存储，却只约束被签名的对象。

它们不是强弱排名，而是不同的证据主语。审计必须写明保护单位：链路、包类、主机、网关、连接、应用主体、消息还是持久对象；同时写明缺口。否则一个宽泛的“已上 IPsec”会被误读成所有应用操作都已认证。

RFC 4301给出了更精确的 IPsec 运行模型。安全服务取决于协议、模式、安全关联端点、密钥和策略；策略数据库可让流量进入保护、丢弃或旁路分支。隧道在线不证明争议数据包命中了保护规则。需要把选择器、策略版本、安全关联、计数器和包或流标识对齐，再接到内层应用的决定。

首次认证不能替后续每个状态变化

RFC 3631 用 HMAC 举出一个很具体的边界：共享秘密挑战可以认证连接开始，并在设计正确时抵抗旧会话重放；但若只认证 TCP 会话开头，后续协议单元不受保护，攻击者仍可能在认证完成后劫持会话。

这要求安全日志保存覆盖图，而不只是一次“认证成功”。方法、目标、头部、正文、随机数、序号和响应哪些被绑定？每一次改变状态的消息是否都有完整性保护？重连是否错误继承前一条连接的权限？最终确认是否在同一保护上下文中？

“有效 MAC”只回答被覆盖字节与一把密钥的关系。要变成授权，还需要主体、范围、资源、政策版本、新鲜度和决定者。两条结论都可以正确，但中间的映射必须可查。

框架名称把决定推迟到协商时

RFC 3631 明确说，SASL 的安全属性取决于实际协商出的机制；GSS-API 也必须单独评估底层机制。框架提供选择和封装，不会把所有选项变成同等安全。

因此要记录报价集合、最终选择、信道绑定、回退条件、参数和得到的属性。协议语法正确并不保证本地政策正确。降级风险就藏在兼容性里：一个为旧客户端保留的选项，可能因错误配置或主动干预变成常态。

现代 RFC 8446把 TLS 1.3 定义为与应用协议相对独立的握手和记录层。版本、密码套件、客户端认证、ALPN、会话恢复与 0-RTT 都影响结论。尤其 0-RTT 带有重放边界；应用若把可重放的早期数据直接当成不可重复的业务指令，TLS 成功也不会阻止重复执行。

证书有效不等于到达期望端点

RFC 3631 对 TLS 的讨论带有时代特征，例如用户可以忽略认证警告。这些界面现象不是今日规范，但它揭示的责任仍然成立：验证政策被应用绕过时，密码学不能恢复被丢弃的身份决定。

当前 RFC 9325指出，在常见的认证 TLS 用途中，主机名验证至关重要。证书链可以有效，对端也可以证明持有私钥，但连接仍可能不是应用原本要到达的端点。

完整收据必须从连接前就保存参考身份，再保存证书中的名称、匹配规则、信任锚、验证时间、状态信息、例外和结论。参考身份来自应用意图，不能让服务端用自己送来的证书倒过来定义。

之后还要另问一遍：哪个应用主体发起动作，具有什么权限。服务端身份、客户端证书、设备身份和用户账号可以相互关联，却不能自动合并。认证谁与允许做什么属于不同授权面。

信任路径是一项本地政策

RFC 3631 比较了层级式证书根与 PGP 式信任图。拓扑不同，共同点是验证必须从接收者认可的起点开始，并依赖相关链路可靠。数学上的签名有效不能选择这个起点。

组织要记录信任库版本、锚来源、名称与用途约束、实际构建的链、验证时间和例外。信任库静默增加一个根，可以在应用代码不变时扩大某个发行者的权力；删除根又可能在证书到期前终止接受。

Lu Heng 关于权威与相信的讨论在这里尤其适用：一个断言的发行者、接收者、范围与边界必须清楚。签名者能证明自己签过什么，不能替依赖方决定这份签名对哪个业务目的有权威。

密钥管理不是上线后的杂务

RFC 4107作为 BCP 107 区分自动与手工密钥管理。自动机制可以确认对端活性、生成新鲜密钥并支持规模化换钥；手工密钥只在边界明确的条件下合理，也仍须有标识、切换、替换和失陷处理。

每个安全结论都要带着密钥来源、生成方式、保存边界、对端绑定、用途、年龄、轮换、撤销和失陷状态。相同算法配合临时密钥与多年共用秘密，风险面完全不同。TLS 恢复所用票据密钥若长期不换，也可能削弱人们以为存在的前向保密属性。

没有换钥和退出设计时，第一次部署的秘密会从技术材料变成永久权力。届时加密仍在运行，组织却无法证明谁已经失去访问权。

防火墙的前提是一张会变化的地图

RFC 3631 将防火墙称为拓扑防御。它依赖清晰的内外边界，单独无法对付内部攻击。隧道、无线桥、直连出口或被攻陷的端点可以改变边界，而规则页面仍显示绿色。

基于地址或名称的认证也受 DHCP、路由、代理、欺骗和 DNS 影响。DNSSEC 能保护签名 DNS 数据的来源与完整性，但不能把底层错误关联变成真实，更不能把解析结果变成应用许可。

所以替代路径、云边缘、隧道、管理域和例外必须与密码配置一同版本化。上季度批准的规则即使文本不变，也可能因为新出口出现而失去语义。

从验证结果到运行结果，需要一条可追溯链

Lu Heng 的现实层次与运行代码优先提供了整理方法：规范声明、实现能力、运行配置、协商状态、验证结论、授权动作和可观察效果是相关但独立的记录。最小初始规范则说明，共同证据接口不应吞并本地未来决策。

一条敏感操作至少应保存：资源与威胁模型；所需安全属性；软件构建；政策与配置；报价与协商；参考身份、凭证、信任锚和验证；密钥生命周期；精确覆盖的包、记录或对象；应用主体与授权规则；允许或拒绝；最后是网络、应用和用户侧结果。警报、降级、旁路、重放拒绝、过期、名称不匹配、截断与政策例外都要留存。

开篇请求的密码验证没有撒谎。它只回答了一个较小的问题。真正的事故是组织把这个小答案升级成了权限，而没有保存任何有权完成升级的记录。

来源

1. RFC 3631 — Security Mechanisms for the Internet
2. RFC 3631 纯文本
3. RFC Editor 的 RFC 3631 信息页
4. IETF Datatracker 的 RFC 3631 记录
5. RFC 3631 文档历史
6. RFC 3631 勘误查询
7. RFC 2316 — IAB 安全架构研讨会报告
8. RFC 3365 — IETF 协议强安全要求
9. RFC 3552 — 安全考虑编写指南
10. RFC 4107 — 密钥管理指南
11. RFC 4301 — IP 安全架构
12. RFC 8446 — TLS 1.3
13. RFC 9325 — TLS 与 DTLS 安全使用建议
14. Lu Heng — Running Code Primary
15. Lu Heng — Minimum Initial Specification
16. Lu Heng — On Reality Layers
17. Lu Heng — On Authority and Belief