8    GSS-API

Generic Security Service Application Program Interface (GSS-API) 関数を使用すると,分散ネットワーク環境にあるアプリケーションは,ネットワーク上で次のセキュリティ・サービスを使用できるようになります。

この章では,次の内容について説明しています。

8.1    GSS-API の概要

GSS-API は,分散型アプリケーションの保護に使用できる一連の汎用 C 関数を定義する,標準的なプログラミング・インタフェースです。 GSS-API には,その処理には欠かせない 2 つの大きな設計上の目標があります。

GSS-API はオープン・スタンダードであるため,セキュリティ技術やネットワーク技術が進化するたびに API を変更する必要が生じないように,汎用性を持たせて設計されています。

GSS-API は,次のようなアーキテクチャを使って,基盤のセキュリティ・メカニズムと技術を幅広くサポートしています。

セキュリティ・メカニズムとは,セキュリティを提供する手段のことです (たとえば Kerberos や公開鍵暗号化など)。使用されている暗号化技術だけでなく,その技術が使用しているデータの構文と意味も含みます。GSS-API 標準を使って保護されたアプリケーションは,1 つまたは複数のセキュリティ・メカニズムを使用できます。

GSS-API は幅広いネットワーク環境で使用できます (たとえば,TCP/IP,SNA,DECnet)。GSS-API は,トランスポート・メカニズムを提供するように設計されたものではありません。その代わり,任意のネットワーク・トランスポート上でセキュリティを提供する設計になっています。トランスポートはアプリケーションが提供する必要があります。通信プロトコルは,プロセス間通信の経路または一連のネットワークが考えられます。

GSS-API 関数はアプリケーションに情報を戻し,アプリケーションは使用中の通信プロトコルを通じてその情報を送信します。分散型アプリケーションのもう一方の側は,情報を GSS-API ライブラリに渡します。

GSS-API 標準を使ってアプリケーションを保護する開発者のために,メカニズムとトランスポートからの独立という設計目標が,基盤となるハードウェアおよびソフトウェア・プラットフォームから独立した一貫性のあるインタフェースを提供しています。つまりプログラミングの投資は 1 回だけで済むということです。アプリケーションを保護するための変更に対する投資は,技術が進化したとしても一定のままです。

8.1.1    GSS-API の前提条件

GSS-API 標準は次のような前提条件に基づいています。

8.1.2    詳細情報

GSS-API は,現在進行中の Internet RFC (Request For Comments) プロセスの一部として策定された業界標準です。

Application Security SDK は,次の RFC に基づいています。

GSS-API 標準は,作業グループ Common Authentication Technology Internet Engineering Task Force (CAT-IETF) の監督下にあります。GSS-API についての詳細は,IETF の Web サイト,www.ietf.org を参照してください。

8.2    Application Security SDK

HP は,Application Security Service Developers Kit (SDK) を通じて GSS-API 関数を実装しています。Application Security SDK は,GSS-API 標準にユニークな機能をいくつか追加した,GSS-API バージョン 2.0 の実装です。

8.3    Application Security SDK 関数

Application Security SDK 関数は複数のカテゴリに分類できます。分散型アプリケーションの保護に必要となるのは 1 つのサブセットだけです。これらの関数は,以下のカテゴリに従って分けることができます。

8.3.1    名前管理関数

ユーザがネットワーク上のシステムにログインするときにユーザ名を使うのと同じように,GSS-API もまたネットワーク内のエントリの識別に名前を使います。ユーザ名は,システムの命名構造に従ってユーザを識別するものです。GSS-API 標準では,名前はアプリケーションまたはそれを使うユーザを識別します。

Kerberos 5 メカニズムでは,名前はプリンシパルに変換されます。プリンシパルとは,Kerberos と何らかの秘密 (通常はパスワード) を共有する任意のユーザ,ネットワーク・サービス,アプリケーション,システムを指します。プリンシパルは,レルム内で一意の名前と,対応する鍵を持っている必要があります。

GSS-API では,外部名,エクスポート名,内部名,メカニズム名の 4 つの形式の名前を使います。形式が異なる名前の間で,変換を行うための関数も用意されています。

GSS-API では,名前は次の目的で使用されます。

アプリケーションまたはそれを使うユーザの名前は,GSS-API によって定義されている構文,構造,命名規則に従ったものではありません。アプリケーションの名前は,アプリケーション自身に依存しています。GSS-API は汎用であるため,異なるフォーマットで名前を提供できます。名前を表現するためのこれらの手法は, 名前タイプと呼ばれ,オブジェクト識別子 (OID) として渡されます。

アプリケーションは,その名前として GSS-API の省略時値を使うこともできます。省略時の名前を使う場合は,特定の名前を指定する必要がなく,OID を渡す必要もありません。この場合,名前は GSS-API の実装に依存します。

GSS-API 関数 説明
gss_canonicalize_name() 内部名をメカニズム固有の名前に変換します。
gss_compare_name() 内部フォーマットによる 2 つの名前が同じかどうかを比較します。
gss_display_name()

人間が解読できる形式,あるいは表示可能な形式に名前を変換します。名前のフォーマットは,GSS-API の実装に固有です。このため,gss_display_name() 関数から戻される表示可能な形式と,そうでない名前は比較しないでください。比較に必要な名前を生成するには,関数 gss_export_name() を使います。この名前は,gss_import_name() を使ってインポートすることはできません。

この関数によって生成される表示可能な形式は,バッファに置かれます。バッファは,gss_release_buffer() を呼び出すことによって解放しなければなりません。

gss_duplicate_name() 既存の内部形式の名前のコピーを作成します。
gss_export_name() 内部名を,標準のフォーマットのエクスポート形式 (文字列) に変換します。
gss_import_name()

アプリケーションの名前 (外部形式) を内部形式に変換します。 アプリケーションは,その名前の解析方法を指定するオブジェクト識別子 (OID) を渡します。たとえば,UNIX の uid またはログイン名などが考えられます。

名前は構造体に入れられて戻され,gss_release_name() を呼び出すことによって解放しなければなりません。gss_import_name() には,省略時の名前は指定できません。省略時の名前を指定できるのは,gss_acquire_cred() で信任状を取得するときのみです。

gss_inquire_mechs_for_name() 指定された名前タイプをサポートするメカニズムを識別します。Application Security SDK では,これは常に Kerberos 5 になります。
gss_inquire_names_for_mech() 指定されたメカニズムによってサポートされている名前タイプの一覧を表示します。Application Security SDK では,これは常に Kerberos 5 がサポートしている名前タイプになります。
gss_release_name() gss_import_name() が呼び出されたときに割り当てられた,GSS-API 名の記憶領域を解放します。

8.3.1.1    省略時の名前と構文

Kerberos のプリンシパル名は,次の形式をとります。name/instance@REALM (/instance および @REALM は省略可能)。/instance を省略した場合は,空のインスタンスであるとみなされます。@REALM を省略した場合は,省略時のレルムであるとみなされます。/ で区切ることによって,複数のインスタンスを指定できます。

Kerberos 5 メカニズムを使った信任状を取得するときに,アプリケーション名に GSS-API の省略時値が使われている場合, 使用される名前は,キャッシュがあれば,省略時の信任状キャッシュにある省略時の信任状の省略時のプリンシパルになります。キャッシュがなければ,省略時の名前は次のルールに従って決定されます。

アプリケーションが gss_import_name() を呼び出すときに,省略時の入力フォーマットを使用しなかった場合,アプリケーションは,その名前の解析方法を指定するオブジェクト識別子 (OID) を渡します。たとえば,GSS_KRB5_NT_HOSTBASED_SERVICE_NAME OID は,service@host という形式の名前の解析構文を指定します。このパラメータの NT は,名前タイプを表します。

8.3.2    信任状管理関数

信任状は,アプリケーションがその ID を証明するために使います。分散型アプリケーションの一方は,セキュリティ・コンテキストの開始と受け入れのために使われる信任状を取得する必要があります。

Kerberos 5 では,3 つのタイプの信任状があります。

Kerberos 5 のセキュリティ用語とインフラストラクチャの詳細は,「セキュリティの基本」を参照してください。

Kerberos 5 メカニズムと GSS-API 標準を使う場合,初回チケットは,身元を証明するものとして,Kerberos プリンシパルによって保持され,提示されます。これらの信任状は,初回認証のためにトラステッド KDC に接続されたことを証明するために,プリンシパルによって使用されます。通常,セキュリティ・サーバによって提供される初回チケットは,信任状キャッシュと呼ばれる中央の格納場所に格納されます。

GSS-API では,初回チケットは記憶領域から取得され,セキュリティ・コンテキストを確立するために使われます。標準 GSS-API と Kerberos 5 メカニズムでは,開始側のアプリケーションは,gss_acquire_cred() の呼び出しの前に,初回チケット (TGT) を取得していなければなりません。ユーザは,kinit またはこれに相当するアプリケーション (たとえば,Single SignOn) を実行することによって初回チケットを取得できます。受け入れ側のアプリケーションは,サービス鍵テーブル・ファイルに格納されている鍵を使って,その ID を確認します。

Application Security SDK は,HP エクステンション関数と呼ばれる追加の関数を提供しています。この関数を使って,次のような各種のタスクを実行できます。

これらの特殊な HP エクステンション関数を使うと,初回信任状が呼び出し側のアプリケーションによって受け取られ,信任状キャッシュに置かれます。その後,この初回信任状を GSS-API 関数を使って取得し,セキュリティ・コンテキストを確立するために必要なサービス・チケットを取得する目的で使用できます。

