摘要

  • 双向模式中，客户端把服务器的挑战值和自己刚生成的随机值一并签名。服务器最后也对这两个值签名，但还加入第三个值，因为客户端在选择自己的随机值之前，已经知道服务器的首个挑战。
  • 第三个值让服务器的响应绑定到新的随机输入，却没有把机制变成安全信道：RFC 3163 不提供完整性或机密性，并明确说主动攻击仍可能成功。

看似多余的第三个数

RFC 3163 的交互乍看像重复校验：服务器发送一个随机挑战，客户端签署包含它的交互记录；随后服务器也签署一份包含同一挑战的记录。服务器的最终令牌为何还要带第三个随机值？

2001 年 8 月发布的实验性 RFC 3163《ISO/IEC 9798-3 Authentication SASL Mechanism》把答案放在参与方作出选择的先后顺序里。关键不是消息有几条，而是谁在生成自己的随机值之前看到了对方的挑战。这个顺序决定签名究竟能够证明交互中的哪些联系。

该 RFC 定义两类 SASL 机制名。9798-U-<algorithm> 用于客户端向服务器的单向认证；9798-M-<algorithm> 则增加双向实体认证：客户端签署服务器的挑战，服务器再签署客户端的挑战。两者都以公钥数字签名和 X.509 证书为基础，认证步骤要求处理证书路径。

签名覆盖的先后关系

在两种模式下，服务器先生成随机值 R_B。随后客户端产生 R_A，并发送 TokenAB。其中有客户端证书资料，以及对 R_A 和 R_B 的签名；客户端还可以放入服务器标识。服务器需要验证签名、确认返回的 R_B 与先前发出的挑战一致，并在有标识时核对服务器身份。

单向模式的核心交互到这里就结束。双向模式还需要服务器答复：TokenBA2 携带服务器证书，并对 R_A、R_B 和一个新值 R_C 签名。客户端验证服务器证书与签名，再确认前两个随机值分别对应此前的交互，并检查可选的客户端标识。

第 7 节解释了第三个值的理由。客户端签名覆盖 R_A，因此服务器不能在机制开始前先挑好数据，再取得客户端对那批数据的签名。但反向情形并不对称：客户端是在已知 R_B 后才选择 R_A。服务器签名中包含 R_B 是必要的，客户端据此核对交互记录；然而，R_B 单独无法给服务器提供同等的保护。因此 RFC 3163 又把 R_C 放进服务器签署的 TokenBA2。

这只是 RFC 对特定签名设计的解释，不能扩大成“任何中间人、重放或主动攻击都已被解决”。随机值必须由密码学安全的随机数生成器产生；如果可预测，机制就可能受到攻击。第三个值回应的是文本描述的顺序差异，不是对其他未覆盖安全属性的修补。

认证并不等于保护会话

RFC 3163 明确限定：该机制只提供认证，不负责后续协议消息的完整性，也不隐藏消息内容。安全章节称它只能防范被动窃听；主动攻击仍可发生，包括会话劫持。IESG 的附注批评得更直接：机制承担了 PKI 的复杂性，却舍弃每次传输的完整性；TLS 能提供相近功能并保留完整性收益。

证书字段也不会把几个决策合成一步。TokenAB 中的 authID 可以表示与证书签名者不同、供访问控制使用的身份。证书路径是否被信任、机制是否认证成功、身份如何映射、应用允许该身份做什么，仍是不同问题。有效签名只能证明某把密钥签署了所覆盖的数据，并不能替应用作授权决定。

RFC 的 IMAP 示例也不是双向模式的实例。它展示的是 9798-U 客户端认证，并说明 Base64 编码及响应前的 + 符号来自 IMAP 配置文件，而非 SASL 机制本身。因此这段示例不能证明双向运行、部署普及或互操作结果。

Lu Heng 的 Note 20 在此仅作为分析视角：把协议实际核验的证据，与关于身份、权力或权限的更大主张分开。随机值对应关系及签名验证属于交互记录；信道保护和应用权限要由其他控制承担。这不是 RFC 3163 作者提出的论点。

来源

  1. RFC 3163 — ISO/IEC 9798-3 Authentication SASL Mechanism
  2. RFC Editor 的 RFC 3163 条目
  3. RFC 2222 — Simple Authentication and Security Layer
  4. RFC 4422 — Simple Authentication and Security Layer (SASL)
  5. RFC 2459 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  6. RFC 5280 — Internet X.509 Public Key Infrastructure Certificate and CRL Profile
  7. RFC 2630 — Cryptographic Message Syntax
  8. RFC 8017 — PKCS #1: RSA Cryptography Specifications
  9. RFC 2060 — Internet Message Access Protocol, Version 4rev1
  10. RFC 2195 — IMAP/POP AUTHorize Extension for Simple Challenge/Response
  11. IANA SASL 机制注册表
  12. NIST FIPS PUB 196 — Entity Authentication Using Public Key Cryptography
  13. Lu Heng，Note 20 — On Reality Layers, Symbolic Power, and Why Clarity Feels So Hostile