Kerberos协议内容详解

这篇帮助文档是由 Fulvio Ricciardi所写。原文地址https://kerberos.org/software/tutorial.html，目前翻译只校对了1-4章

文章目录

1 介绍
2 目标
3 对象和术语的解释
- 3.1 Realm
- 3.2 Principal
- 3.3 Ticket
- 3.4 加密 Encryption
- - 3.4.1 加密类型 Encryption type
  - 3.4.2 加密密钥 Encryption key
  - 3.4.3 Salt
  - 3.4.4 密钥版本号 Key Version Number (kvno)
- 3.5 密钥分发中心 Key Distribution Center KDC
- - 3.5.1 数据库
  - 3.5.2 认证服务器 Authentication Server （AS）
  - 3.5.3 ticket授予服务器（TGS）
- 3.6 Session Key
- 3.7 认证者 Authenticator
- 3.8 重放缓存 Replay Cache
- 3.9 凭证缓存 Credential Cache
4 Kerberos 的运行方式
- 4.1 Authentication Server Request
- 4.2 Authentication Server Reply
- 4.3 Ticket Granting Server Request (TGS_REQ)
- 4.4 Ticket Granting Server Replay (TGS_REP)
- 4.5 Application Request (AP_REQ)
- 4.6 Pre-Authentication
5 详解Tickets
- 5.1 Initial tickets
- 5.2 Renewable tickets
- 5.3 Forwardable tickets
6 交叉认证 Cross Authentication
- 6.1 Direct trust relationships
- 6.2 Transitive trust relationships
- 6.3 Hierarchical trust relationships

1 介绍

Kerberos是一种在不受信任的网络上给可信任的hosts进行授权认证的协议。

2 目标

在描述构成 Kerberos 身份验证系统的元素并查看其操作之前，协议希望实现的一些目标如下：

users的密码绝不能通过网络传播；
users的密码绝不能以任何形式存储在客户端机器上：使用后必须立即丢弃；
即使在认证服务器数据库中，也不应该以未加密的形式存储users的密码；
每个工作会话仅要求users输入一次密码。因此，users可以透明地访问他们授权的所有services，而无需在此会话期间重新输入密码。此特性称为单点登录；
认证信息集中管理，存储在认证服务器上（authentication server）。应用程序服务器不得包含其users的身份验证信息。这对于获得以下结果至关重要：
1. 管理员可以通过在单个位置操作来禁用任何users的帐户，而无需在提供各种services的多个应用服务器上操作；
2. 当users更改密码时，所有services同时更改；
3. 没有冗余的认证信息，否则需要在各个地方进行保护；
不仅users必须证明他们就是他们所说的人，在被要求时，应用服务器也须向客户端证明他们的真实性。这个特性被称为相互认证；
身份验证和授权完成后，如果需要，客户端和服务器必须能够建立加密连接。为此，Kerberos 支持生成和交换用于加密数据的加密密钥。

3 对象和术语的解释

本节提供对象和术语的定义，这些知识对于 Kerberos 协议的后续描述至关重要。由于许多定义都基于其他定义，因此我尽可能将它们整理好，以便在定义之前不会给出术语的含义。但是，可能需要阅读本节两遍才能完全理解所有术语。

3.1 Realm

术语realm表示身份验证管理域。其目的是建立认证服务器有权认证的users、主机或services的边界。这并不意味着users和services之间的身份验证必须属于同一realm：如果两个对象属于不同realm，并且它们之间存在信任关系，则可以进行身份验证。下面将描述这种称为交叉认证的特性。

基本上，当且仅当users/services与该realm的认证服务器共享secret（密码/密钥）时，该users/services才属于该realm。

realm的名称区分大小写，即大写和小写字母之间存在差异，但通常realm总是以大写字母出现。在组织中，使领域名称与 DNS 域相同（尽管使用大写字母）也是一种很好的做法。举例来说，如果一个组织属于 DNS 域 example.com，则相关的 Kerberos 领域是EXAMPLE.COM 是合适的。

3.2 Principal

principal是用于指向认证服务器的数据库中的条目的名称。principal与给定realm的每个users、主机或services相关联。Kerberos 5 中的principal具有以下类型：

component1/component2/…/componentN@REALM

然而，实际上最多使用两个组件。对于引用users的条目，principal 是以下类型：

Name[/Instance]@REALM

实例是可选的，通常用于更好地限定users类型。例如，管理员users通常拥有 admin 实例。以下是指代users的principal示例：

pippo@EXAMPLE.COM admin/admin@EXAMPLE.COM pluto/admin@EXAMPLE.COM

