Kerberos的介绍与认证机制

Kerberos的介绍与认证机制

如下是翻译过来的~~，写的得劲。

系列文章目录

---

一．kerberos的背景

Kerberos于1983年被开发为MIT雅典娜计划的身份验证引擎。1987年作为开源发布，1993年成为IETF标准。Kerberos是用于不受信任网络上的受信任主机的身份验证协议。目前主要由MIT KIT联盟进行推动发展成功将Kerberos建立为Internet的标准安全协议之一。其中MIT Kerberos联盟将是一个以MIT为总部的非营利组织。该联盟将由麻省理工学院（MIT）运营，并由成员组织提供资金，继续开发和推广Kerberos对他们自己的目标至关重要。

二．kerberos 被应用的场景

Kerberos 协议是假设客户端和服务器之间的事务发生在一个开放网络上，在这种网络上，大多数客户端和许多服务器不在物理上都是安全的，并且在网络上传输的数据包可随时监视和修改。这个假定的网络环境类似于今天的 Internet，攻击者可轻松地将其作为客户端或服务器，并可以轻松地窃听或篡改合法客户端和服务器之间的通信。所以实体间建立一个安全的网络连接实现通信很有必要。而在建立安全的网络连接之前，Kerberos 身份验证协议提供了用于实体之间相互身份验证的机制。

三．kerberos的相关概念

如下是文字描述kerberos是如何实现安全可靠的实体之间相互身份验证的机制。

3.1基本身份验证概念

在客户端/服务器应用程序模型中，客户端是代表需要完成某个操作的用户的程序。 这可能是打开和使用文件、访问邮箱、查询数据库或打印文档。服务器是向客户端提供服务（如文件存储、邮件处理、查询处理和打印后台打印）的程序。客户端启动操作，服务器将做出响应。通常情况下，服务器在等待客户端连接并要求提供服务的通信端口上进行侦听。
在 Kerberos 协议模式中，每个客户端/服务器连接开始时都会进行身份验证。 客户端和服务器轮流依次执行一系列操作，这些操作用于向连接每一端的一方确认另一端的一方是真实的。如果身份验证成功，则会话设置完成，从而建立了一个安全的客户端/服务器会话。

3.2密钥身份验证

许多形式的身份验证都基于这样一种想法：实体可以证明它知道仅知道的密钥，例如密码。但是为了保证密码的安全性，必须有一种方法来证明用户知道密码，而不会透露密码。 这就是密钥身份验证背后的理念，这是在整个 Kerberos 协议中使用的一种验证方法。
密钥身份验证中的 “密钥” 是身份验证过程是 “机密” 的。即，实际上不会泄露密钥的内容。
要使密钥身份验证正常工作，会话的双方必须共享一个加密会话密钥 ，该密钥也是机密，仅对它们有效，而不是其他人。密钥为对称密钥，也就是说，它是用于加密和解密的单个密钥。 身份验证过程中的一方通过加密消息来证明其密钥的知识。另一方通过解密消息来证明密钥的知识。

3.3验证器消息

在使用密钥身份验证的简单协议中，客户端会以会话密钥中加密的信息片段的形式提供身份验证器消息。身份验证器消息中的信息在每次执行身份验证协议时必须不同，否则，未经授权的实体可以重复使用已加密的身份验证器消息。
接收到身份验证器消息后，服务器将对其进行解密，并从解密消息的内容中获知解密是否成功。如果解密的消息不会有杂乱的信息，则服务器将知道提供身份验证器消息的客户端使用正确的密钥来加密消息。只有两个实体有权访问会话密钥 ，如果服务器是这样，则加密身份验证器消息的客户端必须是另一个。
对于相互身份验证，将执行类似的协议。服务器提取解密的原始验证器消息中的部分信息，并用共享会话密钥对其进行加密，然后将加密的消息发送到客户端。 客户端对消息进行解密，并将结果与原始结果进行比较。如果解密的消息与原始消息的正确部分匹配，则客户端知道服务器能够使用共享密钥会话密钥对原始消息进行解密，并且能够使用相同的共享密钥会话密钥重新加密该消息的一部分。

3.4密钥分发

