Kerberos 术语

以下章节介绍 Kerberos 的术语及其定义。整个 Kerberos 文档中使用了这些术语。要掌握 Kerberos 概念，必须先了解这些术语。

特定于 Kerberos 的术语

要管理 KDC，您需要了解本节中介绍的术语。

密钥分发中心 (Key Distribution Center, KDC) 是负责颁发凭证的 Kerberos 组件。这些凭证是使用 KDC 数据库中存储的信息创建的。每个领域至少需要两个 KDC：一个主 KDC，以及至少一个从 KDC。所有 KDC 都可生成凭证，但仅有主 KDC 才能处理对 KDC 数据库所做的任何更改。

存储文件包含 KDC 的主密钥。当重新引导服务器以便在启动 kadmind 和 krb5kdc 命令之前自动验证 KDC 时，将使用此密钥。因为该文件包含主密钥，因此，该文件及其所有备份都应安全保存。该文件以 root 的只读权限创建。为确保文件安全，请勿更改其权限。如果该文件遭破坏，可以使用密钥访问或修改 KDC 数据库。

特定于验证的术语

要了解验证过程，您需要知道本节中介绍的术语。程序员和系统管理员应该熟悉这些术语。

客户机是用户工作站上运行的软件。在客户机上运行的 Kerberos 软件将在此过程中发出许多请求。因此，区分该软件的操作和用户的操作非常重要。

术语服务器和服务经常混用。具体而言，术语服务器用于定义运行 Kerberos 软件的物理系统。术语服务对应于服务器上支持的特定功能（如 ftp 或 nfs）。文档通常会将服务器描述为服务的一部分，但此定义混淆了这些术语的含义。因此，术语服务器是指物理系统。术语服务是指软件。

Kerberos 产品使用两种类型的密钥。一种类型是口令派生的密钥。口令派生的密钥分配给每个用户主体，且仅为用户和 KDC 所知。Kerberos 产品使用的另一种密钥类型是随机密钥，它与口令无关，因此不适合用户主体使用。随机密钥通常用于在密钥表中具有相应项并具有 KDC 生成的会话密钥的服务主体。服务主体可以使用随机密钥，因为服务可以访问密钥表中允许其以非交互方式运行的密钥。会话密钥由 KDC 生成，并在客户机和服务之间共享，可用于在两者之间提供安全事务。

票证是一种信息包，用于将用户身份安全地传递到服务器或服务。一个票证仅对一台客户机以及某台特定服务器上的一项特殊服务有效。票证包含：

• 服务的主体名称

• 用户的主体名称

• 用户主机的 IP 地址

• 时间戳

• 定义票证生命周期的值

• 会话密钥的副本

所有此类数据都使用服务器的服务密钥进行加密。请注意，KDC 可颁发嵌入在如下所述的凭证中的票证。颁发后的票证可重复使用，直到过期。

凭证是一种信息包，包含票证和匹配的会话密钥。凭证使用请求主体的密钥进行加密。通常，KDC 会生成凭证以响应客户机的票证请求。

验证者是服务器用于验证客户机用户主体的信息。验证者包含用户的主体名称、时间戳和其他数据。与票证不同，验证者只能使用一次，通常在请求访问服务时使用。验证者使用客户机和服务器共享的会话密钥进行加密。通常，客户机会创建验证者，并将其与服务器或服务的票证一同发送，以便向服务器或服务进行验证。

票证类型

票证具有可管理其使用方式的属性。这些属性在创建票证时指定，但之后亦可修改。例如，可将票证从可转发改为已转发。可以使用 klist 命令查看票证属性。请参见查看 Kerberos 票证。

以下一个或多个术语对票证进行了描述：

Forwardable（可转发）/forwarded（已转发）

可转发票证可以从一台主机发送到另一台主机，从而使客户机无需对自身进行重新验证。例如，如果用户 david 在用户 jennifer 的计算机上时获取了一张可转发票证，则前者可登录到自己的计算机，不必获取新的票证（从而对自身进行重新验证）。有关可转发票证的示例，请参见示例 26-1。

Initial（初始）