相反，如果条目涉及services，则principal 采用以下形式：

Service/Hostname@REALM

第一个组件是services的名称，例如 imap、AFS、ftp。通常用主机host这个词来表示对机器的一般访问（telnet、rsh、ssh）。第二个组成部分是提供所请求services的机器的完整主机名 (FQDN)。该组件与应用程序服务器 IP 地址的 DNS 反向解析完全匹配（以小写字母表示）非常重要。以下是引用services的principal 的有效示例：

imap/mbox.example.com@EXAMPLE.COM

host/server.example.com@EXAMPLE.COM

afs/example.com@EXAMPLE.COM

在 Kerberos 4 中，组件永远不能超过两个，并且它们由字符“.”分隔。而不是“/”，而principal 中涉及services的主机名是短的，即不是 FQDN。以下是有效示例：

pippo@EXAMPLE.COM pluto.admin@EXAMPLE.COM imap.mbox@EXAMPLE.COM

3.3 Ticket

Ticket是客户端提供给应用程序服务器以证明其身份真实性的东西。Ticket由认证服务器颁发，并使用它们所指向的services的密钥进行加密。由于此密钥是仅在认证服务器和提供services的服务器之间共享的secret，因此即使是请求ticket的客户端也无法知道或更改其内容。ticket中包含的主要信息包括：

请求users的principal （通常是users名）；
它所针对的services的principal ；
可以使用ticket的客户端计算机的 IP 地址。在 Kerberos 5 中，此字段是可选的，也可以是多个字段，以便能够在 NAT 或多宿主下运行客户端。
ticket有效期开始的日期和时间（时间戳格式）；
ticket的最长有效期
会话密钥 Session Key；

每张ticket都有一个有效期（通常为 10 小时）。这是必不可少的，因为认证服务器不再对已发出的ticket有任何控制权。尽管realm管理员可以随时阻止为某个users发行ticket，但它不能阻止users使用他们已经拥有的ticket。这就是限制ticket的生命周期以限制任何滥用的原因。

ticket包含许多其他信息和标志来表征他们的行为，但我们不会在这里讨论。在看到身份验证系统的工作原理后，我们将再次讨论ticket和标志。

3.4 加密 Encryption

正如您所看到的，Kerberos 通常需要加密和解密在授权过程中的各个参与者之间传递的消息（ticket和authenticators）。需要注意的是，Kerberos 仅使用对称密钥加密（换句话说，使用相同的密钥进行加密和解密）。某些项目（例如 pkinit）正在积极引入公钥系统，以便通过提供与认证公钥对应的私钥来获得初始users身份验证，但由于没有标准，我们现在将跳过此讨论.

3.4.1 加密类型 Encryption type

Kerberos 4 实现了一种单一类型的加密，即 56 位的DES。The weakness of this encryption plus other protocol vulnerabilities have made Kerberos 4 obsolete. Version 5 of Kerberos, however, does not predetermine the number or type of encryption methodologies supported. It is the task of each specific implementation to support and best negotiate the various types of encryption. However, this flexibility and expandability of the protocol has accentuated interoperability problems between the various implementations of Kerberos 5. In order for clients and application and authentication servers using different implementations to interoperate, they must have at least one encryption type in common. The difficulty related to the interoperability between Unix implementations of Kerberos 5 and the one present in the Active Directory of Windows is a classic example of this. Indeed, Windows Active Directory supports a limited number of encryptions and only had DES at 56 bits in common with Unix. This required keeping the latter enabled, despite the risks being well known, if interoperability had to be guaranteed. The problem was subsequently solved with version 1.3 of MIT Kerberos 5. This version introduced RC4-HMAC support, which is also present in Windows and is more secure than DES. Among the supported encryptions (but not by Windows) the triple DES (3DES) and newer AES128 and AES256 are worth mentioning.

3.4.2 加密密钥 Encryption key

如上所述，Kerberos 协议的目标之一是防止users的密码以未加密的形式存储，即使在认证服务器的数据库中也是如此。考虑到每种加密算法都使用自己的密钥长度，很明显，如果不强制users为每种支持的加密方法使用固定大小的不同密码，则加密密钥就不能作为密码。由于这些原因，引入string2key函数，它将未加密的密码转换为适合要使用的加密类型的加密密钥。每次users更改密码或输入密码进行身份验证时都会调用此函数。string2key 被称为散列函数，这意味着它是不可逆的：无法通过给定的encryption得到对应的密码（除非通过蛮力）。著名的散列算法有MD、5CRC32等。

3.4.3 Salt

