词汇表

Access Control List（ACL，访问控制列表）

包含具有特定访问权限的主体列表的文件。通常，服务器通过查看访问控制列表来验证客户机是否有权使用其服务。请注意，如果没有 ACL 的允许，则仍会拒绝 GSS-API 所验证的主体使用服务。

authentication（验证）

用于检验所声明的主体身份的安全服务。

authorization（授权）

用于确定以下情况的过程：主体是否可以使用服务、允许主体访问哪些对象以及允许针对每个对象执行的访问类型。

client（客户机）

狭义上讲，是指代表用户使用网络服务的进程，例如使用 rlogin 的应用程序。在某些情况下，服务器本身即可是其他某个服务器或服务的客户机。非正式地讲，是指使用服务的主体。

confidentiality（保密性）

用于对数据进行加密的安全服务。保密性还包括完整性和验证服务。另请参见 authentication（验证）、integrity（完整性）、service（服务）。

consumer（使用者）

使用系统服务的应用程序、库或内核模块。

context-level token（上下文级别的令牌）

请参见 token（令牌）。

context（上下文）

两个应用程序之间的信任状态。在两个对等应用程序之间成功建立了上下文之后，上下文接收器可以识别上下文启动者即是所声明的主体，并且可以对发送到上下文接收器的消息进行验证和解密。如果上下文中包括相互验证，则启动器便可知道接收器的标识是否有效，并且还可以对来自接收器的消息进行验证和解密。

credential cache（凭证高速缓存）

包含通过指定机制存储的凭证的存储空间（通常是文件）。

credential（凭证）

用于标识主体和主体身份的信息包。凭证用于指定主体以及主体通常具有的特权。凭证通过安全机制生成。

data replay（数据重放）

消息流中的一条消息被多次接收到。许多安全机制都支持数据重放检测。必须在建立上下文时请求重放检测（如果可用）。

data type（数据类型）

指定数据段所采用的格式，例如 int、string、gss_name_t 结构或者 gss_OID_set 结构。

delegation（委托）

如果基础安全机制允许的话，主体（通常是上下文启动器）可以通过将其凭证委托给对等主体（通常是上下文接受器）来将对等主体指定为代理。接受者可以使用所委托的凭证来代表最初的主体发出请求，当主体在一台计算机上使用 rlogin 登录到另一台计算机时可能会出现这种情况。

exported name（导出名称）

已通过 gss_export_name() 从 GSS-API 内部名称格式转换为 GSS-API 导出名称格式的机制名称。可以使用 memcmp() 将导出名称与那些非 GSS-API 字符串格式的名称进行比较。另请参见 mechanism name, MN（机制名称）和 name（名称）。

flavor（方式）

以前，安全方式和验证方式是等效的术语，都用于表示验证类型（如 AUTH_UNIX、AUTH_DES 和 AUTH_KERB）的方式。RPCSEC_GSS 也是一种安全方式，虽然其除了验证之外还提供完整性和保密性服务。

GSS-API

通用安全服务应用编程接口。即为各种模块化安全服务提供支持的网络层。GSS-API 可提供安全验证、完整性和保密性服务，并允许应用程序在安全性方面获得最大的可移植性。另请参见 authentication（验证）、confidentiality（保密性）和 integrity（完整性）。

host（主机）

可通过网络访问的计算机。

integrity（完整性）

一种安全服务，除了用于进行用户验证之外，还用于通过加密标记来为所传送的数据提供有效性证明。另请参见 authentication（验证）、confidentiality（保密性）和 message integrity code, MIC（消息完整性代码）。

mechanism name, MN（机制名称）

GSS-API 内部格式名称的特殊实例。常规的 GSS-API 内部格式名称中可以包含名称的多个实例，每个实例都采用基础机制格式。但是，机制名称对于特定的机制是唯一的。机制名称通过 gss_canonicalize_name() 生成。

mechanism（机制）

指定加密技术以实现数据验证或保密性的软件包。Kerberos v5 和 Diffie-Hellman 公钥即是此类示例。

message integrity code, MIC（消息完整性代码）

附加到所传送数据的加密标记，用于确保数据的有效性。数据的接收者会生成另一个 MIC，并将该 MIC 与已发送的 MIC 进行比较。如果这两个 MIC 相等，则表明消息有效。某些 MIC（如那些通过 gss_get_mic() 生成的 MIC）对于应用程序可见，而其他 MIC（如那些通过 gss_wrap() 或 gss_init_sec_context() 生成的 MIC）则对于应用程序不可见。

message-level token（消息级令牌）

请参见 token（令牌）。

message（消息）

