摘要

  • draft-ietf-kitten-sasl-ht-02 提议用短期、纯临时共享令牌进行两消息 SASL 重认证。发起方与响应方分别对角色字符串、所选信道绑定数据和可选键值对计算 HMAC。
  • 修订版 02 是 KITTEN 工作组的活跃 Internet-Draft，处于工作组最后征求意见阶段，拟定为 Proposed Standard，2026 年 12 月 24 日到期；它不是 RFC、实现报告或部署事实。
  • ENDP、UNIQ、EXPR 与 NONE 表达不同证据。NONE 把空串作为绑定数据；HMAC 验证成功不能事后补出并未参与计算的 TLS 绑定。
  • 可审计的系统必须分别保存令牌签发、机制锁定、TLS 对端、绑定类型、双向验证、重放与用量预留、撤销收敛、当前授权、会话世代和应用结果。

机制名本身就是证据边界

SASL-HT 机制名以 HT2- 开始，随后是哈希算法，再以信道绑定类型结束。ENDP、UNIQ、EXPR 关联不同的 TLS 输入；NONE 明确表示不使用信道绑定，并令 cb-data 为空。

这不是命名装饰。发起方 HMAC 的输入包含字面角色 Initiator、cb-data 与发起方附加值；响应方使用 Responder、同类绑定输入和响应方附加值。验证只能证明实际进入计算的对象。若输入为空，结果证明的是令牌持有和消息完整性，不是令牌与某条 TLS 信道之间的绑定。

运营系统最容易在这里制造“证据升级”。它收到统一的成功事件，没有保留完整机制名，只知道这是 HT，于是渲染成“mutual + channel bound”。一旦原始类型被丢弃，审计者无法判断成功来自 exporter、端点证书、旧式 unique 输入，还是根本没有绑定。

最低限度的收据应保留完整机制名、TLS 对端身份、绑定类型、绑定输入的安全摘要或明确缺席、连接标识与握手世代。若本地策略要求 EXPR，NONE 的 HMAC 再正确也只能说明密码学验证通过、策略未通过。

令牌在签发时已经带着一段历史

草案要求应用协议扩展提供申请令牌的机制。返回值必须由密码学安全随机数生成器新近产生，并至少包含 128 位熵。它还建议让申请方声明准备用哪个 SASL 机制；如果实际使用不同机制，认证必须失败。

因此，机制绑定不是验证时临时猜出来的属性。签发记录需要保存主体、服务、前序强认证、拟用机制、签发世代、过期规则和用量规则。若复制到验证节点的只有秘密值，没有机制锁定字段，节点即使算对 HMAC，也没有足够材料执行降级保护。

随机性同样不能替代谱系。高熵说明难以猜测，不说明令牌由正确服务签发、属于当前账户、源自足够强的认证，也不说明后来权限没有变化。把“随机而新”写成“仍被授权”，就是从对象属性跳到了制度结论。

草案还说明，这种令牌不加盐且只做一次哈希迭代，不适合保护长期共享秘密，例如密码。HT 令牌库不能因为运行稳定，就逐渐被当成密码库或永久恢复根。

两个 HMAC 证明两个方向

服务器收到发起消息后重新计算 HMAC；相等时，草案把发起方视为通过认证，不等则必须失败。随后服务器发送成功或失败响应。成功响应可以带附加值，并以响应方 HMAC 收尾。

客户端必须验证响应方消息，才能得到双向认证。服务器端的一条 success 日志只证明服务器做过自己的计算与决定，不证明客户端收到了响应，更不证明客户端验过响应 HMAC。网络可能在发送后断开，解析可能失败，客户端也可能错误地跳过验证。

这一区别直接影响重试。服务器或许已经占用并撤销令牌；客户端却把结果视为未知；另一节点还未看到消费状态。若三者都被压成“认证成功”，下一次使用发生时就没有可解释的状态机。

收据应分开记录：发起消息收到、HMAC 比较、用量预留、响应消息生成、响应发出、客户端后续行为、撤销提交与复制确认。协议只有两个消息，运营证据却不应只有一个布尔值。

经过认证的字段仍需解释权

