3.6. The KRB_CRED Exchange (KRB_CRED 交换)

KRB_CRED 消息可以 (MAY) 由需要能够将 Kerberos 凭证从一个主机发送到另一个主机的客户端使用。它通过将票据与包含会话密钥和与票据相关的其他信息的加密数据一起发送来实现这一点。

3.6.1. KRB_CRED 消息的生成

当应用程序希望发送 KRB_CRED 消息时, 它首先 (使用 KRB_TGS 交换) 获取要发送到远程主机的凭证。然后它使用这样获得的一个或多个票据构造 KRB_CRED 消息, 将使用每个票据所需的会话密钥放在 KRB_CRED 消息的加密部分的相应 KrbCredInfo 序列的 key 字段中。

在 KRB_TGS 交换期间获得的与每个票据相关的其他信息也放置在 KRB_CRED 消息的加密部分中的相应 KrbCredInfo 序列中。当前时间以及 (如果应用程序特别需要) nonce, s-address 和 r-address 字段被放置在 KRB_CRED 消息的加密部分中, 然后使用先前在 KRB_AP 交换中交换的加密密钥 (通常是通过子密钥协商的最后一个密钥, 或者如果没有发生协商则是会话密钥) 对其进行加密。

实现说明: 在构造 KRB_CRED 消息以包含在 GSSAPI 初始上下文令牌中时, MIT 的 Kerberos 实现如果会话密钥是 DES 或三重 DES 密钥, 则不会加密 KRB_CRED 消息。为了与 MIT 的互操作性, 如果 Microsoft 实现使用 DES 会话密钥, 则不会加密 GSSAPI 令牌中的 KRB_CRED。从版本 1.2.5 开始, MIT Kerberos 可以接收和解码 GSSAPI 交换中的加密或未加密 KRB_CRED 令牌。Heimdal 的 Kerberos 实现也可以接受加密或未加密的 KRB_CRED 消息。由于 GSSAPI 令牌中的 KRB_CRED 消息在认证器中加密, MIT 的行为不会带来安全问题, 尽管它违反了 Kerberos 规范。

3.6.2. KRB_CRED 消息的接收

当应用程序接收到 KRB_CRED 消息时, 它会验证它。如果发生任何错误, 将报告错误代码供应用程序使用。通过检查协议版本和类型字段是否分别匹配当前版本和 KRB_CRED 来验证消息。不匹配会生成 KRB_AP_ERR_BADVERSION 或 KRB_AP_ERR_MSG_TYPE 错误。然后应用程序解密密文并处理结果明文。如果解密显示数据已被修改, 则生成 KRB_AP_ERR_BAD_INTEGRITY 错误。

如果存在或需要, 接收者可以 (MAY) 验证操作系统报告的发送者地址是否与消息中的发送者地址匹配, 以及接收者的地址之一是否作为接收者地址出现在消息中。地址检查不提供任何额外的安全性, 因为如果存在地址, 它已经在 KRB_AP_REQ 消息中检查过, 并且攻击者将 KRB_CRED 消息反射回其发起者不会获得任何好处。因此, 接收者可以 (MAY) 忽略地址, 即使它存在, 以便在网络地址转换 (NAT) 环境中更好地工作。任一情况的匹配失败都会生成 KRB_AP_ERR_BADADDR 错误。接收者可以 (MAY) 跳过地址检查, 因为 KRB_CRED 消息通常不能反射回发起者。接下来检查时间戳和 usec 字段 (以及 nonce 字段, 如果需要)。如果时间戳和 usec 不存在, 或者如果它们存在但不是当前的, 则生成 KRB_AP_ERR_SKEW 错误。

如果所有检查都成功, 应用程序将每个新票据与来自 KRB_CRED 消息的加密部分的相应 KrbCredInfo 序列中的会话密钥和其他信息一起存储在其凭证缓存中。