Kerberos 术语

下一节介绍了 Kerberos 术语及其定义。这些术语可用于整个 Kerberos 文档。要理解 Kerberos 概念，必须先了解这些术语。

特定于 Kerberos 的术语

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

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

stash file（存储文件）包含 KDC 的主密钥。当重新启动服务器以便在启动 kadmind 和 krb5kdc 命令之前自动验证 KDC 时，将使用此密钥。由于此文件包含主密钥，因此应将此文件及其所有备份安全保存。此文件是使用 root 的只读权限创建的。要确保此文件安全，请勿更改相应的权限。如果此文件已被破坏，则其他用户可能会使用主密钥来访问或修改 KDC 数据库。

特定于验证的术语

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

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

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

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

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

• 服务的主体名称

• 用户的主体名称

• 用户主机的 IP 地址

• 时间标记

• 定义票证生命周期的值

• 会话密钥的副本

所有此类数据都使用服务器的服务密钥进行加密。 请注意，KDC 可颁发嵌入在以下介绍的凭证中。 颁发票证之后，可重用票证直到其到期为止。

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

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

票证类型

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

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

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

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

Initial（初始）

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

Invalid（未生效）

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

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

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

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

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

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

Renewable（可更新）

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

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

票证生命周期

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

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

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

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

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

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

图 26–1 如何确定 TGT 的生命周期

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

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

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

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

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

Kerberos 主体名称

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

表 26–4 Kerberos 主体名称示例

主体名称	说明
changepw/kdc1.example.com@EXAMPLE.COM	更改口令时，允许访问 KDC 的主 KDC 服务器的主体。
clntconfig/admin@EXAMPLE.COM	kclient 安装实用程序使用的主体。
ftp/boston.example.com@EXAMPLE.COM	ftp 服务使用的主体。此主体可用于替代 host 主体。
host/boston.example.com@EXAMPLE.COM	基于 Kerberos 的应用程序（例如 klist 和 kprop）和服务（例如 ftp 和 telnet）使用的主体。此主体称为 host 主体或服务主体，用于验证 NFS 挂载。
K/M@EXAMPLE.COM	主密钥名称主体。一个主密钥名称主体可与每个主 KDC 关联。
kadmin/history@EXAMPLE.COM	一种主体，其中包含用于保存其他主体的口令历史记录的密钥。每个主 KDC 都具有这些主体之一。
kadmin/kdc1.example.com@EXAMPLE.COM	允许使用 kadmind 访问 KDC 的主 KDC 服务器的主体。
kadmin/changepw.example.com@EXAMPLE.COM	一种主体，用于接受来自未运行 Solaris 发行版的客户机的口令更改请求。
krbtgt/EXAMPLE.COM@EXAMPLE.COM	生成票证授予票证时使用的主体。
krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM	此主体是跨领域的票证授予票证的示例。
nfs/boston.example.com@EXAMPLE.COM	NFS 服务使用的主体。此主体可用于替代 host 主体。
root/boston.example.com@EXAMPLE.COM	与客户机的 root 帐户关联的主体。此主体称作 root 主体，用于向已挂载 NFS 的文件系统提供 root 访问权限。
username@EXAMPLE.COM	用户的主体。
username/admin@EXAMPLE.COM	admin 主体，可用于管理 KDC 数据库。