汎用セキュリティ サービス アプリケーション プログラム インターフェイス

汎用セキュリティ サービス アプリケーション プログラム インターフェイス( GSSAPI、GSS-APIとも呼ばれる) は、プログラムがセキュリティサービスにアクセスするためのアプリケーション プログラミング インターフェイスです。

GSSAPI は、2005 年現在使用されている多くの類似しているが互換性のないセキュリティ サービスの問題に対処するIETF^{[アップデート]}標準です。

GSSAPI 自体はセキュリティを提供しません。その代わりに、セキュリティ サービス ベンダーが GSSAPI実装を提供します。通常は、セキュリティ ソフトウェアとともにインストールされるライブラリの形式で提供されます。これらのライブラリは、ベンダーに依存しないGSSAPIのみを使用するアプリケーションを作成できるアプリケーション作成者に GSSAPI 互換のインターフェイスを提供します。セキュリティ実装を置き換える必要が生じても、アプリケーションを書き直す必要はありません。

GSSAPI アプリケーションの決定的な特徴は、実装の詳細を上位レベルのアプリケーションから隠す不透明なメッセージ (トークン) の交換です。アプリケーションのクライアント側とサーバー側は、それぞれの GSSAPI 実装によって提供されたトークンを伝達するように記述されています。GSSAPI トークンは、メカニズムによって固有のメッセージ セキュリティが提供されるため、通常は安全でないネットワーク上でも転送できます。一定数のトークンが交換された後、両端の GSSAPI 実装は、セキュリティ コンテキストが確立されたことをローカル アプリケーションに通知します。

セキュリティ コンテキストが確立されると、機密性の高いアプリケーション メッセージを GSSAPI でラップ (暗号化) して、クライアントとサーバー間の安全な通信を実現できます。GSSAPI ラップによって保証される一般的な保護には、機密性(秘密性) と整合性(信頼性) が含まれます。GSSAPI は、リモート ユーザーまたはリモート ホストの ID に関するローカル保証も提供します。

GSSAPI は約 45 個のプロシージャ呼び出しを記述します。重要なものには次のものがあります。

GSS_信用を獲得

ユーザーの身元証明（多くの場合は秘密の暗号鍵）を取得します

GSS_インポート名

ユーザー名またはホスト名をセキュリティエンティティを識別する形式に変換します

GSS_Init_sec_コンテキスト

サーバーに送信するクライアントトークン（通常はチャレンジ）を生成します

GSS_Accept_sec_context

GSS_Init_sec_contextからのトークンを処理し、返すレスポンストークンを生成することができます。

GSS_ラップ

アプリケーションデータを安全なメッセージトークン（通常は暗号化）に変換します。

GSS_アンラップ

安全なメッセージトークンをアプリケーションデータに変換します

GSSAPIはC言語（RFC 2744）向けに標準化されています。JavaはGSSAPI ^[1] をJGSS（^[2] Java Generic Security Services Application Program Interface）として実装しています。^[3]

GSSAPI には次のような制限があります。

1. 認証のみを標準化し、認可は標準化しない。
2. クライアントサーバーアーキテクチャを想定しています。

新しいセキュリティ メカニズムを予測して、GSSAPI には、元のアプリケーションが構築されたときには存在しなかった新しいメカニズムを検出して使用できる ネゴシエーション疑似メカニズムSPNEGOが含まれています。

現在使用されている主な GSSAPI メカニズムの実装はKerberosです。GSSAPI とは異なり、Kerberos API は標準化されておらず、さまざまな既存の実装で互換性のない API が使用されています。GSSAPI を使用すると、Kerberos 実装を API 互換にすることができます。

• 半径
• オーストラリア
• TLS
• エスピーアイ
• スプネゴ
• RPCSEC GSS

名前

セキュリティ プリンシパル(ユーザーまたはサービス プログラム)にラベルを付けるバイナリ文字列-アクセス制御とIDを参照してください。たとえば、Kerberos では、ユーザーにはuser@REALM のような名前が使用され、プログラムにはservice/hostname@REALM のような名前が使用されます。

資格

身元を証明する情報。指定されたプリンシパルとして行動するエンティティによって使用されます。資格情報には通常、秘密の暗号化キーが含まれます。

コンテクスト

認証/認証済みプロトコルの一方の端の状態。安全なチャネルを構成するために使用できるメッセージ保護サービスを提供する場合があります。

トークン

不透明なメッセージは、初期認証プロトコルの一部として（コンテキストレベルのトークン）、または保護された通信の一部として（メッセージごとのトークン）交換されます。

機構

実際の名前、トークン、資格情報を提供する基礎となる GSSAPI 実装。既知のメカニズムには、Kerberos、NTLM、分散コンピューティング環境(DCE)、SESAME、SPKM、LIPKEY などがあります。

開始者/受容者

最初のトークンを送信するピアがイニシエーターで、もう 1 つはアクセプターです。通常、クライアント プログラムはイニシエーターで、サーバーはアクセプターです。

• 1991年7月: IETF共通認証技術(CAT)ワーキンググループがアトランタで開催され、ジョン・リンが主導した。
• 1993 年 9 月: GSSAPI バージョン 1 (RFC 1508、RFC 1509)
• 1995年5月: Windows NT 3.51がリリースされ、SSPIが含まれるようになりました。
• 1996 年 6 月: GSSAPI の Kerberos メカニズム (RFC 1964)
• 1997 年 1 月: GSSAPI バージョン 2 (RFC 2078)
• 1997 年 10 月: SASL が公開され、GSSAPI メカニズム (RFC 2222) が含まれる
• 2000 年 1 月: GSSAPI バージョン 2 アップデート 1 (RFC 2743、RFC 2744)
• 2004年8月: KITTENワーキンググループがCAT活動を継続するために会合
• 2006 年 5 月: Secure Shell の GSSAPI 使用が標準化されました (RFC 4462)

• PKCS#11 について

• RFC 2743 汎用セキュリティ サービス API バージョン 2 アップデート 1
• RFC 2744 汎用セキュリティ サービス API バージョン 2: C バインディング
• RFC 1964 Kerberos 5 GSS-API メカニズム
• RFC 4121 Kerberos 5 GSS-API メカニズム: バージョン 2
• RFC 4178 シンプルで保護された GSS-API ネゴシエーション メカニズム (SPNEGO)
• RFC 2025 シンプル公開鍵 GSS-API メカニズム (SPKM)
• RFC 2847 LIPKEY - SPKM を使用した低インフラストラクチャ公開鍵メカニズム
• 「次世代共通認証テクノロジー (kitten)」。インターネット エンジニアリング タスク フォース。2013 年 9 月。
• Sun Microsystems (2002)。「GSS-API プログラミング ガイド - Sun Solaris 9」。Oracle Corporation。
• Oracle Corporation (2020)。「GSS-API を使用するアプリケーションの作成 - Oracle Solaris 11.4、セキュリティ開発者ガイド」