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

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

GSSAPIはIETF標準であり、 2005年時点で使用されていた多くの類似しているが互換性のないセキュリティサービスの問題に対処するものである。。

GSSAPI自体はセキュリティを提供しません。代わりに、セキュリティサービスベンダーがGSSAPIの実装を提供します。これは通常、セキュリティソフトウェアにインストールされるライブラリの形で提供されます。これらのライブラリは、アプリケーション開発者に対してGSSAPI互換のインターフェースを提供し、開発者はベンダーに依存しないGSSAPIのみを使用するようにアプリケーションを記述できます。セキュリティ実装を交換する必要が生じた場合でも、アプリケーションを書き直す必要はありません。^{[ 2 ]}

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

セキュリティコンテキストが確立されると、機密性の高いアプリケーションメッセージは、クライアントとサーバー間の安全な通信のために、GSSAPIによってラップ（暗号化）されます。GSSAPIによるラップによって保証される一般的な保護には、機密性（秘密性）と完全性（認証性）が含まれます^{[ 4 ]}。GSSAPIは、リモートユーザーまたはリモートホストのIDに関するローカルな保証も提供できます。

GSSAPIには約45のプロシージャ呼び出しが記述されています。重要なものとしては、以下のものが挙げられます。

GSS_認証情報取得

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

GSS_Import_name

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

GSS_Init_sec_context

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

GSS_Accept_sec_context

GSS_Init_sec_contextからトークンを処理し、応答トークンを生成して返します。

GSS_Wrap

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

GSS_アンラップ

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

GSSAPIはC言語（RFC 2744）用に標準化されています。JavaはGSSAPI ^{[ 5 ]}を JGSS ^{[ 6 ]} （Java Generic Security Services Application Program Interface）として実装しています。^{[ 7 ]}

GSSAPIのいくつかの制限事項^{[ 8 ]は以下のとおりです。}

1. 認証のみを標準化し、認可は標準化しない。
2. クライアント・サーバーアーキテクチャを前提とする。

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

使用されている主要な GSSAPI メカニズム実装はKerberosです。GSSAPIとは異なり、Kerberos API は標準化されておらず、既存のさまざまな実装は互換性のない API を使用しています。GSSAPI は Kerberos 実装の API 互換性を可能にします。^{[ 10 ]}

• 半径
• SASL
• TLS
• SSPI
• スプネゴ
• RPCSEC GSS

名前

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

資格

身元を証明する情報。指定された主体として行動するために、主体が使用する情報。認証情報には通常、秘密の暗号鍵が含まれる。

コンテクスト

認証/認証済みプロトコルの一方の端の状態。メッセージ保護サービスを提供する可能性があり、これを使用して安全なチャネルを構築できます。

トークン

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

機構

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

開始者／受容者

最初にトークンを送信する側がイニシエータ、もう一方の側がアクセプタです。一般的には、クライアントプログラムがイニシエータ、サーバーがアクセプタとなります。

• 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月：セキュアシェルにおける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を使用した低インフラストラクチャ公開鍵メカニズム 
• 「次世代共通認証技術（キティ）」。インターネット技術タスクフォース。2013年9月。
• サン・マイクロシステムズ（2002）。「GSS-APIプログラミングガイド - Sun Solaris 9」。オラクルコーポレーション。
• Oracle Corporation (2020). 「GSS-API を使用するアプリケーションの作成 — Oracle Solaris 11.4、セキュリティ開発者ガイド」。