密钥身份验证技术不解释客户端和服务器如何获取要在会话中使用的会话密钥 。 如果他们是人员，他们可能会在机密上达成一致，并同意密钥。 但如果客户端是在工作站上运行的程序，并且服务器是在网络服务器上运行的服务，则该方法将不起作用。
客户端需要与多个服务器进行通信，每个服务器都需要不同的密钥。 服务器与多个客户端进行通信，每个客户端也需要不同的密钥。 如果每个客户端对于每个服务器需要不同的密钥，并且每个服务器对于每个客户端也需要不同的密钥，则密钥分发会成为问题。 此外，在许多计算机上存储和保护多个密钥的需求会带来巨大的安全风险。
Kerberos 协议的名称建议其解决密钥分发问题的解决方案。 Kerberos是传统希腊语神话中的一个数字，它是一种凶猛的三头狗。Kerberos 协议有三个磁头：客户端、服务器和受信任的第三方。 此协议中的受信任中介是KDC(密钥发行中心) 。
KDC 是在物理上安全的服务器上运行的服务。 它会维护一个数据库，其中包含其领域中所有安全主体的帐户信息。
KDC 以及有关每个安全主体的其他信息都存储了一个仅对主体和 KDC 知道的加密密钥。 这是在每个安全主体和 KDC 之间进行交换时使用的 主密钥 。 在大多数 Kerberos 协议实现中，此主密钥是使用安全主体的密码中的哈希函数派生的。
当客户端想要与服务器建立安全连接时，客户端首先向 KDC 发送请求，而不是发送到要访问的服务器。KDC为客户端创建一个唯一会话密钥 ，并向客户端发送用于彼此进行身份验证的服务器。KDC 有权访问客户端的主密钥和服务器的主密钥。 KDC 使用服务器的主密钥以及使用客户端主密钥的客户端副本来加密服务器的会话密钥副本。
KDC可以通过将会话密钥直接发送到所涉及的每个安全主体来实现其角色作为受信任中介，但在实践中，此过程将不起作用。相反，KDC 会将两个加密的会话密钥发送到客户端。其中服务器的会话密钥就包含在会话票证中。

3.5会话票证

KDC不会将加密的会话密钥发送给两个主体，而是将客户端和服务器的会话密钥副本发送给客户端。客户端的会话密钥副本使用客户端的主密钥加密，因此任何其他实体都无法解密。服务器的会话密钥副本与有关客户端的授权数据一起嵌入到称为票证的数据结构中。票证完全用服务器的主密钥加密，因此客户端或任何其他无法访问服务器的主密钥的实体都无法读取或更改该票证。客户有责任安全存储票证，直到与服务器联系为止。

注意：KDC仅提供票务授予服务。客户端和服务器负责维护其各自的主密钥的安全。

当客户端收到KDC的响应时，它将提取票证和其自己的会话密钥副本，并将两者都放在安全的缓存中。为了与服务器建立安全会话，它将向服务器发送一条消息，该消息包括仍由服务器主密钥加密的票证和由会话密钥加密的身份验证器消息。票证和验证器消息一起发送是客户端到服务器的凭据。
当服务器从客户端收到凭据时，它将使用其主密钥解密票证，提取会话密钥，然后使用会话密钥解密客户端的身份验证器消息。如果一切都检查完了，则服务器将知道客户端的凭据是由KDC（受信任的机构）颁发的。对于相互身份验证，服务器通过使用会话密钥对客户端的身份验证器消息中的时间戳进行加密来进行响应。该加密的消息被发送到客户端。客户端然后解密该消息。如果返回的消息与原始身份验证器消息中的时间戳相同，则对服务器进行身份验证。
另外一个好处是，服务器不需要存储与客户端一起使用的会话密钥。每个客户都有责任在票证缓存中管理服务器的票证，并在每次访问服务器时出示该票证。每当服务器从客户端收到票证时，它都会使用其主密钥解密票证并提取会话密钥。当服务器不再需要会话密钥时，该密钥将被删除。
客户端不需要每次想要访问该特定服务器时都访问KDC。票证可以重复使用。为防止票证被盗的可能性，票证有一个过期时间，该时间由KDC在票证结构中指定。票证有效的时间取决于领域的Kerberos策略。通常，票证的有效期不超过八小时，大约是正常登录会话的时间。当客户端工作站上的用户注销时，将刷新客户端故障单缓存，并销毁所有故障单和客户端会话密钥。

