摘要

  • RFC 3961 把非零的 32 位密钥用途编号纳入加密与校验，让同一基础密钥在不同消息、方向和协议职责中派生出不同的具体密钥。
  • 在简化配置中，用途编号还与 0x99、0xAA、0x55 组合，分别派生校验、加密和完整性密钥；验证通过证明的是这一密码上下文一致，不是业务授权已经成立。

先看一条最容易被日志掩盖的记录：decrypt=success。它看起来像终点，实际上只是中间收据。哪种消息被解开？采用哪个加密类型？使用哪个用途编号？基础密钥属于谁？消息是否新鲜？应用是否允许这项操作？若这些问题没有各自的记录，“成功”会把若干不同权力折叠成一个布尔值。

RFC 3961 在 2005 年处理的正是这种折叠。它没有为 Kerberos 指定唯一算法，而是定义加密与校验机制必须提供的共同轮廓。协议持有“基础密钥”，具体加密系统再根据用途生成“具体密钥”。上层文档只需说明：用这把密钥、这个用途编号加密这些字节。初始向量、填充、派生结构和完整性计算留在配置内部。

算法编号只是入口

RFC 给加密类型与校验类型分配编号，却明确要求完整配置还要定义密钥格式、字符串转密钥、随机数转密钥、派生函数、密码状态、加解密、完整性和伪随机函数。缺少任何一项，机制都不完整。因此 etype=17 之类的数字只是指向规范的索引，不能独自证明客户端支持、服务端启用、KDC 选择，或一次交换安全完成。

今天的 IANA Kerberos 参数登记表 延续了这种作用：它保存编号、名称与引用来源。登记是可互操作词汇，不是部署遥测。RFC 4537 又把“支持”和“选中”分开：客户端可以按偏好提交类型列表，服务端依据本地策略选择并返回子密钥。登记、提供、选择、实际保护流量，是四张不同收据。

用途编号把协议语义写入派生

RFC 3961 认为一把密钥承担多种工作并不稳妥，于是把 Kerberos 各项密钥用途编号化。编号是公开的无符号 32 位整数，零被禁止；新的消费协议应当拥有自己的值。它不是口令，也不是访问令牌。它的作用是让同一基础密钥在不同语义场景中产生不同材料。

简化配置把这种设计写成五个字节：四字节大端用途编号，再接一个区分字节。usage | 0x99 派生独立校验用的 Kc，usage | 0xAA 派生加密用的 Ke，usage | 0x55 派生密文完整性用的 Ki。基础密钥只用于派生；一个具体密钥泄露，不应反推出其他具体密钥。

这并非形式上的整洁。RFC 的安全章节指出，有些软件在 Kerberos v4 与 v5 之间复用密钥，v4 的加密预言机因而可能帮助攻击 v5。随机混淆值降低可预测明文的价值，用途隔离则缩小“一把钥匙通吃多个协议动作”的范围。文档描述的是攻击机制，不是某次已证实事故。

完整性通过，不等于权力通过

解密流程必须校验完整性，失败就丢弃数据。通过意味着密文、派生密钥、用途上下文与标签彼此一致。它不会单独告诉系统：基础密钥究竟绑定哪个主体，上层是否用了规范指定的用途，票据是否新鲜，是否存在重放，应用是否批准请求，服务最后是否交付。

这些判断来自别处。RFC 4120 定义 Kerberos V5 的票据、认证器和协议流程，并取代较早的 RFC 1510。RFC 6113 把该密码框架用于通用预认证。每一层都能引用下一层的结果，却不能代替下一层的授权。

所以一条可审计链至少要保存：消息类型、协商与实际选中的 etype、非秘密的密钥版本或引用、用途编号及其规范条款、受保护对象哈希、实现版本、完整性结果、新鲜度与重放检查、票据结果、应用授权和最终服务结果。秘密密钥本身不应进入日志。

框架留下，第一代算法退场

RFC 3961 的抽象经受了算法更替。RFC 3962 用它定义 AES 类型；RFC 6649 后来弃用单 DES，RFC 8429 又更新 RFC 3961 并弃用更多旧算法。弃用是标准立场，不能反推所有域都已经移除旧配置。

RFC 8009 更能说明抽象的价值：它遵守 RFC 3961 的大框架，却明确不采用简化配置，因为现代做法要求先验证密文再解密。具体构造被替换，协议与密码系统之间的接口仍然成立。

RFC Editor 条目与 Datatracker 记录证明文档状态和历史。勘误页则分别记录了已确认的 Unicode 码点修正、留待文档更新的旧 DES 种子长度问题，以及一项被拒绝的校验机制修改建议。它们维护的是规范证据，不是生产故障清单。

RFC 3961 的历史价值，不是宣称 Kerberos 从此“足够安全”。它迫使协议说明密钥正在做什么，并让这项说明改变实际派生出的密钥。用途编号没有授予权力；它阻止不同权力场景在密码层悄悄混成同一件事。

来源