English

インターネットについてのセキュリティメカニズム
(Security Mechanisms for the Internet)

このメモの位置づけ

このメモは、インターネットコミュニティに情報を提供するものです。 これは、いかなるインターネット標準をも定めるものではありません。 このメモの配布には制限はありません。

著作権表記

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

要旨

セキュリティは、 インターネットプロトコルがセキュアにサービスを提供するように、 これらのプロトコル中に作り込まれなければなりません。 多くのセキュリティ問題は、不適切な実装にたどり着くことになります。 しかし、たとえ正しい実装でも、 基盤となるプロトコル自体が攻略可能な場合、 セキュリティ問題をもつことになります。 「具体的に、どのようにセキュリティが、 あるプロトコル中に実装される必要があるか？」は、 そのプロトコル自体の構造に起因して、多様です。 しかし、 既に開発された標準のインターネットセキュリティメカニズムが適用可能なプロトコルが多くあります。 あらゆる状況において、適用可能な詳細は、多様である可能性があります。 我々は、数多くの異なる選択肢の各々の属性を説明しながらレビューします。

1. はじめに English

インターネットセキュリティ侵害は、サービス妨害からホスト侵害まで、 いくつかのクラスに分類することができます。 大量のトラフィックに基づくサービス妨害攻撃は、 多くの進行中の議論と研究の課題ですが、本書の範囲外です。 「このような攻撃の多くは、良いセキュリティ実践によって、 より困難になること」を覚えておくことが重要です。 ホスト侵害(最も卑近には、 検出されなかったバッファオーバーフローによってもたらされる)は、 プロトコル中の欠陥よりも、むしろ個々の実装中の欠陥を再現します。 それにもかかわらず、注意深く設計されたプロトコルは、 このような欠陥が発生する可能性を少なくし、 攻略しにくくすることができます。

しかし、まさにインターネット上で使われているプロトコルによって容易にされているセキュリティ侵害があります。 セキュリティ問題が、あるプロトコルが元々もっているものである場合、 実装の作法によって、その問題を予防することは、不可能です。

それゆえ、「インターネットのために開発されたプロトコルが、 この基盤的なセキュリティを提供すること」は、決定的に重要です。

具体的に「どのように、 あるプロトコルがセキュア化される必要があるか？」は、 当該プロトコルのセキュリティ要求と共に、 そのプロトコル自体に依存します。 しかし、我々は、IETFにおいて、 数多くの標準セキュリティメカニズムを開発してきました。 多くの場合において、これらのメカニズムの適切な応用は、 プロトコルについて必要不可欠なセキュリティを提供することができます。

数多くのメカニズムが、 インターネット上にセキュリティを提供するために利用可能です。 「どれが選択される必要があるか？」は、多くの異なる要素に依拠します。 我々は、 「IABセキュリティアーキテクチャワークショップ」において検討されたように、 ここで、要素と現行標準の(もしくは、 標準化されつつある)解決策を網羅するガイダンスを提供することを試みます。 [RFC2316]

しかし、セキュリティは、科学ではなく、アート(芸術)です。 盲目にレシピに従うことを試みると、災害をもたらす可能性があります。 いつもしているように、プロトコル設計においても、 良く味見する必要があります。

最後に、セキュリティメカニズムは、 完成したプロトコルにふりかけることができる「魔法の粉」のようなものではありません。 「セキュリティを後から引き締めることができること」は、希です。 良い設計(すなわち、セキュアで、クリーンで、効果的な設計)は、 セキュリティメカニズムが、 そのプロトコルと共に作られるときにできるものです。 暗号技術の適用について考慮せずに、 意味論的な想定において欠陥があるプロトコルをセキュアにすることはできません。

2. 意思決定要素 English

2.1. 脅威のモデル English

セキュリティメカニズムの選択における最も重要な要素は、 「脅威のモデル」です。 すなわち、「誰が、どの資源を、 どの種のメカニズムを使って攻撃することが予期されるか？」です。 (公開情報のみを提供するwebサイトのような)価値が低い標的は、 多くの防護から得られるものが無い可能性があります。 逆に、侵害された場合にインターネットインフラストラクチャの要所を露呈する可能性があるような資源(例えば、 主要なバックボーンルーター、あるいは、高レベルのDNSサーバー)は、 非常に強いメカニズムによって防護される必要があります。 攻撃者にとっての標的の価値は、攻撃の目的に依存します。 その目的が取り扱いに注意を要する情報へのアクセスである場合、 この情報を扱うか、あるいは、 この情報へのアクセスを仲介するすべてのシステムに価値があります。 その目的が大混乱をもたらすことである場合、 インターネットの大部分が依存するようなシステムには、 際立つ価値があります。 たとえ公開情報が、あるwebサイト上に掲載されているだけの場合でも、 その中身を変えることは、その所有者を当惑させ、 重大な被害をもたらす可能性があります。 あるプロトコルを設計するとき、「そのプロトコルには、将来、 どのような用途があるか？」を予想することは、困難です。

