摘要

  • RFC 1964 用机制 OID 与 TOK_ID 标明 Kerberos V5 GSS-API 令牌类别，再由认证器中的 0x8003 校验和承载通道绑定摘要、上下文服务标志与可选 KRB_CRED。
  • 零值 Bnd 只表示调用方没有提供绑定；单向 KRB_AP_REQ 没有接受方确认；KRB_CRED、MIC、Wrap 与序列状态也都不能替代下游授权和应用回执。

安全系统最容易产生的一种误会，是把“字段存在”当成“事实已经发生”。抓包里出现 Kerberos 机制 OID、01 00、六个标志位和一个序列号，看起来像一条完整的证明链。RFC 1964 实际给出的却是一组彼此相邻、含义严格受限的收据。

1996 年 6 月发布的 RFC 1964 为 Kerberos V5 GSS-API 机制指定 1.2.840.113554.1.2.2。初始上下文令牌以 01 00 标识 KRB_AP_REQ；返回的 KRB_AP_REP 用 02 00，KRB_ERROR 用 03 00。MIC、Wrap 和上下文删除也各有类型号。类型号回答“按哪种语法解释”，却不回答令牌是否校验通过、是否属于预期上下文、是否仍在有效期内。

Bnd 记录输入，不创造通道

KRB_AP_REQ 的认证器使用 0x8003 类型校验和承载 GSS-API 上下文信息。前四字节以小端序写入长度 16，随后 16 字节是对调用方通道绑定结构中非空部分计算的 MD5 摘要。整数、长度与数据各有明确编码规则。

关键例外是 GSS_C_NO_BINDINGS：此时 Bnd 被直接设为十六个零。它不是某条默认 TLS 通道、套接字、地址对或主机身份的指纹。它准确表达的是“调用方没有给机制任何通道绑定”。如果应用没有预先约定绑定类型、没有在两端提供可比较的输入，机制无法凭空证明外层通道是谁。

摘要之后的四字节标志也不能被读成结果表。委托、互认证、重放检测与顺序检测，是调用方请求和机制可用能力的逻辑与；机密性和完整性表示逐消息服务可用。“可用”与“已经使用”不同，“请求”与“已经完成”也不同。互认证位只会让返回路径成为必要条件，它本身不是返回包。

互认证必须在反方向留下痕迹

若应用没有设置 mutual_req，RFC 1964 明确规定上下文建立执行单向认证：目标不会因这次 KRB_AP_REQ 向发起方返回确认令牌。目标可能已经验证发起方，发起方却没有因此得到目标的确认。

需要确认的应用必须请求互认证。KRB_AP_REQ 的 APOptions 出现 mutual-required，认证器校验和也出现 mutual 标志。目标随后返回 KRB_AP_REP 或 KRB_ERROR。两者都是返回，但只有校验有效的 KRB_AP_REP 表示互认证交换成功；KRB_ERROR 是失败路径。仅记录“收到响应”会丢失最重要的分支。

即使 KRB_AP_REP 有效，它也只完成上下文建立。它没有替应用解释下一条命令，更没有证明数据库写入、文件访问或业务交易被接受。

委托凭据不是授权书

启用委托时，校验和值超过基础的 24 字节：委托选项 1、长度、以及一个 KRB_CRED。RFC 1964 要求其中转交的 TGT 带 FORWARDABLE 标志。接受方因此获得了请求其他服务票据的能力材料。

但能力还要经过一条新的链：KRB_CRED 解密与校验、凭据缓存保存、生命周期判断、向 KDC 申请具体服务票据、目标服务执行授权策略。KRB_CRED 的转交可以证明凭据到达，不能证明下游服务允许了任何动作。委托标志若没有对应选项和凭据校验，证据还要更弱。

MIC 与 Wrap 只结算消息层

MIC 的 TOK_ID 是 01 01，保护与令牌分离的用户数据完整性；Wrap 的 02 01 把数据装入带完整性、可选加密的令牌。两者还保护序列号和方向指示。可是重放与乱序检测是可选服务，调用方可以请求关闭。

所以，MIC 校验通过只回答数据与上下文校验和之间的关系；Unwrap 成功只回答该保护令牌的处理结果；序列状态只在相应服务启用时说明重复、陈旧或乱序。应用仍需解析内容、检查权限、执行状态变化并给出自己的回执。

RFC 4121 后来更新了机制格式，RFC 6649 又废弃了当年的弱算法。今天不能把 RFC 1964 的 DES/MD5 设计当成密码学建议。但它保留了一个很现代的运营方法：每个符号只拥有运行代码赋予它的那一步效果。以“运行代码优先”作为编辑框架时，OID 是选择器，TOK_ID 是语法标签，Bnd 是输入摘要，标志是上下文能力，KRB_AP_REP 是互认证回执，KRB_CRED 是凭据转交，MIC/Wrap 是消息保护；应用结果仍须由应用证明。

来源