GSS-API 関数 説明
gss_acquire_cred() 初回信任状を,アプリケーションが使うために格納場所から取り出します。コンテキストを確立するためにはこの手順が必要となります。信任状は,この関数を呼び出す前に存在している必要があります。
gss_add_cred() 信任状を追加的に作成します。この関数は,複数のメカニズムがサポートされている場合に使われます。1 つのメカニズムだけを実装している場合は,HP は,関数 gss_acquire_cred() を使うことをお勧めします。
gss_inquire_cred() 信任状についての情報を戻します (たとえば,この信任状がサポートしているメカニズム,信任状タイプ,信任状の存続期間の一覧など)。Kerberos 5 の場合,これは初回信任状に関する情報になります。
gss_inquire_cred_by_mech() 特定のメカニズムに固有の既存の信任状に関する情報を取得します。Application Security SDK の場合,この情報は,Kerberos セキュリティ・サーバから取得した TGT から取得されます。
gss_release_cred() 使い終わった信任状をアプリケーションから解放します。gss_acquire_cred() または gss_add_cred() で取得した信任状は,すべてこの関数を使って解放する必要があります。Kerberos 5 の場合,これは信任状キャッシュにある初回信任状エントリには影響を及ぼしません。

これらの関数は,認証サーバやネットワーク・ファイル・システムなどのネットワーク・エンティティ間で,保留中のやり取りをブロックできます。ブロックは,オペレーティング・システムの機能と,使用されているセキュリティ・メカニズムに依存します。Kerberos 5 メカニズムでは,信任状管理関数は,ディレクトリや認証サーバなど,他のネットワーク・エンティティの間の保留中のやり取りをブロックできます。

8.3.2.1    初回信任状の取得

GSS-API 標準では,コンテキストの確立前に開始側のアプリケーションは,初回信任状を取得し,これを信任状キャッシュと呼ばれる中央の格納場所におく必要があります。格納された信任状は,関数 gss_acquire_cred() を使ってキャッシュから取得されます。

8.3.2.1.1    開始側のアプリケーション

Application Security SDK は,開始側のアプリケーションの初回認証を実行する特別な関数を提供しており,GSS-API 標準を使って取り出せるように信任状をキャッシュに格納します。関数 csf_gss_acq_user() を,Single SignOn,Credentials Manager,kinit などによって制御される認証処理の代わりに使用できます。

この関数に指定するパラメータは秘密タイプであり,本人かどうかを証明するためにプリンシパルから取得されます。ユーザ・プリンシパルの場合,パラメータとして渡す秘密は通常はプリンシパル名とパスワードであり,プロンプトから指定しますが,サービス鍵テーブル・エントリでも構いません。

初回チケットまたは TGT は,転送可能チケットや代理可能チケットなどの属性を指定し,チケットの存続期間と延長期限を指定することで,選択した Kerberos チケット・フラグを付けて取得できます。

8.3.2.1.2    受け入れ側のアプリケーション

受け入れ側のサービス・プリンシパルは,サービス鍵テーブル・ファイルを使う必要があります。このファイルは,Kerberos データベース管理プログラムによって最初に生成され,提供されたランダム鍵の形式の,サービス・プリンシパルの秘密を格納するために使われます。このタイプの初回認証は,GSS-API 関数 gss_acquire_cred() を使って実行されます。

8.3.2.1.3    DES3

Application Security SDK は,DES3 暗号化のためのサポートを提供しています。DES3 を使うことで,DES 暗号化よりも大幅に改善されたセキュリティ保護を実現しています。

DES3 暗号化を使ってメッセージを暗号化できるようにするには,次の条件が満たされている必要があります。

注意

単一のセキュリティ・コンテキストに対して複数の暗号化システムは許可されていません。どれか 1 つだけを使う必要があります。

8.3.2.2    信任状の属性

関数 gss_inquire_cred() を使って,特定の信任状に関連付けられているプロパティ,または属性を確認できます。この関数によって戻される Kerberos 情報には,信任状の存続期間,サポートされているメカニズム,信任状の使用方法などが含まれています。初回信任状に割り当てられる属性は,TGT を取得するときに要求された属性によって異なります。特定の TGT を使って取得したサービスは,その TGT に割り当てられている属性を継承します。

信任状には有効期限が定義されていることがあり,これを過ぎるとその信任状は無効となります。gss_inquire_cred() 関数を使って,信任状が期限切れになったかどうかを判別できます。

メカニズムの実装によっては,信任状が期限切れになった後でアプリケーションがそれを使うことはできない場合があります。その場合,アプリケーションは信任状を解放し,もう一度信任状を取得してから継続することになります。Kerberos 5 メカニズムでは,信任状の存続期間は,Kerberos チケットの存続期間として定義されています。信任状の有効期限が切れた後は,アプリケーションはそれを使って新しいセキュリティ・コンテキストを確立することはできません。アプリケーションは,csf_gss_acq_user()gss_acquire_cred() を使って新しい信任状を解放・取得する必要があります。

注意

GSS-API 標準は,最初に確立された存続期間を過ぎた信任状の期限を延長するための関数は提供していません。しかし,有効期限が切れていない場合は,HP エクステンション関数 csf_gss_renew_cred() を使って信任状の期限を延長できます。信任状の期限を延長するためには,初回チケットはセキュリティ・サーバから延長可能属性フラグを付けて要求されたものでなければなりません。

8.3.2.3    信任状の格納場所

Kerberos 5 では,信任状は,ローカル・ホストのハードディスクまたは他の永続的な記憶媒体に格納されていると想定しています。

ユーザ・プリンシパルは,環境変数によって指定されていない限り,信任状キャッシュの省略時の格納場所に格納されているものと想定されます。場所はプラットフォームによって異なります。

UNIX ユーザの省略時の信任状キャッシュ・ファイルは,環境変数 CSFC5CCNAME が他のパス名に設定されていなければ,krb5/tmp/cc/krb5cc_uid (uid はパスワード・ファイルから取り出したユーザ ID 番号) になります。

サービス・プリンシパルの場合,省略時のサービス鍵テーブル・ファイルは,プラットフォームごとに異なる場所にあります。たとえば UNIX システムの場合,省略時のファイルは,CSFC5KTNAME 環境変数が別のパス名に設定されていなければ,/krb5/v5srvtab になります。

これらの信任状キャッシュとサービス鍵テーブル・ファイルの設定についての詳細は,SSO の『Installation and Administration Guide』を参照してください。

8.3.2.4    信任状関連リソースの管理

gss_acquire_cred() で取得した信任状はすべて,gss_release_cred() を呼び出すことによって解放する必要があります。信任状が解放されるときの実際の動作は,使用するセキュリティ・メカニズムによって異なります。いくつかのケースでは,信任状の内部バッファだけが解放されます。その他のケースでは,ディスクに格納されている信任状も解放されます。Kerberos 5 メカニズムでは,この関数では内部バッファだけが解放されます。

信任状をいつ解放するかを決める前に,アプリケーションは,実行中にセキュリティ・コンテキストを何回か開始したり,受け取ったりする予定があるかどうかを判断しなければなりません。予定がある場合,アプリケーションは,信任状を取得してこれを一度使った後,すぐに解放するのではなく,後でセキュリティ・コンテキストの開始関数または受け入れ関数を使って再使用する必要があります。Kerberos 5 の実装では,こうすることで性能を向上させています。

8.3.3    セキュリティ・コンテキスト管理関数

セキュリティ・コンテキストは,一度確立されると,分散環境にあるアプリケーション間で一意の対話を定義します。セキュリティ・コンテキストは,一方のアプリケーションによって開始され,もう一方のアプリケーションによって受け取られます。セキュリティ・コンテキストは,保護対象のメッセージの交換を行う前に確立する必要があります。

GSS-API 標準の Kerberos 5 の実装では,コンテキストが確立するときに,サービス・チケットの管理に必要な Kerberos のプロセス実行するようになっています。そのプロセスで,サービス・チケットの取得,転送,確認が行われます。コンテキストが確立されると,そのコンテキストには鍵とその他のセキュリティ・パラメータが付加します。セキュリティ・コンテキストの内容は,メッセージを保護するために直接的に使われます。

GSS-API 関数 説明
csf_gss_get_context_options () 使用されている暗号化の種類の確認も含め,既存のセキュリティ・コンテキストに関する情報を取得します。これは Application Security SDK に含まれている HP のエクステンション関数です。
gss_accept_sec_context() 開始側のアプリケーションからのセキュリティ・コンテキストの確立要求を受け取ります。
gss_context_time() セキュリティ・コンテキストの存続期間がどれだけ残っているかを示します。存続期間の決め方とその意味は,メカニズムに依存します。
gss_delete_sec_context() 不要になったコンテキストを破壊します。開始,または受け入れが終わったセキュリティ・コンテキストは,それぞれこの関数を使って破壊する必要があります。
gss_export_sec_context() セキュリティ・コンテキストを別のプロセスに転送します。
gss_import_sec_context() エクスポートされたセキュリティ・コンテキストをインポートします。
gss_init_sec_context() 受け入れ側アプリケーションとのセキュリティ・コンテキストを開始します。
gss_inquire_context() セキュリティ・コンテキストに関する情報を取得します。

これらの関数は,アプリケーションとセキュリティ・サーバの間で保留中になっているやり取りをブロックすることがあります。

8.3.3.1    メカニズムの識別

GSS-API 標準は,使用可能なセキュリティ・メカニズムが複数あるような環境で使われるように設計されています。つまり,対象となるセキュリティ・メカニズムをプログラム的に識別しなければならないということです。

gss_init_sec_context() には,パラメータの 1 つとして,開始側が使おうとしているセキュリティ・メカニズム識別子 (または mech_type) を渡します。 メカニズム識別子は,オブジェクト識別子 (OID) として渡されます。または,開始側は省略時のメカニズム識別子を使うこともできます。省略時のメカニズムとして何が選択されるかは,GSS-API の実装に依存します。Application Security SDK の場合,省略時のメカニズムは Kerberos 5 です。

8.3.3.2    トークンの交換

gss_init_sec_context() の呼び出し時に,Application Security SDK はユーザの信任状キャッシュにサービス・チケットがあるかどうか検索します。キャッシュにサービス・チケットがなければ,Application Security SDK は KDC からサービス・チケットを取り出します。戻されたサービス・チケットは,ユーザの信任状キャッシュに格納されます。GSS-API は,このサービス・チケットとそれに付随する情報をコード化し,これをトークンに戻して相手側のアプリケーションに送信されるようにします。

