3.3. The Ticket-Granting Service (TGS) Exchange (票据授予服务交换)

摘要

消息方向	消息类型	章节
1. 客户端到 Kerberos	KRB_TGS_REQ	5.4.1
2. Kerberos 到客户端	KRB_TGS_REP 或 KRB_ERROR	5.4.2 或 5.9.1

客户端与 Kerberos TGS 之间的 TGS 交换由客户端在寻求获取给定服务器的认证凭证 (该服务器可能在远程域中注册) 时、在寻求续期或验证现有票据时或在寻求获取代理票据时发起.在第一种情况下, 客户端必须已经使用 AS 交换获取了票据授予服务的票据 (TGT 通常在客户端最初向系统认证时获得, 例如当用户登录时).TGS 交换的消息格式几乎与 AS 交换相同.主要区别在于 TGS 交换中的加密和解密不在客户端的密钥下进行.相反, 使用 TGT 或可续期票据的会话密钥, 或来自认证器的子会话密钥.与所有应用程序服务器一样, TGS 不接受过期的票据, 因此一旦可续期或 TGT 过期, 客户端必须使用单独的交换来获取有效票据.

TGS 交换由两条消息组成: 从客户端到 Kerberos 票据授予服务器的请求 (KRB_TGS_REQ) 和回复 (KRB_TGS_REP 或 KRB_ERROR).KRB_TGS_REQ 消息包括对客户端进行认证的信息加上对凭证的请求.认证信息由认证头 (KRB_AP_REQ) 组成, 其中包括客户端先前获得的票据授予、可续期或无效票据.在 TGT 和代理情况下, 请求可以 (MAY) 包括以下一项或多项: 网络地址列表、要密封在票据中供应用程序服务器授权使用的类型化授权数据集合或附加票据 (其使用将在后面描述).TGS 回复 (KRB_TGS_REP) 包含请求的凭证, 在 TGT 或可续期票据的会话密钥中加密, 或者如果存在, 在来自认证器 (认证头的一部分) 的子会话密钥中加密.KRB_ERROR 消息包含错误代码和解释出错原因的文本.KRB_ERROR 消息未加密.KRB_TGS_REP 消息包含可用于检测重放并将其与它回复的消息关联的信息.KRB_ERROR 消息还包含可用于将其与它回复的消息关联的信息.第 3.1 节中提到的关于 KRB_ERROR 消息完整性保护的相同评论适用于 TGS 交换.

3.3.1. [Generation of KRB_TGS_REQ Message (生成 KRB_TGS_REQ 消息)]

在向票据授予服务发送请求之前, 客户端必须 (MUST) 确定应用服务器被认为在哪个域中注册.这可以通过几种方式完成.它可能是预先知道的 (因为域是主体标识符的一部分), 它可能存储在名称服务器中, 或者它可能从配置文件中获得.如果要使用的域是从名称服务器获得的, 则如果提供域名的名称服务未经认证, 则存在被欺骗的危险.这可能导致使用已被入侵的域, 这将导致攻击者能够破坏应用服务器对客户端的认证.

如果客户端知道服务主体名称和域, 并且它还不拥有适当域的 TGT, 则必须获得一个.这首先通过从客户端拥有 TGT 的 Kerberos 服务器请求目标域的 TGT 来尝试 (通过递归使用 KRB_TGS_REQ 消息).Kerberos 服务器可以 (MAY) 返回所需域的 TGT, 在这种情况下可以继续.或者, Kerberos 服务器可以 (MAY) 返回 "更接近" 所需域的域的 TGT (沿着客户端域和请求的域服务器域之间的标准层次路径更远).请注意, 在这种情况下, Kerberos 服务器的错误配置可能会导致结果认证路径中的循环, 客户端应该小心检测和避免.

如果 Kerberos 服务器返回 "更接近" 所需域的域的 TGT, 客户端可以 (MAY) 使用本地策略配置来验证使用的认证路径是可接受的.或者, 客户端可以 (MAY) 选择自己的认证路径, 而不是依赖 Kerberos 服务器选择一个.在任何一种情况下, 用于选择或验证认证路径的任何策略或配置信息, 无论是由 Kerberos 服务器还是由客户端, 都必须 (MUST) 从可信来源获得.

