Generic Security Service Application Programming Interface の略。さまざまなモジュール方式のセキュリティサービスのサポートを提供するネットワーク層です。GSS-API はセキュリティ認証、整合性、および機密性のサービスを提供します。さらに、セキュリティに関連して、アプリケーションの移植性を最大限にすることを可能にします。「認証」、「機密性」、「整合性」の項も参照してください。
「メッセージ整合性コード (MIC)」の項を参照してください。
「機構名 (MN)」の項を参照してください。
「保護品質 (QOP)」の項を参照してください。
特定のアクセス権を持つプリンシパルのリストが格納されているファイル。通常、サーバーはアクセス制御リストを調べて、クライアントがサービスを使用するための権限を持っているかどうかを判断します。GSS-API で認証されていても ACL で許可されていなければ、プリンシパルはサービスを拒否される可能性があることに注意してください。
実際のセキュリティ機構で許可されている場合、プリンシパル (通常はコンテキスト起動側) は、自分の資格とピアとなるプリンシパル (通常はコンテキスト受け入れ側) に「委託」することで、ピアプリンシパルをプロキシに指定できます。「委託」された資格を使用すると、ピアプリンシパルはオリジナルプリンシパルの代わりに要求を行うことができます。たとえば、プリンシパルが rlogin を使用して、あるマシンから別のマシンにリモートログインする場合などです。
gss_export_name() で GSS-API 内部形式 (特に機構名) から GSS-API エクスポート形式に変換された名前。エクスポート名は memcmp() で GSS-API 以外の文字列形式と比較できます。「機構名 (MN)」と「名前」の項も参照してください。
データの認証や機密性を実現するための暗号化技術を指定するソフトウェアパッケージ。たとえば、Kerberos v5 や Diffie-Hellman 公開鍵など。
GSS-API 内部形式名の特別なインスタンス。通常の GSS-API 内部形式名では 1 つの名前に対して複数のインスタンス (それぞれが実際の機構の形式での) を持つことができますが、機構名は特定の機構に一意です。機構名は gss_canonicalize_name() で生成されます。
データを暗号化するセキュリティサービス。機密性には整合性と認証のサービスも含まれます。「認証」、「整合性」、「サービス」の項も参照してください。
狭義では、ユーザーの代わりにネットワークサービスを使用するプロセスを指します。たとえば、rlogin を使用するアプリケーションなどです。サーバー自身が他のサーバーやサービスのクライアントになる場合もあります。広義では、サービスを使用するプリンシパルを指します。
多くのセキュリティ機構では、メッセージストリーム中のメッセージが不適切な順序で受信されたことを検出できます。メッセージの誤順序の検出は、(利用できる場合は) コンテキスト確立時に要求する必要があります。
2 つのアプリケーション間の「信用の状態」。2 つのピア間でコンテキストが正常に確立されると、コンテキスト受け入れ側はコンテキスト起動側が本当に主張しているとおりのアプリケーションであることを認識して、コンテキスト受け入れ側に送信されたメッセージを検証および復号化できます。コンテキストに相互認証が含まれている場合、起動側は受け入れ側の ID が有効であると認識して、受け入れ側から送信されたメッセージを検証および復号化できます (復号化は任意)。
「トークン」を参照してください。
ネットワーククライアントにリソースを提供するプリンシパル。たとえば、boston.eng.acme.com というマシンに rlogin する場合、そのマシンは rlogin サービスを提供するサーバーです。
プリンシパルを識別する情報パッケージ。プリンシパルの「識別バッジ」であり、プリンシパルが誰であるか (そして、多くの場合、プリンシパルがどの特権を持っているか) を示します。資格はセキュリティ機構によって生成されます。
指定された機構によって保存された資格を保持するための保存領域 (通常はファイル)。
プリンシパルがサービスを使用できるかどうか、プリンシパルがどのオブジェクトにアクセスできるか、および、各オブジェクトにどのようなアクセスの種類が許可されているかを決定するプロセス。
ユーザー認証に加えて、転送されたデータの有効性を暗号タグで証明するセキュリティサービス。「認証」、「機密性」、「メッセージ整合性コード (MIC)」の項も参照してください。
「サービス」の項を参照してください。
「フレーバ」の項を参照してください。
「機構」の項を参照してください。
コンテキストが確立されたとき、コンテキスト起動側は自分自身をコンテキスト受け入れ側に認証する必要があります。また、それに加えてコンテキスト起動側が受け入れ側の認証を要求する場合もあります。受け入れ側にも認証が必要な場合、両者は相互認証されていると言います。
データの形式。たとえば、int
、string
、gss_name_t
構造体、gss_OID_set
構造体など。
データリプレイは、メッセージストリーム内の単一のメッセージが複数回受信された場合を指します。多くのセキュリティ機構でデータリプレイの検出をサポートしています。リプレイの検出は、(利用できる場合は) コンテキスト確立時に要求する必要があります。
GSS-API 構造体 gss_buffer_t の形式であるデータパケット。トークンは、ピアとなるアプリケーションへの転送用に、GSS-API 関数で生成されます。
トークンには 2 種類あります。コンテキストレベルトークンには、セキュリティコンテキストを確立または管理するために使用される情報が格納されます。たとえば、gss_init_sec_context() は、コンテキストの受け入れ側に送信するための、コンテキスト起動側の資格ハンドル、ターゲットマシンの名前、要求されるさまざまなサービスのフラグなどをトークンに格納します。
メッセージトークン (メッセージ毎トークンやメッセージレベルトークンとも呼びます) には、ピアとなるアプリケーションに送信されるメッセージから GSS-API 関数によって生成された情報が格納されます。たとえば、gss_get_mic() は、指定されたメッセージから識別用の暗号タグを生成し、ピアに送信されるトークンに (メッセージと一緒に) 格納します。技術的には、トークンはメッセージとは別であると考えられています。このため、gss_wrap() は output_token ではなく output_message を生成すると言われます。
「メッセージ」の項も参照してください。
「不透明」の項を参照してください。
データの値や形式がそれを使用する関数には見えない場合、そのデータは不透明であると言います。たとえば、gss_init_sec_context() への input_token パラメータはアプリケーションには不透明ですが、GSS-API にとっては重要です。同様に、gss_wrap() への input_message パラメータは GSS-API には不透明ですが、ラップを行うアプリケーションにとっては重要です。
プリンシパルの名前。たとえば、「joe@machine」などです。GSS-API の名前は gss_name_t
構造体を通じて処理されます。このような名前はアプリケーションには不透明です。「エクスポート名」、「機構名 (MN)」、「名前型」、「プリンシパル」の項も参照してください。
名前の形式。名前型は gss_OID
型として格納され、名前に使用されている形式を示します。たとえば、「joe@machine」という名前の名前型は GSS_C_NT_HOSTBASED_SERVICE
であるなどです。「エクスポート名」、「機構名 (MN)」、「名前」の項も参照してください。
要求されたプリンシパルの ID を確認するセキュリティサービス。
「機密性」の項を参照してください。
ネットワーク通信に参加する、一意な名前を持つ「クライアント/ユーザー」または「サーバー/サービス」のインスタンス。GSS-API ベースのトランザクションにはプリンシパル間の対話が含まれます。次に、プリンシパル名の例を示します。
joe
joe@machine
nfs@machine
123.45.678.9
ftp://ftp.company.com
「名前」と「名前型」の項も参照してください。
従来、フレーバは認証の種類 (AUTH_UNIX、AUTH_DES、AUTH_KERB) を示していたため、セキュリティフレーバと認証フレーバは同じ意味です。RPCSEC_GSS もセキュリティフレーバですが、これは認証に加えて、整合性と機密性のサービスも提供します。
QOP は Quality of Protection の略で、整合性や機密性のサービスと一緒に使用される暗号化アルゴリズムを選択するときに使用されるパラメータ。整合性と一緒に使用する場合、QOP はメッセージ整合性コード (MIC) を生成するアルゴリズムを指定します。機密性と一緒に使用する場合、QOP は MIC の生成とメッセージの暗号化の両方に対するアルゴリズムを指定します。
ネットワークを通じてアクセス可能なマシン。
GSS-API ベースのアプリケーションからそのピアとなるアプリケーションに送信される gss_buffer_t オブジェクト形式のデータ。たとえば、「ls」はリモートの ftp サーバーにメッセージとして送信されます。
メッセージには、ユーザーが提供するデータ以外の情報が格納されることもあります。たとえば、gss_wrap() はラップされていないメッセージを受け取り、そのメッセージを送信用にラップします。このとき、ラップされたメッセージには、オリジナル (ユーザーが提供した) メッセージとともにその MIC が格納されます。メッセージは格納しない、GSS-API が生成した情報は「トークン」と呼ばれます。詳細は「トークン」の項を参照してください。
Message Integrity Code。データの有効性を保証するために、転送されるデータに添付される暗号タグ。データ受信側は独自の MIC を生成し、送信された MIC と比較します。両者が同じ場合、メッセージは有効です。gss_get_mic() で生成される MIC などはアプリケーションからも見えますが、gss_wrap() や gss_init_sec_context() で生成される MIC などはアプリケーションからは見えません。
「トークン」の項を参照してください。
「トークン」の項を参照してください。
多くのセキュリティ機構は、メッセージストリーム中のメッセージが不正に繰り返されたことを検出できます。メッセージリプレイの検出は、(利用できる場合は) コンテキスト確立時に要求する必要があります。