セキュリティフレーバ

この節では、RPCSEC_GSS API の開発過程を説明します。

RPCSEC_GSS 以前のセキュリティ

RPC がサポートした最初のセキュリティフレーバの 1 つは AUTH_SYS (AUTH_UNIX とも呼ぶ) でした。AUTH_SYS は、ユーザー ID とグループ ID を使用する UNIX 方式の資格を提供して、メッセージの送信者と受信者を識別していました。AUTH_SYS は簡単に実装できましたが、同様に、簡単に資格を偽ることもできました。これは、AUTH_SYS が本当の認証を提供しなかったためです。つまり、サーバーには、そのクライアントが本当に要求しているクライアントであるのかどうかを確認する方法がありませんでした。したがって、AUTH_SYS 下では、比較的簡単に不当な要求をネットワークへ出すことができました。

AUTH_SYS から短期間のうちに次のセキュリティフレーバ AUTH_DES が考え出されました。AUTH_DES は公開鍵認証を元に作成されました。つまり、Diffie-Hellman 鍵交換を使用して、クライアントの公開鍵とサーバーの公開鍵の間で共通鍵を生成します。次に、この共通鍵で DES セッション鍵を暗号化します。そして、サーバーがこの DES セッション鍵の暗号を復号化して、セッションを使用可能にします。

AUTH_DES は AUTH_SYS よりも優れていましたが、使用には制限がありました。主な欠点は、鍵のサイズが今日の暗号化の標準と比べると幾分小さいということでした。

最終的に、もう 1 つの RPC セキュリティフレーバ AUTH_KERB が導入されました。AUTH_KERB は Kerberos V4 を元に作成され、AUTH_DES や AUTH_SYS よりも高いセキュリティを提供します。しかし、資源を多く使用する可能性がありました。

上記セキュリティフレーバについての詳細は、『ONC+ 開発ガイド』を参照してください。

完全性とプライバシ: GSS-API

セキュリティを高めるため、新しいネットワーク層 Generic Security Standard API (GSS-API) が追加されました。GSS-API フレームワークは認証よりも優れた 2 つのセキュリティサービスを提供します。

• 完全性

  完全性サービスを利用すると、GSS-API はプログラム間で交換されるメッセージを機構に基づいて認証できます。暗号チェックサムによって、次のことが可能となります。

  • データの受信者に対する送信者の識別

  • データの送信者に対する受信者の識別 (相互認証が要求された場合)

  • 転送されるデータ自体の認証

• プライバシ

  プライバシサービスには完全性サービスが含まれます。さらに、転送されるデータも暗号化されるため、第三者からデータを保護できます。

  米国の輸出規制により、プライバシサービスはすべての SEAM ユーザーが利用できるわけではありません。

現在、GSS-API は公開されていません。しかし、一部の GSS-API 機能は RPCSEC_GSS 関数を通じて参照できます。つまり、このような機能は確定されない方法で操作できます。プログラマはこれらの値に直接関わる必要はありません。

The RPCSEC_GSS API

RPCSEC_GSS セキュリティフレーバを使用すると、ONC RPC アプリケーションは、GSS-API の特徴を利用できます。RPCSEC_GSS は、次のように GSS-API 層の上に位置します。

図 8-1 GSS-API と RPCSEC_GSS セキュリティ層

RPCSEC_GSS のプログラミングインタフェースを使用すると、ONC RPC アプリケーションは次のことを指定できます。

機構

セキュリティパラダイム。セキュリティ機構が提供するデータ保護はその種類ごとに異なり、同様に、データ保護のレベルも 1 つまたは複数存在する。この場合は、GSS-API がサポートする任意のセキュリティ機構 (Kerberos V5、RSA 公開鍵など)

セキュリティサービス

プライバシまたは完全性のどちらか (あるいは、どちらでもない)。デフォルトは完全性。サービスは機構に依存しない

QOP

保護特性 (Quality of Protection)。プライバシまたは完全性のサービスを実装するときに使用される暗号化アルゴリズムのタイプを指定する。各セキュリティ機構は 1 つまたは複数の関連する QOP を持つことができる

アプリケーションは、RPCSEC_GSS が提供する関数を使用して、有効な QOP と機構のリストを取得できます (「さまざまな関数」を参照)。新しいまたは異なる機構や QOP を使用するたびにアプリケーションを変更する必要が生じないように、開発者は機構や QOP をアプリケーションでハードコーディングすることは避けてください。

従来「セキュリティフレーバ」と「認証フレーバ」の意味は同じでした。RPCSEC_GSS の導入とともに、「フレーバ」は現在少し意味が変わりました。フレーバに現在、認証とともに、(完全性またはプライバシの) サービスも含まれています。ただし、現在のところ、その対象は RPCSEC_GSS だけです。

他のフレーバと同様に、ONC RPC アプリケーションは RPCSEC_GSS を使用して、ピアとセキュリティコンテキストを確立し、データを交換し、コンテキストを破棄します。コンテキストが確立されると、アプリケーションは送信されるデータ単位ごとに QOP とサービスを変更できます。

RPCSEC_GSS についての詳細 (RPCSEC_GSS データタイプも含む) は、rpcsec_gss(3N) のマニュアルページを参照してください。