摘要

  • RFC 1510 用 Realm 间密钥连接 Kerberos 域。票据的 transited 只列中间项；直连时这里可以为空。要看清谁访问谁，还得核对票据中的客户端 Realm 和服务 Realm。
  • RFC 4120 把最后的接受或拒绝权交给应用服务器。若 KDC 未设置路径检查标志，应用必须自行核验路径或拒绝票据；这项检查由接收服务执行。

分析

名单两端，恰好不在名单里

用两个示意 Realm 来看。一名用户登记在 ALPHA.EXAMPLE，要访问 BETA.EXAMPLE 的文件服务。两边共享所需密钥，路径中也没有第三个 Realm。此时 transited 为空，票据其他字段仍写着用户和服务的 Realm。排障时，这个空值说明中间没有站点；两端字段仍须核对。

RFC 1510 把 Realm 描述为管理域，每个域运行自己的 Kerberos 服务。客户端主体名带有所属 Realm；接收服务也可据此决定是否接受请求。管理员用 Realm 间密钥连接两个域，两个方向可以分别设密钥。远端 Realm 会把对方的票据授予服务（TGS）登记为主体，再用共享密钥解开对方签发的票据。

客户端不必在每个目标 Realm 都有账户。它先取得发往远端票据授予服务（TGS）的票据授予票据（TGT），再用它申请目标应用的服务票据。共享密钥搭起加密连接；是否建立和维护这种关系，由管理员决定。

中间Realm成组记录，先后顺序另有其处

路径可能有多个中间 Realm。RFC 1510 称常见结构是层级：每个 Realm 与父级共享密钥，也为每个子级设单独密钥。两端没有直连密钥时，层级可以拼出路径。规范也允许绕开中间 Realm 的替代路径，以提高效率。非层级网络可能还需查询另一份数据库来构造路径。

RFC 1510 把中间 Realm 存成无序集合，并压缩常见的层级名称。字段能列出中间 Realm，却不保留先后顺序；要还原时间线，运维人员得查其他记录。

TGS 会加入签发刚收到票据的前一 Realm，自身 Realm 则留在字段之外。RFC 1510 给出的理由是，服务器不能靠删掉自己的名字来隐藏参与。规范也允许省略其他 Realm，因此接收服务还要按本地信任政策检查余下名单。

2005 年，RFC 4120 取代 RFC 1510，并规定谁最后拍板。应用服务器接受或拒绝认证，也要确认参与的 KDC 对该用户可信。目标 Realm 的 KDC 可以按本域政策检查路径，并在服务票据中设置 TRANSITED-POLICY-CHECKED。没有这个标志，应用必须自行核验路径或拒绝票据。RFC 4120 还指出，不可信 KDC 可能伪造名单。

控制权分在三处。管理者添加 Realm 间密钥；KDC 签发票据并标记做过的检查；应用选择接受哪些路径。新增一把密钥会缩短认证步骤，也会让更多身份可以访问相连服务。配置中多出的一行，定义了未来的访问关系；网络图只是它的示意。

RFC 1510 在 1993 年 9 月写道，协议仍在审议，尚未提交为 Internet 标准。RFC 4120 于 2005 年进入 Standards Track，并明确了实现方责任。还缺一份 1990 年代部署记录，说明哪些应用服务器检查过 transited；有了它，才能判断这项控制是否进入当时的运行系统。

来源