gss_accept_sec_context() の呼び出し時に,GSS-API は,サービス鍵テーブル・ファイル中のその秘密鍵を使ってこのトークンを復号し,サービス・チケットを確認します。確認が成功して相互認証が要求されると,GSS-API は応答の中にトークンを生成します。相互認証が要求されなかった場合,リターン・トークンは生成されません。エラーが発生すると,GSS-API はエラー・トークンを生成します。

8.3.3.3    オプションのセキュリティ手段

コンテキストを開始するときに,アプリケーションはいくつかのオプションのセキュリティ手段を指定できます。 これらオプションのセキュリティ手段についての GSS-API の実装は,使用されているセキュリティ・メカニズムに依存します。

以下の節では,オプションのセキュリティ手段について説明します。

8.3.3.3.1    チャネル・バインディング

チャネル・バインディングは,偽装者によって盗聴されたコンテキスト確立トークンが再使用される可能性があるときに,その有効範囲を限定することによって,コンテキストの確立時に,分散アプリケーション同士の認証の質を高めるために使われます。 チャネル・バインディングは,分散アプリケーションによって指定される追加のデータ項目をセキュリティ・コンテキストに付加することによってこれを実現します。

チャネル・バインディングは,次の 2 つの部分で構成されます。

アドレス情報は,開始側と受け入れ側のどちらの場合もアドレス・タイプアドレス値からなります。アドレス・タイプは,アドレス値のバッファに格納されているプロトコルのタイプを示します。アドレス値は,開始側または受け入れ側の実際のアドレスです (アドレス・タイプに対応したフォーマットで表現されます)。

Kerberos 5 では,KDC は,サービス・チケットを作成するときにクライアントのアドレスをエンコードしてチケットに埋め込みます。 開始側がそのチケットを受け入れ相手に提示し,チャネル・バインディングが gss_accept_sec_context() に渡されると,GSS-API はこのチケットにあるクライアント・アドレスが,チャネル・バインディングにある開始側のアドレスと一致しているかどうかをチェックします。ただしこのチェックは,TCP 接続を使っている場合は行われません。

注意

サポートされているアドレス・フォーマットは,GSS_C_AF_INET のみです。

チャネル・バインディングのデータ構造体のもう 1 つの構成要素は,アプリケーション・データであり,開始側が受け入れ側に比較してもらうために相手に送信できます。アプリケーション・データは,使用されていれば,アプリケーションによって判別されます。コンテキストを開始するときに指定されるデータは,受け入れ側で完全に一致しなければなりません。たとえば,アプリケーションはその「バージョン番号」をアプリケーション・データに挿入して,バージョン番号が一致しないアプリケーションによるセキュリティ・コンテキストの確立を禁止することができます。

チャネル・バインディングは,gss_init_sec_context() によってトークンとしてエンコードされ,その後で受け入れ側に送信されます。 チャンネル・バインディングは,gss_accept_sec_context() によってチェックされます。セキュリティ・コンテキストを開始するアプリケーションは,gss_init_sec_context() を呼び出す前にチャネル・バインディングの値を決定する必要があり,両方のアプリケーションが同一の値をセキュリティ・コンテキスト関数に提示しなければなりません。GSS-API は,受け入れ側のアプリケーションでチャネル・バインディングをチェックします。

チャネル・バインディングが gss_init_sec_context() に渡されると,このチャネル・バインディングを使ってハッシュ値が計算されます。ハッシュ値は,トークンにコード化されます。 gss_accept_sec_context() の呼び出し時に,GSS-API は渡されたチャネル・バインディング使ってハッシュ値を計算し,計算したハッシュ値と,渡されたトークンのハッシュ値を比較します。

8.3.3.3.2    機密性と完全性

開始側は,メッセージに機密性か完全性,また両方を持たせ,これをメッセージの送受信時に使うように指定できます。 受け入れ側は,メッセージの機密性か完全性,または両方がこのコンテキストに必要かどうかを問い合わせることができます。この情報は,開始側に戻されます。

注意

開始側は機密性を要求できますが,受け入れ側がこれをサポートできない場合,機密性は使われません。

gss_init_sec_context() 関数の GSS_C_CONF_FLAGGSS_C_INTEG_FLAG を使って,機密性と完全性の要件を指定します。

8.3.3.3.3    リプレイ検出

リプレイ検出とは,注目しているトークンまたはメッセージが以前に送信されたものかどうかを,一方のアプリケーションがチェックするというものです。

開始側はそのメッセージを,メッセージ・リプレイ・キャッシュと突き合わせてチェックするよう指定できます。これは,メッセージが以前に送信されたメッセージの繰り返しかどうかを判別するために使います。

メッセージがキャッシュされるにつれてより多くのリソースをキャッシュに割り当てるため,リプレイ・キャッシュは必要に応じて拡張します。ただしキャッシュ・サイズには上限があるので注意してください。リプレイ・キャッシュが一定のサイズに達した場合,新しいエントリを 1 つ追加するたびに,古いエントリが 1 つずつ解放されます。キャッシュ全体に関連付けられているリソースは,セキュリティ・コンテキストが削除されるときに解放されます。

注意

Kerberos 5 でサポートされているリプレイ・キャッシュは,2 種類あります。1 つはメッセージ・リプレイ・キャッシュで,コテキスト確立時のパラメータの設定によって制御される,メモリ・ベースのキャッシュです。もう 1 つは認証リプレイ・キャッシュで,UNIX 環境変数で設定が制御されるファイル・ベースのキャッシュです。

8.3.3.3.4    順序外メッセージ検出

開始側は,メッセージの順番を決めて (または番号付けして),すべてのメッセージが受信されたかどうかと,それが送信された順番で受信されたかどうかをチェックするように指定できます。メッセージの順序付けは,リプレイ検出機能も提供します。

8.3.3.3.5    相互認証

開始側は,受け入れ側にも開始側に対する認証を実行するように指定できます。こうすることで,アプリケーションの双方が,相互に正真正銘の相手とやり取りしているということを確信できます。

8.3.3.3.6    暗号化タイプ: DES と DES3

開始側は,初回認証時に DES3 暗号化標準を指定できます。さらに開始側は,セキュリティ・コンテキストを開始するときに,DES3 暗号化も要求できます。DES3 暗号化は,DES 暗号化よりも大幅に改善されたセキュリティを提供しています。

8.3.3.3.7    信任状の委任

Kerberos 5 の実装では,開始側は GSS_C_DELEG_FLAG 委任フラグを設定して,初回チケット (TGT) を別のネットワーク・ホストに転送するように指定できます。ただし,TGT を転送できるのは,その TGT に Kerberos の転送可能属性がある場合に限られます。

8.3.3.4    対象とするセキュリティ手段の指定

開始側は,gss_init_sec_context() を呼び出して,セキュリティ・メカニズムに使わせるセキュリティ手段を指定します。アプリケーションには,セキュリティ・メカニズムによって提供されるセキュリティ手段を示すフラグが戻されます。GSS-API 標準で定義されているすべてのセキュリティ手段を,セキュリティ・メカニズムが提供できるとは限りません。

セキュリティ・コンテキストの確立時に使うセキュリティ手段を開始側が指定すると,受け入れ側はこれを受け入れなければなりません。この時点では,ネゴシエーションの余地はありません。たとえば,開始側が gss_init_sec_context() を呼び出したときに順序付けまたはリプレイ検出を指定した場合,受け入れ側はそれを提供しなければなりません。

開始側が gss_init_sec_context() を呼び出したときにチャネル・バインディングが指定された場合,受け入れ側は,gss_accept_sec_context() の呼び出しの中で完全に一致したチャネル・バインディングを指定しなければなりません。

8.3.4    メッセージ関数

GSS-API メッセージ関数は,メッセージ単位で保護を実行します。メッセージ関数は,どちら側のアプリケーションからも呼び出すことができます。 アプリケーションがこれらの関数を呼び出すときには,QOP (quality of protection) を指定します。これは,メッセージの処理に使われる暗号化アルゴリズムを識別するものです。QOP の値はメカニズムに依存します。暗号化アルゴリズムの適用に使われる鍵は,セキュリティ・コンテキストから取得されます。

GSS-API 関数 説明
gss_get_mic() メッセージから署名を生成し,データが完全なものであり,発信元が信頼できることを保証します。トークン (署名) が戻されます。元のメッセージは,トークンにはカプセル化されません。
gss_unwrap() トークンの復号と確認を行いその完全性を判別し,必要であればメッセージを復号してメッセージを戻します。
gss_verify_mic() メッセージとその署名を突き合わせて,送信中にメッセージが破損していないことを保証します。
gss_wrap() メッセージをトークンにカプセル化し,機密性が指定されていればこれを暗号化します。さらに,メッセージが転送中に破損していないことを保証し,データの発信元の認証を提供するために,署名を入れます。
gss_wrap_size_limit() 使用するネットワークで送信できるトークンの最大サイズが決められている場合に,コンテキストの gss_wrap() を見てメッセージ・サイズの上限を調べます。

次の 4 つの関数は相互にペアの関係になっています。

アプリケーションは,署名をデータとは切り離して送信したい場合は,gss_get_mic()gss_verify_mic() を使用できます。 たとえば,PGP メール (Pretty Good Privacy) では,メッセージが最初に送信され,その後に署名が送信されます。署名がチェックされ,その次に結果が表示され,送信中にメッセージが変更されなかったことを示します。

注意

これらの関数は,GSS-API V2 で始めて導入されたものです。以前のリリースでは,関数 gss_sign()gss_verify()gss_seal()gss_unseal() を使用していました。

8.3.4.1    Quality of Protection

アプリケーションがこれらのメッセージ関数を呼び出すときには,メッセージに適用される完全性または機密性のアルゴリズムを識別する QOP を指定します。Kerberos 5 では,次の 6 つのアルゴリズムが QOP に対して定義されています。

