摘要

  • RFC 3652 将固定 20 字节、用于投递和重组的 Message Envelope，与固定 24 字节的消息头及操作专属消息体分开。Message Credential 中的数字签名不覆盖 Envelope，却覆盖消息头和消息体。
  • Credential 可以承载发起方的数字签名，也可以承载基于预先建立会话密钥的消息认证码（MAC）。这个边界说明的是协议的完整性保护范围，不是已记录的攻击、实现缺陷，也不意味着下层保护不可能。

一条消息包含不同的信任面

2003 年，Handle 系统协议规范需要定义的并不只是查询。客户端要找到负责的 Handle 服务器，请求解析或管理某个 Handle，再理解服务器的回应；协议也必须适应不同传输方式对数据的处理差异。RFC 3652 v2.1 把这些职责排成四个相邻部分：Envelope、Header、Body 和 Credential。RFC 3652

Envelope 总是存在，长度固定为 20 字节。RFC 把它称为用于正确投递消息的包装层，而不是应用层信息。其字段包括协议版本和消息标志、会话 ID、请求 ID、序列号和消息长度。必需的 Header 固定为 24 字节，保存各类操作共用的信息，包括操作码和响应码。Body 则承载操作专用数据，也可能为空。RFC 3652

信任边界并不等于分组边界。RFC 3652 明确说明，Message Credential 的数字签名不保护 Envelope 的内容，却会保护 Header 和 Body。非空 Credential 可以包含消息发起方的数字签名，或基于既有会话密钥生成的单向消息认证码。RFC 将其用途描述为认证客户端与服务器之间的消息，并检查传输后的数据完整性。MAC 依靠双方共享的密钥；数字签名采用不同的密钥模型。RFC 3652 RFC 2104

这种分层对应 Envelope 的职责。Handle 客户端可以通过 UDP 数据报或 TCP 字节流发送消息。RFC 3652 将 UDP 承载的消息限制在 512 字节以内，不计 IP 和 UDP 头部。更长的消息必须分段；每个分段都在 Envelope 中携带序列号，供接收方重组。TCP 虽然提供连续字节流，却不会自动提供 Handle 消息的边界；协议仍可把大消息分段后再重组。RFC 3652 RFC 768 RFC 793

相较之下，Header 和 Body 描述客户端与服务器正在做什么。操作码提出一种 Handle 操作；响应码报告成功、找不到值、服务转介、授权失败或需要认证。协议本身依照另一份文档定义的名称和数据模型，而 RFC 3650 说明整体服务架构。于是，受保护的语义内容从投递包装层之后才开始：重组一个分段，并不等于授权它所携带的操作。RFC 3652 RFC 3650 RFC 3651

认证不是授权

RFC 3652 也把客户端的证明与服务器的许可决定分开。执行管理操作时，服务器可以发出挑战；客户端以响应证明自己持有相应私钥或共享密钥。验证成功之后，服务器仍须检查管理员是否拥有所请求操作所需的权限。挑战响应通过，不代表服务器已经批准 Handle 变更。会话则可以让多项操作共享状态和密钥。RFC 3652

RFC 3552 将数据完整性、对端认证、机密性和系统安全视为不同目标；数字签名或 MAC 不会自动提供所有这些属性。RFC 3652 的安全章节谈及服务器签名与客户端认证，但格式定义限定得更具体：Credential 覆盖 Header 和 Body，不覆盖投递用的 Envelope。这句话本身不能证明任何已部署系统里发生过消息篡改；下层通信通道也可能提供其他保护。RFC 是协议规范，不是事故报告。RFC 3552 RFC 3652

也不能把 Handle Credential 与 X.509 签名配置混为一谈。RFC 3279 定义的是该公钥基础设施中证书和撤销列表的算法标识及编码；它不会扩大 RFC 3652 的签名字节范围，也不会把 Envelope 变成已认证内容。提到加密术语还不够，必须说清楚到底认证了哪个对象。RFC 3279 RFC 3652

RFC 3652 的类别是 Informational，IESG 说明也指出，当时的讨论并未形成关于 Handle 系统或其在 IETF 标识符架构中定位的共识。这份文件记录的是一个协议提案，不是普遍部署的证明。更有限、也更持久的教训是：消息封装、分段重组与认证可能各循不同规则；任何完整性主张都应指出 Credential 实际覆盖了哪些字节。RFC 3652

来源