すべてのインターネットに接続されたシステムは、 最低限の防護を要求します。 2000年に始まって、現在も継続しているのですが、我々は、 新種のインターネットセキュリティ攻撃の出現を目撃してきました。： 侵害に対して脆弱なシステムを探して、 自体に組み込まれた数多くの攻撃手法を通じて自動的に攻撃するインターネット「ワーム」プログラムです。 これらのワームプログラムは、文字通り、数千のシステムを、 非常に短い時間に侵害できます。 「最初のインターネットワームは、 1988年の『モリス』ワームであったこと」に注意してください。 しかし、同種のプログラムは、12年間以上も出現しませんでした！

本書の執筆時点において、これらのワームのすべてが、 通常は合理的にセキュアなプロトコルの実装におけるプログラミングのエラーを利用していました。 しかし、 広く配備されたプロトコル中の基盤的なセキュリティ欠陥を標的とする攻撃を思い描くことは、 難しいことではありません。 それゆえ、 「我々が設計するプロトコル中のそのような欠陥を最小化するために努力すること」は、 急を要します。

攻撃者にとっての標的の価値は、「どこにそれがあるか？」に依存します。 物理的にバックボーン回線上にあるネットワーク監視ステーションは、 主要な標的です。 なぜなら、これは、簡単に「盗聴用ステーション」になりうるからです。 同じマシンが、 (ゲートウェイより内側の)スタブネット上にあって文書作成に使われている場合には、 洗練された攻撃者にとっては、あまり使えないものとなり、それゆえ、 顕著にリスクが少ないといえます。

「どの種類の攻撃が予期される可能性があるか？」も考慮しなければなりません。 最低限、盗聴は、深刻な脅威として見なされなければなりません。 少なくとも1993年以降、非常に多くのこのようなインシデントがありました。 しばしば、積極的な攻撃(すなわち、 攻撃者によるパケットの挿入または削除を含む攻撃)も、リスクです。 「このような攻撃は、既製のツールで放つことができ、 既に『流行中』であると観察されていること」に注意する価値があります。 特に興味深いのは、「セッションハイジャック」と呼ばれる形態の攻撃です。 この攻撃では、通信中の2者間のリンク上の誰かが認証が完了するのを待ち、 それから、一方の主体になりすまして、他方と、 そのコネクションを続けます。

プロトコルをセキュア化するために利用可能で最も重要なツールのひとつは、 暗号技術です。 暗号技術は、ネットワーク自体の、 いかなる特定のセキュリティ属性に依存する必要無しに、 データがネットワークを転送される際に、 様々な種類の防護を適用できるようにします。 これは、重要です。 なぜなら、インターネットは、その分散型の管理と統制によって、 それ自体とその中は、 「信用に値するメディア」と見なすことができないからです。 そのセキュリティは、基盤となるメディアや、あるいは、 ネットワーク運用者とは独立に、 我々がプロトコル自体に作り込むメカニズムから得られるものです。

最後に、当然ながら、防護する者には暗号技術を使う費用が発生します。 この費用は、急速に低下しています。 「ムーアの法則」に加えて、 暗号技術的なコンポーネントやツールキットが容易に利用可能であることは、 強い保護テクニックを使うことを、比較的容易にします。 「公開鍵暗号の処理は、なおも高価であり、各公開鍵暗号の処理の費用が、 あまりに少数のトランザクションに配賦される場合、 おそらく法外に高価である」という例外事項はありますが、 注意深いエンジニアリング設計は、一般に、 この費用を多くのトランザクションに配賦するようにできます。

一般に、今日、断りのない場合、あらゆるプロトコルにおいて、 利用可能な最強の暗号技術を使う必要があります。 強い暗号技術は、しばしば、より弱い暗号技術と比べて、高価ではなく、 しばしば安価です。 あるアルゴリズムの実際の実行費用は、しばしば、 それが提供するセキュリティとは、無関係です。 利用可能なハードウェアによっては、暗号技術は、 非常に高速(1+Gbps)に行うことができ、たとえソフトウェアにおいても、 その実行の影響は、時間を経て縮まってきています。

2.2. 必須メカニズムについて English

我々は、IETFにおいて、 「実装することの必須」メカニズムの見解を発展させました。 この哲学は、 「あるプロトコルの異なる実装間の相互運用可能性を確保する」という我々の主要な切望から発展したものです。 プロトコルが多くが、 「どのように特定のタスクを行うか？」についてのオプションを提供しますが、 すべてが実装しなければならない最低限のものを提供しない場合、 「複数の相互運用可能性の無い実装をもたらす」可能性があります。 これは、 異なる実装間において採用された重複のないメカニズムの選択の結末です。

所与のプロトコルが、たったひとつ、あるいは、 少数のセキュリティメカニズムを利用する可能性がありますが、 これらのメカニズム自体は、しばしば、 いくつかの暗号技術的システムを利用する可能性があります。 様々な暗号技術的システムは、強度と性能において多様です。 しかし、多くのプロトコルにおいて、我々は、 「いかなる2つの実装でも、最終的には、 両者間で共通の暗号技術的システムを交渉できること」を確保するために、 「実装することの必須」を規定する必要があります。

プロトコルには、 非常に限定されたドメイン内で動作することを予定して、当初、 設計されたものがあります。 しばしば、「特定のプロトコルについての実装の対象ドメインは、 十分によく定義されており、セキュアであるので、そのプロトコル自体は、 いかなるセキュリティメカニズムをも提供する必要がないこと」が議論されます。

