test

Sun 企業辯證機制使用指南

安全性質

本節將說明 RPCSEC_GSS API 的開發及性質。

RPCSEC_GSS 之前的安全

RPC 所支援的最早的安全性質之一就是 AUTH_SYS（亦稱為 AUTH_UNIX）。AUTH_SYS 可以提供一張 UNIX 式的證書，利用使用者及群組識別碼來辨識一份訊息的發件人及收件人身份。AUTH_SYS 很容易實行。不過也很容易被人避開，因為它無法提供真正的辯證 - 亦即一個伺服器無法確認一個客戶端實際上就是它所宣稱的身份。因此在 AUTH_SYS 之下便很容易偽造一個網路要求。

在 AUTH_SYS 之後不久又出現了另外一種安全性質﹕AUTH_DES。AUTH_DES 是以一個共用的密鑰辯證為基礎的 - 它使用一種 Diffie-Hellman 密鑰交換來在客戶端的專用密鑰以及一個伺服器的公開密鑰之間產生一個共用密鑰。共用密鑰便被用來加密一個 DES 作業階段密鑰，伺服器會將其解密以建立一個作業階段。

雖然 AUTH_DES 要比 AUTH_SYS 大有進步，它仍然有某些限制，因此不能廣為使用。許多人主要反對的理由在於，以今天的加密標準而言，其密鑰的大小不夠。

終於最後又產生了另一種 RPC 安全性質。AUTH_KERB 是以 Kerberos V4 為基礎的，可以比 AUTH_DES 或 AUTH_SYS 提供較佳的安全防護。不過它還是有被利用的可能。

如需有關這些安全性質的詳細資訊，請參見 ONC+ 開發者使用指南。

整合性及保密性﹕GSS-API

為了改善安全上的防護，另外新增了兩項通用安全標準﹕API 或 GSS-API 來作為新的網路層級。GSS-API 架構在辯證之外有兩種額外的安全服務﹕

註解 -

目前 GSS-API 尚未被公開。不過某些特定的 GSS-API 功能可藉由 RPCSEC_GSS 功能而變得“可見” - 亦即以一種“不透明”的方式來操控它們。程式設計師不需要直接考量其數值。

RPCSEC_GSS API

RPCSEC_GSS 安全性質允許 ONC RPC 應用程式利用 GSS-API 的功能。RPCSEC_GSS 位於 GSS-API 層級“之上”，如下所示﹕

圖 8-1 GSS-API 及 RPCSEC_GSS 安全層級

Graphic

ONC RPC 應用程式可以利用 RPCSEC_GSS 的程式編寫介面來指定﹕

機制

一種安全的樣式。每一種安全機制都可以提供不同類型的資料保護，以及一或多層的資料保護。這__指的是 GSS-API 所支援的任何安全機制（Kerberos V5、RSA 共用密鑰等等）。

安全服務

保密性或是整合性（或兩者皆否）。預設值為整合性。此項服務與機制無關。

QOP

保護品質。QOP 指定要用來實施保密性或整合性服務的加密運算式類型。每一種安全機制都有一或多個相關的 QOP。

應用程式可以透過 RPCSEC_GSS 所提供的函數來取得有效的 QOP 及機制清單。（請參見 "其他函數"。）開發者應該避免硬性將機制及 QOP 編碼入其應用程式，以免使用新的或不同的機制及 QOP 來修改應用程式。

註解 -

歷史上來說，“安全性質”及“辯證性質”指的是相同的東西。自從 RPCSEC_GSS 問市之後，現在“性質”就有了一種較為不同的意義。性質可以包括一項服務（整合性或保密性）及辯證，雖然目前只有 RPCSEC_GSS 這一種性質是如此。

ONC RPC 應用程式可以使用 RPCSEC_GSS 來建立與同層的安全上下文、交換資料、並且損毀上下文，正如與其他性質一樣。一旦建立上下文之後，應用程式就能為每個傳送的資料單位變更 QOP 及服務。

如需有關 RPCSEC_GSS 的詳細資訊，包括 RPCSEC_GSS 資料類型，請參見 rpcsec_gss(3N) 線上援助頁。