在 Kerberos 5 中，与版本 4 不同，引入了密码盐的概念。这是一个字符串，在通过 string2key 函数获取密钥之前要将其连接到未加的密密码。Kerberos 5 使用与 salt 相同的usersprincipal ：

K pippo = string2key ( Ppippo + “pippo@EXAMPLE.COM” )

Kpippo是userspippo的加密密钥， Ppippo是users未加密的密码。
这种盐有以下优点：

属于同一realm并具有相同未加密密码的两个principal 仍然具有不同的密钥。例如，假设管理员有一个负责日常工作的负责人 (pippo@EXAMPLE.COM) 和负责管理工作的负责人 (pippo/admin@EXAMPLE.COM)。为方便起见，该users很可能为两个principal 设置了相同的密码。盐的存在保证了相关的键是不同的。
如果users在不同realm有两个帐户，两个realm的未加密密码相同是很常见的，由于存在 salt，一个领域中的帐户可能遭到入侵，不会自动导致另一个领域也被入侵。

可以配置空盐以与 Kerberos 4 兼容。反之亦然，为了与 AFS 兼容，可以配置一个盐，它不是principal 的完整名称，而只是cell的名称。

讨论了加密类型、string2key 和 salt 的概念后，可以检查以下观察结果的准确性：为了在各种 Kerberos 实现之间存在互操作性，协商通用的加密类型是不够的，但是还需要使用相同类型的 string2key 和 salt。
同样重要的是要注意，在解释 string2key 和 salt 的概念时，仅参考了usersprincipal ，从未参考过服务器principal 。原因很明确：services，即使它与认证服务器共享一个secret，也不是一个未加密的密码（谁会输入它？），而是一个密钥，一旦由管理员在 Kerberos 服务器上生成，就会像在提供services的服务器上一样被记住。

3.4.4 密钥版本号 Key Version Number (kvno)

当users更改密码或管理员更新应用程序服务器的密钥时，此更改会促使计数器来记录。标识密钥版本的计数器的当前值被称为密钥版本号或更简单地说kvno。

3.5 密钥分发中心 Key Distribution Center KDC

我们已经笼统地谈到了认证服务器（authentication server）。由于它是涉及users 和services认证的基本对象，我们现在将更深入地研究它，而不深入研究其操作的所有细节，而是侧重于协议操作的部分。
Kerberos 环境中的认证服务器，基于其分发services访问的ticket功能，称为密钥分发中心或简称为 KDC。由于它完全驻留在单个物理服务器上（通常与单个进程重合），因此在逻辑上可以将其分为三个部分：数据库、认证服务器 (AS) 和ticket授予服务器 (TGS)。让我们简要地看一下它们。

3.5.1 数据库

数据库是与users和services相关联的条目entries 的容器。我们通过使用principal （如条目的名称）来引用条目，即使术语principal 经常用作条目的同义词。每个条目都包含以下信息：

条目关联的principal ；
加密密钥和相关的kvno；
与principal 关联的ticket的最长有效期；
与principal 关联的ticket可以续订的最长时间（仅限 Kerberos 5）；
表征ticket行为的属性或标志；
密码有效期；
principal 的到期日期，在此之后将不会发出任何ticket。

为了更难以窃取数据库中存在的密钥，实现使用与principal K/M@REALM 关联的主密钥 master key对数据库进行加密。甚至任何用作备份或用于从 KDC 主服务器向从服务器传播的数据库转储都使用此密钥进行加密，必须知道该密钥才能重新加载它们。

3.5.2 认证服务器 Authentication Server （AS）

认证服务器是 KDC 的一部分，用于响应来自客户端的初始身份验证请求，当users尚未通过身份验证时，必须输入密码。作为对身份验证请求的响应，AS 发出一个特殊的ticket，称为Ticket Granting Ticket,，或者更简单地说 TGT，与其关联的principal 是 krbtgt/REALM@REALM。如果users确实是他们所说的那样（我们稍后会看到他们如何证明这一点），他们可以使用 TGT 来获取其他servicesticket，而无需重新输入他们的密码。

3.5.3 ticket授予服务器（TGS）

Ticket Granting Server 是 KDC 组件，它向具有有效 TGT 的客户端分发servicesticket，保证在应用服务器上获取请求资源的身份的真实性。TGS 可以被认为是一个应用服务器（假设访问它需要提供 TGT），它提供services票据作为services的发行。重要的是不要混淆缩写 TGT 和 TGS：第一个表示ticket，第二个表示services。

3.6 Session Key