采用 gss_buffer_t 对象格式的数据，该对象从基于 GSS-API 的应用程序发送到对等应用程序。发送到远程 ftp 服务器的 "ls" 便是一个消息示例。

消息中不仅仅包含用户所提供的数据。例如，gss_wrap() 可提取未包装的消息并生成要发送的已包装消息。经过包装的消息同时包括原始消息和随附的 MIC。GSS-API 所生成的不包括消息的信息是一个令牌。请参见 token（令牌）。

MIC

请参见 message integrity code, MIC（消息完整性代码）。

MN

请参见 mechanism name, MN（机制名称）。

mutual authentication（相互验证）

建立了上下文之后，上下文启动器必须向上下文接收器验证其身份。在某些情况下，启动器可能会请求接收器对其进行验证。如果接受器执行此操作，则可以说启动器和接收器进行相互验证。

name type（名称类型）

指定了名称的特定形式。名称类型以 gss_OID 类型存储，用于指明名称所使用的格式。例如，user@machine 的名称类型可以是 GSS_C_NT_HOSTBASED_SERVICE。另请参见 exported name（导出名称）、mechanism name, MN（机制名称）和 name（名称）。

name（名称）

主体的名称，如 user@machine。GSS-API 中的名称通过 gss_name_t 结构进行处理，该结构对于应用程序是不透明的。另请参见 exported name（导出名称）、mechanism name, MN（机制名称）、name type（名称类型）和 principal（主体）。

opaque（不透明）

应用于一段数据，其值或格式通常对于使用它的函数不可见。例如，gss_init_sec_context() 的 input_token 参数对于应用程序是不透明的，但是对于 GSS-API 则至关重要。同样，gss_wrap() 的 input_message 参数对于 GSS-API 也是不透明的，但是对于进行包装的应用程序至关重要。

out-of-sequence detection（失序检测）

许多安全机制都可以检测消息流中的消息是否未按正确的顺序接收。必须在建立上下文时请求消息检测（如果可用）。

per-message token（每消息令牌）

请参见 token（令牌）。

principal（主体）

参与网络通信并且具有唯一名称的客户机/用户或服务器/服务实例；基于 GSS–API 的事务涉及主体之间的交互。主体名称的示例包括：

• user

• user@machine

• nfs@machine

• 123.45.678.9

• ftp://ftp.company.com

另请参见 name（名称）和 name type（名称类型）。

privacy（保密性）

请参见 confidentiality（保密性）。

provider（提供者）

用于为使用者提供服务的应用程序、库或内核模块。

Quality of Protection, QOP（保护质量）

用于选择与完整性服务或保密性服务结合使用的加密算法的参数。如果与完整性服务结合使用，则 QOP 会指定用于生成消息完整性代码 (message integrity code, MIC) 的算法。如果与保密性服务结合使用，则 QOP 会指定用于对 MIC 和消息均进行加密的算法。

replay detection（重放检测）

许多安全机制都可以检测是否错误重复了消息流中的消息。必须在建立上下文时请求消息重放检测（如果可用）。

security flavor（安全方式）

请参见 flavor（方式）。

security mechanism（安全机制）

请参见 mechanism（机制）。

security service（安全服务）

请参见 service（服务）。

server（服务器）

用于为网络客户机提供资源的主体。例如，如果使用 rlogin 登录到计算机 boston.eng.acme.com，则该计算机即是提供 rlogin 服务的服务器。

service（服务）

1. （也称为网络服务）提供给网络客户机的资源，通常由多台服务器提供。例如，如果使用 rlogin 登录到计算机 boston.eng.acme.com，则该计算机即是提供 rlogin 服务的服务器。

2. 安全服务可以是完整性服务或保密性服务，提供除验证之外的保护级别。另请参见 authentication（验证）、integrity（完整性）和 confidentiality（保密性）。

token（令牌）

采用 GSS-API gss_buffer_t 结构形式的数据包。令牌通过 GSS-API 函数生成，用于传送到对等应用程序。

令牌具有以下两种类型：上下文级别的令牌，包含用于建立或管理安全上下文的信息。例如，gss_init_sec_context() 可将上下文启动器的凭证句柄、目标计算机的名称、所请求的各种服务的标志以及可能的其他项捆绑到要发送到上下文接收器的令牌中。

消息令牌（又称为每消息令牌或消息级别的令牌），包含 GSS-API 函数根据发送到对等应用程序的消息所生成的信息。例如，gss_get_mic() 可为指定的消息生成一个标识加密标记，并将其存储到随该消息发送到对等应用程序的令牌中。从技术上来说，令牌与消息是不同的，这就是为什么称 gss_wrap() 生成的是 output_message 而不是 output_token。

另请参见 message（消息）。