歴史は、この言及が誤りであることを示してきました。 必然的に、よくできたプロトコルは、 (たとえ限られた用法のために開発された場合でも、) より広範な環境において使われるようになり、 当初のセキュリティの想定が保たれなくなります。

この問題を解決するために、IETFは、 「たとえ利用されるドメインが、当初、 非常に限られていると想定されると確信されるときでも、 『すべての』プロトコルが適切なセキュリティメカニズムを提供すること」を要求します。

「強制的メカニズムは、 『実装』することが必須であること」を理解することが重要です。 「エンドユーザが、実際に、これらのメカニズムを使うこと」は、 必ずしも必須ではありません。 エンドユーザが「プロトコルを、 『セキュア』ネットワーク上に配備していること」を知っている場合、 彼らは、 実行費用に比してあまり効用が無いと信じるセキュリティメカニズムを不能にすることを選択する可能性があります。 (我々は、一般に、たとえそのようなときでも、 強いセキュリティを不能にする見識について懐疑的ですが、 これは、本書の範囲外です。)

「特定のメカニズム群を実装することは、必須である」と主張することは、 「当該セキュリティメカニズムによって提供されるプロトコルを必要とするエンドユーザは、 必要なときに、それを利用できること」を意味します。 特に、セキュリティメカニズムについては、 「メカニズムを実装することが必須であるから」ということは、安直に、 「セキュリティメカニズムは、 デフォルトメカニズムである必要があること」あるいは「セキュリティメカニズムは、 設定によって無効にすることはできないこと」を意味しません。 必須実装アルゴリズムが古く、かつ、弱い場合、 より強いアルゴリズムが利用可能なとき、古いものを不能にする方が良いです。

2.3. 防護の粒度 English

セキュリティメカニズムには、 ネットワーク全体を防護できるものがあります。 これは、ハードウェアについて経済的に合理化しますが、これは、 このようなネットワークの内部を、 内部からの攻撃に対して開かれたままにする可能性があります。 他のメカニズムは、時分割されたマシンの個々のユーザまで、 防護を提供できます。 ただし、おそらく、そのマシンが侵された場合、 ユーザのなりすましのリスクがあります。

理想的な防護の粒度を事前評価するとき、プロトコル設計者は、 典型的な利用パターン、 実装する層(下記参照)および配備可能性を考慮する必要があります。 あるプロトコルがセキュアなマシン群(例：NOC (Network Operations Center))の内部でのみ使われる傾向がある場合、 「サブネット単位の粒度」が適切である可能性があります。 対照的に、単一のアプリケーションに固有なセキュリティメカニズムは、 TCP中に組み込むのではなく、 そのアプリケーション中に組み込むのが最善です。 そうしなければ、配備は、非常に困難となります。

2.4. 実装される層 English

セキュリティメカニズムは、あらゆる層に配置することができます。 一般に、下位層にメカニズムを配置することによって、 広範で多様な高位層プロトコルを防護できますが、 それらを同様に防護できない可能性があります。 リンク層の暗号化器は、IPパケットのみならず、 ARPパケットさえも護ることができます。 しかし、その範囲は、たった1リンクのみです。 逆に、署名された電子メールメッセージは、 たとえ多くの蓄積転送型のメールゲートウェイを通じて送られた場合でも防護され、 実際の送信者を識別することができ、その署名は、 そのメッセージが配信されたずっと後になっても検証できます。 しかし、たった1種のメッセージのみが防護されます。 (Netnews投稿用のような)同様なフォーマットのメッセージは、 そのメカニズムが具体的に採用され、 そのNewsを扱うプログラムに実装されない限り、防護されません。

3. 標準セキュリティメカニズム English

3.1. ワンタイムパスワード English

[RFC2289] に記述されているようなワンタイムパスワードのスキームは、 従来のパスワードよりも、はるかに強いものです。 そのホストは、ユーザのパスワードのコピーを蓄積する必要がなく、 ネットワーク上を転送されることもありません。 しかし、いくつかのリスクがあります。 転送された文字列は、 ユーザが打鍵したパスワードから得られるものであるので、推測攻撃は、 なおも可能である可能性があります。 (まさに、この攻撃を放つプログラムは、既に利用可能です。)さらに、 そのユーザのログインする能力は、事前に決定された利用回数の後、 必ず期限切れとなります。 多くの場合において、これは、機能のひとつですが、その実装は、 「新しいパスワードがネットワーク越しにクリアテキストで送られること」を要求すること無く、 その認証データベースを最初期化する方法を提供する必要があることになります。

商品としてのハードウェア認証トークンがあります。 セッションハイジャックの論点とは別に、 このようなトークンについてのサポートは、 追加的なプロトコルメッセージを要求する可能性があります。 (特に、チャレンジ／レスポンス型トークン。 この場合、サーバーは、認証の試みごとに異なる乱数を送信する。)

3.2. HMAC English

HMAC [RFC2104] は、 選好されるshared-secret認証テクニックです。 両者が同一の秘密鍵を知っている場合、HMACは、 あらゆる任意のメッセージを認証するために使えます。 これは、乱雑なチャレンジを含み、これは、 「HMACは、 古いセッションのリプレイを予防するために採用できること」を意味します。

