ネットワーク WG
Request for Comments: 2222
分類:スタンダードトラック

J. Myers
Netscape Communications
1997年10月

English

SASL(シンプル認証とセキュリティ層)
(Simple Authentication and Security Layer (SASL))

このメモの位置づけ

本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを規定するとともに、それを改良するための検討や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」(STD 1) の最新版を参照すること。このメモの配布に制限はない。

著作権表記

Copyright (C) The Internet Society (1997). All Rights Reserved.

目次

1. 要旨

2. 本書の構成
2.1. 本書の読み方
2.2. 本書において使われる用語法
2.3. 例示

3. 導入と概要

4. 要件のプロファイリング

5. 固別の論点
5.1. クライアントが最初にデータを送る
5.2. サーバーが追加的データとともに成功を返す
5.3. 複数の認証

6. 登録手順
6.1. SASL メカニズム登録についてのコメント
6.2. 登録された SASL メカニズムリストの在処
6.3. 変更コントロール
6.4. 登録テンプレート

7. メカニズム規定
7.1. Kerberos v4 メカニズム
7.2. GSSAPI メカニズム
7.2.1 認証プロトコル交換のクライアント側
7.2.2 認証プロトコル交換のサーバー側
7.2.3 セキュリティ層
7.3. S/Key メカニズム
7.4. 外部メカニズム

8. 参考文献

9. セキュリティについての考慮事項

10. 著者のアドレス

補遺 A. SASL のトランスポートセキュリティとの関係

著作権表記全文

 

1. 要旨 English

本書は、コネクションベースのプロトコルに認証サポートを追加するための手法について記述する。この仕様を利用するために、プロトコルは、サーバーに対してユーザを識別し認証するためのコマンドと、オプションとして以降のプロトコルの相互作用の防護を交渉するためのコマンドを含む。セキュリティ層が、その利用が交渉された場合、プロトコルとコネクションの間に挿入される。本書は、プロトコルがどのようにそのようなコマンドを仕様としているかを記述し、コマンドによって利用されるいくつかのメカニズムを規定し、コネクション上において交渉されたセキュリティ層を運ぶことに利用されるプロトコルを規定する。

 

2. 本書の構成 English

2.1. 本書の読み方 English

本書は、2つの異なる読者層のために書かれている。プロトコル設計において認証をサポートするためにこの仕様を利用するプロトコル設計者と、この仕様を利用するプロトコルのためクライアント/サーバーの実装者である。

「導入と概要」、「要件のプロファイリング」および「セキュリティについての考慮事項」の各章は、プロトコル設計者が特定のプロトコルにおける利用のためにこの仕様をプロファイリングする際に、理解し対応する必要がある論点を扱う。

この仕様を使うプロトコルの実装者は、本書中の情報に加えて、プロトコル固有のプロファイリング情報を必要とする。

2.2. 本書において使われる用語法 English

例示において、"C:"と"S:"は、それぞれ、クライアントとサーバーによって送られたラインを示す。

本書中のキーワード"MUST", "MUST NOT", "SHOULD", "SHOULD NOT" および "MAY" は、「RFC において要請の程度 を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」 [RFC2119] に規定されているように解釈されるべきものである。

2.3. 例示 English

本書中の例示は、この仕様の IMAP プロファイル [RFC 2060] のためのものである。チャレンジ・レスポンスの base64 符号化やレスポンスの前の"+ "は、IMAP4 プロファイルの一部であり、SASL 仕様自体の部分ではない。

 

3. 導入と概要 English

SASL(Simple Authentication and Security Layer)は、コネクションベースのプロトコルに認証サポートを追加するための手法である。この仕様を利用するために、プロトコルは、サーバーに対してユーザを識別し認証するためのコマンドと、オプションとして以降のプロトコルの相互作用のためにセキュリティ層を交渉するためのコマンドを含む。

コマンドは、SASL メカニズムを識別する、要求されたアーギュメントを持つ。 SASL メカニズムは、文字列によって命名される。(文字列は、)長さが 1文字から 20文字までであり、大文字、ディジェット、ハイフン、かつ/または、アンダースコアから成る。 SASL メカニズム名は、IANA に登録されなければならない。新しい SASL メカニズムを登録するための手順は、「登録手順」の章において提供される。

