Kerberos 身份验证的工作原理

Question

我试图弄清楚 kerberos 身份验证是如何工作的，我发现的信息总是缺少某些东西，好像其中的一部分是理所当然的。我了解整个过程，但缺少一些细节。

获得 TGT：

1. 首先，用户应该从 KDC 获得一个 TGT（Ticket Granting Tickets）——用户发送的请求只有它的用户名 (UPN)，没有它的密码。提供了一些额外信息以防止重新发送请求，例如 IP 地址和时间戳。如果需要预认证，则时间与用户密码散列。

2. KDC 将向用户发送回以下信息： A. TGT - 带有时间戳、用户名、IP 地址和会话密钥 - TGT 使用只有 KDC 知道的秘密进行加密，因此任何人都不能更改。
   B. 用户和 KDC 的会话密钥，用于以后的通信。
   这些东西使用用户密码（KDC 和用户之间的基本共享秘密）加密。如果使用了预身份验证，服务器将在发回信息之前检查时间戳是否有效。

3. 用户接收信息并使用其密码对其进行解密 - 然后将其存储在其内存中（kerberos 托盘）。

获得TGS：

1. 当用户被请求从服务中进行身份验证时，他向 KDC 发送请求以获取 TGS（票证授予服务），该请求包含 TGT、UPN 和 SPN（服务主体名称 - 例如，网页的 URI） .

2. 然后 KDC 解密 TGT 并验证它的真实性，它与 UPN 对应，来自相同的 IP 地址并且仍然有效（票证有一个有效的时间段）。

3. KDC 向使用服务密码加密的用户发送 TGS。

4. 用户将 TGS 提交给服务 - 服务使用自己的密码对其进行解密。

5. 身份验证是完整的，因为该服务依赖于它的密码仅在它和 KDC 之间共享这一事实，因此它相信 KDC 之前对用户进行了身份验证。

几个问题：

1. 我错过了什么还是仅此而已？

2. 用户和 KDC 何时使用会话密钥？什么时候？为什么有必要？为什么用户密码不够用？

3. 用户和服务之间还应该有一个会话密钥（据我所知） - 何时以及为什么使用它（与最后一个问题相同）？

4. Kerberos 在各方之间有 5 分钟的间隔限制 - 我理解为什么保持时间同步很重要，因为它被用作我们加密和解密的东西，所以为什么任何间隔都可以？为什么是5分钟？

如果您有任何更正，我会很高兴。

提前致谢，托默

Answer 1

所以，我想我已经找到了答案。

我会做一些更正，因为这个问题有一些不准确的地方。

获得 TGT：

1. 首先，用户应该从 KDC 获得一个 TGT（Ticket Granting Tickets）——用户发送一个只有用户名 (UPN) 而没有密码的请求。提供了一些额外信息以防止重新发送请求，例如 IP 地址和时间戳。如果需要预认证，则时间与用户密码散列。
2. KDC 将向用户发送回以下信息：

A. TGT - 带有时间戳、用户名、IP 地址和会话密钥 - TGT 使用只有 KDC 知道的秘密进行加密，因此任何人都不能更改。

所有这些都简称为“身份验证器”。

B. 用户和 KDC 的会话密钥，用于以后的通信。 这些东西使用用户密码（KDC 和用户之间的基本共享秘密）加密。如果使用了预身份验证，服务器将在发回信息之前检查时间戳是否有效。

TGT 本身仅通过 KDC 的秘密进行散列，而不是通过用户的密码进行散列。

3. 用户接收信息并使用其密码对其进行解密 - 然后将其存储在其内存中（kerberos 托盘）。

获得TGS：

1. 当用户被请求从服务中对自己进行身份验证时，他会向 KDC 发送请求以获取 TGS（票证授予服务），该请求包含TGT、UPN 和 SPN

该请求还包括一个新的身份验证器（而不是提到的 UPN），KDC 将对照 TGT 中的身份验证器进行检查。验证器使用用户和 KDC 的会话密钥进行加密。KDC 将使用它的密码解密 TGT，然后从中提取会话密钥（它不保存信息），然后使用会话密钥解密验证器。

（服务主体名称 - 例如，网页的 URI）。

SPN 不包含 URI——它包含主机、服务和端口——类似于：HTTP/localhost:80 或 ldap/localdc。如果使用默认端口，则可以省略端口号（例如 80 用于 HTTP 或 389 用于 ldap）。

2. 然后 KDC 解密 TGT 并验证它的真实性，它与 UPN 对应，来自相同的 IP 地址并且仍然有效（票证有一个有效的时间段）。
3. KDC向用服务密码加密的用户发送TGS。

KDC 还会发送一个会话密钥供客户端和用户稍后使用。它以 KDC 和之前用户的会话密钥加密发送它 - 会话密钥的另一个副本（客户端和服务器）在 TGS 内部，在 TGS 内部也驻留了客户端的身份验证器。

4. 用户将 TGS 提交给服务 - 服务使用自己的密码对其进行解密。
5. 身份验证是完整的，因为该服务依赖于它的密码仅在它和 KDC 之间共享这一事实，因此它相信 KDC 之前对用户进行了身份验证。

用户还发送用客户端和服务器的会话密钥加密的验证器。然后服务器使用它的密码解密 TGS - 从 TGS 中提取会话密钥并使用它来解密验证器并将其与 TGS 中的进行比较。如果有效，则客户端的身份验证完成。Kerberos 还为客户端提供了一个选项来对服务器进行身份验证（称为相互身份验证）——如果客户端发送了相互身份验证的标志，那么还有另一个步骤。

6. 服务器向客户端发送一个时间戳，该时间戳使用他们的共享会话密钥加密。服务器通过操纵客户端发送的数据（意味着它可以解密）来证明它的真实性，因此它意味着它知道只有它和 KDC 应该知道的服务器密码。

几个问题：

1. 我错过了什么还是仅此而已？
2. 用户和 KDC 何时使用会话密钥？什么时候？为什么有必要？为什么用户密码不够用？
3. 用户和服务之间还应该有一个会话密钥（据我所知） - 何时以及为什么使用它（与最后一个问题相同）？
4. Kerberos 在各方之间有 5 分钟的间隔限制 - 我理解为什么保持时间同步很重要，因为它被用作我们加密和解密的东西，所以为什么任何间隔都可以？为什么是5分钟？

1. 是的。
2. 何时回答，至于原因 - 动机是为可选的攻击者提供较少的使用密码创建的数据样本，因此更难从加密数据中破解密码。会话密钥一直在变化（每次登录或 TGT 到期后），当攻击者可以破解它时，它就没有用了。
3. 回答。
4. 好吧，由于同步未完成，因此必须有一定的差距。我对这里的 5 分钟有一个猜测 - KDC 和服务器应该将最后 5 分钟的请求保留在内存中，以便攻击者不会重新发送有效请求并获得身份验证（称为重放攻击）。因此，每次发出请求时，服务器或 KDC 都必须查看内存以查看它是否不是重新发送的请求。显然，这是一种权衡，因为时间间隔越大，服务器需要分配给该任务的内存就越多。顺便说一句 - 默认情况下，时间段仅为 5 分钟，并且是可配置的。

希望它有帮助。

所有内容都在此链接中（如果从头到尾阅读整个内容，则非常重复-您应该只阅读您想了解的部分）-

我还阅读了一些 RFC - https://tools.ietf.org/html/rfc1510

还有两个不太详细的链接：

https://technet.microsoft.com/en-us/library/cc961976.aspx

https://technet.microsoft.com/en-us/library/aa480475.aspx（处理 IIS 身份验证 - 有一部分提到并解释了 kerberos）。