正如我们所见，users和services与 KDC 共享一个secret 。对于users来说，这个secret是从他们的密码中衍生出来的密钥，而对于services来说，它是他们的密钥（由管理员设置）。这些键称为长期键，因为它们不会在工作会话更改时更改。

但是，users也有必要与services共享一个secret，至少在客户端在服务器上打开工作会话期间：此密钥由 KDC 在签发ticket时生成，称为会话密钥 Session Key。发给services的Session Key副本由 KDC 封装在ticket中（在任何情况下，他们的应用程序服务器都知道长期密钥，可以对其进行解码并提取Session Key），而发给users的Session Key 副本则使用users的长期密钥把其封装在加密数据包中。会话密钥在证明users的真实性方面起着基本作用，我们将在下一段中看到这一点。

3.7 认证者 Authenticator

即使users 的principal 存在于ticket中，并且只有应用服务器可以提取并可能管理此类信息（因为ticket是用services的密钥加密的），这也不足以保证客户端的真实性。当合法客户端将ticket发送到应用服务器时，冒名顶替者可以捕获（记住开放和不安全网络的假设）ticket，并在适当的时候将其发送以非法获取services。另一方面，包括可能使用它的机器的 IP 地址的方式也并不是很有用：众所周知，在开放和不安全的网络中，地址很容易被伪造。为了解决这个问题，我们必须利用客户端和服务器，至少在会话期间拥有只有他们知道的共同会话密钥（KDC 也知道它，因为它生成它）。因此应用以下策略：连同包含ticket的请求，客户端添加另一个数据包（Authenticator），其中包含users的principal 和时间戳（当时的）并使用session key对其进行加密；必须提供services的服务器在收到此请求后，解开第一张ticket，提取session key；如果users确实是他/她所说的人，则服务器能够解密authenticator以提取时间戳。如果后者与服务器时间相差小于 2 分钟（但可以配置容差），则认证成功。

3.8 重放缓存 Replay Cache

冒名顶替者有可能同时窃取ticket和authenticator，并在验证器有效的 2 分钟内使用它们。这是非常困难的，但并非不可能。为了解决 Kerberos 5 的这个问题，引入了重放缓存。在应用服务器中（也包括在 TGS 中），有能力记住过去 2 分钟内到达的身份验证器，如果它们是副本则拒绝它们。有了这个，只要冒名顶替者不够聪明，无法复制ticket和身份验证器，并使它们在合法请求到达之前到达应用服务器，问题就解决了。这真的是一个骗局，因为当冒名顶替者可以访问该services时，真实users将被拒绝

3.9 凭证缓存 Credential Cache

客户端从不保留users的密码，也不记住通过应用 string2key 获得的密钥：它们用于解密来自 KDC 的回复并立即丢弃。然而，另一方面，要实现单点登录 (SSO) 特性，即要求users在每个工作会话中只输入一次密码，就必须记住ticket和相关的会话密钥。存储此数据的地方称为“凭据缓存”。此缓存需要位于何处不取决于协议，而是因一种实现而异。通常出于可移植性的目的，它们位于文件系统（MIT 和 Heimdal）中。在其他实现（AFS 和 Active Directory）中，为了在出现易受攻击的客户端时提高安全性，

4 Kerberos 的运行方式

最后，在掌握了前面段落中描述的概念之后，可以讨论 Kerberos 的运行方式。我们将通过列出和描述在身份验证期间,在客户端和 KDC 之间以及客户端和应用程序服务器之间传递的每个数据包来讨论说明。基于此，强调应用服务器从不直接与密钥分发中心KDC通信是重要的：即使是由 TGS 打包的服务票据the service tickets，也只能通过希望访问它们的客户端到达服务器。下面列出了我们将讨论的消息（另请参见下图）：

AS_REQ是初始的用户身份验证请求（即使用 kinit 发出）此消息被定向到KDC的组件“认证服务器(AS) ” 中；
AS_REP是认证服务器对前一个请求的回复。基本上它包含 TGT（使用 TGS 密钥加密）和session key（使用请求用户的密钥加密）；
TGS_REQ是客户端向ticket授予服务器 (TGS) 发出的某服务的ticket请求。该数据包包括从前面的消息中获得的 TGT 和由客户端生成并使用会话密钥session key加密的身份验证符；
TGS_REP是ticket授予服务器对前一个请求的回复。里面的内容是请求的服务的ticket（用服务的秘密密钥加密）和服务session key，session key由TGS生成并使用AS先前生成的会话密钥加密的；
AP_REQ是客户端发送到应用服务器访问某个服务的请求。它由从 TGS 获得的服务的ticket和和客户端再次生成的验证器组成，但这次使用服务的session key（由 TGS 生成）进行加密；
AP_REP是应用服务器给客户端的回复，以证明它确实是客户端期望的服务器。这个数据并不总是被请求。客户端仅在双向验证时才向服务器请求。