3.5票证授予票证(TGT)

由于Kerberos协议是最初设计的，因此用户的主密钥是从用户提供的密码派生而来的。当用户登录时，该用户工作站上的Kerberos客户端接受了该用户的密码，并将该文本通过单向哈希函数传递，从而将其转换为加密密钥。产生的哈希是用户的主密钥。客户端使用此主密钥解密从KDC接收的会话密钥。
原始Kerberos设计的问题是，每次客户端从KDC解密会话密钥时，客户端都需要用户的主密钥。这意味着客户端必须在每次客户端/服务器交换的开始时要求用户提供密码，或者客户端必须将用户的密钥存储在工作站上。用户的频繁打扰太麻烦了。将密钥存储在工作站上可能会损害从用户密码派生的密钥（这是长期密钥）。
Kerberos协议针对此问题的解决方案是让客户端从KDC获得临时密钥。此临时密钥仅对于此登录会话有用。当用户登录时，客户端请求KDC的票证，就像它请求任何其他服务的票证一样。KDC通过创建登录会话密钥和用于特殊服务器的票证（KDC的完整票证授予服务）进行响应。登录会话密钥的一个副本被嵌入到票证中，并且该票证已使用KDC的主密钥加密。登录会话密钥的另一个副本使用从用户登录密码派生的用户主密钥进行加密。票证和加密的会话密钥都发送到客户端。
当客户端收到KDC的答复时，它将使用从用户密码派生的用户主密钥解密登录会话密钥。客户端不再需要从用户密码派生的密钥，因为客户端现在将使用登录会话密钥来解密从KDC获得的任何服务器会话密钥的副本。客户端将登录会话密钥与KDC的完整票证授予服务的票证一起存储在票证缓存中。
完整的票证授予服务的票证称为票证授予票证（TGT）。当客户端向KDC索要到服务器的票证时，它以身份验证器消息和票证（在本例中为TGT）的形式提供凭据，就像它将凭据向其他任何服务提供一样。票证授予服务使用其主密钥打开TGT，提取该客户端的登录会话密钥，然后使用登录会话密钥为服务器加密客户端的会话密钥副本。

四．Kerberos的授权流程

4.1认证服务交换

用户通过输入登录名和密码开始登录网络。该Kerberos的用户的工作站上的客户端密码转换为加密密钥，并将结果保存在一个程序变量。
然后，客户端通过向KDC的身份验证服务发送KRB_AS_REQ类型的消息（Kerberos身份验证服务请求），向密钥分发中心（KDC）的票证授予服务（TGS）请求凭据。该消息的第一部分标识用户和所请求的TGS服务。该消息的第二部分包含预身份验证数据，旨在证明用户知道密码。这只是一个身份验证器消息，它使用从用户登录密码派生的主密钥进行加密。
当KDC收到KRB_AS_REQ时，它将在其数据库中查找用户，获取关联用户的主密钥，解密预身份验证数据，并评估其中的时间戳。如果时间戳有效，则可以确保KDC使用用户的主密钥对预身份验证数据进行加密，从而确保客户端是真实的。

KDC验证用户身份后，它将创建客户端可以提供给TGS的凭据，如下所示：
1.KDC发明了一个登录会话密钥，并使用用户的主密钥对副本进行加密。
2.KDC将登录会话密钥和用户授权数据的另一个副本嵌入到授予票据的票证（TGT）中， 并使用KDC自己的主密钥对TGT进行加密。
3.KDC通过使用类型KRB_AS_REP（Kerberos身份验证服务回复）的消息进行回复，将这 些凭据发送回客户端。
4.当客户端收到答复时，它将使用从用户密码派生的密钥来解密新的登录会话密钥。
5.客户端将新密钥存储在其票证缓存中。
6.客户端从消息中提取TGT，并将其存储在票证缓存中。
4.2票务授予服务交换
在为客户端建立了票证授予票证（TGT）和会话密钥之后，客户端可以为服务请求单独的会话密钥和票证。

