認証プロトコルのフレームワーク

ればならない。コマンドは、初期レスポンスを与えるパラメータをオプション として持つ必要がある。

3. 認証プロトコル交換が実施されるようにする手法の規定。「どのようにチ ャレンジ・レスポンスが符号化されているか」、「どのようにサーバーが交換の 成功又は失敗を示すか」、「どのようにクライアントが交換を中止するか」など を含む。

4. 双方向において、すべてのネゴシエーションしたセキュリティ層を有効 とさせるかを指定する。

5. 「どのように認可 ID がクライアントからサーバー宛てに送られるか」

について仕様の解釈を規定する。

・登録手順

本仕様ではIANAに登録する手順も定めている。新しいSASLメカニズムを 登録する場合には、登録テンプレートに必要事項を記載してIANAに送る。

本仕様では以下に示すSASLメカニズムを規定している。

1. Kerberos v4  メカニズム名 ”KERBEROS_V4”

2. GSSAPI  メカニズム名 “GSSAPI”

3. S/Key  メカニズム名 SKEY”

RFC2444 The One-Time-Password SASL Mechanismでこの仕様を更新 している。

4. 外部メカニズム  メカニズム名 EXTERNAL”

例えばIPsecやTLSが外部メカニズムに指定できる。

SASLでは「3.1ネットワーク認証プロトコル」で述べる以下のメカニズム が登録された。

・The One-Time-Password SASL Mechanism  RFC2444  （ワンタイムパ スワード認証）

・ISO/IEC 9798-3 Authentication SASL Mechanism  RFC3164  （公開鍵 方式認証）

・SASLのメカニズムの例

ここにS/KeyのSASLメカニズムの例を示す。この例ではIMAP4のプロト コル上に実装したものでS:  C: はそれぞれサーバー、クライアントで送られ たラインを示す。”+”やbase64でエンコードしたチャレンジ・レスポンスは

IMAP4の仕様によるものでSASLで定めたものではない。

認証成功の例

S: * OK IMAP4 Server //サーバーの準備OK

C: A001 AUTHENTICATE SKEY //クライアントがSKEYメカニズムを要求 S: + //サーバーがクライアントにパラメータ要 求

C: bW9yZ2Fu //クライアントがパラメータ送信

S: + OTUgUWE1ODMwOA== //サーバーがチャレンジ送信 C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA== //ハッシュを応答 S: A001 OK S/Key authentication successful //認証成功

認証失敗の例

S: * OK IMAP4 Server

C: A001 AUTHENTICATE SKEY S: +

C: c21pdGg=

S: + OTUgUWE1ODMwOA== //サーバーがチャレンジ送信

C: BsAY3g4gBNo= //クライアントの誤った応答

S: A001 NO S/Key authentication failed //認証失敗

また、SASLではAnonymousログインもサポートしている。

RFC2245：Anonymous SASL Mechanism

今までの anonymous ログインでは平文テキストパスワードを使っていたが、

IETFでは平文によるログインコマンドを許可しないので、このRFC2245が 開発された。

3.1.1.2  GSS-API 汎用セキュリティサービスAPI v2

  （ Generic Security Service Application Program Interface Version 2   RFC2743）

GSS-API[107] は汎用的な形式で規定したセキュリティサービスを提供する

APIで、アプリケーションにソースレベルの移植性を提供する。この仕様は用 いるメカニズムやプログラム言語に独立であるので、他の言語バインドの仕様 で補完することになる。GSS-API v2はRFC2078として規定されたが、本 RFC2743はRFC2078に代わるものである。対応するC言語バインドは

RFC2744として規定されている。

GSS-APIはセキュリティサービスとして強いセキュリティのためにクレデ

ンシャルの扱いとセッションにおける認証や完全性及びメッセージの秘匿の機 能を定義している。GSS-APIを用いたアプリケーションはローカルな実装で用 意されたトークンを受け入れ、それをリモートシステムの相手に転送する。相 手は受信したトークンをGSS-APIで検証することになる。GSS-APIは以下の 特徴がある。