注意：后面的段落用圆括号 () 将未加密数据括起来，将加密数据用大括号 {} 括起来：( x, y, z ) 表示 x, y, z 未加密；{ x, y, z }K 表示 x, y, z 使用对称密钥 K 一起加密。同样重要的是要注意，在数据包中列出组件的顺序与实际情况无关。

4.1 Authentication Server Request

在这个阶段，称为初始身份验证请求，客户端 (kinit) 向 KDC（更具体地说是 AS）请求一个 Ticket Granting Ticket。该请求是完全未加密的，如下所示：

其中： Principal Client 是与寻求身份验证的用户相关联的principal（例如 pippo@EXAMPLE.COM）； PrincipalService 是与请求服务的ticket相关联的主体，因此是字符串“krbtgt/REALM@REALM”（请参阅注释*）； IP_list 是一个 IP 地址列表，指示可以使用将要发行的ticket的主机（请参阅注释 **）； Lifetime是要签发的票证的最大有效时间（请求）。

注意 *：添加主要服务到初始身份验证请求，因为这将不断设置为 TGS 主体，即 krbtgt/REALM@REALM。然而，情况并非如此，事实上，一个用户计划在一个工作会话期间只使用一项服务，不会使用单点登录，并且可能直接向 AS 索要该服务的票证，从而跳过后续请求到 TGS。从操作的角度来看（MIT 1.3.6），以下命令就足够了：kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM
注意 **：IP_list也可能为空。在这种情况下，任何机器都可以使用相应的票证。这解决了 NAT 下那些客户端的问题，因为他们的请求到达服务时的源地址与请求用户的源地址不同，但与进行 NAT 的路由器相同。相反，在具有多个网卡的机器的情况下，IP_list 应该包含所有卡的 IP 地址：事实上，很难预先预测提供服务的服务器将通过哪个连接进行联系。

4.2 Authentication Server Reply

当前一个请求到达时，AS检查 PrincipalClient和 PrincipalClient在 KDC 数据库中是否存在：如果两者中至少有一个不存在，则向客户端发送错误消息，否则身份验证服务器AS处理回复如下：

它随机创建一个会话密钥，该密钥将成为客户端和 TGS 之间共享的secret。此处称为SK TGS;
它创建了Ticket Granting Ticket，写入请求用户的principal、服务principal（通常是krbtgt/REALM@REALM，但请阅读上一段的注释*）、IP地址列表（前三项信息是当它们到达时被 AS_REQ 数据包复制）、时间戳格式的日期和时间（KDC 的）、生命周期（见注释**）以及最后的会话密钥。 SK TGS; 因此，Ticket Granting Ticket如下所示：

它生成并发送包含以下内容的回复：服务密钥加密的ticket，KTGS; 服务principal、时间戳、生命周期和session key都使用请求服务的用户的密钥加密（我们称之为Kuser）。总之：

此消息似乎包含冗余信息（PrincipalService, timestamp, lifetime and session key）。但事实并非如此：由于 TGT 中存在的信息是使用服务器的密钥加密的，因此客户端无法读取，需要重复。此时，当客户端收到回复消息时，会要求用户输入密码。盐与密码连接，然后应用 string2key 函数：使用生成的密钥尝试解密由 KDC 使用存储在数据库中的用户的秘密密钥加密的部分消息。如果用户确实是他/她所说的那样，并且因此输入了正确的密码，则解密操作将成功，因此可以提取会话密钥并将 TGT（保持加密）存储在用户的凭据缓存中。

注 *：实际生命周期，如，放入票证的生命周期为以下值中的最低值：客户端请求的生命周期、用户主体中包含的生命周期和服务主体中包含的生命周期。实际上，在实现方面，可以从 KDC 的配置中设置另一个限制并应用于任何票证。

4.3 Ticket Granting Server Request (TGS_REQ)

此时，已经证明是他/她所说的用户（因此在他/她的凭证缓存中有一个 TGT 和会话密钥 SK TGS），想要访问该服务但还没有合适的票证，将请求 (TGS_REQ) 发送到构造它的票证授予服务Ticket Granting Service ，如下所示：

使用用户principal、客户端机器时间戳创建一个身份验证器，并使用与 TGS 共享的session key加密所有内容，即：