申请其他服务的票据

1.用户工作站上的Kerberos客户端通过向密钥分发中心（KDC）发送类型为KRB_TGS_REQ （Kerberos票证授予服务请求）的消息来请求服务的凭据。此消息包括客户端正在为其 请求凭据的服务的身份，使用用户的新登录会话密钥加密的身份验证器消息以及从“身 份验证服务交换”获得的TGT 。
2.当KDC收到KRB_TGS_REQ时，KDC用其密钥解密TGT，并提取用户的登录会话密 钥。
3.KDC使用登录会话密钥来解密用户的身份验证器消息并对其进行评估。如果验证者通 过测试，则KDC将从TGT中提取用户的授权数据，并为用户创建会话密钥，以便与请 求的服务器共享。
4.KDC用用户的登录会话密钥加密服务会话密钥的一个副本。
5.KDC将服务会话密钥的另一个副本与用户的授权数据一起嵌入到票证中，并使用服务 器的主密钥对票证进行加密。
6.KDC通过使用类型KRB_TGS_REP（Kerberos票证授予服务答复）的消息进行答复，将 这些凭证发送回客户端。
7.当客户端收到答复时，它将使用用户的登录会话密钥解密服务会话密钥，并将服务会 话密钥存储在其票证缓存中。
8.客户端将票证提取到服务器，并将其存储在票证缓存中。
4.3客户端/服务器交换
用户有权使用服务器票证后，工作站客户端可以与该服务器建立安全的通信会话。

建立与服务器的安全通信会话

1.客户端向服务器发送一条消息，类型为 KRB _ AP _ REQ(Kerberos 应用程序请求) 。 此消息包含一个身份验证器消息，该消息使用由与服务器的会话的 密钥发行中心 (KDC) 发送的密钥、与服务器会话的票证以及一个指示客户端是否请求相互身份验证的标志来 加密。设置请求相互身份验证的标志是配置 Kerberos的选项之一。 用户决不会询问 是否应使用相互身份验证。
2.服务器接收 KRB_AP_REQ，对票证进行解密，并提取用户的授权数据和会话密钥。
3.服务器使用票证中的会话密钥来解密用户的身份验证器消息，并在内部计算时间戳。
4.如果身份验证器消息有效，则服务器将检查客户端请求中的相互身份验证标志。
5.如果设置了相互身份验证标志，则服务器将使用会话密钥来加密用户的身份验证器消 息中的时间，并将结果返回到类型为 KRB_AP_REP（Kerberos应用程序回复）。
6.当客户端收到 KRB_AP_REP时，它会使用与服务器共享的会话密钥来解密服务器的 身份验证器消息，并将该服务发送给的时间与原始验证器消息中的时间进行比较。如 果它们匹配，则客户端可以确保服务为正版，连接将继续。

如下图为官网截图参考：
https://www.kerberos.org/software/tutorial.html

五.Kerberos的策略

Kerberos票证策略在域级别定义，并由域的密钥分发中心（KDC）实施。Kerberos策略作为域安全策略属性的子集存储在Active Directory中。默认情况下，策略选项只能由Domain Administrators组的成员设置。域策略包括以下选项：

支持过期的票
支持约束委派
可以转发的支持票
支持可续票
设置最大票龄
设置最大续订年龄
设置最大代理票龄
票证过期时强制注销用户

使用受约束的委派，可以将计算机设置为仅将凭据转发到特定的服务列表。这些服务必须与转发凭据的计算机位于同一域中。在受约束的委派下，票证不再从客户端发送到服务器。服务器计算机创建服务票证，以根据需要从用于验证客户端的信息中进行转发。

尽管用于域的Kerberos策略可以通过允许转发票证来允许委派身份验证，但是该策略的这一方面不必适用于所有用户或所有计算机。可以设置单个用户帐户的属性，以禁止任何服务器转发该用户的凭据。可以将单个计算机帐户的属性设置为禁用任何用户的凭据转发。在这两种情况下，都可以通过创建组策略来禁用委派，该组策略将应用于Active Directory的组织单位中的所有用户或所有计算机。