摘要

  • RFC 2444 用具名的 SASL 机制和明确的交换格式，取代应用各自解析一次性口令的临时做法。
  • OTP 机制可以完成认证交换，但本身不提供安全层、会话隐私、服务器身份认证或主动攻击防护。

1998 年的邮件协议不缺登录命令，缺的是一致的接入口。RFC 2444 的摘要点出当时的问题：应用把 OTP 以临时方式接入，再靠启发式解析猜测用户输入。它把这个办法收进 Simple Authentication and Security Layer（SASL），让协议能够请求一个有名字、有交互规则的 OTP 机制，而不必为每种应用另写口令解析器。

这种规范化解决的是“怎样接上”，不是“接上以后是否安全”。RFC 2222 早已把用户认证和可选的安全层分开：机制可以协商后续通信是否使用保护。RFC 2444 对自身边界更直接——OTP 机制不提供安全层。它明确不提供会话隐私、服务器认证，也不防主动攻击。因此，一次成功的认证响应只说明该交换完成；它不能证明后续命令所在的通道已加密或服务器已向用户证明身份。

机制沿用 RFC 2289 的 OTP 系统，并采用 RFC 2243 的扩展响应。服务端必须理解四种形式：hex、word、init-hex、init-word。前两种提交答案，后两种还承担重置序列的作用。规范要求支持 MD5，并建议支持 SHA-1；客户端应识别序列号过低的失败，并向用户提供重置选项。每次使用还会更新服务器的认证数据库记录。换言之，标准把消息形状定下来，也把版本兼容、状态推进和并发处理留成了运营责任。

RFC 2444 以不可信客户端（例如公共终端）说明用途。被截获的 OTP 最多应给该客户端一次替用户行事的机会。但这个限制不延伸到认证之后的会话。文档也指出，攻击者拿到认证数据库后仍可进行字典攻击；虽然该数据库不必等同于明文口令库，却不能因此视作无风险。规范同时提醒存在被动字典攻击，并要求实现保护底层 OTP 规范所说的竞争攻击。

SASL 还区分“用于证明凭证的身份”和“希望获得权限的身份”。两者可以不同：代理人可用自己的凭证认证，却请求另一个身份的权限；授权身份为空时，服务器可从认证凭证推导。于是 OTP 答对了，只是认证问题的答案，不是完整授权决定。SASL 机制名、挑战响应、宿主协议的编码、传输保护、服务器身份和应用权限之间仍有清楚的边界。

RFC 2444 更新了 1997 年的 SASL 规范，并把 S/Key SASL 机制的预期用途改为过时。后来 RFC 4422 取代最初的 SASL 框架；RFC 5034 给出了 POP3 配置，RFC 5802 则定义另一种机制 SCRAM。这些文件说明框架仍在演进，不能证明 RFC 2444 曾普遍部署，也不能把其 1998 年的算法建议当成今天的安全指南。标准描述应有行为，不是现网普查。

它的历史贡献不宜夸大：应用终于可以调用标准化的 OTP 入口，而非依赖各自的解析惯例。剩下的责任同样写在协议边界之外：协议设计者规定 SASL 令牌如何传送，实现者保证序列更新一致，运营者保护认证后的通信，应用决定该身份可以做什么。“一次性”限制的是答案的重复使用，不是整个会话的风险。

来源