gpt4 book ai didi

kerberos - Kerberos 身份验证的工作原理

转载 作者:行者123 更新时间:2023-12-02 19:26:02 26 4
gpt4 key购买 nike

我试图弄清楚kerberos身份验证是如何工作的,但我发现的信息总是缺少一些东西,就好像其中的一部分被认为是理所当然的。我大致了解该过程,但缺少一些细节。

获取 TGT:

  1. 首先,用户应从 KDC 获取 TGT(票证授予票证) - 用户发送仅包含其用户名 (UPN) 且不包含密码的请求。提供一些额外信息以防止重新发送请求,例如 IP 地址和时间戳。如果需要预身份验证,则时间将与用户的密码一起进行哈希处理。

  2. KDC 正在向用户发回以下信息:A. TGT - 带有时间戳、用户名、IP 地址和 session key - TGT 使用只有 KDC 知道的 secret 进行加密,因此任何人都无法更改。
    B. 用户和 KDC 在后续通信中使用的 session key 。
    这些内容使用用户密码(KDC 和用户之间的基本共享 secret )进行加密。如果使用预身份验证,服务器将在发回信息之前检查时间戳是否有效。

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

获取 TGS:

  1. 当用户被请求从服务中验证自身身份时,他向 KDC 发送 TGS(票证授予服务)请求,该请求包含 TGT、UPN 和 SPN(服务主体名称 - 例如,网页的 URI)。

  2. 然后,KDC 解密 TGT 并验证其真实性,确认它与来自同一 IP 地址的 UPN 相对应并且仍然有效(票证具有有效时间段)。

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

  4. 用户向服务提供 TGS - 该服务使用自己的密码对其进行解密。

  5. 身份验证已完成,因为服务依赖于其密码仅在其与 KDC 之间共享这一事实,因此它相信 KDC 之前已对用户进行了身份验证。

几个问题:

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

  2. 用户和 KDC 何时使用 session key ?在什么时候?为什么有必要?为什么用户密码不够?

  3. 用户和服务之间还应该有一个 session key (据我所知) - 何时以及为何使用它(与上一个问题相同)?

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

如果您有任何更正,我将很高兴。

提前致谢,托默

最佳答案

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

由于问题有一些不准确的地方,我会进行一些更正。

Getting TGT:

  1. First a user should get a TGT (Ticket Granting Tickets) from the KDC - the user sends a request with only it's user name (UPN) and without it's password. Some extra information is given to prevent a resent of the request such as ip address and a timestamp. If preauthentication is required then the time is hashed with the user's password.
  2. The KDC is sending the user back the following:

A. TGT - with a timestamp, user name, ip address and a session key - the TGT is encrypted with a secret only the KDC knows and therefore cannot be changed by anyone.

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

B. Session key for the user and the KDC to be used in later communication.Those things are encrypted using the users password (a basic shared secret amongst the KDC and the user). In case a preauthentication was used the server will check if the timestamp was valid before sending the information back.

TGT 本身仅由 KDC 的 secret 进行哈希处理,而不会根据用户的密码进行哈希处理。

  1. The users receive the information and decrypt it using it's password - and then stores it in it's memory (kerberos tray).

Getting TGS:

  1. When the user is requested to authenticate itself from a service he sends a request to the KDC for a TGS (Ticket Granting Service), the request contains the TGT, UPN and the SPN

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

(Service Principal Name - say, the URI of a webpage).

SPN 不包含 URI - 它包含主机、服务和端口 - 类似于:HTTP/localhost:80 或 ldap/localdc。如果使用默认端口(例如 HTTP 为 80 或 LDAP 为 389),则可以省略端口号。

  1. The KDC then decrypts the TGT and validate it's authenticity, that it is corresponds with the UPN, from the same IP address and still valid (the ticket has an effective time period).3. The KDC sends a TGS to the user encrypted with the service password.

KDC 还会发送一个 session key 供客户端和用户稍后使用。它使用 KDC 的 session key 和之前的用户进行加密发送 - session key (客户端和服务器)的另一个副本位于 TGS 本身内部,TGS 内部还驻留有客户端的身份验证器。

  1. The user presents the TGS to the service - which decrypts it using it's own password.5. The authentication is complete since the service counts on the fact that it's password is only shared between it and the KDC so it trusts that the KDC authenticated the user earlier.

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

  • 服务器向客户端发送使用共享 session key 加密的时间戳。服务器通过操纵客户端发送的数据来证明其真实性(意味着它可以解密它),因此这意味着它知道只有它和 KDC 应该知道的服务器密码。
  • A few questions:

    1. Am I missing something or that's it?
    2. When does the user and the KDC ever use the session key? At what point? Why is it necessary? Why does the user password isn't enough?
    3. There should also be a session key between the user and the service (to the best of my knowledge) - when and why is it used (same as the last question)?
    4. Kerberos has a 5 minute gap limitation between all parties - I understand why keeping the time in sync is important since it is used as something that we encrypt and decrypt so how come any gap is OK? Why 5 minutes?
    1. 是的。
    2. 回答了何时以及原因 - 动机是为可选攻击者提供更少的使用密码创建的数据样本,这样就更难从加密数据中破解密码。 session key 一直在变化(每次登录或 TGT 过期后),当攻击者可以破解它时,它就不再有用了。
    3. 已答复。
    4. 嗯,由于同步尚未完成,因此存在一些间隙是可以接受的。我对这里的 5 分钟有一个猜测 - KDC 和服务器应该保留最后 5 分钟的请求,以便攻击者不会重新发送有效请求并获得身份验证(称为重播攻击)。因此,每次发出请求时,服务器或 KDC 都必须在内存中查找,看看它是否不是重新发送的请求。显然,这是一个权衡,因为时间间隙越大,服务器需要分配给该任务的内存就越多。顺便说一句 - 默认情况下,时间段仅为 5 分钟,并且是可配置的。

    希望有帮助。

    所有内容都在此链接中(如果从头到尾阅读整个内容,则非常重复 - 您应该只阅读您想要理解的部分)- https://Technet.microsoft.com/en-us/library/cc772815(v=ws.10).aspx

    我还阅读了一些 RFC - https://www.rfc-editor.org/rfc/rfc1510

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

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

    https://technet.microsoft.com/en-us/library/aa480475.aspx (涉及 IIS 身份验证 - 有一部分提到并解释了 kerberos)。

    关于kerberos - Kerberos 身份验证的工作原理,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/39735008/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com