[Kerberos] Kerberos教程（一）

1 简介

Kerberos协议旨在通过开放和不安全的网络提供可靠的身份验证，其中可能拦截属于它的主机之间的通信。但是，应该知道，如果使用的计算机容易受到攻击，Kerberos不提供任何保证：身份验证服务器，应用程序服务器（imap，pop，smtp，telnet，ftp，ssh，AFS，lpr，...）和客户端必须不断更新，以确保请求用户和服务提供商的真实性。

以上几点证明了这句话：“Kerberos是不受信任网络上可信主机的身份验证协议”。举例来说，并重申这一概念：如果获得对服务器的特权访问的人可以复制包含密钥的文件，则Kerberos的策略是无用的。实际上，入侵者会将此密钥放在另一台计算机上，并且只需要为该服务器获取一个简单的欺骗DNS或IP地址，以便将客户端显示为可靠的服务器。

2 目的

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

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

3 组件和术语的定义

3.1 Realm

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

基本上，当且仅当他/它与该领域的认证服务器共享秘密（密码/密钥）时，用户/服务才属于领域。

领域的名称区分大小写，即大写和小写字母之间存在差异，但通常领域始终以大写字母显示。在组织中，使领域名称与DNS域相同（尽管是大写字母）也是一种很好的做法。在选择领域名称时遵循这些提示可以显着简化Kerberos客户端的配置，尤其是在需要与子域建立信任关系时。举例来说，如果组织属于DNS域example.com，则相关的Kerberos领域是EXAMPLE.COM是合适的。

3.2 Principle

Princip是用于引用身份验证服务器数据库中的条目的名称。主体与给定领域的每个用户，主机或服务相关联。Kerberos 5中的主体具有以下类型：

COMPONENT1 / COMPONENT2 /.../ componentN @ REALM

但是，实际上最多使用两个组件。对于引用用户的条目，主体是以下类型：

名称[/实例] @REALM

该实例是可选的，通常用于更好地限定用户类型。例如，管理员用户通常具有管理员实例。以下是引用用户的主体示例：

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

相反，如果条目引用服务，则主体采用以下形式：

服务/主机名@ REALM

第一个组件是服务的名称，例如imap，AFS，ftp。通常它是单词host，用于表示对机器的通用访问（telnet，rsh，ssh）。第二个组件是提供所请求服务的机器的完整主机名（FQDN）。重要的是，此组件与应用程序服务器的IP地址的DNS反向解析完全匹配（以小写字母表示）. 以下是引用服务的委托人的有效示例：

imap/mbox.example.com@EXAMPLE.COM host/server.example.com@EXAMPLE.COM afs/example.com@EXAMPLE.COM

应该注意的是，最后一种情况是一个例外，因为第二个组件不是主机名，而是主体引用的AFS单元的名称。最后，有些主体不是指用户或服务，而是在认证系统的操作中发挥作用。一个整体示例是krbtgt / REALM @ REALM，其关联密钥用于加密票证授予票证（稍后我们将对此进行说明）。

在Kerberos 4中，永远不会有两个以上的组件，它们由字符“。”分隔。当引用服务的主体中的主机名是短的，而不是FQDN时，而不是“/”。以下是有效的例子：

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

3.3 Ticket

票证是客户端呈现给应用程序服务器以证明其身份的真实性的事物。票证由认证服务器发出，并使用它们所针对的服务的密钥加密。由于该密钥是仅在认证服务器和提供服务的服务器之间共享的秘密，因此即使请求该票证的客户端也不知道它或改变其内容。机票中包含的主要信息包括：

请求用户的主体（通常是用户名）;
它旨在用于服务的主体;
可以使用故障单的客户端计算机的IP地址。在Kerberos 5中，此字段是可选的，也可以是多个字段，以便能够在NAT或多宿主下运行客户端。
门票有效期开始时的日期和时间（以时间戳格式）;
门票的最长寿命
会话密钥（这具有基本作用，如下所述）;