サーバーが要求されたメカニズムをサポートする場合、認証プロトコル交換を開始する。これは、要求されたメカニズムに固有な一連のサーバーチャレンジとクライアントレスポンスから成る。チャレンジ・レスポンスは、メカニズムによって任意の長さのバイナリトークンとして規定される。プロトコルのプロファイルは、次に、どのようにこれらのバイナリトークンがコネクション越しの転送のために符号化されるかを仕様とする。

認証コマンド、もしくは何らかのクライアントレスポンスを受け取った後、サーバーは、チャレンジを発行し、失敗を示すか、または、完了を示すことができる。プロトコルのプロファイルは、どのようにサーバーが上記のどちらを行っているかを示すかを仕様とする。

チャレンジを受け取った後、クライアントは、レスポンスを発行するか、または、交換を中止することができる。プロトコルのプロファイルは、どのようにクライアントが上記のどちらを行っているか示すかを仕様とする。

認証プロトコル交換において、メカニズムは、認証を行い、(しばしば userid として知られる)認可 ID をクライアントからサーバー宛てに送付し、メカニズム固有のセキュリティ層の利用を交渉する。セキュリティ層の利用が合意された場合、次に、メカニズムは、また、両者が受け取ることができる最大 cipher-text バッファサイズを規定もしくは交渉しなければならない。

送付された認可 ID は、クライアントの認証クレデンシャル中の ID とは異なる可能性がある。このことは、プロキシサーバーが自身のクレデンシャルを使いつつ、プロキシ(代理)している ID のアクセス権限を要求して認証するようなことを許容する。あらゆるメカニズムにおいて、空の文字列の認可 ID を送付することは、サーバーにクライアントの認証クレデンシャルから認可 ID を引き出すことを求めることになる。

セキュリティ層の利用が交渉された場合、これは、コネクション上で送られる以降のすべてのデータに適用される。セキュリティ層は、クライアントによって送られたデータについての認証交換の最後のレスポンス、および、サーバーによって送られたデータについての完了表示の直後に有効となる。一度セキュリティ層が有効になると、プロトコルストリームは、セキュリティ層によって cipher-text のバッファの中に送られる。各バッファーは、ネットワークバイト順に、先頭に 4オクテットのフィールドを付加されて、下記のバッファの長さとなるオクテットのストリームとしてコネクション上を転送される。cipher-text バッファの長さは、他方によって規定もしくは交渉された最大サイズより長くてはならない。

 

4. 要件のプロファイリング English

この仕様を利用するために、プロトコル規定は、次の情報を提供しなければならない。:

1. サービス名。IANA の「サービス」要素のレジストリから選択され、GSSAPI ホストベースサービス名については [RFC 2078] から選択される。

2. 認証プロトコル交換を開始するためのコマンドの規定。このコマンドは、パラメータとして、クライアントによって選択されたメカニズム名を持たなければならない。

コマンドは、初期レスポンスを与えるパラメータをオプションとして持つ必要がある(SHOULD)。このオプションとしてのパラメータは、先にデータを送るクライアントをもつように規定されたメカニズムを使うとき、クライアントに同道巡りを避けることを許容する。この初期レスポンスがクライアントによって送られ、選択されたメカニズムが初期チャレンジで開始するサーバーを持つように規定されているとき、コマンドは失敗する。詳細情報については、本書の 5.1 を見よ。

3. 認証プロトコル交換が実施されるようにする手法の規定。「どのようにチャレンジ・レスポンスが符号化されているか」、「どのようにサーバーが交換の成功または失敗を示すか」、「どのようにクライアントが交換を中止するか」、「どのように交換手法がプロトコルにおけるあらゆるライン長制限と相互作用するか」を含む。

4. 双方向において、あらゆる交渉されたセキュリティ層が有効となり始めるオクテットの識別。

5. 「どのように認可 ID がクライアントからサーバー宛てに送られるか」について仕様が解釈される。

 

5. 固別の論点 English

5.1. クライアントが最初にデータを送る English

メカニズムには、認証プロトコル交換における最初の送信データがクライアントからサーバー宛てであることを仕様とするものがある。

プロトコルのプロファイルが初期クライアントレスポンスを含む認証プロトコル交換を開始するコマンドを許容する場合、このパラメータは、このようなメカニズムとともに利用される必要がある(SHOULD)