注意

同じ QOP が指定されていると,gss_get_mic()gss_wrap() は署名を同じ方法で計算します。

8.3.5    その他のサポート関数

この節では,アプリケーションの保護に使用できる,その他のサポート関数の一覧をまとめます。

GSS-API 関数 説明
gss_add_oid_set_member() オブジェクト識別子 (OID) をセットに追加します。
gss_create_empty_oid_set() オブジェクト識別子のないセットを作成します。
gss_display_status() GSS-API ステータス・コードを表示可能なテキスト形式に変換します。アプリケーションは,いくつかのエラーが示されている複数のステータス・メッセージを受け取るために,この関数を何度も呼び出す必要が生じることもあります。アプリケーションは,gss_release_buffer() を呼び出すことによってバッファを解放します。この関数は,メジャー・ステータス・コードとマイナー・ステータス・コードの両方を扱います。
gss_indicate_mechs() ローカル・システムでサポートされているメカニズム識別子を戻します。この構造体は,gss_release_oid_set() を使ってアプリケーションが解放しなければなりません。
gss_release_buffer() 表示可能な名前,バッファ,トークンの記憶域を解放します。gss_display_status()gss_display_name()gss_export_name()gss_export_sec_context()gss_init_sec_context()gss_accept_sec_context()csf_gss_acq_user()gss_wrap()gss_get_mic()gss_unwrap() の呼び出し後に使われます。
gss_release_oid_set() OID セット・オブジェクトの記憶域を解放します。
gss_test_oid_set_member() オブジェクト識別子がセットのメンバかどうかを判別します。

その他,HP のエクステンション関数があります。

Application Security SDK 関数 説明
cs_oid_cmp() 2 つの OID を比較します。
cs_oid_dup() OID を複製します。
cs_oid_free() OID に関連付けられているリソースを解放します。
cs_oid_in_set() OID が何らかの OID セットに含まれているかどうかを判別します。
cs_oid_set_cmp() 2 つの OID セットを比較します。
cs_oid_set_dup() OID セットを複製します。
cs_oid_set_free() OID セットに関連付けられているリソースを解放します。
cs_oid_set_insert() OID セットに OID を挿入します。GSS-API v2 準拠のために,関数 gss_add_oid_set_member() のほうが優先的に使われます。
cs_oid_set_isect() 2 つの OID セットの共通部分となる新しいセットを作成します。
cs_oid_set_union() 2 つの OID セットの集合となる新しいセットを作成します。
csf_gss_get_OidAddress() 組み込まれている OID セットのアドレスを取得します。
csf_gss_get_RfcOidSet() 組み込まれている Kerberos OID セットのアドレスを取得します。
csfgss_pPtr() OID メカニズムまたは OID メカニズム・セットのポインタを取得します。

8.3.5.1    OID と OID セット

OID (オブジェクト識別子) と OID セットを理解するには,いくつかの背景情報が役に立ちます。

8.3.5.1.1    OSI

CCITT X.200 に詳細が記述されている OSI は,物理層からユーザ・アプリケーション層までのコンピュータの相互接続を司る,国際的に標準化されたアーキテクチャです。より高い層にあるオブジェクトを抽象的に定義し,より低い層のオブジェクトによって実装することを意図しています。

8.3.5.1.2    ASN.1

OSI の抽象オブジェクトの指定方法を ASN.1 (Abstract Syntax Notation One,CCITT X.208 で定義されています) と呼びます。ASN.1 は,こうした抽象オブジェクトを 1 とゼロの並びとして表現するための一連のルールを定義したものです。ASN.1 は,さまざまなデータ型の定義が可能な,柔軟性のある表記法です。たとえば,整数とビット文字列などの単純な型,セットとシーケンスなどの構造化された型,その他の型に関して定義された複雑な型が可能です。

8.3.5.1.3    オブジェクト識別子

OID (オブジェクト識別子) は,アルゴリズムと属性タイプなど,オブジェクトを識別するために使われる単純なデータ型の 1 つです。OID は,一連の整数コンポーネント,つまり,登録機関によって意味が与えられている値で構成されています。

GSS-API では,OID は名前タイプとメカニズムなどのパラメータを識別するために使われます。下の例で,この仕組みを示します。

例 8-1:  文字列の入った構造体を指す定数

定数 GSS_C_NT_USER_NAME は,次の OID 文字列を含んだ gss_OID_desc 構造体を指すように初期設定された gss_OID タイプです。

{10, (void *)"\x2a\x86\x48\x86\xf7\x12\x01\x02\x01\x01"}

これは,次の 10 進値によるオブジェクト識別子に変換できます。

{ 1 2 840 113554 1 2 1 1 }

これはさらに,次のオブジェクトの階層を表しています。

{iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) generic(1) user_name(1)}

例 8-2:  文字列を指す定数

定数 rfc_krb5_c_OID は,次の OID 文字列を指す gss_OID タイプです。

{iso(1) member-body(2) United States(840) mit(113554) infosys(1) gssapi(2) krb5v2(3)}

8.3.5.1.4    OID セット

OID セットは,一連の OID と,その OID 数を表す整数からなる,GSS-API のデータ構造体です。GSS-API 関数の中には,セットを使って多数のさまざまなメカニズムと属性オブジェクトの入出力を行うものもあります。たとえば,gss_acquire_cred() を呼び出すと,サポートされているすべてのメカニズムのオブジェクト識別子の入った OID セットが戻されます。gss_test_oid_set_member() を使用すると,特定の OID がセット内にあるかどうかを確認できます。

OID セットは,関数 gss_create_empty_oid_set() および gss_add_oid_set_member() を使って作成することもできます。

8.3.6    V1 準拠関数

Application Security SDK には,GSS-API Version 2 ではサポートされていない関数がいくつかあります。HP は,今回のリリースでは,v1 との相互運用性の目的でこれらの関数を引き続きサポートしています。GSS-API Version 2 を使って記述する新しいアプリケーションでは,v1 の関数ではなく,それに相当する v2 の関数を使用する必要があります。

GSS-API v1 の関数 相当する GSS-API v2 の関数
gss_open() このアクションは必要なくなりました
gss_close() このアクションは必要なくなりました
gss_process_context_token() このアクションは必要なくなりました
gss_seal() gss_wrap()
gss_sign() gss_get_mic()
gss_unseal() gss_unwrap()
gss_verify() gss_verify_mic()

8.4    ベスト・プラクティス

以降の節では,Application Security SDK を使ってカスタム・アプリケーションを作成する際に,セキュリティに関して考慮すべき点と,推奨事項を取り上げます。

8.4.1    マルチ・スレッディング

次の関数は,スレッド・セーフではありません。

これらの関数はすべて,初回チケットの取得に関するものであるため,アプリケーションのマルチ・スレッドの部分での使用は避けてください。

gss_init_sec_context()gss_accept_sec_context() は,どちらもマルチ・スレッド・セーフを保証するために特別な処置がなされています。他の関数はすべて,各スレッドが一意のセキュリティ・コンテキストを使用している限り,スレッド・セーフです。

8.4.2    キャッシュ管理

プリンシパル間でのキャッシュの共有は,セキュリティ上危険です。キャッシュを共有するプリンシパルの 1 つが,そのキャッシュを使っている別のプリンシパルになりすます可能性があるためです。その結果,プリンシパルやプリンシパルを信頼しているサーバが悪用されたり,またはリプレイされたメッセージが受け渡されたりすることが考えられます。

HP では,開始側ごとに一意の信任状キャッシュを使い,受け入れ側ごとに一意の鍵テーブル・エントリを使うことをお勧めしています。また,受け入れ側のアプリケーションごとに,別々の鍵テーブル・ファイルが用意されているのが理想です。

8.4.3    暗号化タイプ

Application Security SDK は,DES と DES3 の両方の暗号化タイプをサポートしています。HP は,DES3 暗号化の使用をお勧めしています。DES3 は DES と比べて保護機能が大幅に向上しています。

ただし,DES3 では移植性に制限があります。DES3 暗号化を使っているアプリケーションは,Application Security SDK の実装でしか使用できません。

8.4.4    セキュリティ・コンテキストのエクスポート

gss_export_sec_context() 関数は,プロセス間でセキュリティ・コンテキストを渡すためのトークンを作成します。このトークンには,コテキストの秘密鍵が含まれているため,特別に細心の注意を払う必要があります。エクスポートされたセキュリティ・コンテキストは,GSS-API では保護できないため,アプリケーションによって保護しなければなりません。

GSS-API のこの機能を使うアプリケーションは,エクスポートしたセキュリティ・コンテキストをプロセス間で安全な方法で受け渡す必要があります。エクスポートしたセキュリティ・コンテキストは,セキュリティ・コンテキストを作成したホストの範囲内で保持するようにしてください。

8.4.5    GSS と Kerberos 5 による鍵管理

秘密鍵は,暗号化アルゴリズムと鍵付きチェックサム・アルゴリズムによって使用され,定期的に変更する必要があります。どのくらいの頻度で変更すべきかは,使用しているアルゴリズムと保護するデータの量に依存します。頻度を減らす 1 つの方法としては,DES の代わりに DES3 を使うなど,より強力な暗号化アルゴリズムを使うことが挙げられます。

使われている鍵のタイプには,次の 5 つがあります。

セキュリティ・コンテキストのセッション鍵以外は信任状キャッシュまたはサービス鍵テーブル・ファイルに格納されるため,信任状キャッシュとサービス鍵テーブル・ファイルは保護しておく必要があります。

8.4.6    マルチ・スレッド関数

次の Application Security SDK 関数は,スレッド・セーフではありません。

これらの関数はすべて,初回チケットの取得に関するものであるため,マルチ・スレッド環境での使用は避けてください。プログラムがスレッドを作成する前に信任状が取得されると,その信任状はマルチ・スレッド型の開始側または受け入れ側に渡されることがあります。