コネクション認証についてHMACを使うことの残念な欠点は、 「その秘密は、両者によってクリアに知られていなければならないこと」であり、 鍵が長期間使われるとき、この秘密は、望まれないものとなります。

適切である限り、HMACは、より古いテクニック(特に、 鍵付きハッシュ関数)より選好されて使われる必要があります。 (BGPセッションセキュリティメカニズム [RFC2385] において使われているのような)MD5 [RFC1321] に基づくシンプルな鍵付きハッシュは、特に、 MD5における弱点のヒントが与えられたら、新しいプロトコルにおいては、 避けるべきものです。

HMACは、MD5とSHA-1 [RFC3174] を含むあらゆるセキュアハッシュ関数を使って実装できます。 SHA-1は、新しいプロトコルについて、選好されます。 なぜなら、これは、この目的のために、 より頻繁に使われるようになっており、 よりセキュアである可能性があるからです。

「HMACに基づくメカニズムは、 すべてのプロトコルデータユニット(aka packet)について採用される必要があること」を理解することが重要です。 HMACに基づくシステムをTCPセッションの開始部分を認証するために使い、 残りのすべてのデータを何の防護無しに送ることは、誤りです。

TCPセッションが盗まれるようにしてしまう攻撃プログラムが存在しています。 攻撃者は、ただ、HMAC の処理が行われた後、 セッションを盗むためには、このようなツールを使う必要があるだけです。

3.3. IPsec English

IPsec [RFC2401], [RFC2402], [RFC2406], [RFC2407], [RFC2411]は、一般的な、 IP層の暗号化と認証のプロトコルです。 そうであるので、これは、TCPとUDPの両方を含むすべての上位層を防護します。 その通常の防護の粒度は、「ホスト to ホスト」、 「ホスト to ゲートウェイ」および「ゲートウェイ to ゲートウェイ」です。 この仕様は、ユーザ単位の粒度の防護を許容しますが、 これは、比較的まれです。 このようであるので、IPsecは、現在、ホスト単位の粒度が粗すぎるとき、 不適切です。

IPsec は、IP層に導入されるので、 ネットワーキングのコードにまで入り込む可能性があります。 これを実装することは、一般に、新しいハードウェアか、あるいは、 新しいプロトコルスタックのいずれかを要求します。 他方、これは、アプリケーションにとっては、相当に透過的です。 IPsec上で動作するアプリケーションは、 それらのプロトコルをまったく変更することなく、 向上したセキュリティを得ることができます。 しかし、少なくとも、IPsecがより広く配備されるまでは、 大部分のアプリケーションは、 「自身のセキュリティメカニズムを規定する代わりに、 IPsecの上で動作するもの」と想定しては、いけません。 大部分の最近のOS(オペレーティングシステム)は、 利用可能なIPsecをもっています。 大部分のルーターは、少なくとも、コントロールパスについては、 もっていません。 TLSを使うアプリケーションは、 アプリケーション固有の認証の利点を生かすようにする可能性が高いです。

IPsecについての鍵管理は、証明書か、 「共有された秘密」のいずれかを使うことができます。 明白な理由によって、証明書が選好されます。 しかし、それらは、システム管理者に、 より多くの頭痛をもたらす可能性があります。

IPsecとNAT [RFC2993] の相性が悪いことについて、 潜在的可能性が高いです。 NATは、組み込まれたIPアドレスをもつ、 あらゆるプロトコルと簡単には共存できません。 IPsecについては、ヘッダーの中だけを見れば、 すべてのプロトコルについての、すべてのパケットが、 そのようなアドレスをもっています。 この相性問題は、しばしば、 トンネルモードを使うことによって避けることができますが、 他の理由によって、常に適切な選択であるとは限りません。 IPsecがNAT経由で、より容易に通過できるようにする作業が進行中です。 [NATIKE]

最近のIPsec用途は、VPN(バーチャルプライベートネットワーク)用です。 「その他に制約条件が無い」と想定すれば、IPsecは、 VPNのような状況のために選択されるセキュリティプロトコルです。 この状況とは、1台のマシンがIPsecを使ってインターネット越しにホームネットワークに接続するリモートアクセスのシナリオを含むものです。

3.4. TLS English

TLS [RFC2246] は、TCPの最上位で動作する、 暗号化され、認証されたチャネルを提供します。 TLSは、当初、webブラウザーによる利用のために設計されましたが、 TLSの用途は、決して、これに限られません。 しかし、一般に、TLSを使うことを望む各アプリケーションは、 個別に変換される必要があります。

一般に、サーバーは、常に、証明書によって認証されます。 クライアントも、(相互の認証を提供する)証明書をもつ可能性があります。 ただし、これは、あまり配備されていません。 「サーバーでさえ、実践においては、 暗号技術な意味においてセキュアなものとして認証していないこと」は、 不幸な現実です。 [Bell98] なぜなら、大部分の実装は、ユーザに、 (警告に対してOKをクリックすることによって、)認証の失敗を無視することを許容しており、 大部分のユーザは、定型的に、そのようにしているからです。 それゆえ、設計者は、TLSによって防護されたコネクション越しでも、 プレインテキストパスワードを求めることを心配する必要があります。 (この要件は、実装が そのサーバーの証明書の真正性と認可を検証できる可能性が高い場合、 緩和できます。)