最初のクライアントレスポンスパラメータが与えられない場合、あるいは、プロトコルのプロファイルが初期クライアントレスポンスを含む認証プロトコル交換を開始するコマンドを許可しない場合、サーバーは、データを持たないチャレンジを発行する。クライアントのこのチャレンジに対するレスポンスは、こうして、初期クライアントレスポンスとして使われる。(サーバーは、こうして次のチャレンジを送ることに進み、完了を示すか、あるいは失敗を示す。)

5.2. サーバーが追加的データとともに成功を返す English

メカニズムには、サーバーチャレンジデータが交換の成功としての完了の表示とともにクライアント宛てに送られることを規定するものがある。例えば、このデータは、サーバーをクライアント宛てに認証する。

プロトコルのプロファイルが、このサーバーチャレンジが成功表示と共に返されることを許容しない場合、サーバーは、成功としての完了の表示なしにサーバーチャレンジを発行する。クライアントは、次に、データなしで反応する。この空のレスポンスを受け取った後、サーバーは、成功としての完了を示す。

5.3. 複数の認証 English

プロトコルのプロファイルによって他に表明されない限り、成功となる唯一の SASL 交渉は、プロトコルセッションにおいて発生する可能性がある。この場合、一度、認証プロトコル交換が成功として完了したら、以降の認証プロトコル交換を開始する試みは失敗する。

プロファイルが複数の SASL 交渉成功が発生することを明示的に許容する場合、複数のセキュリティ層が同時に有効となる可能性はない。セキュリティ層が有効であり、以降の SASL 交渉がセキュリティ層を選択しない場合、当初のセキュリティ層は、有効として残る。セキュリティ層が有効であり、以降の SASL 交渉が 2番目のセキュリティ層を選択する場合、2番目のセキュリティ層が最初のものを置き換える。

 

6. 登録手順 English

SASL メカニズムの登録は、6.4  にあるテンプレートを埋めて、それを iana@isi.edu 宛てに送ることによって行われる。IANA は、明らかに偽の登録を却下する権利を持つが、登録フォームにおけるハマグリ(項目の比喩的表現)のレヴューは行わない。

SASL メカニズムについて、命名慣行はない。; SASL メカニズム名の文法に適合するあらゆる名前が登録できる。

登録手順が求めるものではないが、SASL メカニズムの著者には、可能である限り、コミュニティのレヴューとコメントを求めることが強く勧められる。著者は、提案されたメカニズム の仕様をインターネットドラフトとして投稿することにより、コミュニティのレヴューを求めることができる。広域利用のために意図された SASL メカニズムは、適切であるとき、通常の IETF プロセスを通じて標準化される必要がある。

6.1. SASL メカニズム登録についてのコメント English

登録された SASL メカニズムについてのコメントは、まず、メカニズムの「オーナー」に送られる必要がある。コメントの送信者は、オーナーと連絡をとる合理的な試みの後、IANA に SASL メカニズム登録自体に彼らのコメントを添付することを要求できる。 IANA がこれを提供する場合、コメントは、SASL メカニズム登録自体と共にアクセス可能とされる。

6.2. 登録された SASL メカニズムリストの在処 English