gss_init_sec_context()gss_accept_sec_context() は,どちらもマルチ・スレッド・セーフを保証するために特別な処置がなされています。Application Security SDK の他の呼び出しはすべて,各スレッドが一意のセキュリティ・コンテキストを使用している限り,スレッド・セーフです。

8.4.7    相互認証

相互認証は,セキュリティ・コンテキストを確立する間に,開始側と受け入れ側の両方のプリンシパルに,相手が本人かどうかをチェックすることを義務付けるものです。相互認証が必要かどうかは,関数 gss_init_sec_context()req_flags パラメータの GSS_C_MUTUAL_FLAG オプションで示されます。

プリンシパルに相互認証の実行を義務付けない場合,メッセージのリプレイが生じる危険があります。相互認証を実行しない場合は,req_flags パラメータの GSS_C_REPLAY_FLAG を使ってメッセージ・リプレイ検出を有効にしておく必要があります。

8.4.8    パスワードの保護

HP は,プリンシパルからのパスワード情報の取得に使われるすべてのダイアログ・ボックスやフォームで,キーボードのエコーをオフにしておくことを推奨しています。これにより,同じ部屋にいる誰かに,コンピュータ画面のパスワードを見られてしまうのを防ぐことができます。

パスワードの格納に使うバッファは,使った後は直ちにゼロに設定する必要があります。

8.4.9    リプレイの防止

gss_init_sec_context() 関数には,メッセージ・リプレイ検出機能を有効にするかどうかを示すフラグが含まれています (req_flags パラメータの GSS_C_REPLAY_FLAG)。アプリケーションがコンテキストを確立するときに相互認証を実行しない場合 (req_flags パラメータの GSS_C_MUTUAL_FLAG フラグが FALSE に指定されている場合) メッセージ・リプレイ検出機能を有効にしておくことが重要です。

メッセージ・リプレイ検出は,他のアプリケーションから受信したメッセージを,リプレイ・キャッシュを使って格納することを義務付けます。キャッシュは開始側と受け入れ側の両方にあります。これらのキャッシュはメモリベースであり,サイズは上限まで拡大できます。したがって,リプレイ検出はプロセスのサイズに影響を及ぼすことになります。新しいリプレイ・キャッシュ・エントリは,gss_unwrap()gss_verify_mic() の実行中に割り当てられ,アプリケーションにメモリ・リークがあるように見えますが,これは通常の動作です。メッセージ・リプレイ検出を使うセキュリティ・コンテキストが削除されると,メッセージ・リプレイ・キャッシュ全体も削除されます。

認証のリプレイ検出には,別のタイプのリプレイ・キャッシュが使われます。 これは,UNIX の 環境変数 CSFC5RCNAME,または Windows のレジストリ・エントリ RepCache によって制御される,省略時のファイルベースのキャッシュです。セキュリティに影響を及ぼす可能性があるため,このキャッシュがメモリ・ベースのキャッシュになるようには構成できません。このタイプのキャッシュは常にアクティブであり,開始側のアプリケーションによって制御されることはありません。

8.4.10    信任状のリフレッシュ

有効期限のない暗号鍵を含んでいるセキュリティ・パラメータが 2 つあります。1 つはサービス鍵テーブル・エントリであり,もう 1 つはセキュリティ・コンテキストです。HP では,これらの鍵の暗号が解読される可能性を最小限に抑えるために,この 2 つのパラメータを定期的にリフレッシュすることを推奨しています。

8.4.11    リソース管理

多くの関数が,アプリケーションによって使われるセキュリティ情報を格納するために,文字列,バッファ,その他のリソースを作成します。これらのリソースは,使い終わったら,SDK に含まれている適切な関数を呼び出すことによって正しく解放することが重要です。これに失敗すると,セキュリティが損なわれることにつながります。管理を誤ったリソースは,セキュリティ攻撃で取得され,読み取られる可能性があります。

SDK マニュアルの「リファレンス」の項で,取り扱いに注意を要するリソースを作成する関数の内容を解放するための,適切なリソース管理の呼び出しについての詳細が記されています。個々の SDK マニュアルの「リファレンス」の項をよく読み,セキュリティを危険にさらすのを防ぐための正しい手順を判断してください。

8.4.12    サービス鍵テーブル・ファイル

サービス鍵テーブル・ファイルには,それが本人かどうかをチェックするために受け入れ側のアプリケーションが使う信任状が格納されています。このファイルへのアクセスは,ファイルの内容を読み取るユーザ・パーミッションを与えないことで,厳しく制限する必要があります。トラステッド・サービスだけに,このファイルへのアクセスを許可する必要があります。

サービス鍵テーブル・ファイルの信任状は,有効期限がありません。このため HP では,これらの信任状を定期的にリフレッシュすることを推奨しています。サービス鍵テーブル・ファイルのエントリをリフレッシュするには,セキュリティ・サーバによって新しいランダムな鍵を生成し,プリンシパル・データベース管理プログラムを使ってサービス・ホストに抽出します。

8.4.13    チケット属性

Kerberos 5 の初回チケットを,各種の属性を付けて要求できます。その属性は,csf_gss_acq_user() 関数のフラグによって指定されます。以降の節では,要求できる属性について説明します。

8.4.13.1    転送可能チケット

転送は,あるホストから別のホストへ,TGT を送るメカニズムです。転送された TGT を使って,TGT で指定されている最初のプリンシパルの代わりに,2 番目のホストで新しいサービス・チケットを生成できます。チケットは,トラステッド・プリンシパルだけに転送するようにしてください。

8.4.13.2    事前認証

事前認証は,TGT 要求を使って追加の暗号化データを送信するものです。追加の暗号化データは,Encrypted Timestamp の形式をとります。追加のこの情報により,認証プロセス中にセキュリティをさらに高めることができます。CSF_GSS_C_ACQ_USER_OPT_NOPREAUTH が指定されている場合,事前認証が必要ないことを示しています。

HP では,事前認証を省略することは,セキュリティとは別の理由でそうする必要がある場合を除き,お勧めしていません。このため,どうしても必要な場合以外は,このオプションの使用を避けることをお勧めします。特に Kerberos 5 セキュリティ・メカニズムの場合,初回チケットの取得中に事前認証を行うことで,自分の名前が偽装者によってチケットに書き込まれるのを防ぐことができます。本来ならばこれらのチケットは,チケットに名前が指定されているプリンシパルによってしか使用できません。それだけがチケットを復号するための秘密鍵を所有しているからです。ただし,悪意のある者が何らかの暗号解読機能を持っている場合,事前認証によって,悪意のある者が活用できる情報がセキュリティ・サーバから取得されるのを防ぐことができます。また事前認証によってチケット要求の鮮度も保証されます。

8.4.13.3    チケットの存続期間

要求されたチケットの存続期間は,CSF_GSS_ACQ_USER_OPT_LIFETIME フラグによって指定されます。セキュリティ・サーバは,要求されたものよりも短い存続期間の初回チケットを戻すことがあります。指定されたレルムのプリンシパル宛てに発行されたチケットの最大存続期間が,特殊なプリンシパルである krbtgt/REALM@REALM の設定によって制御されるためです。

Kerberos のバージョンによって課されるチケットの存続期間の制限もあります。Kerberos 4 におけるチケット存続期間の最大値は,21 時間 15 分です。最大存続期間を 1 日とする場合,Kerberos 5 のチケットは 24 時間完全に存続しますが,Kerberos 4 のチケットは 21 時間 15 分で期限切れとなります。

8.4.13.4    チケットの延長期限

CSF_GSS_C_ACQ_USER_OPT_RENEWABLE フラグを使うと,チケットを要求するときに延長可能属性を指定できます。ただしセキュリティ・サーバは,要求されたものよりも短い延長期限で初回チケットを戻すことがあります。これは,指定されたレルムのプリンシパル宛てに発行されたチケットの最大延長期限は,特殊なプリンシパルである krbtgt/REALM@REALM の設定によって制御されるためです。

延長可能チケットを受け取った後,延長期限は一連の規則によって制御されます。プリンシパルが最初に TGT を要求するときには,存続期間と延長期限は関連付けられません。初回チケットが発行される段階では,許可されている延長可能時間と存続期間は関係がありません。しかし,チケットが延長されると2 つの時間が関連を持つことになります。

8.4.13.4.1    存続期間と延長の設定に関する一般的な規則

チケットを延長する場合,延長後の存続期間は次の規則に従って決まります。

8.5    移植性のあるアプリケーションの構築

GSS-API 標準は汎用性を持たせて設計されており,GSS-API を組み込んだアプリケーションは,ソース・レベルで互換性があります。しかし,異なるベンダの GSS-API の実装を使用すると,ベンダ間で移植性の問題にぶつかることがあります。

以降の節では,この影響を最小限に抑え,Application Security SDK を使って作成された GSS-API のプラットフォーム間の移植性を高めるために役立つ推奨事項を取り上げます。

8.5.1    表示可能な名前の使用と名前の比較

gss_display_name() 関数は,内部的な名前 (つまり gss_import_name() によって戻された名前) を,表示に適したテキスト形式に変換します。GSS-API 標準では,表示可能な名前と gss_display_name() から戻される名前タイプの OID が, gss_import_name() への入力に適したものである必要がないため,表示可能な名前のフォーマットは,実装ごとに固有であり,オペレーティング・システムに依存します。表示可能な名前のフォーマットは,実装がクロス・ベンダ,クロス・プラットフォーム,ベンダによるインクリメンタルなリリースなどに関係なく,GSS-API の複数の実装の間で異なっていても構いません。このため,表示可能な名前は,GSS-API 標準外部の名前比較関数への入力としては確実なものとはいえません。このような目的には,gss_export_name() 関数で作成されるエクスポート名のフォーマットを使用してください。エクスポート名が使われる可能性のある例としては,ACL (アクセス制御リスト) 機能,アカウント管理,診断支援などがあります。

8.5.2    メカニズムの指定