Authenticator = { Principal Client , Timestamp }SK TGS
创建一个请求数据包，其中包含：ticket需要的服务principal，未加密的生命周期；已经用 TGS 的密钥加密的 Ticket Granting Ticket ；及刚刚创建的验证器。总之：

TGS_REQ = ( PrincipalService , Lifetime , Authenticator) { TGT }KTGS

4.4 Ticket Granting Server Replay (TGS_REP)

当前一个请求到达时，TGS 首先验证所请求服务的principal （PrincipalService) 存在于 KDC 数据库中：如果存在，则使用 krbtgt/REAM@REALM 的密钥打开 TGT 并提取会话密钥session key (SK TGS) 用于解密验证器authenticator。对于要签发的服务的ticket，它会检查以下条件是否成立：

TGT 尚未到期；
这PrincipalClient 存在于验证器中的与存在于 TGT 中的匹配；
authenticator 不存在于重放缓存中且未过期；
如果 IP_list 不为空，它检查请求数据包的源 IP 地址（TGS_REQ）是否是列表中包含的 IP 地址之一；

上述检查的件证明TGT确实属于发出请求的用户，因此TGS开始处理回复如下：

它随机创建一个会话密钥session key，该密钥将是客户端和服务之间共享的secret。称为SKService;
它创建服务t的icket，将请求用户的Principal、服务Principal、IP 地址列表、时间戳格式的（KDC）日期和时间、生命周期（作为 TGT 的生命周期和与服务Principal相关联），最后是会话密钥 SKService,也被称作Tserveice，新的ticket如下：
它发送包含以下内容的回复消息：先前创建的ticket（使用service secret key加密（我们称之为

KService)）; 服务Principal、时间戳、生存期和新会话密钥，都使用从 TGT 中提取的会话密钥进行加密。总之：

当客户端收到回复时，凭证缓存中会有session key SK TGS，它可以解密包含其他会话密钥的消息部分，并将其与服务票证service ticket一起记忆，然而，它仍然是加密的。

4.5 Application Request (AP_REQ)

拥有访问服务的凭据（即ticket和相关session key）的客户端可以通过 AP_REQ 消息请求应用服务器访问资源。应该记住，与之前涉及 KDC 的消息不同，AP_REQ 不是标准的，而是因应用程序而异。因此，应用程序程序员的工作是制定客户端将使用其凭据向服务器证明其身份的策略。但是，我们可以通过示例考虑以下策略：

客户端创建一个包含用户principal 和时间戳的身份验证器authenticator ，并使用与应用程序服务器共享的会话密钥 SKService加密所有内容，即：

Authenticator = { Principal Client , Timestamp }SKService
它创建一个包含服务ticket TService的请求数据包这是用它的秘密密钥和刚刚创建的验证器加密的。总之：

AP_REQ = Authenticator { TService }KService

当前一个请求到达时，应用服务器使用所请求服务的密钥打开票证并提取会话密钥 SK服务它用于解密验证器。为了确定发出请求的用户是可信的，从而授予对服务的访问权限，服务器会验证以下条件：

ticket 未过期；
验证器中存在的PrincipalClien与ticket中存在的匹配；
身份验证器不存在于重放缓存中且未过期；
如果 IP_list (从票证中提取) is not null 它检查请求数据包 (AP_REQ) 的源 IP 地址是否是列表中包含的 IP 地址之一；

注意：前面的策略与票据授予服务器用来检查请求服务票据的用户的真实性的策略非常相似。但这并不奇怪，因为我们已经解释过可以将 TGS 视为一个应用服务器，其服务是向那些使用 TGT 证明其身份的人提供票证。

4.6 Pre-Authentication

正如身份验证服务器回复 (AS_REP) 的描述中所见，在分发票证之前，KDC 只需检查请求用户和服务提供者的主体是否存在于数据库中。然后，特别是如果它涉及对 TGT 的请求，则更容易，因为 krbtgt/REALM@REALM 肯定存在，因此知道用户的主体存在就足以通过简单的初始身份验证请求获得 TGT . 显然，如果请求来自非法用户，则此 TGT 无法使用，因为他们不知道密码，也无法获取用于创建有效验证器的会话密钥。但是，以如此简单的方式获得的这张票可能会遭受暴力攻击，试图猜测该票所针对的服务的长期密钥。明显地，即使使用当前的处理能力，猜测服务的秘密也不是一件容易的事情，但是，在 Kerberos 5 中，引入了预身份验证概念来加强安全性。因此，如果 KDC 策略（可配置）请求对初始客户端请求进行预身份验证，则身份验证服务器会回复一个错误数据包，指示需要进行预身份验证。根据错误，客户端要求用户输入密码并重新提交请求，但这次添加了用用户长期密钥加密的时间戳，正如我们所知，这是通过将 string2key 应用于未加密的密码而获得的加盐后，如果有的话。这一次，KDC，既然知道了用户的秘钥，
需要注意的是，预身份验证是 KDC 策略，因此协议不一定需要它。在实现方面，MIT Kerberos 5 和 Heimdal 默认禁用预身份验证，而 Windows Active Directory 中的 Kerberos 和 AFS kaserver（这是一个预身份验证的 Kerberos 4）请求它。

