|
ネットワーク WG Request for Comments： 2222 分類：スタンダードトラック |
J. Myers Netscape Communications 1997年10月 |
本書は、 インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを規定するとともに、 それを改良するための検討や提言を求めるものである。 このプロトコルの標準化状態およびステータスについては、 「Internet Official Protocol Standards」(STD 1)の最新版を参照すること。 このメモの配布に制限はない。
Copyright (C) The Internet Society (1997). All Rights Reserved.
2. 本書の構成
2.1. 本書の読み方
2.2. 本書において使われる用語法
2.3. 例示
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. 外部メカニズム
本書は、 コネクションベースのプロトコルに認証サポートを追加するための手法について記述する。 この仕様を利用するために、プロトコルは、 サーバーに対してユーザを識別し認証するためのコマンドと、 オプションとして以降のプロトコルの相互作用の防護を交渉するためのコマンドを含む。 セキュリティ層が、その利用が交渉された場合、 プロトコルとコネクションの間に挿入される。 本書は、 プロトコルがどのようにそのようなコマンドを仕様としているかを記述し、 コマンドによって利用されるいくつかのメカニズムを規定し、 コネクション上において交渉されたセキュリティ層を運ぶことに利用されるプロトコルを規定する。
本書は、2つの異なる読者層のために書かれている。 プロトコル設計において認証をサポートするためにこの仕様を利用するプロトコル設計者と、 この仕様を利用するプロトコルのためクライアント／サーバーの実装者である。
「導入と概要」、 「要件のプロファイリング」および「セキュリティについての考慮事項」の各章は、 プロトコル設計者が特定のプロトコルにおける利用のためにこの仕様をプロファイリングする際に、 理解し対応する必要がある論点を扱う。
この仕様を使うプロトコルの実装者は、本書中の情報に加えて、 プロトコル固有のプロファイリング情報を必要とする。
例示において、"C:"と"S:"は、それぞれ、 クライアントとサーバーによって送られたラインを示す。
本書中のキーワード"MUST", "MUST NOT", "SHOULD", "SHOULD NOT"および"MAY"は、 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」 [RFC2119] に規定されているように解釈されるべきものである。
本書中の例示は、 この仕様のIMAPプロファイル [RFC 2060]のためのものである。 チャレンジ・レスポンスのbase64符号化やレスポンスの前の"+"は、 IMAP4プロファイルの一部であり、SASL仕様自体の部分ではない。
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バッファの長さは、 他方によって規定もしくは交渉された最大サイズより長くてはならない。
この仕様を利用するために、プロトコル規定は、 次の情報を提供しなければならない。：
メカニズムには、 認証プロトコル交換における最初の送信データがクライアントからサーバー宛てであることを仕様とするものがある。
プロトコルのプロファイルが初期クライアントレスポンスを含む認証プロトコル交換を開始するコマンドを許容する場合、 このパラメータは、 このようなメカニズムとともに利用される必要がある(SHOULD)。
最初のクライアントレスポンスパラメータが与えられない場合、あるいは、 プロトコルのプロファイルが初期クライアントレスポンスを含む認証プロトコル交換を開始するコマンドを許可しない場合、 サーバーは、データを持たないチャレンジを発行する。 クライアントのこのチャレンジに対するレスポンスは、こうして、 初期クライアントレスポンスとして使われる。 (サーバーは、こうして次のチャレンジを送ることに進み、完了を示すか、 あるいは失敗を示す。)
メカニズムには、 サーバーチャレンジデータが交換の成功としての完了の表示とともにクライアント宛てに送られることを規定するものがある。 例えば、このデータは、サーバーをクライアント宛てに認証する。
プロトコルのプロファイルが、 このサーバーチャレンジが成功表示と共に返されることを許容しない場合、 サーバーは、成功としての完了の表示なしにサーバーチャレンジを発行する。 クライアントは、次に、データなしで反応する。 この空のレスポンスを受け取った後、サーバーは、成功としての完了を示す。
プロトコルのプロファイルによって他に表明されない限り、 成功となる唯一のSASL交渉は、 プロトコルセッションにおいて発生する可能性がある。 この場合、一度、認証プロトコル交換が成功として完了したら、 以降の認証プロトコル交換を開始する試みは失敗する。
プロファイルが複数のSASL交渉成功が発生することを明示的に許容する場合、 複数のセキュリティ層が同時に有効となる可能性はない。 セキュリティ層が有効であり、 以降のSASL交渉がセキュリティ層を選択しない場合、 当初のセキュリティ層は、有効として残る。 セキュリティ層が有効であり、 以降のSASL交渉が2番目のセキュリティ層を選択する場合、 2番目のセキュリティ層が最初のものを置き換える。
SASLメカニズムの登録は、 6.4 にあるテンプレートを埋めて、 それをiana@isi.edu宛てに送ることによって行われる。 IANAは、明らかに偽の登録を却下する権利を持つが、 登録フォームにおけるハマグリ(項目の比喩的表現)のレヴューは行わない。
SASLメカニズムについて、命名慣行はない。； SASLメカニズム名の文法に適合するあらゆる名前が登録できる。
登録手順が求めるものではないが、SASLメカニズムの著者には、 可能である限り、 コミュニティのレヴューとコメントを求めることが強く勧められる。 著者は、 提案されたメカニズム の仕様をインターネットドラフトとして投稿することにより、 コミュニティのレヴューを求めることができる。 広域利用のために意図されたSASL メカニズムは、適切であるとき、 通常のIETFプロセスを通じて標準化される必要がある。
登録されたSASLメカニズムについてのコメントは、まず、 メカニズムの「オーナー」に送られる必要がある。 コメントの送信者は、オーナーと連絡をとる合理的な試みの後、 IANAにSASLメカニズム登録自体に彼らのコメントを添付することを要求できる。 IANAがこれを提供する場合、コメントは、 SASLメカニズム登録自体と共にアクセス可能とされる。
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] に従っていただきたい。)
一度、SASLメカニズム登録がIANAによって公表されたら、著者は、 その規定について変更を要求する可能性がある。 変更要求は、登録要求と同じ手順に従う。
SASLメカニズムのオーナーは、 SASLメカニズムについての責任をIANAに通知することによって他者もしくは他の機関に渡すことができる。；
このことは、検討やレヴューなしに行うことができる。
IESGは、SASLメカニズムについての責任を再指名する可能性がある。 このことの最も卑近な事例は、 登録の著者が死亡したり連絡を取れなくなったり、あるいは、 そうしなければコミュニティにとって重要な変更ができないメカニズムに対して変更を可能にすることであろう。
SASLメカニズム登録は、削除されてはいけない。 ；もはや利用するのに適切ではないメカニズムについては、 「意図された用途(intended use)」フィールドについての変更によって「廃止(OBSOLETE)」を宣言することができる。 ; このようなSASLメカニズムは、 IANAによって公表されるリストにおいて明確に印が付けられる。
IESGは、 IETFスタンダードトラックに載っているすべてのSASLメカニズムのオーナーであると見なされる。
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:
(著者が興味深いと考えるあらゆる他の情報は、この行の下に追記される可能性がある。)
次のメカニズムが、ここに規定されている。
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 認証失敗
GSSAPI [RFC 2078]を採用しているすべてのメカニズムについてのメカニズム名は、 "GSSAPI"である。
クライアントは、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で反応する。 クライアントは、これでサーバーを認証されたものとすることができる。
サーバーは、 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として認証することを認可されていることを検証しなければならない。 これらの検証の後、認証プロセスが完了する。
セキュリティ層およびそれらに対応するビットマスクは、次のとおり。：
1 セキュリティ層なし
2 インテグリティ保護。送信者は、conf_flagにFALSEをセットしてGSS_Wrapを呼ぶ。
4 守秘性保護。送信者は、conf_flagにTRUEをセットしてGSS_Wrapを呼ぶ。
将来、他のビットマスクが規定される可能性がある。 ；理解されていないビットは、交渉され尽くされなければならない。
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認証成功
外部認証についてのメカニズム名は、"EXTERNAL"である。
クライアントは、認可IDと共にレスポンスを送る。
サーバーは、 クライアントが認可IDとして認証することを認可されているかを判定するためにSASL外部の情報を使う。 クライアントが、そのように認可された場合、 サーバーは認証交換の成功としての完了を示し、そうでない場合、 サーバーは失敗を示す。
この外部情報を提供しているシステムは、例えば、 IPsecもしくはTLSである。
クライアントが認可IDとして空の文字列を送る場合(それゆえ認可IDがクライアントの認証クレデンシャルから引き出されることを要求する場合)、 認可IDは、 外部認証を提供しているシステム中にある認証クレデンシャルから引き出されるべきである。
| [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月. |
セキュリティ論点が、このメモ全体を通じて検討されている。
インテグリティ保護をサポートするメカニズムは、 セキュリティ層の交渉と認可IDがインテグリティ保護されるように設計される。 クライアントが少なくともインテグリティ保護をもつセキュリティ層を選択するとき、 このことは、活発な攻撃者がコネクションをハイジャックし、 平文コネクションを交渉するように認証交換に手を入れることに対して保護する。
サーバーもしくはクライアントが複数の認証メカニズムをサポートしていて、 両者が異なるセキュリティ強度を持つとき、 活発な攻撃者がサポートされている最新のセキュアメカニズムを使うためのパーティを開催する可能性がある。 この種の攻撃に対して防護するために、 異なる強度のメカニズムをサポートするクライアントもしくはサーバーは、 それが使う設定可能な最小強度を持つ必要がある。 この最小強度チェックがサーバーにおいてのみあることでは不十分である。 なぜならば、活発な攻撃者は、 サポートされているとクライアントが見ているメカニズムを変更することができ、 クライアントにその最も弱いサポートされているメカニズムについての認証クレデンシャルを送るようにすることができるからである。
クライアントのSASLメカニズムの選択は、平文によって行われ、 活発な攻撃者によって手を入れられる可能性がある。 あらゆる新しいSASLメカニズムが、 活発な攻撃者がSASLメカニズム名かつ／またはチャレンジ・レスポンスに手を入れることによって、 より弱いセキュリティプロパティを持つ認証を手に入れることができないように設計されることが重要である。
認証前の相互作用するあらゆるプロトコルは、平文によって行われ、 活発な攻撃者によって手を入れられる可能性がある。 クライアントがインテグリティ保護を選択した場合、 あらゆるセキュリティに慎重なプロトコル交渉が認証が完了する後に行われることが重要である。 各プロトコルは、一度、認証が完了したら、 認証前に行われる交渉が無視されるか、あるいは、 再検証されるように設計される必要がある。
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
SASLと(IPsecやTLSのような)様々なセキュアにされたコネクションを提供するサービスの関係について、 疑問が提起された。
SASLの鍵となる2つの機能は、次のとおり。：
これらの機能は、 いくつかのアプリケーションプロトコルにとって極めて重要であるが、 トランスポートセキュリティサービスが常にそれらを提供するとは限らない。 これらのサービスに基づいて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.