SASL メカニズム登録は、anonymous FTP ディレクトリ(ftp://ftp.isi.edu/in-notes/iana/assignments/sasl-mechanisms/)に投稿され、すべての登録された SASL メカニズムは、定期的に発行される "Assigned Numbers" RFC [currently STD 2, RFC 1700] 中に掲載される。SASL メカニズム記述や他の支援材料も、それを"rfc- editor@isi.edu"宛てに送ることによって情報提供(Informational)RFC として公表することができる。(「RFC を書く人のために(the instructions to RFC authors)」[RFC 2223] に従っていただきたい。)

6.3. 変更コントロール English

一度、SASL メカニズム登録が IANA によって公表されたら、著者は、その規定について変更を要求する可能性がある。変更要求は、登録要求と同じ手順に従う。

SASL メカニズムのオーナーは、SASL メカニズムについての責任を IANA に通知することによって他者もしくは他の機関に渡すことができる。;

このことは、検討やレヴューなしに行うことができる。

IESG は、SASL メカニズムについての責任を再指名する可能性がある。このことの最も卑近な事例は、登録の著者が死亡したり連絡を取れなくなったり、あるいは、そうしなければコミュニティにとって重要な変更ができないメカニズムに対して変更を可能にすることであろう。

SASL メカニズム登録は、削除されてはいけない。;もはや利用するのに適切ではないメカニズムについては、「意図された用途(intended use)」フィールドについての変更によって「廃止(OBSOLETE)」を宣言することができる。; このような SASL メカニズムは、IANA によって公表されるリストにおいて明確に印が付けられる。

IESG は、IETF スタンダードトラックに載っているすべての SASL メカニズムのオーナーであると見なされる。

6.4. 登録テンプレート English

To: iana@iana.org
Subject: Registration of SASL mechanism X

SASL mechanism name:

Security considerations:

Published specification (オプションとして推奨):

Person & email address to contact for further information:

Intended usage:

(COMMON、LIMITED USE もしくは OBSOLETE のひとつ)

Author/Change controller:

(著者が興味深いと考えるあらゆる他の情報は、この行の下に追記される可能性がある。)

 

7. メカニズム規定 English

次のメカニズムが、ここに規定されている。

7.1. Kerberos v4 メカニズム English

Kerberos v4 についてのメカニズム名は、"KERBEROS_V4"である。

最初のチャレンジは、ネットワークバイト順に 32ビットの乱数から成る。クライアントは、Kerberos チケットとプリンシパルについての認証子"service.hostname@realm"に反応する。この"service"は、プロトコルのプロファイルにおいて仕様とされたサービス名であり、"hostname"は、サーバーのホスト名の最初の部分をすべて小文字にしたものであり、この"realm"は、サーバーの Kerberos レルムである。Kerberos 認証子の中に含められた暗号化されたチェックサムフィールドは、サーバーが提供したチャレンジをネットワークバイト順に含む。

チケットと認証子を復号し検証する際に、サーバーは、含まれているチェックサムフィールドが、当初サーバーが提供した 32ビットの乱数と等しいことを検証する。検証が成功となるために、サーバーは、チェックサムに 1 を足し、8オクテットのデータを作成しなければならない。最初の 4オクテットは、ネットワークバイト順にインクリメントしたチェックサムを含み、5番目のオクテットは、サーバーによってサポートされているセキュリティ層を仕様とするビットマスクを含み、6番目から 8番目までのオクテットは、ネットワークバイト順に、サーバーが受け取ることができる最大 cipher-text バッファサイズを含む。サーバーは、DES ECB モードを使って、セッション鍵中の 8オクテットのデータを暗号化し、2番目のチャレンジにおいて、その暗号化されたデータを発行しなければならない。暗号化されていないデータの最初の 4オクテットが以前に送ったチェックサムに 1を加えたものと等しい場合、クライアントは、サーバーを認証されたものとする。

クライアントは、データを作成しなければならない。最初の 4オクテットは、ネットワークバイト順に当初サーバーが発行したチェックサムを含み、 5番目のオクテットは、選択されたセキュリティ層を指定するビットマスクを含み、 6番目から 8番目までのオクテットは、ネットワークバイト順に クライアントが受け取ることができる最大 cipher-text バッファサイズを含み、残りのオクテットは、認可 ID を含む。クライアントは、次に、データの長さが 8オクテットの倍数となるようにするために、1 からto 8 までの値 0 のオクテットを付加しなければならない。クライアントは、次に、DES PCBC モードを使って、データをセッション鍵で暗号化し、暗号化されたデータで反応しなければならない。サーバーは、データを複合し、含まれているチェックサムを検証する。サーバーは、Kerberos チケットにおいて識別されたプリンシパルがその認可 ID として接続することを認可されていることを検証しなければならない。この検証の後、認証プロセスは、完了する。

セキュリティ層および対応するビットマスクは、次のとおり。:

1 セキュリティ層なし
2 インテグリティ(krb_mk_safe)保護
4 守秘性(krb_mk_priv)保護

将来、他のビットマスクが規定される可能性がある。;理解されていないビットは、交渉され尽くされなければならない。

例: 次のものは、2つの IMAP4 プロトコルに対する Kerberos v4 ログインシナリオである。(シンプルな認証子における改行は、編集上の分かりやすさのためであり、実際の認証子ではないことに注意。)

S: * OK IMAP4 サーバー
C: A001 AUTHENTICATE KERBEROS_V4
S: + AmFYig==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd  
 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: + or//EoAADZI=
C: DiAF5A4gA+oOIALuBkAAmw==
S: A001 OK Kerberos V4 認証成功

S: * OK IMAP4 サーバー
C: A001 AUTHENTICATE KERBEROS_V4
S: + gcfgCA==
C: BAcAQU5EUkVXLkNNVS5FRFUAOCAsho84kLN3/IJmrMG+25a4DT
 +nZImJjnTNHJUtxAA+o0KPKfHEcAFs9a3CL5Oebe/ydHJUwYFd
 WwuQ1MWiy6IesKvjL5rL9WjXUb9MwT9bpObYLGOKi1Qh
S: A001 NO Kerberos V4 認証失敗

7.2. GSSAPI メカニズム English

GSSAPI [RFC 2078] を採用しているすべてのメカニズムについてのメカニズム名は、"GSSAPI"である。

7.2.1 認証プロトコル交換のクライアント側 English

クライアントは、GSS_Init_sec_context を呼び、input_context_handleについて 0(初期値)を渡し、GSS_C_NT_HOSTBASED_SERVICE の input_name_type と "service@hostname" の input_name_string と共に呼ばれる GSS_Import_Name からの output_name に等しい targ_name を渡す。この "service"は、プロトコルのプロファイルにおいて指定されたサービス名であり、"hostname"は、サーバーの完全なホスト名である。クライアントは、次に、結果 output_token で反応する。 GSS_Init_sec_context が GSS_S_CONTINUE_NEEDED を返す場合、クライアントは、サーバーが以降のチャレンジにおいてトークンを発行することを期待する必要がある。クライアントは、この段落にあるアクションを繰り返して、GSS_Init_sec_context 宛の他の呼び出しにトークンを渡さなければならない。

GSS_Init_sec_context が GSS_S_COMPLETE を返したとき、クライアントは、次のアクションをとる。: GSS_Init_sec_context への最後の呼び出しが output_token を返した場合、クライアントは、output_token で反応し、そうでない場合、クライアントは、データなしで反応する。クライアントは、次に、サーバーに以降のチャレンジにおいてトークンを発行することを期待する必要がある。クライアントは、このトークンを GSS_Unwrap に渡し、最初のオクテットの結果平文をサーバーによってサポートされているセキュリティ層を指定するビットマスク として、 2番目から 4番目のオクテットをサーバー宛に送るための最大サイズ output_message として解釈する。クライアントは、次に、データを作成する。この最初のオクテットは、選択されたセキュリティ層を指定するビットマスクを含み、 2番目から 4番目のオクテットは、ネットワークバイト順に クライアントが受け取ることができる最大サイズの output_message を含み、残りのオクテットは、認可 ID を含む。クライアントは、GSS_Wrap 宛てにデータを conf_flag に FALSE をセットして渡し、生成された output_message で反応する。クライアントは、これでサーバーを認証されたものとすることができる。

7.2.2 認証プロトコル交換のサーバー側 English

サーバーは、input_context_handle に 0(初期値)をセットして初期クライアントレスポンスを GSS_Accept_sec_context 宛に input_token として渡す。

GSS_Accept_sec_context が GSS_S_CONTINUE_NEEDED を返す場合、サーバーは、チャレンジにおいてクライアント宛に生成された output_token を返し、この段落にあるアクションを繰り返して、結果レスポンスを GSS_Accept_sec_context 宛の他の呼び出しに渡す。

GSS_Accept_sec_context が GSS_S_COMPLETE を返すとき、クライアントは、次のアクションをとる。: GSS_Accept_sec_context 宛の最後の呼び出しが output_token を返した場合、サーバーは、チャレンジにおいて それをクライアント宛に返し、クライアントからデータなしの返答を期待する。 output_token が返されるか否かに関わらず(かつクライアントからのそのような output_token 宛のあらゆるレスポンスの受領後であるか否かに関わらず)サーバーは、次に、4オクテットのデータを作成する。この最初のオクテットは、サーバーによってサポートされているセキュリティ層を指定するビットマスクを含み、2番目から 4番目のオクテットは、ネットワークバイト順にサーバーが受け取ることができる最大サイズの output_token を含む。サーバーは、次に、conf_flag に FALSE をセットして平文を GSS_Wrap 宛に渡し、生成された output_message をチャレンジにおいてクライアントに発行しなければらない。サーバーは、次に、結果レスポンスを GSS_Unwrap 宛に渡し、最初のオクテットの結果平文を選択されたセキュリティ層のためのビットマスクとして、 2番目から 4番目のオクテットをクライアント宛に送るための最大サイズ output_message として、残りのオクテットを認可 ID として解釈しなければならない。サーバーは、src_name が認可 ID として認証することを認可されていることを検証しなければならない。これらの検証の後、認証プロセスが完了する。

7.2.3 セキュリティ層 English

セキュリティ層およびそれらに対応するビットマスクは、次のとおり。:

1 セキュリティ層なし
2 インテグリティ保護。送信者は、conf_flag に FALSE をセットして GSS_Wrap を呼ぶ。
4 守秘性保護。送信者は、conf_flag に TRUE をセットして GSS_Wrap を呼ぶ。

将来、他のビットマスクが規定される可能性がある。;理解されていないビットは、交渉され尽くされなければならない。

7.3. S/Key メカニズム English

MD4 ダイジェストアルゴリズムを使う S/Key [RFC 1760] についてのメカニズム名は、"SKEY"である。

クライアントは、初期レスポンスを認可 ID とともに送る。

サーバーは、10進法のシーケンス番号、その後 1つのスペースおよび示された認可 ID のための種となる文字列を含んだチャレンジを発行する。クライアントは、ネットワークバイト順の 64ビットの値、もしくは「6 英単語」フォーマットに符号化されたものとして one-time-password を返す。

サーバーは、one-time-password を検証しなければならない。この検証の後、認証プロセスが完了する。

S/Key 認証は、いかなるセキュリティ層も提供しない。

例: 次のものは、IMAP4 プロトコルにおける 2つの S/Key ログインシナリオである。

S: * OK IMAP4 サーバー
C: A001 AUTHENTICATE SKEY
S: +
C: bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key 認証成功

S: * OK IMAP4 サーバー
C: A001 AUTHENTICATE SKEY
S: +
C: c21pdGg=
S: + OTUgUWE1ODMwOA==
C: BsAY3g4gBNo=
S: A001 NO S/Key 認証失敗

次のものは、IMAP4 のようなプロトコルにおける S/Key ログインシナリオであり、これは、AUTHENTICATE コマンドに対するオプションとしての「初期レスポンス」アーギュメントを持つ。

S: * OK IMAP4-Like サーバー
C: A001 AUTHENTICATE SKEY bW9yZ2Fu
S: + OTUgUWE1ODMwOA==
C: Rk9VUiBNQU5OIFNPT04gRklSIFZBUlkgTUFTSA==
S: A001 OK S/Key 認証成功

7.4. 外部メカニズム English

外部認証についてのメカニズム名は、"EXTERNAL"である。

クライアントは、認可 ID と共にレスポンスを送る。

サーバーは、クライアントが認可 ID として認証することを認可されているかを判定するために SASL 外部の情報を使う。クライアントが、そのように認可された場合、サーバーは認証交換の成功としての完了を示し、そうでない場合、サーバーは失敗を示す。

この外部情報を提供しているシステムは、例えば、IPsec もしくは TLS である。

クライアントが認可 ID として空の文字列を送る場合(それゆえ認可 ID がクライアントの認証クレデンシャルから引き出されることを要求する場合)、認可 ID は、外部認証を提供しているシステム中にある認証クレデンシャルから引き出されるべきである。

 

8. 参考文献 English

[RFC 2060] Crispin, M.,
"Internet Message Access Protocol - Version 4rev1",
RFC 2060, 1996年12月.
 
[RFC 2078] Linn, J.,
"Generic Security Service Application Program Interface, Version 2",
RFC 2078, 1997年 1月.
 
[RFC 2119] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード
(Key words for use in RFCs to Indicate Requirement Levels)」,
RFC 2119, 1997年 3月.
 
[RFC 2223] Postel, J., and J. Reynolds,
「RFC を書く人のために(the instructions to RFC authors)」,
RFC 2223, 1997年10月.
 
[RFC 1760] Haller, N.,
"The S/Key One-Time Password System",
RFC 1760, 1995年 2月.
 
[RFC 1700] Reynolds, J., and J. Postel,
"Assigned Numbers",
STD 2, RFC 1700, 1994年10月.

 

9. セキュリティについての考慮事項 English

セキュリティ論点が、このメモ全体を通じて検討されている。

インテグリティ保護をサポートするメカニズムは、セキュリティ層の交渉と認可 ID がインテグリティ保護されるように設計される。クライアントが少なくともインテグリティ保護をもつセキュリティ層を選択するとき、このことは、活発な攻撃者がコネクションをハイジャックし、平文コネクションを交渉するように認証交換に手を入れることに対して保護する。

サーバーもしくはクライアントが複数の認証メカニズムをサポートしていて、両者が異なるセキュリティ強度を持つとき、活発な攻撃者がサポートされている最新のセキュアメカニズムを使うためのパーティを開催する可能性がある。この種の攻撃に対して防護するために、異なる強度のメカニズムをサポートするクライアントもしくはサーバーは、それが使う設定可能な最小強度を持つ必要がある。この最小強度チェックがサーバーにおいてのみあることでは不十分である。なぜならば、活発な攻撃者は、サポートされているとクライアントが見ているメカニズムを変更することができ、クライアントにその最も弱いサポートされているメカニズムについての認証クレデンシャルを送るようにすることができるからである。

クライアントの SASL メカニズムの選択は、平文によって行われ、活発な攻撃者によって手を入れられる可能性がある。あらゆる新しい SASL メカニズムが、活発な攻撃者が SASL メカニズム名かつ/またはチャレンジ・レスポンスに手を入れることによって、より弱いセキュリティプロパティを持つ認証を手に入れることができないように設計されることが重要である。

認証前の相互作用するあらゆるプロトコルは、平文によって行われ、活発な攻撃者によって手を入れられる可能性がある。クライアントがインテグリティ保護を選択した場合、あらゆるセキュリティに慎重なプロトコル交渉が認証が完了する後に行われることが重要である。各プロトコルは、一度、認証が完了したら、認証前に行われる交渉が無視されるか、あるいは、再検証されるように設計される必要がある。

 

10. 著者のアドレス English

John G. Myers
Netscape Communications
501 E. Middlefield Road
Mail Stop MV-029
Mountain View, CA 94043-4042

EMail: jgmyers@netscape.com

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

Email: miyakawa@ipa.go.jp

 

補遺 A. SASL のトランスポートセキュリティとの関係 English

SASL と(IPsec や TLS のような)様々なセキュアにされたコネクションを提供するサービスの関係について、疑問が提起された。

SASL の鍵となる 2つの機能は、次のとおり。:

  1. 認可 ID のクライアントのクレデンシャル中の ID からの分離。このことは、プロキシサーバーのようなエージェントに自身のクレデンシャルを使って認証することを許可しつつ、それらがプロキシしている ID のアクセス権限を要求する。
     
  2. 認証交換の成功としての完了の際に、サーバーは、クライアントが使うことを希望する認可 ID を知る。このことは、サーバーにプロトコルにおいて「ユーザが認証された」状態に移行することを許可する。

これらの機能は、いくつかのアプリケーションプロトコルにとって極めて重要であるが、トランスポートセキュリティサービスが常にそれらを提供するとは限らない。これらのサービスに基づいて SASL メカニズムを規定することは、非常に面倒なタスクであろう。それは、これらのサービスの枠組みは、SASL の枠組みと冗長であり、これらの重要な SASL 機能を提供する手段のいくつかが工夫される必要があるからである。

時々、既存のコネクションにおいて、SASL モデルに適合しないセキュリティサービスの利用を可能にすることが要求されることがある。(TLS は、そのようなサービスの一例である。)このことは、コマンド(例えば"STARTTLS")をプロトコルに追加することによってできる。このようなコマンドは、SASL の範囲外であり、SASL 認証プロトコル交換を開始するコマンドとは異なる必要がある。

状況によっては、SASL をこれらのトランスポートセキュリティサービスのひとつの下に使うことは、合理的である。トランスポートサービスがコネクションをセキュアにし、両サービスがクライアントを認証し、SASL が認可 ID を交渉する。 SASL 交渉は、プロトコルを「認証されていない」状態から「認証された」状態に移行するものである。"EXTERNAL" SASL メカニズムは、明らかに、トランスポートサービスがコネクションをセキュアにし、クライアントを認証し、SASL が認可 ID を交渉するような場合を扱うことを意図している。

十分に強いトランスポートセキュリティサービスの下に SASL を使うとき、SASL セキュリティ層は、おそらく過剰になるであろう。クライアント・サーバーは、それゆえおそらく、SASL セキュリティ層の利用を交渉し尽くすことを望むであろう。

 

著作権表記全文

Copyright (C) The Internet Society (1997). All Rights Reserved.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implmentation may be prepared, copied, published andand distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.