・メカニズム独立：GSS-APIは用いるセキュリティメカニズムから独立して おり、対称鍵や公開鍵暗号技術にも実装できる。対称鍵に適用したものにはThe Kerberos Version 5 GSS-API Mechanism RFC1964があり、公開鍵に適用し たものにThe Simple Public-Key GSS-API Mechanism (SPKM) RFC2025 がある。

・プロトコル環境独立：GSS-APIは用いるプロトコルに独立で各種の通信プ ロトコルに適用できる。

・プロトコル・アソシエーション独立：GSS-APIは通信プロトコル･アソシ エーションから独立しており、各種の呼出しプロトコルの方法に適用できる。

・実装環境への適用性：GSS-APIは特定のTrusted Computing Base（TCB） に依存しない。GSS-APIはTCBにもTCBでないものにも適用できる。

GSS-APIはクライアントとサーバー間の認証のためのセキュリティコンテ

クストの初期化と、以後のクライアントとサーバー間のメッセージの完全性確 保や秘匿の操作を分離している。以下に簡単なGSS-APIの認証の例を述べる。

・クライアントはGSS_Init_sec_context()を呼出し、サーバーに対象名

（targ_name）で識別されたセキュリティコンテクストを確立する。

・引き続き双方向認証の準備も行うことができる。GSS_Init_sec_context() はoutput_tokenを返し、これをサーバーに送信する。

・サーバーは受信したトークンをGSS_Accept_sec_context()の入力とし、ク ライアントの認証を検証する。

・以後メッセージの完全性や秘匿を行うセッションが続く。

GSS-APIの構成

ここではGSS-APIを構成する要素と概念について述べる。

・クレデンシャル

クレデンシャルは認証に必要な情報であり、メカニズムによって暗号鍵や公 開鍵が含められる。クレデンシャルはローカルに管理され、その使用に当たっ てはクレデンシャルのハンドルを用いる。

・トークン

トークンはGSS-APIのクライアント/サーバー間で転送されるデータ要素で あり、2つのクラスがある。コンテクストレベルのトークンはピア間でセキュ リティコンテクストを確立する（認証する）ために交換される。続くメッセー ジ毎のトークンは通信するデータの完全性や秘匿をサポートするために用いら れる。

・セキュリティコンテクスト

セキュリティコンテクストはピア間でローカルに保持しているクレデンシャ ルを用いて確立する（認証する）。GSS-APIは通信プロトコルに独立なので様々 な実装が可能である。セキュリティコンテクストは明示的なセッションがリリ ースされている間は保持され、セッションが開放されると、セキュリティメカ ニズムで使用した暗号データは消滅する。

・メカニズムタイプ

GSS-APIの基で使用するセキュリティメカニズム（対称鍵か公開鍵か）はピ

ア間で認識される必要がある。使用するメカニズムはネゴシエートすることに なるが、デフォルトのメカニズムを持つことが推奨されている。

GSS-APIの認証に用いるためのクレデンシャルの取得は具体的なメカニズ

ムで異なる。クレデンシャルを取得するにはGSS_Acquire_cred()の呼出しを

行うが、Kerberos v5で扱うクレデンシャルは対称鍵を扱い、公開鍵方式では

X.509証明書を扱う。以下のメカニズムは「3.1ネットワーク認証プロトコル

標準」の節で概説する。

・対称鍵方式のKerberos v5についてはRFC1964 The Kerberos Version 5 GSS-API Mechanismがある。

・公開鍵方式のISO／IEC9798-3で定めたメカニズムを使うGSS-APIの実 装がSPKM(Simple Public Key Mechanism)で規定された。

・SASLメカニズムで公開鍵方式認証ISO／IEC9798-3を規定したものが ISO/IEC 9798-3 Authentication SASL Mechanism RFC3163である。

  GSS-APIは言語独立にアプリケーションからの呼出し手順やインタフェ

ースを定めているが、具体的にC言語にバインドした仕様がRFC2744で規定 されている。