安全风格

本节描述 RPCSEC_GSS API 的发展和本质。

RPCSEC_GSS 以前的安全

RPC 所支持的第一批安全风格中的一个是 AUTH_SYS (又作 AUTH_UNIX)。 AUTH_SYS 借助用户和组 ID， 提供了一个 UNIX 风格的资格，用于识别一个消息的发送方和接收方。 AUTH_SYS 易于实施；然而，其也易于绕过，因为其没有提供真正的鉴别 - 也就是说，无法让一个服务器来验证一个客户机实际就是其所声称的身份。因此，在 AUTH_SYS 下伪造一个网络请求就较为容易。

后来的一个安全风格，AUTH_DES，是在 AUTH_SYS 之后不久出现的。 AUTH_DES 基于一个公用密钥鉴别 - 它使用一个 Diffie-Hellman 密钥交换来在一个客户机的私有密钥和一个服务器的公用密钥之间产生一个共有密钥。共有密钥用于为一个 DES 对话密钥加密，而一个服务器为后者解密，以建立一个对话。

尽管 AUTH_DES 代表着一个相对于 AUTH_SYS 的显著的进步，但对广泛应用还是有一些限制。对很多人来讲，主要的反对面就是依照今天的加密标准，其密钥尺寸有些不够长。

最终，另一 RPC 安全风格得到引进。 AUTH_ KERB，基于 Kerberos V4，提供有比 AUTH_DES 或 AUTH_SYS 更好的安全。然而，其还是可以被利用。

如要了解更多有关这些安全风格的信息，请参见 ONC+ Developer's Guide。

完整性和隐私：GSS-API

为了改善安全，一个新的网络层，类属安全标准 API，或 GSS-API，得以添加。 GSS-API 框架结构提供了鉴别以外的两个额外的安全 服务：

• 完整性。与完整性服务一起， GSS-API 使用底层机制来鉴别程序之间所交换的消息。加密校验和建立：

  • 数据发端方对接收方的身份

  • 接收方对发端方的身份 (如果相互鉴别被请求)

  • 所传输的数据自身的可靠性

• 隐私。隐私服务包括完整性服务。另外，所传输的数据也 经过加密，以便使其受到保护，防备任何的偷听者。

  由于美国输出限制，隐私服务可能不是所有的 SEAM 用户均可用的。

---

注意：

当前， GSS-API 并未对外批露。然而，通过 RPCSEC_GSS 函数，某些 GSS-API 特性是 "可见"的- 可以用一种 "不透明" 的方式对其进行操纵。程序员无需直接顾及它们的值。

---

RPCSEC_GSS API

RPCSEC_GSS 安全风格允许 ONC RPC 应用程序来利用 GSS-API 的特性。 RPCSEC_GSS 居于 GSS-API 层的 "顶部"，情形如下：

图形 8-1 GSS-API 和 RPCSEC_GSS 安全层

使用针对 RPCSEC_GSS， ONC RPC 应用程序的编程接口，可以指定：

机制

一种安全措施。每个种类的安全机制均提供一个不同种类的数据保护，以及一个或多个级别的数据保护。这样的话，就是指 GSS-API 所支持的任何安全机制 (Kerberos V5，RSA 公用密钥，等等)。

安全服务

或是隐私，或是完整性 (或两者都不是)。默认为完整性。服务是与机制无关的。

QOP

保护质量。 QOP 指定用于实施隐私或完整性服务的加密算法的类型。每个安全机制可以有一个或多个 QOP 与其相关联。

应用程序可以通过 RPCSEC_GSS 所提供的函数，获得有效 QOP 和机制的列表。 (请参见 "其它函数"。) 开发者应当避免将机制和 QOP 硬性编码进其应用程序，以便该应用程序不需要修改就可以使用新的或不同的机制和 QOP。

---

注意：

从历史上讲，"安全风格"和"鉴别风格"指的是同一意思。随着 RPCSEC_GSS 的引进， "风格" 现在拥有一个有些不同的意义。与鉴别一起，风格现在可以包括一个服务 (完整性或隐私)，尽管当前 RPCSEC_GSS 是唯一可以做到这一点的风格。

---

使用 RPCSEC_GSS，ONC RPC 应用程序可以与一个对等机建立一个安全的环境，交换数据，以及销毁环境，就象它们对待其它的风格一样。一旦一个环境得到建立，应用程序就可以为所发送的每个数据单元更改 QOP 和服务。

如要了解更多有关 RPCSEC_GSS 的信息，其中包括 RPCSEC_GSS 数据类型，请参见 rpcsec_gss(3N) 手册页。