TLSを利用するためには、一般に、 アプリケーションの改造が要求されますが、 実装を提供するツールキット(フリーと、商品の両方)が存在します。 これらは、アプリケーションのコードに組み込まれるように設計されました。 TLSを使うアプリケーションは、IPsecを使うものよりも、 アプリケーション固有の証明書ポリシーを主張できるようになります。

3.5. SASL English

SASL [RFC2222] は、 TCP上で使われる認証と暗号化のメカニズムを交渉するためのフレームワークです。 そうであるので、そのセキュリティ属性は、 交渉されたメカニズムのものとなります。 具体的には、この交渉されたメカニズムが以降のすべてのメッセージ、 もしくは、 (TCPが使われているように)基盤となっている防護プロトコルを認証しない限り、 TCP接続は、セッションを盗むことに対して脆弱です。

あなたがTLS(もしくはIPSec)をSASLの下で使う必要がある場合、 「まず、なぜ、SASLを意識するのか？」、「なぜ、 単にTLSの認証機能を使って行われないのか？」

ここでのその答えは、微妙です。 TLSは、認証のために、証明書を使いこなします。 卑近な配備状況では、サーバーのみが、証明書をもち、一方、 クライアントは、認証されずにいます。 (少なくとも、TLS処理自体によっては。)

SASLは、(パスワード(ワンタイム、 または otherwise)のような)より伝統的なクライアント認証技術の利用を許容します。 強力な組み合わせは、基盤の防護とサーバーの認証のためにTLSを使い、 クライアントを認証するためにSASLに基づくシステムを使うものです。 異なる認証テクニックが異なる方向で使われているとき、 中間者による脆弱性を避けるために、注意が払われねばなりません。

3.6. GSS-API English

GSS-API [RFC2744] は、 アプリケーションが認証、インテグリティ、および／または、 守秘性を要求するときに使うためのフレームワークを提供します。 SASLとは異なり、GSS-APIは、 UDPに基づくアプリケーションと共に容易に使えます。 これは、プロトコルのデータユニット中に埋め込まれる可能性がある(「メモリのチャンク」として知られる)オペイクな認証トークンの作成機能を提供します。 「GSS-APIによって防護されたプロトコルのセキュリティは、 その基盤となっているセキュリティメカニズムに依存すること」に注意してください。 これは、別個に評価されなければなりません。 同様の考慮事項は、当然ながら、相互運用可能性についても適用されます。

3.7. DNSSEC English

DNSSEC [RFC2535] は、 デジタル的にDNSレコードに署名します。 これは、 「DNSキャッシュを汚染する攻撃」から防護するために肝要なツールのひとつです。 [Bell95] これらは、名前に基づく認証を破って、攻撃者宛て、 あるいは攻撃者越しにトラフィックを指図するのに使われる可能性があります。 後者は、DNSSECを他の何らかのセキュリティメカニズム(特に、 IPsec)の肝要なコンポーネントにします。

本書の執筆時点において、 インターネット上に広く配備されていませんが、これは、 ドメイン名をIPプロトコルのアドレスに対応させるためのセキュアメカニズムを提供する潜在的能力を提供します。 これは、また、 他の情報をDNS名にセキュアに関連づけるためにも使うことができます。

この情報は、特定ノードにおいてサポートされているサービス、あるいは、 セキュアセッションを交渉するためにIPsecと共に使われる鍵と同程度にシンプルである可能性があります。 「DNS中に一般目的アプリケーションの強い鍵を置くという概念は、 否決されました [RFC3445] が、 特定のアプリケーション(特に、IPsec)についての強い鍵の標準化が、 進行中であること」に注意してください。

3.8. Security/Multipart English

Security/Multiparts [RFC1847] は、 電子メールを防護するために選好されるメカニズムです。 より詳細には、これは、暗号化、および／または、 デジタル署名が組み込まれるMIMEフレームワークです。 S/MIMEとOpenPGP(下記参照)は、Security/Multipartを、 そのエンコードに使います。 対応しているメーラーは、容易に、 そのメールの暗号技術的な部分を認識し、処理できます。

Security/Multipartsは、「オブジェクトセキュリティ」の一形態です。 ここでは、エンドユーザにとって関心の対象であるオブジェクトは、 トランスポートメカニズムや中間のストレージ等からは独立したものとして、 防護されます。 現在、インターネットにおいて利用可能なオブジェクト防護の一般的形態は、 ありません。

電子メール以外のS/MIME使用の良い例としては、 SIP (Session Initiation Protocol)[RFC3261] 参照。

3.9. デジタル署名 English

「チャレンジ／レスポンス認証」の最強の形態のひとつは、 デジタル署名に基づきます。 公開鍵暗号技術の利用は、 共通鍵暗号技術に基づくスキームより選好されます。 なぜなら、クライアントの秘密の複製を必要とするサーバーは無いからです。 むしろ、そのクライアントは、プライベート鍵をもちます。 サーバーは、対応する公開鍵をもちます。

デジタル署名を正しく使うことは、意外に困難です。 クライアントは、送られてきたチャレンジそのものに署名してはいけません。 なぜなら、このような状況において放つことができる数論的攻撃が、 いくつかあるからです。