gss_acquire_cred()csf_gss_acq_user() に OID セットを渡し,gss_init_sec_context()gss_import_name() に OID セットを渡すと,技術が変化したときにアプリケーションの移植性は低くなります。たとえば,セキュリティ・メカニズムとして Kerberos を導入した企業が,のちに公開鍵セキュリティ・メカニズムに変更することなどが考えられます。 アプリケーションの開発時に Kerberos を指定した OID セットがハード・コードされていると,そのアプリケーションを変更する必要が生じます。さらにメカニズムの OID も変わる可能性があります。

移植性を高めるためには,アプリケーションは,省略時の OID と OID セットの値を関数に渡す必要があります。こうすることで,GSS-API の実装は,使用可能な適切なメカニズムを選択できます。

8.5.3    Quality of Protection (QOP) の指定

gss_wrap() および gss_get_mic() 関数は,メッセージに適用するアルゴリズムを指定する QOP パラメータを受け取ります。QOP パラメータの値は,メカニズムに固有です。省略時の値以外を指定すると (この場合は GSS-API の実装が値を選択します),メカニズムに対してアプリケーションをハード・コードすることになります。

このため,使用するメカニズムを変更した場合や,現在使用しているメカニズムの機能が変わった場合に,アプリケーションのソース・コードを変更する必要が生じます。

gss_unwrap() および gss_verify_mic() 関数とその逆の機能を果たす gss_wrap() および gss_get_mic() 関数は,メッセージの保護に使用する実際の QOP を戻すものと想定されています。アプリケーションがメッセージをエンコードするときに省略時の QOP を指定した場合,逆の関数によって戻される QOP はメカニズムに依存します。

移植性を高めるためには, アプリケーションは,gss_wrap() および gss_get_mic() 関数を呼び出すときには省略時の QOP 値を指定し,この逆の関数 (gss_unwrap() および gss_verify_mic()) によって戻される値は使わないようにする必要があります。

省略時の完全性の QOP は次のとおりです。

機密性の QOP は次のとおりです。

使用される省略時の QOP は,セキュリティ・コンテキストが確立されたときに選択された暗号化タイプに依存します。

注意

DES3 の QOP には移植性がありません。この QOP を指定すると,アプリケーションは Kerberos 5 メカニズム専用になります。

8.5.4    省略時の名前

いくつかの GSS-API 関数は,省略時の名前を選択するようなパラメータを受け取ります。 しかし,GSS-API 標準では,省略時の名前を形成する方法を定義していないため,省略時の名前はメカニズムに依存し,オペレーティング・システムにも依存します。たとえば,ある GSS-API の実装では,環境変数を問い合わせることによって省略時の名前を形成し,GSS-API の別の実装では,ユーザの ID (たとえば UNIX の UID) から形成するなどが考えられます。さらに,間接的な選択基準やメカニズムの慣例に基づいて省略時の名前を形成する GSS-API の実装もあります。たとえば,Application Security SDK の Kerberos メカニズムの実装では, 省略時の名前は,GSS_C_INITIATE に使用する信任状の場合は user@REALM, GSS_C_ACCEPT に使用する信任状の場合は host/hostname@REALM となります。

HP では,移植性を高めるために,メカニズムに依存する省略時の名前は使わないことを推奨しています。

8.6    クリック・リファレンス

Application Security SDK は,次の表に示すように,アプリケーションの保護に使われる標準の関数と独自の関数からなります。

関数 説明
cs_oid_cmp() 2 つの OID を比較します。
cs_oid_dup() OID を複製します。
cs_oid_free() OID を解放します。
cs_oid_in_set() OID が何らかの OID セットに含まれているかどうかを判別します。
cs_oid_set_cmp() 2 つの OID セットを比較します。
cs_oid_set_dup() OID セットを複製します。
cs_oid_set_free() OID セットを解放します。
cs_oid_set_insert() OID セットに OID を挿入します。
cs_oid_set_isect() 既存の 2 つの OID セットの共通部分となる新しい OID セットを作成します。
cs_oid_set_union() 既存の 2 つの OID セットの集合となる新しい OID セットを作成します。
csf_gss_acq_user() セキュリティ・コンテキストの開始前にユーザを取得します。
csf_gss_get_context_options() 使用されている暗号化のタイプを確認します。
csf_gss_get_OidAddress() 組み込まれている OID のアドレスを戻します。
csf_gss_get_RfcOidSet() 組み込まれている Kerberos の OID セットのアドレスを戻します。
csf_gss_inq_user() ユーザに関する情報を取得します。
csfgss_pPtr() OID メカニズムまたは OID メカニズム・セットのポインタを取得します。
csf_gss_release_user() 不要になったユーザを削除します。
csf_gss_renew_cred() 信任状を延長します。
gss_accept_sec_context() ピア・アプリケーションによって開始されたセキュリティ・コンテキストを受け入れます。
gss_acquire_cred() 格納されている信任状を,アプリケーションでの使用のために取り出します。
gss_add_cred() 信任状を追加的に作成します。
gss_add_oid_set_member() オブジェクト識別子 (OID) をセットに追加します。
gss_canonicalize_name() 内部名をメカニズム固有の名前 (MIN) に変換します。
gss_close() v1 との相互運用性のためにサポートされている関数です。
gss_compare_name() 内部名で表現された 2 つの名前を比較します。
gss_context_time() セキュリティ・コンテキストの有効期限の残り時間を調べます。
gss_create_empty_oid_set() オブジェクト識別子のないセットを作成します。
gss_delete_sec_context() セキュリティ・コンテキストを削除します。
gss_display_name() 内部形式の名前をテキストに変換します。
gss_display_status() GSS-API のステータス・コードをテキストに変換します。
gss_duplicate_name() 既存の内部形式の名前のコピーを作成します。
gss_export_name() メカニズムに固有の名前をエクスポート形式に変換します。
gss_export_sec_context() セキュリティ・コンテキストを別のプロセスに転送します。
gss_get_mic() メッセージの,メッセージ完全性コード (MIC) と呼ばれる署名を計算します。
gss_import_name() テキスト形式の名前を内部形式に変換します。
gss_import_sec_context() エクスポートされたセキュリティ・コンテキストをインポートします。
gss_indicate_mechs() 使用可能なセキュリティ・メカニズムを調べます。
gss_init_sec_context() ピア・アプリケーションとのセキュリティ・コンテキストを開始します。
gss_inquire_context() セキュリティ・コンテキストに関する情報を取得します。
gss_inquire_cred() 信任状に関する情報を取得します。
gss_inquire_cred_by_mech() 信任状に関するメカニズムごとの情報を取得します。
gss_inquire_mechs_for_name() 指定された名前タイプをサポートするメカニズムの一覧を表示します。
gss_inquire_names_for_mech() 指定されたメカニズムによってサポートされている名前タイプの一覧を表示します。
gss_oid_to_str() OID を文字列として表示します。
gss_open() v1 との相互運用性のためにサポートされている関数です。
gss_process_context_token() ピア・アプリケーションからのセキュリティ・コンテキストのトークンを処理します。v1 との相互運用性のためにサポートされている関数です。
gss_release_buffer () バッファを削除します。
gss_release_cred() 使用後の信任状を削除します。
gss_release_name() 内部形式の名前を削除します。
gss_release_oid() OID オブジェクトの記憶域を解放します。
gss_release_oid_set() オブジェクト識別子のセットを削除します。
gss_seal() gss_wrap() によって置き換えられています。
gss_sign() gss_get_mic() によって置き換えられています。
gss_str_to_oid() 文字列から OID を作成します。
gss_test_oid_set_member() オブジェクト識別子がセットのメンバかどうかを調べます。
gss_unseal() gss_unwrap() によって置き換えられています。
gss_unwrap() メッセージに添付された署名をチェックし,必要であればメッセージの内容を復号します。
gss_verify() gss_verify_mic() によって置き換えられています。
gss_verify_mic() 受信されたメッセージの署名をチェックします。
gss_wrap() メッセージに署名を添付し,必要であればメッセージの内容を暗号化します。
gss_wrap_size_limit() 使用するネットワークで送信できるトークンの最大サイズが決められている場合に,コンテキストの gss_wrap() を見てメッセージ・サイズの上限を調べます。

8.6.1    リファレンス・ページの表記規則

各関数はリファレンス・ページで,次の項目を使って説明されています。

使用目的

関数の用途の簡単な説明。

構文

使用可能なパラメータと,コマンド行引数の完全なリスト。

入力パラメータは,アプリケーションから Application Security SDK に渡される引数です。

出力パラメータは,Application Security SDK からアプリケーションに渡される引数です。

入力パラメータが省略可能な場合,アプリケーションはそのパラメータに対する省略時の値を渡すことができます。

出力パラメータが省略可能な場合,アプリケーションにとってそのパラメータは必須ではないため,Application Security SDK は値を戻す必要がありません。このことを示す場合は,出力パラメータに NULL を使用してください。

注意

メモリ・リークを避けるために,アプリケーションは常に,戻された値に関連付けられている記憶域を使用後に解放する必要があります。

パラメータ

関数に渡され,関数から戻される一連の変数。2 進値の場合は,

NULL に初期設定されているパラメータは,ゼロになることもあります。

説明

関数の定義,使用目的,使用上のヒント。

移植性に関する考慮事項

HP によって保護されたアプリケーションを,別の環境に移植するための考慮事項。

リターン値

関数によって戻されるメジャー・ステータス・コードの一覧。

関連項目

関連のある関数呼び出しの一覧。

8.7    定数

Application Security SDK に含まれているヘッダ・ファイルでは多数の定数を使用しています。以下に,リファレンス用にヘッダ・ファイルの定数の定義を示します。

コンテキスト・フラグ 定義
GSS_C_DELEG_FLAG 1
GSS_C_MUTUAL_FLAG 2
GSS_C_REPLAY_FLAG 4
GSS_C_SEQUENCE_FLAG 8
GSS_C_CONF_FLAG 16
GSS_C_INTEG_FLAG 32
GSS_C_ANON_FLAG 64
GSS_C_PROT_READY_FLAG 128
GSS_C_TRANS_FLAG 256
CSF_GSS_C_DES_FLAG 268435456
CSF_GSS_C_DES3_FLAG 536870912