每张票都有一个到期日（通常为10小时）。这是必不可少的，因为身份验证服务器不再对已发出的票证有任何控制权。即使领域管理员可以随时阻止为某个用户发布新票证，也不能阻止用户使用他们已经拥有的票证。这是限制门票生命周期以限制任何滥用行为的原因。

门票包含许多其他信息和标志，表明了他们的行为，但我们不会在这里讨论。在查看身份验证系统的工作原理后，我们将再次讨论故障单和标记。

3.4 加密

3.4.1 加密类型(可略)

Kerberos 4实现了单一类型的加密，即56位的DES。此加密的弱点加上其他协议漏洞使Kerberos 4过时了。但是，Kerberos的第5版不预先确定支持的加密方法的数量或类型。每个特定实现的任务是支持和最佳地协商各种类型的加密。但是，协议的这种灵活性和可扩展性加剧了Kerberos 5的各种实现之间的互操作性问题。为了使用不同实现的客户端和应用程序和认证服务器进行互操作，它们必须至少具有一种共同的加密类型。与Kerberos 5的Unix实现和Windows Active Directory中存在的实现之间的互操作性相关的困难就是一个典型的例子。实际上，Windows Active Directory支持有限数量的加密，并且只有与Unix共用的56位DES。如果必须保证互操作性，尽管存在众所周知的风险，但这需要保持后者。该问题随后通过MIT Kerberos 5的1.3版解决。该版本引入了RC4-HMAC支持，它也存在于Windows中，并且比DES更安全。在支持的加密（但不是Windows）中，三重DES（3DES）和更新的AES128和AES256值得一提。Windows Active Directory支持有限数量的加密，并且只有与Unix共用的56位DES。如果必须保证互操作性，尽管存在众所周知的风险，但这需要保持后者。该问题随后通过MIT Kerberos 5的1.3版解决。该版本引入了RC4-HMAC支持，它也存在于Windows中，并且比DES更安全。在支持的加密（但不是Windows）中，三重DES（3DES）和更新的AES128和AES256值得一提。Windows Active Directory支持有限数量的加密，并且只有与Unix共用的56位DES。如果必须保证互操作性，尽管存在众所周知的风险，但这需要保持后者。该问题随后通过MIT Kerberos 5的1.3版解决。该版本引入了RC4-HMAC支持，它也存在于Windows中，并且比DES更安全。在支持的加密（但不是Windows）中，三重DES（3DES）和更新的AES128和AES256值得一提。

3.4.2 加密密钥

如上所述，Kerberos协议的目标之一是防止用户的密码以未加密的形式存储，即使在认证服务器数据库中也是如此。考虑到每个加密算法使用其自己的密钥长度，很明显，如果不强制用户对支持的每种加密方法使用固定大小的不同密码，则加密密钥不能是密码。由于这些原因，string2key引入了一种功能，它将未加密的密码转换为适合所用加密类型的加密密钥。每次用户更改密码或输入密码进行身份验证时，都会调用此函数。string2key被称为散列函数，这意味着它是不可逆的：假设加密密钥无法确定生成它的密码（除非是暴力）。著名的哈希算法是MD5和CRC32。

3.4.3 盐

在Kerberos 5中，与版本4不同，已经引入了密码盐的概念。这是在应用string2key函数获取密钥之前要连接到未加密密码的字符串。Kerberos 5使用与salt相同的用户主体：

K pippo = string2key（P pippo +“pippo@EXAMPLE.COM”）

K pippo是用户pippo的加密密钥，P pippo是用户的未加密密码。这种盐具有以下优点：

属于同一领域且具有相同未加密密码的两个主体仍具有不同的密钥。例如，假设一个管理员拥有日常工作的主体（pippo@EXAMPLE.COM）和一个管理工作的管理员（pippo/admin@EXAMPLE.COM）。出于方便的原因，该用户很可能为两个主体设置了相同的密码。盐的存在保证了相关的键是不同的。
如果用户在不同领域有两个帐户，则两个领域的未加密密码相同是相当频繁的：由于存在盐，一个领域可能会损害帐户，不会自动导致另一个妥协。