当客户端获得 "更接近" 目标域的 TGT 时, 客户端可以 (MAY) 缓存此票据并在将来与 "更接近" 域中的服务的 KRB-TGS 交换中重用它.但是, 如果客户端通过从初始 KDC 开始而不是作为获得另一个票据的一部分来获得 "更接近" 域的 TGT, 则可能会使用到 "更接近" 域的更短路径.这条更短的路径可能是理想的, 因为更少的中间 KDC 会知道所涉及的票据的会话密钥.出于这个原因, 客户端在决定将来使用票据时应该 (SHOULD) 评估它们是否信任在获得 "更接近" 票据时经过的域.

一旦客户端获得适当域的 TGT, 它确定哪些 Kerberos 服务器为该域提供服务并联系其中一个.该列表可能通过配置文件或网络服务获得, 或者它可以 (MAY) 从域的名称生成.只要域之间交换的密钥保持秘密, 使用虚假的 Kerberos 服务器只会导致拒绝服务.

与 AS 交换一样, 客户端可以 (MAY) 在 KRB_TGS_REQ 消息中指定许多选项.这些选项之一是用于用户到用户认证的 ENC-TKT-IN-SKEY 选项.用户到用户认证的概述可以在第 3.7 节中找到.生成 KRB_TGS_REQ 消息时, 此选项表示客户端在请求的附加票据字段中包含从应用服务器获得的 TGT, 并且 KDC 应该 (SHOULD) 使用此附加票据的会话密钥加密应用服务器的票据, 而不是使用主体数据库中的服务器密钥.

客户端准备 KRB_TGS_REQ 消息, 提供认证头作为 padata 字段的元素, 并包括与 KRB_AS_REQ 消息中使用的相同字段以及几个可选字段: 用于应用服务器使用的 enc-authorization-data 字段和某些选项所需的附加票据.

在准备认证头时, 客户端可以选择一个子会话密钥, 在该密钥下将加密来自 Kerberos 服务器的响应.如果客户端选择子会话密钥, 必须小心确保所选子会话密钥的随机性.

如果未指定子会话密钥, 将使用 TGT 的会话密钥.如果存在 enc-authorization-data, 则必须 (MUST) 在认证头的认证器部分的子会话密钥中加密 (如果存在), 或者如果不存在, 则使用 TGT 的会话密钥加密.

准备好后, 将消息发送到目标域的 Kerberos 服务器.

3.3.2. Receipt of KRB_TGS_REQ Message (接收 KRB_TGS_REQ 消息)

KRB_TGS_REQ 消息的处理方式与 KRB_AS_REQ 消息类似, 但需要执行许多额外的检查.首先, Kerberos 服务器必须 (MUST) 确定附带票据是为哪个服务器准备的, 并且它必须 (MUST) 选择适当的密钥来解密它.对于正常的 KRB_TGS_REQ 消息, 它将是票据授予服务, 并将使用 TGS 的密钥.如果 TGT 是由另一个域颁发的, 则必须 (MUST) 使用适当的域间密钥.如果 (a) 附带票据不是当前域的 TGT, 而是当前域中应用程序服务器的票据, (b) 在请求中指定了 RENEW、VALIDATE 或 PROXY 选项, 并且 (c) 请求票据的服务器是附带票据中命名的服务器, 则 KDC 将使用颁发给该服务器的密钥解密认证头中的票据.如果在 padata 字段中找不到票据, 则返回 KDC_ERR_PADATA_TYPE_NOSUPP 错误.

一旦附带票据被解密, 认证器中用户提供的校验和必须 (MUST) 针对请求的内容进行验证, 如果校验和不匹配 (错误代码为 KRB_AP_ERR_MODIFIED) 或校验和不具有防碰撞性 (错误代码为 KRB_AP_ERR_INAPP_CKSUM), 则必须 (MUST) 拒绝消息.如果不支持校验和类型, 则返回 KDC_ERR_SUMTYPE_NOSUPP 错误.如果存在授权数据, 则使用认证器中的子会话密钥解密它们.