信任状の使用 定義
GSS_C_BOTH 0
GSS_C_INITIATE 1
GSS_C_ACCEPT 2

ステータス・コードのタイプ 定義
GSS_C_GSS_CODE 1
GSS_C_MECH_CODE 2

アドレスのタイプ 定義
GSS_C_AF_UNSPEC 0
GSS_C_AF_LOCAL 1
GSS_C_AF_INET 2
GSS_C_AF_IMPLINK 3
GSS_C_AF_PUP 4
GSS_C_AF_CHAOS 5
GSS_C_AF_NS 6
GSS_C_AF_NBS 7
GSS_C_AF_ECMA 8
GSS_C_AF_DATAKIT 9
GSS_C_AF_CCITT 10
GSS_C_AF_SNA 11
GSS_C_AF_DECnet 12
GSS_C_AF_DLI 13
GSS_C_AF_LAT 14
GSS_C_AF_HYLINK 15
GSS_C_AF_APPLETALK 16
GSS_C_AF_BSC 17
GSS_C_AF_DSS 18
GSS_C_AF_OSI 19
GSS_C_AF_X25 21
GSS_C_AF_NULLADDR 255

各種の NULL 値 定義
GSS_C_NO_NAME NULL
GSS_C_NO_BUFFER NULL
GSS_C_NO_OID NULL
GSS_C_NO_OID_SET NULL
GSS_C_NO_CONTEXT NULL
GSS_C_NO_CREDENTIAL NULL
GSS_C_NO_CHANNEL_BINDINGS NULL
CSF_GSS_C_NO_USER NULL
CSF_GSS_C_ACQ_USER_OPT_NONE NULL

QOP 定義
GSS_C_QOP_DEFAULT 0
GSS_KRB5_CONF_C_QOP_DES 0
GSS_KRB5_INTEG_C_QOP_MD5 1
GSS_KRB5_INTEG_C_QOP_DES_MD5 2
GSS_KRB5_INTEG_C_QOP_DES_MAC 3
CSF_GSS_KRB5_INTEG_C_QOP_DES3_MD5 5341
CSF_GSS_KRB5_CONF_C_QOP_DES3 5342

ユーザ・オプション 定義
CSF_GSS_C_ACQ_USER_OPT_LIFETIME 1
CSF_GSS_C_ACQ_USER_OPT_RENEWABLE 2
CSF_GSS_C_ACQ_USER_OPT_CCNAME 4
CSF_GSS_C_ACQ_USER_OPT_KTNAME 8
CSF_GSS_C_ACQ_USER_OPT_SVCKEY 16
CSF_GSS_C_ACQ_USER_OPT_ALWAYS_FETCH 256
CSF_GSS_C_ACQ_USER_OPT_FORWARDABLE 32
CSF_GSS_C_ACQ_USER_OPT_PROXIABLE 64
CSF_GSS_C_ACQ_USER_OPT_NOPREAUTH 128

暗号化タイプ 定義
CSF_GSS_C_ENCTYPE_DES_CBC_CRC 1
CSF_GSS_C_ENCTYPE_DES_CBC_MD5 3
CSF_GSS_C_ENCTYPE_DES3_CBC_MD5 5

相互認証のタイプ 定義
CSF_GSS_C_PREAUTH_NONE 0
CSF_GSS_C_PREAUTH_ENC_TIMESTAMP 2
CSF_GSS_C_PREAUTH_ENC_UNIX_TIME 5

チャレンジの状態 定義
CSF_GSS_C_USER_STATE_NULL 0
CSF_GSS_C_USER_STATE_PASSWORD_NOECHO 1
CSF_GSS_C_USER_STATE_CHALLENGE_ECHO 2
CSF_GSS_C_USER_STATE_OTP_ECHO 3
CSF_GSS_C_USER_STATE_PASSWORD_ECHO 4
CSF_GSS_C_USER_STATE_CHALLENGE_NOECHO 5
CSF_GSS_C_USER_STATE_OTP_NOECHO 6

その他 定義
GSS_C_INDEFINITE 0xFFFFFFFF
CSF_GSS_C_PURGE_FLAG 1

8.8    データ構造体

Application Security SDK では,関数呼び出しとのデータの受け渡しに,次のデータ構造体を使います。

8.8.1    gss_channel_bindings_t

gss_channel_bindings_t は,セキュリティ・コンテキストの通信チャネルを識別する情報の入ったデータ構造体のポインタです。「チャネル・バインディング」で,チャネル・バインディングがどのように動作するかを説明しています。

gssapi.h ヘッダ・ファイルで定義されている構造体は,次のとおりです。

typedef struct _gss_channel_bindings_struct {
OM_uint32					initiator_addrtype;
gss_buffer_desc		initiator_address;
OM_uint32					acceptor_addrtype;
gss_buffer_desc		acceptor_address;
gss_buffer_desc		application_data;
} gss_channel_bindings_desc, *gss_channel_bindings_t;

initiator_addrtype および acceptor_addrtype フィールドは,initiator_address および acceptor_address バッファにあるアドレスのタイプを示します。Application Security SDK は,アドレス・フォーマット GSS_C_AF_INET をサポートしています。

次の関数呼び出しは,channel_bindings_t 構造体を使います。

gss_accept_sec_context()
gss_init_sec_context()

8.8.2    gss_buffer_t

gss_buffer_t は,関数呼び出しとのデータの受け渡しに使われるデータ構造体のポインタです。実際のデータ構造体であるバッファ記述子は,データの合計バイト数の入った長さフィールドと,実際のデータへのポインタの入った値フィールドからなります。

gssapi.h ヘッダ・ファイルで定義されている構造体は,次のとおりです。

typedef struct gss_buffer_desc_struct { 
size_t					length;
void						*value
} gss_buffer_desc, *gss_buffer_t;

関数呼び出しによってこのデータ構造体を使って戻されるデータの記憶域は,その関数が割り当てます。アプリケーションは,この領域を使い終わったら,gss_release_buffer() を呼び出して解放しなければなりません。使用されていないバッファは,GSS_C_EMPTY_BUFFER の値に初期設定されます。

次の関数呼び出しは,オプションの構造体を使います。

csf_gss_acq_user()
gss_accept_sec_context()
gss_delete_sec_context()
gss_display_name()
gss_display_status()
gss_export_name()
gss_export_sec_context()
gss_get_mic()
gss_import_name()
gss_import_sec_context()
gss_init_sec_context()
gss_process_context_token()
gss_release_buffer()
gss_unwrap()
gss_verify_mic()
gss_wrap()

8.8.3    csf_gss_opts_t

csf_gss_opts_t は,ユーザ・コンテキストに対するオプションのパラメータを格納するデータ構造体のポインタです。

ext.h ヘッダ・ファイルに定義されている 1 個のオプションを格納するための構造体は,次のとおりです。

typedef struct csf_gss_mech_opt_desc_struct {
gss_OID					mechOID;			/* Mech to specify option for */ 
OM_uint32				id;					/* Identifier of option */
void *					val;					/* Value associated with option if appropriate */  
} csf_gss_mech_opt_desc, *csf_gss_opts_t;

オプションごとに 1 つ必要なこれらの構造体の配列を作成する必要があります。配列の最後のレコードの mechOID フィールドは,GSS_C_NO_OID に初期設定します。

次の関数呼び出しは,オプションの構造体を使います。

csf_gss_acq_user()

8.9    リターン値

以下は,アプリケーションのデバッグとトラブルシューティングに役立てるための情報です。

8.9.1    定義されているステータス・コード

多くの Application Security SDK 関数は,メジャー・ステータスと,マイナー・ステータスという 2 つのリターン値を持っています。どちらのステータス・コードも,共通の構造体に戻されます。

メジャー・ステータスがゼロの場合,関数は正常に実行されています。メジャー・ステータスがゼロ以外の場合は,Application Security SDK でエラーが発生したか,基盤の Kerberos 5 メカニズムで何か失敗が生じたことを示しています。ゼロ以外のメジャー・ステータスが戻された場合は,マイナー・ステータスを参照して,失敗に関する詳細なエラー・コードを調べてください。

エラーの状態をプログラム的にチェックして復旧するには,Application Security SDK に含まれているヘッダ・ファイルを参照してください。

Application Security SDK は,メジャー・ステータスの値を評価するマクロも提供しています。

8.9.2    エラー処理マクロ

リターン値を処理するには,次のマクロを使用します。

名前 説明
GSS_ERROR() ルーチン・エラーまたは呼び出しエラーが発生したことを示します。
GSS_CALLING_ERROR() 呼び出しエラーが発生したことを示します。
GSS_ROUTINE_ERROR() ルーチン・エラーが発生したことを示します。
GSS_SUPPLEMENTARY_INFO() 補足的な情報のビットが設定されているかどうかを示します。

8.9.2.1    GSS_ERROR( )

構文

GSS_ERROR(major_status)

パラメータ

major_status

エラーがあるかどうかを示すメジャー・ステータス。OM_uint32 型を使います。

説明

GSS_ERROR() マクロは,メジャー・ステータスがルーチン・エラーまたは呼び出しエラーを示している場合は,真と評価します。

関連項目

GSS_CALLING_ERROR(), GSS_ROUTINE_ERROR()

8.9.2.2    GSS_CALLING_ERROR( )

構文

GSS_CALLING_ERROR(major_status)

パラメータ

major_status

エラーがあるかどうかを示すメジャー・ステータス。OM_uint32 型を使います。

説明

GSS_CALLING_ERROR() マクロは,呼び出しエラーを示す呼び出しビットが設定されていれば,論理 1 (1) と評価します。ビットが設定されていなければ,論理ゼロ (0) と評価します。

呼び出しエラー・ビット

GSS_S_CALL_INACCESSIBLE_READ 01xxxxxx
GSS_S_CALL_INACCESSIBLE_WRITE 02xxxxxx
GSS_S_CALL_BAD_STRUCTURE 03xxxxxx