DSS (Digital Signature Standard)[DSS] と RSA [RSA] は、共に良い選択です。 各々は、それぞれに優位性をもちます。 DSAで署名することは、「良い乱数の利用」を要求します。 [RFC1750] その敵が、いかなる署名についてでも、 そこに使われている乱数を復元できる場合、あるいは、 あなたが2つの異なる文書について同一の乱数を使う場合、 あなたのプライベート鍵は、復元できてしまいます。 DSSは、新しいプライベート鍵を生成することについて、 RSAよりもはるかに良い性能をもちます。 そして、RSAは、署名を検証することについて、 はるかに良い性能をもちますが、DSSは、署名を生成することについて、 (RSA)よりいくらか良い性能をもちます。

3.10. OpenPGPとS/MIME English

デジタル署名は、 「オブジェクトセキュリティ」アプリケーションを構築するために利用できます。 オブジェクトセキュリティは、蓄積されたデータや、 電子メールのような転送プロトコルを防護するために使えます。

この執筆時点において、 2つの異なるセキュアなメールプロトコル(OpenPGP [OpenPGP] と S/MIME [S/MIME])が、PEM [PEM] を置き換えるものとして提案されています。 どちらが成功するかは、わかりません。 両者は、セキュアメールと共に使うために規定されましたが、 他のプロトコルによって運ばれるデータを防護するためにも採用できます。 両者は、ユーザを認証するために証明書を使います。 両者は、メールメッセージの秘密と認証を提供できます。 しかし、その証明書フォーマットは、まったく異なります。 歴史的に、PGPに基づくメールとS/MIMEに基づくメールの相違点は、 証明書の連鎖法のスタイルでした。 S/MIMEにおいて、ユーザは、X.509証明書を提示します。 その認証(certification)関係図は、 非常に少数のルートをもつ木となります。 対照的に、PGPは、いわゆる「信用の網(web of trust)」を使います。 ここで、あらゆるユーザが、あらゆる他人の証明書に署名できます。 この認証(certification)の関係図は、まさに任意の関係図(もしくは、 関係図の集合)となります。

いかなる証明書スキームにおいても、信用は、2つの主要な特徴に依存します。 まず、これは、 既知の信頼可能な源泉(X.509(証明書)のルート(CA)か、あるいは、 しばしば自分自身であるところの検証者によって高度に信頼されている者のいずれか)から出発しなければなりません。 2番目に、署名の連鎖は、信頼できなければなりません。 すなわち、認証パス中の各ノードが、決定的です。 これが、誠実でない、あるいは、侵されている場合、 それが保証しているあらゆる証明書は、信頼できないものになります。 他のすべての要素が等しいならば、(これは、 希ですが、)より短い連鎖の方を選好可能とされます。 いくつかの相違点は、 これらの技術によって表現される2つの哲学的な見知の間の関係を反映しています。 他の相違点は、「別々の設計チームであったこと」に起因します。

S/MIMEは、「ばかでも使える証明(fool proof)」となるように設計されました。 すなわち、エンドユーザ設定が、ほとんど要求されません。 具体的には、エンドユーザは、 信用の関係等を認識している必要がありません。 その発想は、「あるS/MIMEクライアント(メーラー)が『この署名は、 妥当です。』という場合、そのユーザは、 その基礎となっている意味合いを理解することを必要とせずに、 その言明を額面通りに『信用』できる必要がある」ということです。

これを達成するために、S/MIMEは、典型的には、 現定数の「ルート」CA (Certifying Authorities)に基づきます。 その目標は、 「地球規模の信用された証明書インフラストラクチャを構築すること」です。

このアプローチの短所は、「これが機能する前に、 公開鍵インフラストラクチャが配備されていることを要求すること」です。 2人のエンドユーザは、単にS/MIME機能をもつソフトウェアを入手して、 begin communicatingセキュアに通信を始めることは、 できない可能性があります。 これは、そのプロトコルの制約ではなく、 広く入手可能なソフトウェアについての典型的な設定の制約です。 一方もしくは両方が、 相互に信用されたCAから証明書を入手する必要がある可能性があります。 さらに、そのCAは、事前に、 彼らのメールを扱うソフトウェアによって信用されていなければなりません。 この過程は、費用と法的義務を伴う可能性があります。 これは、究極的には、この技術を配備することが、 より困難であることに帰結します。 特に、エンドユーザが、 その面倒なことの対価としての価値を必ずしも正当に評価しない環境において、 このようにいえます。

PGPの「信用の網(web of trust)」アプローチは、 「2人のエンドユーザが、PGPソフトウェアを簡単に入手でき、すぐに、 セキュアに通信し始めることができる」という優位性をもちます。 何らインフラストラクチャは、要求されず、先に進むために、 費用や法的契約への署名は、不要です。 このようであるので、PGPは、 アドホックなセキュリティ協定を確立する必要がある人々にアピールします。

PGPの短所は、「エンドユーザに、それを効果的に利用するために、 基礎となっているセキュリティ技術を理解していることを要求すること」です。 具体的には、世間知らずのユーザを騙して、 実際には偽りの「署名された」メッセージを受容させることは、 相当に簡単です。