初始票证是一种直接颁发的票证，而并非基于票证授予票证的票证。某些服务（如用于更改口令的应用程序）可能会要求将票证标记为初始，以便向这些程序本身确保客户机可知道其密钥。初始票证表明客户机最近已进行了自我验证，而并非依赖于已长期使用的票证授予票证。

Invalid（无效）

无效票证是一个尚未变为可用的以后生效票证。应用服务器会拒绝无效票证，直到其通过验证为止。要进行验证，必须在票证开始时间已过之后由客户机将设置了 VALIDATE 标志的票证放置在票证授予服务请求的 KDC 中。

Postdatable（可以后生效）/postdated（以后生效）

以后生效的票证是一种在其创建之后的某个指定时间之前不会生效的票证。例如，此类票证对于计划在深夜运行的批处理作业非常有用，因为如果该票证被盗，则在运行批处理作业之前无法使用该票证。颁发以后生效的票证时，该票证尚未生效，且在其开始时间已过且客户机请求 KDC 进行验证之前一直保持此状态。通常，以后生效的票证在票证授予票证的到期时间之前会一直有效。但是，如果将以后生效的票证标记为可更新，则通常会将其生命周期设置为等于票证授予票证的整个生命周期的持续时间。

Proxiable（可代理）/proxy（代理）

有时，主体需要允许服务代表其执行操作。创建该票证时，必须指定代理的主体名称。Oracle Solaris 发行版不支持可代理票证或代理票证。

可代理票证与可转发票证类似，但前者仅对单个服务有效，而可转发票证授予服务对客户机身份的完全使用权限。因此，可以将可转发票证视为一种超级代理。

Renewable（可更新）

由于拥有很长生命周期的票证存在安全风险，因此可将票证指定为可更新票证。可更新票证具有两个到期时间：票证当前实例的到期时间，以及任意票证的最长生命周期（一周）。如果客户机要继续使用票证，则可在第一个到期时间之前更新票证。例如，某个票证的有效期为一个小时，而所有票证的最长生命周期为 10 个小时。如果持有该票证的客户机要将该票证再保留几个小时，则此客户机必须在有效的小时数内更新票证。如果票证到达最长票证生命周期（10 个小时），则该票证将自动过期且无法更新。

有关如何查看票证属性的信息，请参见查看 Kerberos 票证。

票证生命周期

每当主体获取包括票证授予票证 (ticket-granting ticket, TGT) 在内的票证时，都会将票证的生命周期设置为以下生命周期值中的最小值：

• 通过 kinit 的 -l 选项指定的生命周期值，前提是使用 kinit 获取票证。缺省情况下，kinit 使用最长生命周期值。

• kdc.conf 文件中指定的最长生命周期值 (max_life )。

• Kerberos 数据库中为提供票证的服务主体指定的最长生命周期值。如果使用 kinit，则服务主体为 krbtgt/realm。

• Kerberos 数据库中为请求票证的用户主体指定的最长生命周期值。

图 27-1 说明了如何确定 TGT 的生命周期以及四个生命周期值的来源。虽然该图说明的是如何确定 TGT 的生命周期，但所有主体获取票证时的情况基本相同。唯一的区别在于，kinit 不提供生命周期值，而提供票证的服务主体（非 krbtgt/ realm 主体）会提供最长生命周期值。

图 27-1 如何确定 TGT 的生命周期

可更新票证生命周期也是由四个值中的最小值确定的，但是使用的却是可更新的生命周期值，如下所示：

• 通过 kinit 的 -r 选项指定的可更新生命周期值，前提是使用 kinit 获取或更新票证。

• kdc.conf 文件中指定的最长可更新生命周期值 (max_renewable_life )。

• Kerberos 数据库中为提供票证的服务主体指定的最长可更新生命周期值。如果使用 kinit，则服务主体为 krbtgt/realm。

• Kerberos 数据库中为请求票证的用户主体指定的最长可更新生命周期值。

Kerberos 主体名称

每张票证都以主体名称标识。主体名称可以标识用户或服务。以下是一些主体名称的示例。

表 27-4 Kerberos 主体名称示例