发起方和响应方都可以加入任意键值对。因为这些字节进入 HMAC，它们获得完整性与来源保证。草案举出的用途包括携带最初提供的 SASL 机制与信道绑定类型的降级保护哈希。

但 HMAC 不定义字段模式。它不决定未知键应拒绝还是忽略，不决定同名冲突，不决定某身份能否请求某会话世代，也不决定响应方给出的上下文是否足以驱动应用动作。

一条“经过认证”的 role=admin 仍只是令牌持有者真实发送了这串字节。权限系统必须检查当前账户、服务范围、策略版本和所请求动作。若权限在令牌签发后被收回，旧令牌可能继续通过密码学验证，却不能冻结旧授权。

所以字段收据应包含原始字节摘要、模式版本、允许键集合、解析结果、策略决策、拒绝原因与下游状态变化。真实性是输入条件，不是执行许可。

0-RTT 让证明提前，也让重放边界必须可见

发起消息可以放进 TLS 1.3 早期数据。此时，除了 HT 消息和 SASL profile 必需的封装，发起方不得再放应用载荷；若出现额外载荷，响应方必须中止 SASL 认证。草案给出的理由是早期数据可能被重放。

这条边界意味着：可以把认证证明设计成幂等早期操作，不能把付款、删除、密钥变更或会话修改夹在旁边，然后借认证成功声称动作恰好执行一次。服务端仍需进行重放检查、用量预留和当前授权，之后才可接纳非幂等工作。

即使响应方在成功消息旁带回应用数据，客户端也还要验证响应 HMAC，应用还要解释这些数据。减少网络往返没有减少控制面数量，只是改变了它们发生的顺序。

“短期”必须落在时钟和计数器上

草案建议令牌按经过时间或使用次数限制寿命，并建议扩展支持轮换或撤销；示例流程显示服务在成功使用后撤销令牌。示例表达设计意图，不是分布式提交收据。

系统需要回答具体问题：谁的时钟决定过期？计数器是单节点、单区域还是全局？验证前预留会不会因失败烧掉令牌？响应发出后再消费会不会留下双重接受窗口？节点崩溃时如何分类第一次结果？

对于多区域服务，高熵与有效期都不能解决复制延迟。两台节点可能同时持有同一正确记录，并都得到正确 HMAC。要实现一次性语义，必须把占用、消费或撤销放入能覆盖所有合格验证者的状态边界，或者诚实承认它只是有限时间内可多次使用的凭证。

策略强度应跟随后续影响。若认证后仍需新鲜授权、且只创建可撤销的新会话，短暂重复可能可控。若它直接恢复高权限控制台，一次双重接受可能触发不可逆动作，消费一致性就必须更强。

authcid 不是当前授权结论

草案明确指出，HT 不能传递授权身份字符串，也不保护授权身份；它提供信道绑定，而非 SASL 安全层。成功结果因此不能替代权限判断。

authcid 告诉服务器谁在提出认证。应用还需把它映射到当前账户状态、禁用标志、角色、服务范围和具体动作。令牌在角色变更前签发，不代表变更后仍可沿用旧权限。

会话恢复也在应用层。队列游标、文档版本、锁、订阅和事务上下文都不自动进入 HMAC。应用需要命名会话 ID、上一世代、目标世代与冲突策略；找不到正确状态时，应选择新建、拒绝或要求完整认证，而不是把身份成功改写成状态已恢复。

能在事后回答问题的收据

一组克制但有效的收据包括：不含秘密的令牌记录 ID、签发方、前序认证类型、主体与服务、拟用机制、签发时间、过期与用量规则、TLS 对端、绑定类型、双向消息摘要、附加字段模式、重放预留、消费或撤销提交、复制范围、当前授权策略、会话世代、获准动作与观察结果。

敏感材料不能为了“完整日志”而复制。原始令牌、可复用认证器和 exporter 数据需要严格保管。目标是建立可连接的非秘密凭据，让系统能够说清证据停在哪一层。

最终用语也应分层：HMAC 已验证；双向验证已完成；令牌消费在某范围内已提交；当前策略允许某会话转换；应用产生某结果。未证明的后半句不能由前半句代写。

来源