如果任何解密指示完整性检查失败, 则返回 KRB_AP_ERR_BAD_INTEGRITY 错误.

如第 3.1.2 节所述, 如果 KDC 收到与其最近处理的 KRB_TGS_REQ 消息相同的消息, 则 KDC 必须 (MUST) 发送有效的 KRB_TGS_REP 消息.但是, 如果认证器是重放, 但请求的其余部分不相同, 则 KDC 应该 (SHOULD) 返回 KRB_AP_ERR_REPEAT.

3.3.3. Generation of KRB_TGS_REP Message (生成 KRB_TGS_REP 消息)

KRB_TGS_REP 消息与 KRB_AS_REP (KRB_KDC_REP) 共享其格式, 但其类型字段设置为 KRB_TGS_REP.详细规范在第 5.4.2 节中.

响应将包括请求服务器的票据或要联系的中间 KDC 的票据授予服务器的票据以获取请求的票据.查询 Kerberos 数据库以检索适当服务器的记录 (包括将用于加密票据的密钥).如果请求是远程域的 TGT, 并且如果没有与请求域共享密钥, 则 Kerberos 服务器将选择与请求域 "最接近" 的域 (与其共享密钥) 并改用该域.这是 KDC 的响应将是针对与客户端请求的服务器不同的服务器的唯一情况.

默认情况下, 新颁发票据的地址字段、客户端名称和域、传递域列表、初始认证时间、过期时间和授权数据将从 TGT 或可续期票据复制.如果需要更新传递字段但不支持传递类型, 则返回 KDC_ERR_TRTYPE_NOSUPP 错误.

如果请求指定了结束时间, 则新票据的结束时间设置为以下项的最小值: (a) 该请求, (b) TGT 的结束时间, 以及 (c) TGT 的开始时间加上应用程序服务器的最大生命周期和本地域的最大生命周期的最小值 (请求主体的最大生命周期在颁发 TGT 时已经应用).如果新票据要续期, 则上述结束时间将替换为以下项的最小值: (a) 票据的 renew_till 字段的值和 (b) 新票据的开始时间加上旧票据的生命周期 (endtime-starttime).

如果已请求 FORWARDED 选项, 则生成的票据将包含客户端指定的地址.仅当在 TGT 中设置了 FORWARDABLE 标志时, 才会接受此选项.PROXY 选项类似; 生成的票据将包含客户端指定的地址.仅当在 TGT 中设置了 PROXIABLE 标志时, 才会接受它.在对附加 TGT 的请求中不会接受 PROXY 选项.

如果请求的开始时间不存在、指示过去的时间或在 KDC 可接受的时钟偏移窗口内并且未指定 POSTDATE 选项, 则票据的开始时间设置为认证服务器的当前时间.如果它指示超出可接受时钟偏移的未来时间, 但未指定 POSTDATED 选项或未在 TGT 中设置 MAY-POSTDATE 标志, 则返回错误 KDC_ERR_CANNOT_POSTDATE.否则, 如果 TGT 设置了 MAY-POSTDATE 标志, 则生成的票据将被延期, 并根据本地域的策略检查请求的开始时间.如果可接受, 则按请求设置票据的开始时间, 并设置 INVALID 标志.延期票据在使用前必须 (MUST) 通过在到达开始时间后将其呈现给 KDC 来验证.但是, 在任何情况下, 新颁发的延期票据的开始时间、结束时间或 renew-till 时间都不得超出 TGT 的 renew-till 时间.

如果已指定 ENC-TKT-IN-SKEY 选项并且在请求中包含了附加票据, 则表示客户端正在使用用户到用户认证向没有访问持久密钥的服务器证明其身份.第 3.7 节描述了此选项对整个 Kerberos 协议的影响.在生成 KRB_TGS_REP 消息时, KRB_TGS_REQ 消息中的此选项告诉 KDC 使用颁发附加票据的服务器的密钥解密附加票据并验证它是 TGT.如果请求中缺少请求服务器的名称, 则将使用附加票据中客户端的名称.否则, 将请求服务器的名称与附加票据中客户端的名称进行比较.如果不同, 则拒绝请求.如果请求成功, 则将使用附加票据中的会话密钥来加密颁发的新票据, 而不是使用新票据将使用的服务器的密钥.