関連項目

GSS_ERROR()GSS_ROUTINE_ERROR()

8.9.2.3    GSS_ROUTINE_ERROR( )

構文

GSS_ROUTINE_ERROR(major_status)

パラメータ

major_status

エラーがあるかどうかを示すメジャー・ステータス。OM_uint32 型を使います。

説明

GSS_ROUTINE_ERROR() マクロは,ルーチン・エラーを示す呼び出しビットが設定されていれば,論理 1 (1) と評価します。ビットが設定されていなければ,論理ゼロ (0) と評価します。

呼び出しエラー・ビット

GSS_S_BAD_BINDINGS xx04xxxx
GSS_S_BAD_STATUS xx05xxxx
GSS_S_BAD_SIG xx06xxxx
GSS_S_BAD_MECH xx01xxxx
GSS_S_BAD_NAME xx02xxxx
GSS_S_BAD_NAMETYPE xx03xxxx
GSS_S_CONTEXT_EXPIRED xx0Cxxxx
GSS_S_CREDENTIALS_EXPIRED xx0Bxxxx
GSS_S_DEFECTIVE_CREDENTIAL xx0Axxxx
GSS_S_DEFECTIVE_TOKEN xx09xxxx
GSS_S_FAILURE xx0Dxxxx
GSS_S_NO_CRED xx07xxxx
GSS_S_NO_CONTEXT xx08xxxx

関連項目

GSS_CALLING_ERROR(), GSS_ERROR()

8.9.2.4    GSS_SUPPLEMENTARY_INFO( )

構文

GSS_SUPPLEMENTARY_ERROR(major_status)

パラメータ

major_status

補足的な情報ビットがあるかどうかを調べるメジャー・ステータス。OM_uint32 型を使います。

説明

GSS_SUPPLEMENTARY_INFO() マクロは,補足的な情報ビットが設定されていれば,論理 1 と評価し,ビットが設定されていなければ,論理 0 と評価します。特定のビットが設定されているかどうかを調べるには,アプリケーションは,メジャー・ステータスと対象の情報ビットのマクロの AND を計算する必要があります。

補足的な情報ビット

GSS_S_CONTINUE_NEEDED xxxx0001
GSS_S_DUPLICATE_TOKEN xxxx0002
GSS_S_OLD_TOKEN xxxx0004
GSS_S_UNSEQ_TOKEN xxxx0008

関連項目

GSS_ERROR()

8.9.3    メジャー・ステータス

以下に,Application Security SDK 関数呼び出しによって戻されるメジャー・ステータス・コードを,番号順に示します。

16 進値 リターン・コード 説明
00000000 GSS_S_COMPLETE 関数呼び出しは正常に終了しました。
01xxxxxx GSS_S_CALL_INACCESSIBLE_READ 必要な入力パラメータを読み取れませんでした。
02xxxxxx GSS_S_CALL_INACCESSIBLE_WRITE 必要な出力パラメータを読み取れませんでした。
03xxxxxx GSS_S_CALL_BAD_STRUCTURE パラメータの形式が正しくありません。
xx01xxxx GSS_S_BAD_MECH 要求されたメカニズムは無効です。
xx02xxxx GSS_S_BAD_NAME 無効な名前が指定されました。
xx03xxxx GSS_S_BAD_NAMETYPE サポートされていないタイプの名前が指定されました。
xx04xxxx GSS_S_BAD_BINDINGS 間違ったチャネル・バインディングが指定されました。
xx05xxxx GSS_S_BAD_STATUS 間違ったステータス・コードが指定されました。
xx06xxxx GSS_S_BAD_SIG または GSS_S_BAD_MIC トークンに無効な MIC が含まれていました。
xx07xxxx GSS_S_NO_CRED 信任状が指定されていないか,無効であるか,アクセスできません。
xx08xxxx GSS_S_NO_CONTEXT コンテキストが確立されませんでした。
xx09xxxx GSS_S_DEFECTIVE_TOKEN トークンが無効です。
xx0Axxxx GSS_S_DEFECTIVE_CREDENTIAL 信任状が無効です。
xx0Bxxxx GSS_S_CREDENTIALS_EXPIRED 参照されている信任状は期限が切れています。
xx0Cxxxx GSS_S_CONTEXT_EXPIRED セキュリティ・コンテキストは期限が切れています。
xx0Dxxxx GSS_S_FAILURE 何らかの理由で GSS-API レベルでのエラーが発生しました。minor_status パラメータに詳細情報が含まれています。
xx0Exxxx GSS_S_BAD_QOP 要求された QOP をコンテキストが提供できませんでした。
xx0Fxxxx GSS_S_UNAUTHORIZED この操作は,ローカルのセキュリティ・ポリシによって禁止されています。
xx10xxxx GSS_S_UNAVAILABLE この操作またはオプションは無効です。GSS_S_CONTINUE_NEEDED は,補足的な情報ビット・フラグです。まず,GSS_ERROR() を使って,メジャー・ステータスのエラーを検査することによって,GSS_S_CONTINUE_NEEDED を調べます。エラーが示されていなかった場合は,メジャー・ステータスと GSS_S_CONTINUE_NEEDED のビットごとの AND をとります。
xx11xxxx GSS_S_DUPLICATE_ELEMENT 要求された信任状要素はすでに存在しています。
xx12xxxx GSS_S_NAME_NOT_MN 指定された名前はメカニズム名ではありません。
xxxx0001 GSS_S_CONTINUE_NEEDED セキュリティ・コンテキストの確立を完了するには,ピア・アプリケーションからのトークンが必要です。gss_init_sec_context() または gss_accept_sec_context() を再度呼び出して,トークンを生成する必要があります。
xxxx0002 GSS_S_DUPLICATE_TOKEN トークンは以前のトークンの複製でした。
xxxx0004 GSS_S_OLD_TOKEN トークンの有効期限が切れています。
xxxx0008 GSS_S_UNSEQ_TOKEN 後のトークンが先に処理されました。
xxxx0010 GSS_S_GAP_TOKEN 期待されているメッセージごとのトークンが受信されていません。

8.9.4    マイナー・ステータス

以下に,GSS と Kerberos の組み合わせでのエラー・コードを示します。

16 進値 リターン・コード 説明
087F979E4 GSS_KRB5_S_KG_CTX_BINDINGS ピア・コンテキスト・バインディングの検査に失敗しました。
087F979E5 GSS_KRB5_S_KG_BAD_AUTHENTICATOR GSS 認証子が間違っています。
087F979E6 GSS_KRB5_S_KG_NO_MECH メカニズムがありません。
087F979E7 GSS_KRB5_S_KG_KRB_ERR トークンは KRB-ERR です。
087F979E8 GSS_KRB5_S_KG_RECV_ADDR 復号には送信者のアドレスが必要です。
087F979E9 GSS_KRB5_S_KG_SENDER_ADDR 暗号化には送信者のアドレスが必要です。
087F979EA GSS_KRB5_S_KG_BAD_MSG トークンはプライベート・メッセージまたは安全なメッセージではありません。
087F979EB GSS_KRB5_S_KG_CTX_INCOMPLETE 完全でないセキュリティ・コンテキストを使おうとしています。
087F979EC GSS_KRB5_S_KG_BAD_LENGTH トークンのフィールドの長さが正しくありません。
087F979ED GSS_KRB5_S_KG_BAD_QOP_USAGE QOP の使い方が間違っているか,サポートされていません。
087F979EE GSS_KRB5_S_KG_CONTEXT_ESTABLISHED コンテキストはすでに完全に確立されています。
087F979EF GSS_KRB5_S_KG_NO_SUBKEY 認証子にサブキーがありません。
087F979F0 GSS_KRB5_S_KG_TGT_MISSING 信任状キャッシュに TGT がありません。
087F979F1 GSS_KRB5_S_KG_KEYTAB_NOMATCH 鍵テーブルのプリンシパルに要求された名前と一致するものがありません。
087F979F2 GSS_KRB5_S_KG_CCACHE_NOMATCH 信任状キャッシュのプリンシパルが指定された名前と一致していません。
087F979F3 GSS_KRB5_S_G_BAD_KEYGEN サブキーを生成できません。
087F979F4 GSS_KRB5_S_G_BAD_STATUS ディスプレイ・ステータス・コードが不明です。
087F979F5 GSS_KRB5_S_G_UNKNOWN_QOP 指定された QOP は不明です。
087F979F6 GSS_KRB5_S_G_BAD_USAGE 信任状の使い方が不明です。
087F979F7 GSS_KRB5_S_G_WRONG_SIZE バッファのサイズが間違っています。
087F979F8 GSS_KRB5_S_G_BAD_MSG_CTX メッセージ・コンテキストが無効です。
087F979F9 GSS_KRB5_S_G_BUFFER_ALLOC gss_buffer_t データを割り当てることができません。
087F979FA GSS_KRB5_S_G_VALIDATE_FAILED 検査エラーです。
087F979FB GSS_KRB5_S_G_NOSRVC 名前文字列に SERVICE: プレフィックスがありません。
087F979FC GSS_KRB5_S_G_UID_LEN uid_t に対するバッファの長さが間違っています。
087F979FD GSS_KRB5_S_G_NOUSER UID がユーザ名を解決していません。
087F979FE GSS_KRB5_S_G_BAD_UID_NOSUPP UID はこのオペレーティング・システムではサポートされていません。
087F979FF GSS_KRB5_S_G_BAD_SERVICE_NAME 名前文字列 SERVICE-NAME@ がありません。

8.9.5    Kerberos 固有のコード

Kerberos 固有のエラー・コードは,マイナー・エラー・コードです。

ステータス・コードのテキスト表現を取得するには,関数 gss_display_status() を使います。

戻されるエラー・コードの完全なリストを見るには,...\include\csf\sts および ...\include\csfc5\sts ディレクトリにあるヘッダ・ファイルを参照してください。