5 详解Tickets

如前所述，既然已经讨论了 KDC 的操作和参与身份验证的主机之间的消息，我们现在可以转向票证。这些取决于它们内部是否设置了属性（也称为标志），以某种方式运行。我在下面列出了最重要的票证类型，即使考虑到我在谈论协议并不完全正确，我也会参考（足以使事情清楚）MIT Kerberos 5 的 1.3.6 版。

5.1 Initial tickets

初始票证是直接从 AS 获得的票证，即当用户必须通过输入密码进行身份验证时。从这里可以推断出 TGT 始终是初始票证。另一方面，服务票是由 TGS 在提供 TGT 时分发的，因此不是初始票。但是，此规则有一个例外：为了保证用户仅在几秒钟之前输入密码，某些 Kerberos 应用程序可能会要求服务票证为初始值；在这种情况下，尽管不是 TGT，但从 AS 而不是 TGS 请求票证，因此是初始票证。在操作方面，用户 pippo，希望获得机器 mbox.example.com 上 imap 服务的初始票证（因此不使用 TGT），使用命令：

[pippo@client01 pippo]$ kinit -S imap/mbox.example.com@EXAMPLE.COM pippo@EXAMPLE.COM pippo@EXAMPLE.COM 的
密码：
[pippo@client01 pippo]$
[pippo@client01 pippo]$ klist - f
票证缓存：FILE:/tmp/krb5cc_500
默认主体：pippo@EXAMPLE.COM有效起始过期服务主体
01/27/05 14:28:59 01/28/05 14:28:39 imap/mbox.example.com @EXAMPLE.COM标志：我Kerberos 4 票证缓存：/tmp/tkt500
klist：您没有缓存票证

应注意标志 I 的存在，表明它是初始票。

5.2 Renewable tickets

可更新票证可以重新提交给 KDC 进行更新，即在整个生命周期内重新分配。显然，只有当票证尚未过期且未超过最大续订时间（在密钥分发中心数据库中设置）时，KDC 才会接受续订请求。能够续订票证结合了出于安全原因持有短期票证的必要性，并且不必长时间重新输入密码：例如，假设一项工作必须处理数天且不得需要任何人为干预. 在以下示例中，pippo 要求提供最多持续一小时但可续订 8 天的票证：

kinit -l 1h -r 8d pippo
pippo@EXAMPLE.COM 的密码：
[pippo@client01 pippo]$
[pippo@client01 pippo]$ klist -f
票证缓存：FILE:/tmp/krb5cc_500
默认主体：pippo@EXAMPLE.COM有效起始到期服务主体
01/27/05 15:35:14 01/27/05 16:34:54 krbtgt/EXAMPLE.COM@EXAMPLE.COM更新至 02/03/05 15:35:14，标志：RI Kerberos 4 票证缓存：/tmp/tkt500
klist：您没有缓存票证

而 pippo 无需重新输入密码即可更新他的票证：

[pippo@client01 pippo]$ kinit -R
[pippo@client01 pippo]$
[pippo@client01 pippo]$ klist -f
Ticket cache: FILE:/tmp/krb5cc_500
默认委托人：pippo@EXAMPLE.COM有效起始过期服务委托人
01 /27/05 15:47:52 01/27/05 16:47:32 krbtgt/EXAMPLE.COM@EXAMPLE.COM更新至 02/03/05 15:35:14，标志：RIT Kerberos 4 票证缓存：/ tmp/tkt500
klist：您没有缓存任何票证

5.3 Forwardable tickets

假设我们在具有相关 TGT 的机器上有一个工作会话，并希望从它登录到另一台机器上，并保留票证。可转售票是这个问题的解决方案。从一台主机转发到另一台主机的票证本身是可转发的，因此一旦通过身份验证，就可以访问所有所需机器上的登录名，而无需重新输入任何密码。
要在没有 Kerberos 的情况下获得相同的结果，必须使用安全性较低的方法，例如 rsh 或使用 ssh 进行公钥身份验证。然而，后一种方法在用户主目录位于网络文件系统（例如 NFS 或 AFS）上的系统上可能不切实际，因为私钥（应该是私有的）会通过网络。