今日、PGPは、セキュリティに関心ある人々の間では、 多大な受容を得ています。 セキュリティに関心ある人は、 必要不可欠な地球規模のインフラストラクチャが存在しない環境においてもセキュアな電子メールを必要としています。

対照的に、S/MIMEは、 セキュアな内部CAシステムが配備できる組織体の設定において、 うまく動作します。 これは、エンドユーザに多くのセキュリティ知識を要求しません。 S/MIMEは、注意深く横断認証(cross certification)を設定することによって、組織体間に使えますが、 これは、見た目よりも困難です。

この執筆時点においては、 地球規模の証明書インフラストラクチャが、我々を悩ませています。 プライバシーについての考慮事項とともに、 適切なビジネスモデルについての疑問は、 今後の台頭を妨げる可能性があります。

3.11. ファイアウォールとトポロジー English

ファイアウォールは、トポロジー的な防護メカニズムです。 すなわち、ファイアウォールは、 ドメインの良い「内部」と悪い「外部」の間のきちんと定義された境界に依拠し、 ファイアウォールは、情報の通過を仲介します。 ファイアウォールは、正しく採用された場合、 非常に価値がある可能性がありますが、 それらのネットワークを防護する能力には限界があります。

当然ながら、最初の限界は、「ファイアウォールは、 内部からの攻撃からは、防護できないこと」です。 このような攻撃の実際のインシデント比率は、知られていません(し、 おそらく、知ることができません)が、「これは、相当数あり、 おそらくセキュリティ問題の大多数を構成すること」に疑いの余地は、 ありません。 より一般的に、ファイアウォールは、 きちんと制限された境界を要求するとしたら、 そのような境界が存在しなければ、ファイアウォールは、役にたちません。 あらゆる外部へのコネクションは、たとえ、 それらがファイアウォールを意図的に通過するプロトコルであれ、 トンネル化されたリンクであれ、防護されていない無線LANであれ、 あるいは、通常の内部ホストからの直接の外部へのコネクションであれ、 その防護を弱めます。 ファイアウォールは、かねてより、ユーザがプロトコルを、 ファイアウォールを通過するようにトンネル化するにしたがって、 トンネル終点において不適切なセキュリティをもつ可能性があり、 有効でなくなりつつある傾向があります。 そのトンネルが暗号化されている場合、そのファイアウォールが、 それらを知覚できる方法は、ありません。 しばしば指摘されるファイアウォールの優位性は、 「内部ホストの存在を外部の目から隠すこと」にあります。 しかし、これだけの漏洩があると、うまくマシンを隠せる可能性は、 むしろ低くなります。

より微妙にファイアウォールは、 不必要にインターネットとそのプロトコルの「エンド to エンド」モデルに傷をつけました。 まさに、すべてのプロトコルが、安全に、あるいは、容易に、 ファイアウォールを通過できるわけではないのです。 セキュリティについてファイアウォールに依存するサイトは、自らが、 インターネットの新しく有用な局面から切り離されていることを自覚する可能性があります。

ファイアウォールは、セキュリティの構造全体の1要素として使われるとき、 最善に動作します。 例えば、厳密なファイアウォールは、 露出しているWebサーバーとバックエンドデータベースの間の通信チャネルのみを開けることによって、 両者を分離するために使うことができます。 同様に、 暗号化されたトンネルトラフィックのみを許容するファイアウォールは、 VPNの一部をセキュアにするために使えます。 また、VPNの他方のエンドである場合は、 同等にセキュアにする必要があります。

3.12. Kerberos English

Kerberos [RFC1510] は、2つの主体に、 相互に認証し、鍵とする素材を交換するメカニズムを提供します。 クライアント側において、アプリケーションは、 Kerberos「チケット」と「認証子(authenticator)」を入手します。 オペイク(opaque：不透明)データと見なされる必要がある、 これらの要素は、次に、クライアントからサーバー宛てに通信されます。 そして、そのサーバーは、それらの真正性を検証できます。 両者は、次に、そのKerberosソフトウェア宛てに、 データの防護(もしくは暗号化)に使えるセッション鍵を共に提供することを依頼する可能性があります。

Kerberosは、それ自体、プロトコル中に使われる可能性があります。 しかし、これは、SASLとGSSAPIのもとのメカニズムとしても利用可能です。 これは、いくつかの既知の脆弱性 [KRBATTACK] [KRBLIM] [KRB4WEAK] をもちますが、セキュアに使うことができます。

3.13. SSH English

SSH は、クライアントとサーバー間にセキュアなコネクションを提供します。 これは、TLSと非常によく似た動作をします。 しかし、これは、 端末のようなデバイス上のリモートコネクションのためのプロトコルとして最適化されます。 そのより革新的な機能のひとつは、 そのSSHによって防護されたTCPコネクションにおける他のプロトコルの「トンネル化」についてのサポートです。 この機能は、見識あるセキュリティの人々が、 セキュアでないネットワーク越しに、セキュアでないサーバー経由で、 「電子メールやnewsの読み書き」のような行為を行うことをできるようにしました。 これは、真のVPNを構成するものではありませんが、しばしば、 その代わりに使うことができます。

4. セキュアでないメカニズム English

卑近なセキュリティメカニズムには、 「解決のためのもの」とはいえない「問題のもの」があります。

4.1. プレーンテキストのパスワード English

