kerberos身份验证的工作原理

时间：2016-09-27 22:00:39

标签： kerberos

我试图弄清楚kerberos身份验证是如何工作的，我发现的信息总是丢失一些东西，好像它的一部分被视为理所当然。我一般都知道这个过程但是缺少一些细节。

获得TGT：

  1. 首先，用户应从KDC获得TGT（票证授予票证） - 用户仅发送带有用户名（UPN）的请求和没有密码的请求。提供了一些额外的信息以防止重新发送请求，例如IP地址和时间戳。 如果需要预身份验证，则使用用户密码对时间进行哈希处理。

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

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

    4. 获取TGS：

    1. 当请求用户从服务中验证自己时，他向KDC发送请求以获取TGS（票证授予服务），该请求包含TGT，UPN和SPN（服务主体名称 - 比方说，网页的URI。）

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

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

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

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

      6. 几个问题：

      1. 我错过了什么或那就是它吗？

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

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

      4. Kerberos在所有各方之间有5分钟的差距限制 - 我理解为什么保持时间同步非常重要，因为它被用作我们加密和解密的东西，那么如果有任何差距就可以了呢？为什么5分钟？

        5. 如果你有任何更正，我会很高兴。

        提前致谢， Tomer的

1 个答案:

答案 0 :(得分：3)

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

由于问题存在一些不准确之处，我会做一些更正。

  

获得TGT：

     
      
  1. 首先，用户应该从KDC获得TGT（票证授予票证） - 用户仅发送具有其用户名（UPN）且没有其密码的请求。提供了一些额外的信息以防止重新发送请求，例如IP地址和时间戳。如果需要预身份验证，则使用用户密码对时间进行哈希处理。
    2.   
  2. KDC正在向用户发回以下内容：
    3.         

    一个。 TGT - 具有时间戳，用户名，IP地址和会话密钥 - TGT仅使用KDC知道的秘密加密，因此任何人都无法更改。

所有这些都被称为＆＃34;身份验证器＆＃34;。

  

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

TGT本身只是由KDC的秘密所散播，而不是用户的密码。

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

    获取TGS：

         
        
    1. 当要求用户从服务中验证自己时，他向KDC发送请求以获取TGS（票证授予服务），该请求包含 TGT，UPN和SPN
      2.   

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

  

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

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

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

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

  
      
  1. 用户将TGS呈现给服务 - 该服务使用自己的密码对其进行解密。
    2.   
  2. 验证已完成，因为该服务依赖于它的密码仅在它与KDC之间共享这一事实，因此它相信KDC之前对用户进行了身份验证。
    3.   

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

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

    几个问题：

         
        
    1. 我错过了什么或者那是什么？
      2.   
    2. 用户和KDC何时使用会话密钥？在什么时候？为什么有必要？为什么用户密码不够？
      3.   
    3. 用户和服务之间也应该有一个会话密钥（据我所知） - 何时以及为何使用它（与上一个问题相同）？
      4.   
    4. Kerberos在所有各方之间有5分钟的差距限制 - 我理解为什么保持时间同步非常重要，因为它被用作我们加密和解密的东西，那么如何才能有任何差距？为什么5分钟？
      5.   
    1. 是
    2. 回答关于何时，为什么 - 动机是为可选攻击者提供使用密码创建的较少数据样本，因此从加密数据中破解密码将更加困难。会话密钥一直在变化（每次登录或在TGT到期后），并且当攻击者破解它时，它将没有用处。
    3. 回答。
    4. 嗯，由于同步未完成，因此必须有一些差距。我对这里的5分钟有一个猜测 - KDC和服务器应该在最后5分钟的请求中保留内存，以便攻击者不会重新发送有效请求并进行身份验证（称为重放攻击）。因此，每次发出请求时，服务器或KDC都必须查看内存以查看它是否不是令人不满的请求。显然存在权衡，因为时间间隔越大，服务器需要为此任务分配的内存越多。顺便说一句 - 默认情况下，时间段仅为5分钟，并且可配置。

      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并对其进行了解释）。

相关问题
最新问题