如果 (a) 作为认证头一部分呈现给 KDC 的票据中的服务器名称不是 TGS 本身的名称, (b) 服务器在 KDC 的域中注册, 并且 (c) 请求了 RENEW 选项, 则 KDC 将验证在票据中设置了 RENEWABLE 标志, 在票据中未设置 INVALID 标志, 并且 renew_till 时间仍在未来.如果请求了 VALIDATE 选项, KDC 将检查开始时间是否已过以及是否设置了 INVALID 标志.如果请求了 PROXY 选项, 则 KDC 将检查在票据中是否设置了 PROXIABLE 标志.如果测试成功并且票据通过了下一节中描述的热列表检查, KDC 将颁发适当的新票据.

KRB_TGS_REP 消息中响应的密文部分在认证器中的子会话密钥 (如果存在) 或 TGT 中的会话密钥中加密.它不使用客户端的密钥加密.此外, 客户端密钥的过期日期和密钥版本号字段被省略, 因为这些值与客户端的数据库记录一起存储, 并且不需要该记录来满足基于 TGT 的请求.

3.3.3.1. Checking for Revoked Tickets (检查已撤销的票据)

每当向票据授予服务器发出请求时, 都会针对已取消票据的热列表检查呈现的票据.此热列表可能通过存储 "可疑票据" 的颁发时间戳范围来实现; 如果呈现的票据的 authtime 在该范围内, 则将被拒绝.这样, 一旦向服务器所在域的 KDC 报告了盗窃, 被盗的 TGT 或可续期票据就不能用于获取附加票据 (续期或其他).在报告被盗之前获得的任何正常票据仍将有效 (因为票据不需要与 KDC 交互), 但仅在其正常过期时间之前.如果为跨域认证颁发了 TGT, 则使用跨域 TGT 不会受到影响, 除非将热列表传播到颁发此类跨域票据的域的 KDC.

3.3.3.2. Encoding the Transited Field (编码传递字段)

如果作为认证头一部分呈现给 KDC 的 TGT 中服务器的身份是票据授予服务的身份, 但 TGT 是从另一个域颁发的, 则 KDC 将查找与该域共享的域间密钥并使用该密钥解密票据.如果票据有效, 则 KDC 将遵守请求, 但须遵守上面描述 AS 交换的章节中概述的约束.客户端身份的域部分将从 TGT 中获取.如果颁发 TGT 的域的名称不是客户端主体的域, 则将其添加到要颁发的票据的传递字段中.这是通过从 TGT 读取传递字段 (将其视为域名的无序集合)、将新域添加到集合, 然后构造和写出其编码 (简写) 形式 (这可能涉及现有编码的重新排列) 来完成的.

请注意, 票据授予服务不会添加其自己域的名称.相反, 它的职责是添加前一个域的名称.这可以防止恶意 Kerberos 服务器故意遗漏自己的名称 (但是, 它可以省略其他域的名称).

本地域和主体域的名称都不包括在传递字段中.它们出现在票据的其他地方, 并且已知两者都参与了主体的认证.因为不包括端点, 所以本地和单跳域间认证都会导致传递字段为空.

因为此字段添加了每个传递域的名称, 所以它可能非常长.为了减少此字段的长度, 使用其编码格式 (在第 3.3.3.2 节的其余部分中描述).

3.3.4. [Receipt of KRB_TGS_REP Message (接收 KRB_TGS_REP 消息)]

当客户端从 KDC 接收到 KRB_TGS_REP 消息时, 它以类似于处理 KRB_AS_REP 的方式处理该消息.回复的加密部分使用 TGT 的会话密钥解密, 如果存在子会话密钥, 则使用认证器中的子会话密钥解密.验证随机数以检测重放.新凭证存储在凭证缓存中以供将来使用.

有关完整的处理细节和验证步骤, 请参考原始 RFC 4120 文档第 3.3.4 节.