プレーンテキストのパスワードは、今日、 使われている最も卑近なセキュリティメカニズムです。 あいにく、それらは、最も弱いものでもあります。 暗号化する層によって防護されていないとき、それらは、 まったく受容できません。 たとえ暗号化とともに使われているときでも、 プレーンテキストのパスワードは、極めて弱いものです。 なぜなら、それらは、 遠隔にあるシステムに転送されなければならないからです。 そのシステムが侵害された場合、あるいは、 その暗号化する層において効果的なサーバー認証をクライアントに提供しない場合、 敵は、そのパスワードを収集することができ、潜在的には、 それらを他の標的に対して使うことができてしまいます。

その他の弱点が、卑近な実装テクニックに起因して生じます。 [MT79] は、 ホストがユーザのパスワードの一方向ハッシュを保存するために、 プレインテキスト形態よりは良い形態であると見なされています。 しかし、それらは、 (HMACに基づくチャレンジ／レスポンスのような)より強い認証メカニズムへの移行を妨げる可能性があります。

盗聴以外で、パスワードに対する最強の攻撃は、パスワード推測です。 適したプログラムと辞書があれば(また、これらは、広く入手可能ですが)、 20から30%のパスワードは、大部分の環境において推測できます。 [Klein90]

4.2. アドレスに基づく認証 English

その他の卑近なセキュリティメカニズムには、 アドレスに基づく認証があります。 これは、せいぜい、かなり制限された環境において、機能するのみです。 「あなたの環境が少数のマシンから成り、 すべてがきちんと運用管理され、 セキュアシステムが信用されたユーザによって動作させられる場合」かつ「そのネットワークがソースルーティングをブロックし、 あなたの発信元アドレスの偽装を予防するルータによって区分されており、 無線ステーションが無いことが分かっている場合」かつ「あなたがアドレスに基づく認証をそのネットワーク上のマシンに制限する場合」には、 あなたは、おそらく安全です。 しかし、これらの条件は、めったに成立しません。

その脅威には、ARPスプーフィング、ローカルプロキシの濫用、再採番、 ルーティングテーブルの破損もしくは攻撃、 DHCP IPアドレス・スプーフィング(UDPに基づくプロトコルについての特定のリスク)、 「シーケンス番号推測」および「ソースルートされたパケット」があります。 これらのすべては、よく効いてしまう可能性があります。

4.3. 名前に基づく認証 English

名前に基づく認証は、アドレスに基づく認証のすべての問題をもち、 さらに、新しい問題ももちます。： DNSについての攻撃 [Bell95] と、 アドレスと名前の間の「1対1対応」の欠如です。 最低限、DNSからホスト名を取得するプロセスは、 対応するアドレスレコードを取得し、クロスチェックする必要があります。 DNSキャッシュを汚染するようなテクニックは、しばしば、 このようなチェックを無効にする可能性があります。

DNSSECは、この種の攻撃に対する防護を提供します。 しかし、これは、基盤となっているアドレスの信頼性を向上してくれません。 さらに、このテクニックは、多くの誤報を発生させてしまいます。 これらのルックアップ(lookup)は、マシンに信頼できる情報を提供しません。 ただし、それらは、 人間にとって有用なデバッグ用ツールである可能性があり、 「どのように、攻撃は起きたのか？」の再現を試みるとき、 ログとしては有用である可能性は、あります。

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

完全なセキュリティメカニズムは、ありません。 何も起きない場合でも、 あらゆるネットワークに基づくセキュリティメカニズムは、 終点の侵害によって、妨害される可能性があります。 すなわち、ここに記述した各メカニズムは、固有の限界をもちます。 所与のメカニズムを採用することについてのあらゆる意思決定は、 可能性のある失敗モードのすべてを測る必要があります。 これら(の意思決定)は、次に、 その終点におけるセキュリティの失敗についてのリスクを測る必要があります。

6. IANAについての考慮事項 English

本書に関して、IANAについての考慮事項は、ありません。

7. 謝辞 English

Brian Carpenter, Tony Hain, Marcus Leechは、 数多くの有用な示唆を与えてくれました。 この内容の多くは、 「IABセキュリティアーキテクチャワークショップ」の参加者から得ました。

8. 参考資料

9. 知的財産権について

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr＠ietf.org.

10. 著者情報 English

本書は、IAB (Internet Architecture Board)の出版物です。 本書の完成時点における IAB のメンバーは、下記のとおり。：

Bernard Aboba
Harald Alvestrand
Rob Austein
Leslie Daigle, Chair
Patrik Faltstrom
Sally Floyd
萩野純一郎(いとぢゅん)
Mark Handley
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Michael StJohns

Internet Architecture Board
EMai： iab＠iab.org

Steven M. Bellovin, Editor
EMai： bellovin＠acm.org

Jeffrey I. Schiller, Editor
EMail： jis＠mit.edu

Charlie Kaufman, Editor
EMail： charliek＠microsoft.com

翻訳者情報

宮川 寧夫
miyakawa＠ipa.go.jp

11. 著作権表記全文

Copyright (C) The Internet Society (2003).  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 implementation may be prepared, copied, published and 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 assignees.

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.

謝辞

RFC編集者のための資金は現在、 Internet Societyによって提供されています。