6 交叉认证 Cross Authentication

我们已经提到了属于某个领域的用户可以验证和访问另一个领域的服务的可能性。这种称为交叉身份验证的特性基于所涉及领域之间存在信任关系的假设。这可能是单向的，这意味着领域 A 的用户可以访问领域 B 的服务，但反之则不能，或者是双向的，正如人们所期望的，相反的情况也是可能的。在下面的段落中，我们将研究交叉身份验证，将信任关系分解为直接、传递和分层。

6.1 Direct trust relationships

这种类型的信任关系是基本的，是交叉认证的基础，用于构建我们稍后将看到的其他两种类型的关系。当领域 B 的 KDC 直接信任领域 A 的 KDC 时，就会发生这种情况，从而允许后一个领域的用户访问其资源。从实际的角度来看，通过让两个相关的 KDC 共享一个密钥来获得直接信任关系（如果需要双向信任，则密钥变为两个）。为此，引入了远程票证授予票证的概念，在两个领域 A 和 B 的示例中，它采用 krbtgt/B@A 形式，并使用相同的密钥添加到两个 KDC。这个密钥是保证两个领域之间信任的秘密。显然，要使其双向（即 A 也信任 B），

正如我们将在下面的示例中很快看到的那样，远程 TGT 的引入使交叉身份验证成为正常域内身份验证的自然概括：这强调了先前对 Kerberos 操作的描述继续有效，只要它被接受一个领域的 TGS 可以验证另一个领域的 TGS 发布的远程 TGT。注意当远程 TGT 不是由 AS 发出时出现的正式异常，就像本地 TGT 发生的那样，而是由本地票证授予服务器根据本地 TGT 发出。
现在让我们看一个例子来阐明这一切。让我们假设领域EXAMPLE.COM的用户pippo，其关联主体是pippo@EXAMPLE.COM，希望通过ssh访问属于TEST.COM领域的pluto.test.com服务器：

如果 Pippo 在领域EXAMPLE.COM 中还没有TGT，他会发出初始身份验证请求(kinit)。显然，回复来自他领域的AS；
他给 ssh pippo@pluto.test.com 无需重新输入密码即可在 pluto.test.com 上打开远程 shell 的命令；
ssh 客户端对 DNS 进行两次查询：它计算 pluto.test.com 的 IP，并在刚刚获得的地址上执行相反的操作，以获得规范形式的主机名 (FQDN)（在这种情况下，它与 pluto .test.com);
由于先前的结果，ssh 客户端然后意识到目的地不属于用户的领域，因此向领域EXAMPLE.COM 的TGS（注意，它为此向其领域的TGS 询问）远程TGT krbtgt /TEST.COM@EXAMPLE.COM;
使用远程 TGT，它向域 TEST.COM 的 TGS 请求 host/pluto.test.com@TEST.COM 服务票；
当 TEST.COM 票证授予服务收到请求时，它会检查其数据库中是否存在主体 krbtgt/TEST.COM@EXAMPLE.COM，它可以使用它来验证信任关系。如果此验证是肯定的，则最终颁发服务票证（使用 host/pluto.test.com@TEST.COM 的密钥加密），pippo 将发送到主机 pluto.test.com 以获取远程 shell。

6.2 Transitive trust relationships

当必须进行交叉身份验证的领域数量增加时，要交换的密钥数量呈二次增加。例如，如果有 5 个领域并且关系必须是双向的，则管理员必须生成 20 个密钥（将 5 个元素的组合乘以 2 乘以 2）。

为了解决这个问题，Kerberos 5 在信任关系中引入了传递性：如果领域 A 信任领域 B，领域 B 信任领域 C，那么 A 将自动信任 C。这种关系属性大大减少了密钥的数量（即使认证通道增加）。

但是，仍然存在一个问题：如果不是直接的，客户端无法猜测身份验证路径（capath）。因此，必须通过在每个客户端的配置中创建一个特殊的节 ([capaths]) 来通知他们正确的路径。KDC 也必须知道这些路径，KDC 将使用它们来检查传输。

6.3 Hierarchical trust relationships

如果在组织内使用大写字母命名领域的约定（强烈推荐选择），并且如果后者属于层次结构，则 Kerberos 5 将支持具有信任关系的相邻领域（层次结构）（自然，这种假定的信任必须得到适当密钥的支持）并将自动构建（无需 capaths）传递身份验证路径。但是，管理员可以通过在客户端配置中强制使用 capaths 来更改此自动机制（例如出于效率原因）。