Generic Security Service Application Program Interface (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 標準は次のような前提条件に基づいています。
アプリケーションは分散されている。
GSS-API 標準は,アプリケーションは分散ネットワーク・アプリケーションであるか,ピア・ツー・ピアまたは開始側/受け入れ側の関係を使って 2 つの部分に分かれているものと想定しています。
ソース・コードは変更可能である。
GSS-API 標準は,GSS-API 関数をアプリケーションのソース・コードに組み込めるものと想定しています。
アプリケーションはトークンの配信を保証する。
トークンとは,GSS-API によって戻され,アプリケーションとそのピアとの通信に必要な不透過なデータ・オブジェクトです。GSS-API 標準は,アプリケーションはコンテキストが確立してから終了するまでに生成されたトークンを,生成された順番で配信できるものと想定しています。
アプリケーションはそのデータ・オブジェクトの割り当てを解除する。
GSS-API 標準は,アプリケーションがデータ・オブジェクトを割り当てた場合は,割り当ての解除もそのアプリケーションが行うものと想定します。GSS-API 関数によってデータ・オブジェクトが戻されると,アプリケーションは必ず,対応する GSS-API 関数を使用してそのオブジェクトを解放しなければなりません。その結果オブジェクトの割り当ては解除されます。そうしないと,アプリケーションでメモリ・リークやメモリ障害が発生する可能性があります。割り当ての解除に正しい関数を使用しないと,セキュリティ・ネットワークへの侵入を許すような状況を作ることになります。
GSS-API は,現在進行中の Internet RFC (Request For Comments) プロセスの一部として策定された業界標準です。
Application Security SDK は,次の RFC に基づいています。
RFC 2078 "Generic Security Service Application Program Interface, Version 2, Update 1" 1998 年 9 月 3 日
"Generic Security Service API Version 2: C-bindings," 1998 年 8 月 7 日
RFC 1964 "The Kerberos Version 5 GSS-API Mechanism," 1996 年 6 月
RFC 1510 "The Kerberos Network Authentication Service (V5)," 1993 年 9 月
Internet Draft "Public Key Cryptography for Initial Authentication in Kerberos" (updates RFC 1510)
ファイル名:
draft-ietf-cat-kerberos-pk-init-07.txt
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 の実装です。
Application Security SDK は,Kerberos 5 のメカニズムをサポートしています。サンプル・コードとドキュメントに,Kerberos 5 と GSS-API を使って分散型アプリケーションを保護するための明確な手順と,このセキュリティ・メカニズムに固有の考慮事項を示してあります。
Application Security SDK には,GSS-API の機能を強化する,追加の関数も多数含まれています。エクステンションと呼ばれるこれらの関数では,次のような,Kerberos 5 の追加のセキュリティ機能の使用が可能です。
認証トークンとユーザ・データの暗号化を含む,Triple DES (DES3) の完全サポート。HP では,すべてのデータを DES3 を使って暗号化することをお勧めします。DES3 は,DES に比べてセキュリティを大幅に向上させます。
開始側のアプリケーションがセキュリティ・コンテキストを確立する前に必要な,初回信任状を取得するためのプログラミング・サポート。このエクステンション関数を使うと,初回信任状を取得するときに,kinit,ActiveTRUST SignOn (CyberSafe Corporation から入手可能),HP の Single SignOn などを使う必要がなくなります。
トークン・カードなど,ハードウェア認証デバイスの認識。 これは認証要求の際に,クライアント・レベルでセキュリティのレベルをさらに 1 つ追加します。
Kerberos 5 信任状を延長する能力。これは,既存の有効な信任状存続期間を延ばし,ユーザがユーザ名とパスワードを提示しなければならない回数を減らします。
8.3 Application Security SDK 関数
Application Security SDK 関数は複数のカテゴリに分類できます。分散型アプリケーションの保護に必要となるのは 1 つのサブセットだけです。これらの関数は,以下のカテゴリに従って分けることができます。
名前管理関数 -- GSS-API で使われる内部と外部の名前を扱う関数。
信任状管理関数 -- 信任状の取得,問い合わせ,解放に使われる関数。このカテゴリには,Application Security SDK の中にあり,GSS-API 標準ではない HP エクステンション関数も含まれています。このカテゴリの関数は初回認証の実装に使われており,DES3 暗号化,ハードウェア認証,信任状の延長のためのサポートが含まれています。
セキュリティ・コンテキスト管理関数 -- セキュリティ・コンテキストの開始,受け入れ,エクスポート,インポート,問い合わせ,削除に使われる関数。
メッセージ関数 -- データの完全性,データの発信元,必要に応じて機密性の保護に使われる関数。
その他の関数 -- 状態の表示,バッファの解放,オブジェクト識別子 (OID) セットの操作に使われる,その他のサポート関数。
V1 準拠関数 -- GSS-API Version 1 との相互運用性のためにサポートされている関数。これらの関数は GSS-API Version 2 に置き換えられています。
ユーザがネットワーク上のシステムにログインするときにユーザ名を使うのと同じように,GSS-API もまたネットワーク内のエントリの識別に名前を使います。ユーザ名は,システムの命名構造に従ってユーザを識別するものです。GSS-API 標準では,名前はアプリケーションまたはそれを使うユーザを識別します。
Kerberos 5 メカニズムでは,名前はプリンシパルに変換されます。プリンシパルとは,Kerberos と何らかの秘密 (通常はパスワード) を共有する任意のユーザ,ネットワーク・サービス,アプリケーション,システムを指します。プリンシパルは,レルム内で一意の名前と,対応する鍵を持っている必要があります。
GSS-API では,外部名,エクスポート名,内部名,メカニズム名の 4 つの形式の名前を使います。形式が異なる名前の間で,変換を行うための関数も用意されています。
エクスポート名は,標準フォーマットで表したオクテット文字列であり,GSS-API 関数によって生成され,GSS-API 標準の外部での名前比較に使われます。
内部名は不透過です。つまり,エラー・メッセジなどに名前を表示できないということです。この種類の名前は,GSS-API 内部のあらゆる目的のために使われます。Kerberos 5 メカニズムとの使い方の例としては,特定のユーザ名に属する信任状を見つけるなどがあります。
メカニズム名は,内部名のうち,メカニズムに固有の特殊なケースです。つまり,1 つのメカニズムに特有であることを意味します。Application Security SDK のように,1 つのメカニズムだけをサポートしている場合は,内部名とメカニズム名は同じです。
信任状の取得 -- 一方のアプリケーションが信任状を取得するために,その名前を GSS-API の内部フォーマットにインポートします。
セキュリティ・コンテキストの確立 -- 開始側は,セキュリティ・コンテキストを確立する相手を名前で識別します。
名前の比較 -- セキュリティ・コンテキストが確立された後,名前の比較が必要になることがあります。名前の比較は,正しい名前フォーマットが使われている限り,GSS-API 標準の内部と外部のどちらでも可能です。
GSS-API 標準の外部では,名前の比較にはエクスポート名を使う必要があります。たとえば受け入れ側は,開始した相手の名前を,アクセス制御リスト (ACL) と突き合わせて比較するなどが考えられます。 この比較を実行するための関数呼び出しは,この API には提供されていません。
アプリケーションまたはそれを使うユーザの名前は,GSS-API によって定義されている構文,構造,命名規則に従ったものではありません。アプリケーションの名前は,アプリケーション自身に依存しています。GSS-API は汎用であるため,異なるフォーマットで名前を提供できます。名前を表現するためのこれらの手法は, 名前タイプと呼ばれ,オブジェクト識別子 (OID) として渡されます。
アプリケーションは,その名前として GSS-API の省略時値を使うこともできます。省略時の名前を使う場合は,特定の名前を指定する必要がなく,OID を渡す必要もありません。この場合,名前は GSS-API の実装に依存します。
Kerberos のプリンシパル名は,次の形式をとります。name/instance@REALM
(/instance
および
@REALM
は省略可能)。/instance
を省略した場合は,空のインスタンスであるとみなされます。@REALM
を省略した場合は,省略時のレルムであるとみなされます。/
で区切ることによって,複数のインスタンスを指定できます。
Kerberos 5 メカニズムを使った信任状を取得するときに,アプリケーション名に GSS-API の省略時値が使われている場合, 使用される名前は,キャッシュがあれば,省略時の信任状キャッシュにある省略時の信任状の省略時のプリンシパルになります。キャッシュがなければ,省略時の名前は次のルールに従って決定されます。
ユーザ (つまり人間) の省略時のプリンシパルは,ユーザのログイン名です。
サービスの省略時のプリンシパルは,host/fqdn@REALM
です (fqdn
は,サービスが実行しているシステムの完全修飾ドメイン名,REALM
はシステムの省略時のレルム)。
HP では,セキュリティを高めるために,サービスには省略時のプリンシパル名
host/
を共有するのではなく,独自のプリンシパル名を付けることをお勧めします。たとえば,セキュアな FTP サービスは,プリンシパル名
ftp/fqdn@REALM
または
ftp@REALM
(fqdn
インスタンスを省略) を使うことが考えられます。セキュアな telnet サービスはプリンシパル名
telnet/fqdn@REALM
または
telnet@REALM
を使うことが考えられます。
アプリケーションが
gss_import_name()
を呼び出すときに,省略時の入力フォーマットを使用しなかった場合,アプリケーションは,その名前の解析方法を指定するオブジェクト識別子 (OID) を渡します。たとえば,GSS_KRB5_NT_HOSTBASED_SERVICE_NAME
OID は,service@host
という形式の名前の解析構文を指定します。このパラメータの
NT
は,名前タイプを表します。
8.3.2 信任状管理関数
信任状は,アプリケーションがその ID を証明するために使います。分散型アプリケーションの一方は,セキュリティ・コンテキストの開始と受け入れのために使われる信任状を取得する必要があります。
Kerberos 5 では,3 つのタイプの信任状があります。
初回チケット -- このタイプの信任状は,ユーザ・プリンシパルの初回認証の後,Kerberos セキュリティ・サーバから受け取ります。初回チケットは正しくはチケット・グランティング・チケット (または TGT) と呼ばれ,開始側のアプリケーションに必要になります。
サービス・チケット -- このチケットは,保護されているアプリケーションに,ユーザ・プリンシパルを使ってアクセスすることを許可するものです。サービス・チケットを受け取るには,TGT を取得しておく必要があります。
サービス鍵テーブル・エントリ -- プリンシパル・データベース中のプリンシパルと関連付けられた,秘密鍵のコピーです。この鍵は,データベース管理プログラムを使って,プリンシパル・データベースからサービス鍵テーブル・ファイルへ抽出しなければなりません。サービス鍵テーブル・ファイルの鍵は,初回チケットの取得の代わりに,受け入れ側のアプリケーションによって使われます。
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 エクステンション関数と呼ばれる追加の関数を提供しています。この関数を使って,次のような各種のタスクを実行できます。
コンテキストの開始前に,初回信任状を取得する。これは,ユーザから秘密情報を取得するプログラム・プロンプトを通じて,または,開始側のアプリケーションにも開始側のホスト上のサービス鍵テーブル・ファイルに格納されている秘密鍵の使用を許可することによって行われます。
スマート・カード・デバイスから公開鍵信任状を取り出して,TGT を取得する。
転送可能,または延長可能など,特定のオプションを付けて初回信任状を要求する。
信任状の存続期間を延ばすために,有効期限前に信任状を延長する。
不要になったら信任状に関連付けられているバッファを解放する。
これらの特殊な 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 暗号化を使ってメッセージを暗号化できるようにするには,次の条件が満たされている必要があります。
ActiveTRUST Security Server が DES3 向けに設定されていること。
開始側と受け入れ側のアプリケーション用のプリンシパルが,プリンシパル・データベースの中に同じ DES3 鍵を持っていること。
開始側のプリンシパルが DES3 を使って TGT を取得していること。
開始側のアプリケーションが,セキュリティ・コンテキストの開始時に DES3 の使用を指定していること。
注意
単一のセキュリティ・コンテキストに対して複数の暗号化システムは許可されていません。どれか 1 つだけを使う必要があります。
関数
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()
を使って信任状の期限を延長できます。信任状の期限を延長するためには,初回チケットはセキュリティ・サーバから延長可能属性フラグを付けて要求されたものでなければなりません。
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 の実装は,使用されているセキュリティ・メカニズムに依存します。
以下の節では,オプションのセキュリティ手段について説明します。
チャネル・バインディングは,偽装者によって盗聴されたコンテキスト確立トークンが再使用される可能性があるときに,その有効範囲を限定することによって,コンテキストの確立時に,分散アプリケーション同士の認証の質を高めるために使われます。 チャネル・バインディングは,分散アプリケーションによって指定される追加のデータ項目をセキュリティ・コンテキストに付加することによってこれを実現します。
チャネル・バインディングは,次の 2 つの部分で構成されます。
アドレス情報
オプションのアプリケーション・データ
アドレス情報は,開始側と受け入れ側のどちらの場合もアドレス・タイプとアドレス値からなります。アドレス・タイプは,アドレス値のバッファに格納されているプロトコルのタイプを示します。アドレス値は,開始側または受け入れ側の実際のアドレスです (アドレス・タイプに対応したフォーマットで表現されます)。
Kerberos 5 では,KDC は,サービス・チケットを作成するときにクライアントのアドレスをエンコードしてチケットに埋め込みます。
開始側がそのチケットを受け入れ相手に提示し,チャネル・バインディングが
gss_accept_sec_context()
に渡されると,GSS-API はこのチケットにあるクライアント・アドレスが,チャネル・バインディングにある開始側のアドレスと一致しているかどうかをチェックします。ただしこのチェックは,TCP 接続を使っている場合は行われません。
注意
チャネル・バインディングのデータ構造体のもう 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_FLAG
と
GSS_C_INTEG_FLAG
を使って,機密性と完全性の要件を指定します。
8.3.3.3.3 リプレイ検出
リプレイ検出とは,注目しているトークンまたはメッセージが以前に送信されたものかどうかを,一方のアプリケーションがチェックするというものです。
開始側はそのメッセージを,メッセージ・リプレイ・キャッシュと突き合わせてチェックするよう指定できます。これは,メッセージが以前に送信されたメッセージの繰り返しかどうかを判別するために使います。
メッセージがキャッシュされるにつれてより多くのリソースをキャッシュに割り当てるため,リプレイ・キャッシュは必要に応じて拡張します。ただしキャッシュ・サイズには上限があるので注意してください。リプレイ・キャッシュが一定のサイズに達した場合,新しいエントリを 1 つ追加するたびに,古いエントリが 1 つずつ解放されます。キャッシュ全体に関連付けられているリソースは,セキュリティ・コンテキストが削除されるときに解放されます。
注意
Kerberos 5 でサポートされているリプレイ・キャッシュは,2 種類あります。1 つはメッセージ・リプレイ・キャッシュで,コテキスト確立時のパラメータの設定によって制御される,メモリ・ベースのキャッシュです。もう 1 つは認証リプレイ・キャッシュで,UNIX 環境変数で設定が制御されるファイル・ベースのキャッシュです。
開始側は,メッセージの順番を決めて (または番号付けして),すべてのメッセージが受信されたかどうかと,それが送信された順番で受信されたかどうかをチェックするように指定できます。メッセージの順序付けは,リプレイ検出機能も提供します。
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()
gss_wrap()
と
gss_unwrap()
アプリケーションは,署名をデータとは切り離して送信したい場合は,gss_get_mic()
と
gss_verify_mic()
を使用できます。
たとえば,PGP メール (Pretty Good Privacy) では,メッセージが最初に送信され,その後に署名が送信されます。署名がチェックされ,その次に結果が表示され,送信中にメッセージが変更されなかったことを示します。
注意
これらの関数は,GSS-API V2 で始めて導入されたものです。以前のリリースでは,関数
gss_sign()
,gss_verify()
,gss_seal()
,gss_unseal()
を使用していました。
アプリケーションがこれらのメッセージ関数を呼び出すときには,メッセージに適用される完全性または機密性のアルゴリズムを識別する QOP を指定します。Kerberos 5 では,次の 6 つのアルゴリズムが QOP に対して定義されています。
注意
同じ QOP が指定されていると,
gss_get_mic()
とgss_wrap()
は署名を同じ方法で計算します。
この節では,アプリケーションの保護に使用できる,その他のサポート関数の一覧をまとめます。
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 メカニズム・セットのポインタを取得します。 |
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 の関数を使用する必要があります。
以降の節では,Application Security SDK を使ってカスタム・アプリケーションを作成する際に,セキュリティに関して考慮すべき点と,推奨事項を取り上げます。
8.4.1 マルチ・スレッディング
gss_acquire_cred()
gss_add_cred()
csf_gss_acq_user()
csf_gss_inq_user()
csf_gss_release_user()
csf_gss_renew_cred()
これらの関数はすべて,初回チケットの取得に関するものであるため,アプリケーションのマルチ・スレッドの部分での使用は避けてください。
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 つがあります。
ユーザ・プリンシパルは,プリンシパル・データベースにその秘密鍵 (パスワード) が格納されています。この鍵は,チケット・グランティング・チケット (TGT) を取得するのに使われます。ユーザ・プリンシパルが,同じパスワードを持つ複数の TGT を取得した場合は,有効期限が切れる前にパスワードを変更する必要があります。
各 TGT にはセッション鍵が含まれています。この鍵は,サービス・チケットの取得と,チケットの延長に使われます。ユーザ・プリンシパル,またはクライアントや他のサービスの役割を果たすサービス・プリンシパルが,同じ TGT を持つ複数のサービス・チケットを取得した場合は,有効期限が切れる前に,新しい TGT を取得する必要があります。
TGT の存続期間を短くすることもできます。csf_gss_acq_user()
に存続期間を指定すると,この関数はこれを最短の値として扱います。存続期間を過ぎた TGT を使わないよう保証するには,CSF_GSS_C_ACQ_USER_OPT_ALWAYS_FETCH
オプションを使います。このオプションは
csf_gss_acq_user()
に,指定された存続期間を持つ新しい TGT を KDC から取得するように強制します。
各サービス・チケットにはセッション鍵が含まれています。この鍵は,セキュリティ・コンテキストの確立に使われます。ユーザ・プリンシパル,または別のサービスに対するクライアントの役割を果たすサービス・プリンシパルが,同じサービス・チケットを使う複数のセキュリティ・コンテキストを確立した場合,サービス・チケットの有効期限が切れる前にサービス・チケットを交換する必要があります。サービス・チケットは一般に,これを取得するために使った TGT と同時に有効期限が切れます。有効期限が切れる前にサービス・チケットを交換する唯一の方法は,新しい TGT を取得することです。これによってサービス・チケットが格納される信任状キャッシュが再初期化されます。
サービス・プリンシパルは,プリンシパル・データベースとサービス鍵テーブル・ファイルにも秘密鍵が格納されています。セキュリティ・コンテキストを受け取るときには,この鍵を使ってデータを暗号化します。ユーザ・プリンシパルがサービス・プリンシパルのために取得する各サービス・チケットには,この暗号化されたデータが含まれています。
さらに,他のサービスに対するクライアントの役割を果たすサービス・プリンシパルは,その秘密鍵を使って TGT を取得します。サービス・プリンシパルの秘密鍵は,通常は使用頻度が高いため,頻繁に変更する必要があります。これは,HP が,サーバ・アプリケーション間でサービス・プリンシパルの共有をお勧めしない,1 つの理由です。
各セキュリティ・コンテキストにはセッション鍵が含まれています。この鍵は,メッセージを保護するときに使われます。セキュリティ・コンテキストに期限はありません。1 つのセキュリティ・コンテキストを使って大量のデータを交換する場合や,1 回の対話が長時間に及ぶ場合は,セキュリティ・コンテキストを定期的に削除して新しいセキュリティ・コンテキストを確立する必要があります。
セキュリティ・コンテキストのセッション鍵以外は信任状キャッシュまたはサービス鍵テーブル・ファイルに格納されるため,信任状キャッシュとサービス鍵テーブル・ファイルは保護しておく必要があります。
8.4.6 マルチ・スレッド関数
次の Application Security SDK 関数は,スレッド・セーフではありません。
gss_acquire_cred()
gss_add_cred()
csf_gss_acq_user()
csf_gss_inq_user()
csf_gss_release_user()
csf_gss_renew_cred()
これらの関数はすべて,初回チケットの取得に関するものであるため,マルチ・スレッド環境での使用は避けてください。プログラムがスレッドを作成する前に信任状が取得されると,その信任状はマルチ・スレッド型の開始側または受け入れ側に渡されることがあります。
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 存続期間と延長の設定に関する一般的な規則
チケットを延長する場合,延長後の存続期間は次の規則に従って決まります。
チケットは,延長可能チケット属性を持っている場合に限り延長できます。
延長可能チケットは,チケットの存続期間中の任意の時点で延長できます。
期限の切れたチケットは延長できません。
延長可能チケットは,延長期限が切れるまで,複数回延長できます。
延長されたチケットは,延長可能チケットの最初の存続期間と同じ存続期間を持ちます。たとえば,チケットの存続期間が 30 分で,延長期限が 50 分だとします。このとき,15 分経った後でチケットが延長されたとします。このような場合,延長可能チケットの存続期間は,やはり 30 分となります。
延長期限の残りが,元のチケットの存続期間よりも短いと,チケットが延長されるときに規則が変更されます。延長されたチケットの有効期限は,元のチケットが発行されたときの延長期限を過ぎることはできません。前述の例で,このチケットを延長可能チケットとして最初に取得した後,25 分経った後で,チケットの有効期限が切れる前にチケットを延長したとします。延長後のチケットはこの後,30 分ではなく 25 分間有効になります (25 + 25 = 50 分)。延長可能であり,延長されたチケットが有効となる合計時間は,元のチケットに設定されている最大延長期限以下でなければなりません。
延長可能 TGT を指定して取得された代理 (サービス) チケットは,延長可能オプションとその延長期限を継承し,TGT と共に延長されます。これは,サービス・チケットはそれを取得するために使った TGT の属性を (できる限り) 継承するという,全般的な考え方に従ったものです。
チケットの延長に,パスワードは必要ありません。
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 は次のとおりです。
DES3 の場合は
CSF_GSS_KRB5_INTEG_C_QOP_DES3_MD5
DES の場合は
GSS_KRB5_INTEG_C_QOP_DES_MD5
機密性の QOP は次のとおりです。
DES3 の場合は
CSF_GSS_KRB5_CONF_C_QOP_DES3
DES の場合は
GSS_KRB5_CONF_C_QOP_DES
使用される省略時の QOP は,セキュリティ・コンテキストが確立されたときに選択された暗号化タイプに依存します。
注意
DES3 の QOP には移植性がありません。この QOP を指定すると,アプリケーションは Kerberos 5 メカニズム専用になります。
いくつかの 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 は,次の表に示すように,アプリケーションの保護に使われる標準の関数と独自の関数からなります。
gss
で始まる関数呼び出しは,GSS-API 標準です。
cs
または
csf
で始まる関数呼び出しは,HP 固有のエクステンション関数です。
関数 | 説明 |
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()
を見てメッセージ・サイズの上限を調べます。 |
各関数はリファレンス・ページで,次の項目を使って説明されています。
使用目的
関数の用途の簡単な説明。
構文
使用可能なパラメータと,コマンド行引数の完全なリスト。
入力パラメータは,アプリケーションから Application Security SDK に渡される引数です。
出力パラメータは,Application Security SDK からアプリケーションに渡される引数です。
入力パラメータが省略可能な場合,アプリケーションはそのパラメータに対する省略時の値を渡すことができます。
出力パラメータが省略可能な場合,アプリケーションにとってそのパラメータは必須ではないため,Application Security SDK は値を戻す必要がありません。このことを示す場合は,出力パラメータに
NULL
を使用してください。
注意
メモリ・リークを避けるために,アプリケーションは常に,戻された値に関連付けられている記憶域を使用後に解放する必要があります。
パラメータ
関数に渡され,関数から戻される一連の変数。2 進値の場合は,
論理 1 は真を表します。
論理 0 は偽を表します。
NULL
に初期設定されているパラメータは,ゼロになることもあります。
説明
関数の定義,使用目的,使用上のヒント。
移植性に関する考慮事項
HP によって保護されたアプリケーションを,別の環境に移植するための考慮事項。
リターン値
関数によって戻されるメジャー・ステータス・コードの一覧。
関連項目
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 |
Application Security SDK では,関数呼び出しとのデータの受け渡しに,次のデータ構造体を使います。
gss_channel_bindings_t
-- セキュリティ・コンテキストの通信チャネルを識別します。
gss_buffer_t
-- 関数呼び出しの入力データまたは出力データを指定します。
csf_gss_opts_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()
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()
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
に初期設定します。
次の関数呼び出しは,オプションの構造体を使います。
以下は,アプリケーションのデバッグとトラブルシューティングに役立てるための情報です。
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() |
補足的な情報のビットが設定されているかどうかを示します。 |
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 |
関連項目
以下に,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 |
期待されているメッセージごとのトークンが受信されていません。 |
以下に,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
に
@
がありません。 |
Kerberos 固有のエラー・コードは,マイナー・エラー・コードです。
ステータス・コードのテキスト表現を取得するには,関数
gss_display_status()
を使います。
戻されるエラー・コードの完全なリストを見るには,...\include\csf\sts
および
...\include\csfc5\sts
ディレクトリにあるヘッダ・ファイルを参照してください。