可以配置空盐以与Kerberos 4兼容。反之亦然，为了与AFS兼容，可以配置不是主体的完整名称的盐，而只是单元的名称。

在讨论了加密类型，string2key和salt的概念之后，可以检查以下观察的准确性：为了在各种Kerberos实现之间存在互操作性，仅仅协商一种常见的加密方式是不够的，但是也需要使用相同类型的string2key和salt。同样重要的是要注意，在解释string2key和salt的概念时，仅引用用户主体，而不是服务器的主体。原因很清楚：即使服务与身份验证服务器共享密钥，服务也不是未加密的密码（谁会输入？），但是一旦由Kerberos服务器上的管理员生成的密钥被记忆为它位于提供服务的服务器上。

3.4.4 密钥版本号（kvno）

当用户更改密码或管理员更新应用程序服务器的密钥时，通过推进计数器来记录此更改。标识密钥版本的计数器的当前值被称为密钥版本号或更简称为kvno。

3.5 密钥分发中心（KDC）

我们一直在谈论身份验证服务器。由于它是用户和服务认证中涉及的基本对象，因此我们现在将更深入地了解它，而不必考虑其操作的所有细节，而不是专用于协议操作的部分的主题。 Kerberos环境中的身份验证服务器基于其用于访问服务的票证分发功能，称为密钥分发中心或更简要的KDC。由于它完全驻留在单个物理服务器上（通常与单个进程一致），因此可以在逻辑上将其分为三个部分：数据库，身份验证服务器（AS）和票证授予服务器（TGS）。我们来看看它们。

注意：可以在主/从（MIT和Heimdal）或Multimaster结构（Windows Active Directory）中使服务器在域内冗余。协议不描述如何获得冗余，但取决于所使用的实现，这里不再讨论。

3.5.1 数据库

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

Entry所关联的Principal;
加密密钥和相关的kvno;
与Principal相关的Ticket最长有效期;
可以renewed与Principle关联的Ticket的最长时间（仅限Kerberos 5）;
表示Tickets行为的属性或标志;
Password到期日;
Principal的到期日，之后不会发出票。

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

3.5.2 认证服务器（AS）

当尚未通过身份验证的用户必须输入密码时，身份验证服务器是KDC的一部分，它会回复来自客户端的初始身份验证请求。为了响应身份验证请求，AS会发出一个称为Ticket Granting Ticket的特殊Ticket，或者更简要的TGT，与之关联的主体是krbtgt / REALM @ REALM。如果用户实际上是他们所说的人（我们稍后会看到他们如何证明这一点），他们可以使用TGT获取其他service tickets，而无需重新输入密码。

3.5.3 票证授予服务器（TGS）

TGS是KDC组件，它将service tickets分发给具有有效TGT的客户端，从而保证用于在应用程序服务器上获取所请求资源的身份的真实性。可以将TGS视为应用服务器（假定访问它需要呈现TGT），其提供service tickets作为服务的发布。重要的是不要混淆缩写TGT和TGS：第一个表示ticket，第二个表示service。

3.6 Session Key

正如我们所看到的，users和services与KDC共享秘密。对于users，此sercret是从其password派生的key，而对于services，它是他们的secret key（由管理员设置）。这些密钥称为long term长期密钥，因为它们在工作会话更改时不会更改。

但是，users还必须与services共享秘密，至少在客户端在服务器上打开工作会话的时间：此密钥由KDC在发出ticket时生成，称为session key。用于服务的副本由ticket中的KDC封装（在任何情况下，他们的应用服务器都知道长期密钥并且可以对其进行解码并提取会话密钥），而用于该用户的副本封装在加密的数据包中用户长期密钥。会话密钥在证明用户的真实性方面起着重要作用，我们将在下一段中看到。

3.7 Authenticator

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

3.8 重放缓存Replay Cache

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

3.9 凭证缓存Credential Cache

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

【参考】

http://www.kerberos.org/software/tutorial.html