|
ネットワーク WG Request for Comments： 3552 BCP： 72 分類：ベストカレントプラクティス |
E. Rescorla RTFM, Inc. B. Korver Xythos Software Internet Architecture Board IAB 2003年7月 |
この文書は、 インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、 改善するために議論と示唆を求めるものです。 このメモの配布に制限はありません。
Copyright (C) The Internet Society (2003). All Rights Reserved.
すべてのRFCには、 「セキュリティについての考慮事項」の章をもつことが要求されています。 これまで、このような章の記述は、十分ではありませんでした。 本書は、RFC著者に良い「セキュリティについての考慮事項」の章の書き方についてのガイドラインを提供します。
すべてのRFCには、 「セキュリティについての考慮事項」の章を立てることがRFC 2223によって要求されています。 この目的は、 文書の著者に「設計においてセキュリティを考慮すること」を促すことと、 読者に関連するセキュリティ論点を知らしめることの両方にあります。 このメモは、両目的からRFC著者にガイダンスを提供することを意図しています。
本書は、3部から構成されています。
第1部は、セキュリティ入門と共通用語の定義を組み合わせたものです。
第2部は、
「セキュリティについての考慮事項」を書くための一連のガイドラインです。
第3部は、一連の例示です。
本書中のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は、BCP 14, RFC 2119 [KEYWORDS] に記述されているように解釈されるべきものです。
大部分の人々は、セキュリティについて、 プロトコルやシステムについての一枚岩のような属性であるかのように語ります。 しかし、これは明らかに誤りであることに気づきます。 むしろ、セキュリティは、関連性をもちながら、 ある程度独立した一連の属性といえます。 これらの属性のすべてが、 すべてのアプリケーションに要求されるとは限りません。
我々は、セキュリティの目標事項を、 通信セキュリティ(通信を防護することに関するものと、 運用管理的セキュリティもしくはシステムセキュリティ(システムを防護すること)に関するものとに大まかに分けることができます。 通信はシステムによって行われ、システム間は通信チャネルによるので、 これらの目標は明らかに不可分ですが、それらは、 また、独立に提供できます。
著者によって、通信セキュリティの目標事項の分類は異なります。 我々が発見した最も有用な分類は、3つの主要な分野に分けることです。： 守秘性、 データインテグリティおよびエンティティ間の認証です。
セキュリティについて考えるとき、 大部分の人々が「守秘性」のことを考えます。 守秘性は、 「あなたのデータが意図されないユーザから秘密に保たれること」を意味します。 通常、これらの意図されないユーザは、まさに盗聴者です。 攻撃者があなたの電話を盗聴するとき、 あなたの守秘性がリスクにさらされます。
明らかに、あなたが秘密をもつ場合、 おそらく他者がそれらを発見することを懸念します。 それゆえ、あなたは、最低限、守秘性を維持することを望みます。 映画の中でスパイが風呂場に入って行き、 盗聴させないように水を出すのを観るとき、 彼らが探している属性は守秘性です。
2番目の主要な目標は、「データインテグリティ」です。 ここでの基本的なアイディアは、「我々は、 受け取ったデータが送信者が送ったデータと同一であることを確認したい」ということです。 紙に基づくシステムにおいて、一定のデータインテグリティは、 自動的に備わっています。 あなたがペンで書かれた手紙を受け取ったとき、 「ペンのインクは紙から消すのが難しいので、 攻撃者によって削除された単語は無い」と確信をもつことができます。 しかし、攻撃者は容易に紙上に印を書き加えたり、 メッセージの意味を完全に変えた可能性があります。 同様に、メッセージを切り詰めるためにページを短くすることは容易です。
一方、電子的な世界においては、すべてのビットは同様に見えるので、 転送中のメッセージを不正に変更することは、簡単なことです。 単にメッセージを回線から削除し、適当な箇所を切り取り、 適当なデータを加え、任意の新しいメッセージを生成するだけでよく、 受信者は賢くありません。 これは、攻撃者にとって、手紙を取り上げ、 新しい紙を買ってそのメッセージをコピーし、 意のままに変更することと、道徳的には同義です。 すべてのビットは同様に見えるので、電子的に行うことは、かなり容易です。
我々が関心をもつ3番目の属性は、「エンティティ間の認証」です。 我々がこれによって意味するのは、「我々は、 『通信の一端が意図された相手であること』を知っていること」です。 エンティティ間の認証無しには、守秘性を提供することも、 データインテグリティを提供することも非常に困難です。 例えば、我々がAliceからメッセージを受け取る場合、 データインテグリティの属性は、「これは、 実際に攻撃者ではなくAliceによって送られたこと」を我々が知っていない限り、 あまり有用ではありません。 同様に、我々は、Bobに秘密のメッセージを送ることを望む場合、 我々が実際に秘密のメッセージを攻撃者に送っているならば、 我々にとって、あまり価値がありません。
「エンティティ間認証は、 非対称的に提供される可能性があること」を銘記してください。 あなたが誰かに電話をかけるとき、あなたは、 「正しい相手と話している」と確信を持つことができます。(あるいは、 少なくとも「あなたがかけた電話番号のところにいる人が出ている」と確信を持つことができます。)他方、 彼らがcaller IDをもたない場合、電話を受けた者は、 誰からかかってきたか分かりません。 電話を誰かにかけることは、受信者認証の例です。 なぜならば、あなたは、電話を取った者が誰であるかを知っていますが、 相手は送信者について何も知らないからです。
メッセージングの状況において、あなたは、しばしば、 特定のメッセージの送信者の身元を確立するためにエンティティ間認証を使うことを望みます。 このような文脈において、 この属性は「データ源泉認証(Data Origin Authentication)」と呼ばれます。
終点認証を提供するシステムは、「一方が、 通信相手の身元を確認すること」を許容します。 システムがデータインテグリティを提供するとき、受信者は、 送信者の身元と「彼は、 送信者が送ろうとしたデータを受け取っていること」の両方に確信をもつことができます。 しかし、彼は、 必ずしもこの事実を第三者に実証することができるとは限りません。 これを実現する機能は、「否認防止」と呼ばれています。
否認防止が望まれる状況が多くあります。 一方が一方的に廃棄したい契約について両者が署名した状況を検討します。 彼は、「もともとそれに署名しなかった」と主張する可能性があります。 否認防止は、彼がそのようにすることを防ぎ、それゆえ相手方も保護します。
残念ながら、否認防止は、 実際に達成することは極めて困難である可能性があり、 単純なアプローチは一般に不適格です。 4.3には、その困難性の一端を記述してあります。 これは、一般に、「2者の利害は、 一致していない(一方が他方が否定しようとすることを証明することを望む)」という事実に依拠しています。
一般に、システムセキュリティは、 人のマシンとデータを防護することに関するものです。 その意図は、「マシンは、認可されたユーザのみによって、 所有者が意図した目的で使われる必要があること」です。 さらに、それらは、それらの目的のために利用可能である必要があります。 攻撃者は、正規のユーザの資源を奪うことができてはいけません。
大部分のシステムは、 完全に公衆がアクセス可能であることを意図していません。 むしろ、それらは、 特定の認可された個人によって使われることが意図されています。 多くのインターネットサービスは、 すべてのインターネットユーザが利用可能ですが、 それらのサーバーでさえ、通常、 特定のユーザ向けに広範なサービスを提供しています。 例えば、しばしば、Webサーバーは、 あらゆるユーザにデータを提供しますが、 ページを変更する権限を特定のユーザに限定しています。 一般公衆によるこのような変更は、「不正な用法」です。
認可されたユーザであることは、 「システムを自由に操って良いこと」は意味しません。 上述のように、活動によっては、認可されたユーザのみに制限されるもの、 特定のユーザのみに制限されるもの、 さらにシステム管理者以外のユーザには禁止されているものがあります。 さらに場合によっては、 通常は許容されている活動さえ禁止される可能性があります。 例えば、ユーザは、電子メールを送ることが許可されているが、 一定の大きさ以上のファイルやウイルスに感染したファイルを送信することが禁止されている可能性があります。 これらは「不適切な用法」の例です。
我々の3番目の目標は、 「システムは正規のユーザが利用可能である必要があること」でした。 このような用法を脅かす、幅広く多用な攻撃が可能です。 このような攻撃は、まとめてサービス妨害攻撃と呼ばれます。 サービス妨害攻撃は、しばしば、しかけるのが極めて容易である一方、 止めるのが困難です。 多くのこのような攻撃は、マシンの資源を浪費するように設計されており、 正規のユーザに対するサービスを困難にしたり不可能にしたりします。 他の攻撃には、標的マシンをクラッシュさせ、 完全にユーザのサービスを妨害するものがあります。
脅威モデルは、 「攻撃者が資源に対して行うことができると想定されている」能力を記述します。 これには、情報、計算処理能力、 およびシステムコントロールの観点から、 攻撃者が利用可能なリソースを示す情報などが含まれる必要があります。 脅威モデルの目的には、ふたつあります。 まず、我々は、我々が懸念する脅威を識別することを望みます。 次に、我々は、一定の脅威を範疇外とするルールを定めることを望みます。 ほとんどすべてのセキュリティシステムが十分に熱心で資源をもつ攻撃者に対して脆弱です。
インターネット環境には、良く理解された脅威モデルがあります。 一般に、我々は、 「プロトコル交換に参加しているエンドシステム自体は、 侵されていない」と想定します。 エンドシステムのひとつが侵されたとき、 攻撃に対して防護することは極めて困難です。 しかし、これらの状況下における被害を最小化するプロトコルを設計することは可能です。
逆に、我々は、「攻撃者は、 エンドシステムが通信を行っている通信チャネルをほとんど完全にコントロールできる」と想定します。 これは、「攻撃者は、 ネットワーク上のいかなるPDU (Protocol Data Unit)をも読むことができ、 検知されずに偽装されたパケットを回線上に削除・変更・挿入できること」を意味します。 これは、 信用できるマシンから来たように見えるパケットを生成できることを含みます。 それゆえ、 たとえあなたが通信しようとする相手のエンドシステム自体はセキュアである場合でも、 インターネット環境は、 「あるシステムから来たと示すパケットが実際にそうである」という保証は提供しません。
「PDUの意味は、レベルに応じて異なること」を理解することが重要です。 IPレベルにおいて、PDUは、IPパケットを意味します。 TCPレベルにおいて、これは、TCPセグメントを意味します。 アプリケーション層において、これは、 ある種のアプリケーションPDUを意味します。 例えば、電子メールのレベルにおいて、RFC-822メッセージか、 ひとつのSMTPコマンドのいずれかを意味する可能性があります。 HTTPレベルにおいて、 リクエストもしくはレスポンスを意味する可能性があります。
既述のように、資源をもつ熱心な攻撃者は、 通信チャネル全体をコントロールできます。 しかし、数多くの攻撃は、さほど資源をもたない攻撃者によって、 しかけられる可能性があります。 数多くの既知の攻撃は、 ネットワークについて限られたコントロール能力しかもたない攻撃者によって、 しかけられる可能性があります。 例えば、パスワード盗聴攻撃は、 任意のパケットを読むことができる攻撃者によってしかけられる可能性があります。 これは、一般に、 待ち伏せ攻撃 [INTAUTH] と呼ばれます。
逆に、Morrisのシーケンス番号推測攻撃 [SEQNUM] は、 任意のパケットを読むことはできないが書ける攻撃者によって、 しかけられる可能性があります。 攻撃者にネットワークに書き込むことを要求する攻撃は、 積極的な攻撃として知られています。
それゆえ、攻撃を体系化する有用なやり方のひとつは、 攻撃をしかけるのに要求される能力に基づいて分類することです。 この節の残りでは、これらの分野について記述し、 各分野のいくつかの例を提供します。
待ち伏せ攻撃において、攻撃者は、 ネットワークからパケットを読みますが、書き込みません。 このような攻撃をしかける最も単純なやり方は、 被害者と同じLAN上にいることです。(イーサーネット、 802.3およびFDDIを含む)最も卑近なLANの設定において、 回線上のいかなるマシンでも、 同一のLAN上のいかなる他のマシン宛のすべてのトラフィックを読むことができます。 「スイッチングハブでは、 特定のマシン宛てのトラフィックは、 そのマシンが存在するセグメントだけに送られるので、 この種の盗聴を実質的により困難にすること」を覚えておいてください。
同様に、ふたりふたりの被害者のマシン間の通信パスにおいて、 ホストをコントロールできる攻撃者は、 彼らの通信に待ち伏せ攻撃をしかけることができます。 そのトラフィックが侵されたマシンを通るようにルーティングインフラストラクチャを侵すことも可能です。 これは、被害者のマシン上で待ち伏せ攻撃を行うように、 ルーティングインフラストラクチャに対する積極的な攻撃を含む可能性があります。
無線通信チャネルには、特別に考慮に値する事項があり、 特に最近人気が高まっている802.11を使うような無線に基づくLANについて考慮する価値があります。 データは、単に、よく知られた周波数でブロードキャストされるので、 攻撃者は、その転送内容を単に受け取ることができる必要があるだけです。 このようなチャネルは、待ち伏せ攻撃に対して特に脆弱です。 多くのこのようなチャネルが暗号技術的防護を備えていますが、 品質が低く、 ほとんど使用に耐えないことがよくあります [WEP]。
一般に、攻撃の目標は、 「送信者と受信者がプライベートに保ちたい情報を入手すること」です。 このプライベート情報は、電子的な世界で有用なクレデンシャル、 かつ／または、 ビジネスの機密情報のような電子的な世界の外界で有用なパスワードやクレデンシャルを含む可能性があります。
待ち伏せ攻撃の古典的な例は、 もともとプライベートなデータを回線から盗聴することです。 例えば、SSLは広範に利用可能であるにもかかわらず、 多くのクレジットカード取引は、 いまだに平文でインターネット上を転送されています。 攻撃者は、そのようなメッセージを盗聴し、 詐欺的な取引を行うのに使うことができるクレジットカード番号を復元することができます。 さらに、ビジネスの機密情報は、日常的に平文の電子メールで、 ネットワーク上を送られています。
待ち伏せ攻撃のこれ以外に例に、パスワード盗聴があります。 パスワード盗聴は、資源を無権限に利用するために行われます。 多くのプロトコル([TELNET], [POP], [NNTP] 等)は、 クライアントをサーバーに認証させるために、共有パスワードを使います。 しばしば、このパスワードは、クライアントからサーバーに、 通信チャネル上を平文で転送されます。 それゆえ、このトラフィックを読むことができる攻撃者は、 パスワードを捕捉し、それをリプレイすることができます。 換言すれば、攻撃者は、サーバーに対してコネクションを開始し、 クライアントのふりをして、 捕捉されたパスワードを使ってログインすることができます。
「攻撃のログイン段階は、積極的であるが、 実際のパスワード捕捉フェイズは、待ち伏せによること」を銘記してください。 さらに、サーバーがコネクションの起点アドレスをチェックしない限り、 ログイン段階では、 いかなる特別なネットワークのコントロールを要求しません。
多くの暗号技術的プロトコルは、「オフライン攻撃」の対象となります。 このようなプロトコルにおいて、攻撃者は、 被害者の秘密鍵を使って処理されたデータを復元し、それから、 その鍵について暗号技術的攻撃をしかけます。 パスワードは、特に脆弱な標的を作ります。 なぜならば、それらは、典型的には低エントロピーであるからです。 パスワードに基づく、 数多くの有名なチャレンジ&レスポンスプロトコルは、 「辞書攻撃」に対して脆弱です。 攻撃者は、チャレンジレスポンスを捕捉し、 (辞書ファイルのような)よくある単語リストから正しい応答をもたらすパスワードを発見するまで、 各項目を試す処理を行います。
NISが使われているとき、同様の攻撃は、 ローカルネットワーク上でしかけられる可能性があります。 Unixパスワードは、一方向性関数を使って暗号化されますが、 このような暗号化されたパスワード [KLEIN] を解読するツールが存在します。 NISが使われるとき、暗号化されたパスワードは、 ローカルネットワーク上を転送され、それゆえ、 攻撃者はパスワードを盗聴し攻撃することができます。
これまで、 パスワードファイルを復元するために積極的な攻撃によってOSの小さなセキュリティホールを攻略することも可能でした。 次に、これらのセキュリティホールは、 前述のオフラインのパスワード復元テクニックを使うことによって、 実際のアカウントにすることに成功する可能性があります。 それゆえ、我々は、 低レベルの積極的な攻撃をオフラインの待ち伏せ攻撃と組み合わせます。
攻撃がネットワークへの書き込みを含むとき、我々は、 これを積極的な攻撃と呼びます。 IPがIPsec無しで使われるとき、 送信者のアドレスについての認証機能はありません。 その結果、 攻撃者が任意の発信元アドレスをもったパケットを作ることは、 自然なことです。 我々は、これを詐称攻撃(スプーフィング攻撃)と呼びます。
特定の状況下において、このようなパケットは、 ネットワークによってフィルタリングされる可能性があります。 例えば、多くのパケットフィルタリングファイアウォールは、 「外部」インターフェィスに到着する「内部」ネットワークの発信元アドレスをもったすべてのパケットをフィルタリングしています。 しかし、 「これはファイアウォール内部の攻撃者に対する防護を提供しないこと」を銘記してください。 一般に、設計者は、 「攻撃者はパケットを偽装できる」と想定する必要があります。
しかし、パケットを偽装する能力は、 任意のパケットを受け取る能力とは関連していません。 事実、偽装されたパケットを送ることができてもレスポンスを受け取らない積極的な攻撃があります。 我々は、これらを「ブラインド攻撃」と呼びます。
「すべての積極的な攻撃がアドレス偽装を要求するわけではないこと」を銘記してください。 例えば、TCP SYNサービス妨害攻撃 [TCPSYN] は、 送信者のアドレスを偽装することなく、 しかけられて成功する可能性があります。 しかし、攻撃が発見された場合、 「身元を隠すために他人のアドレスにを偽装すること」は、 よくあることです。
各プロトコルは、特定の積極的な攻撃に影響されやすいですが、 経験では、「数多くの攻撃の共通パターンがあらゆるプロトコルに当てはまること」を示しています。 次節では、数多くのこのようなパターンを記述しており、 既知のプロトコルに応用されたそれらの具体的な例を提供しています。
リプレイ攻撃において、 攻撃者はメッセージの順序を回線外に記録し、 それらを当初受け取った主体に再送します。 「攻撃者はメッセージを理解できる必要がないこと」を銘記してください。 単に、それらを補足して再送するだけでよいのです。
例えば、クレジットカードによる購入や株取引のように、 何らかのサービスを要求するためにS/MIMEメッセージが使われる事例を検討します。 攻撃者が、被害者の邪魔をするだけの場合、 サービスを2回実行することを望む可能性があります。 攻撃者はメッセージを補足し、 たとえそれを理解できなくても再送することにより、 結果的にトランザクションを2回実行させることが可能です。
メッセージ挿入攻撃において、攻撃者は、 いくつかの選択された属性についてメッセージを偽装し、 ネットワーク中に挿入します。 しばしば、このメッセージは、 攻撃者の身元を偽装するために偽装された発信元アドレスをもちます。
例えば、サービス妨害攻撃は、 標的とされたホストに指図された一連の偽のTCP SYNパケットを注入することによって、しかけられる可能性があります。 標的となるホストは、自身のSYNで応答し、 新しいコネクションのためにカーネルデータ構造を用意します。 攻撃者は、3ウェイハンドシェイクを完結させないので、 用意しているコネクション終点は、 ひたすらカーネルメモリを埋めながら待つことになります。 典型的なTCPスタック実装は、 この「半開き」状態のコネクション数を制限しており、 この制限に達したとき、正規のホストからも、 それ以上のコネクションを開始することができません。 「攻撃者は被害者のSYNを処理する必要がないので、 この攻撃はブラインド攻撃であること」を覚えておいてください。
メッセージ削除攻撃において、攻撃者は、 回線上からメッセージを削除します。 Morrisのシーケンス番号推測攻撃 [SEQNUM] は、 しばしば、メッセージ削除攻撃に成功することを要求します。 このブラインド攻撃において、アドレスが偽装されているホストは、 攻撃されているホストから偽装されたTCP SYNパケットを受け取ります。 このSYNパケットの受信は、RSTを生成します。 これは、不正なコネクションを切断します。 RSTを送らないようにするために(攻撃が成功するように)Morrisは、 SYNパケットが失われて応答されないように、 ホストのキューのバッファを溢れさせることを記述しています。
メッセージ変更攻撃において、攻撃者は、 回線からメッセージを削除し、それを変更し、 ネットワーク中に再投入します。 攻撃者がメッセージ中にデータを送ることを望むが、同時に、 その一部を変更することを望む場合、この種の攻撃は特に有効です。
攻撃者がインターネット越しの物品の購入を攻撃することを望む事例を考えます。 攻撃者は、被害者のクレジットカード番号をもっていないので、 被害者が発注するのを待ち、配送先を自身のものに(また、 おそらく物品の記述を)書き換えます。 「この特定の攻撃は、 攻撃者がクレジットカード番号をメッセージの原本からカットして、 新しいメッセージにペーストするので、 カットアンドペースト攻撃として知られていること」を覚えておいてください。
「カットアンドペースト攻撃」の興味深い他の例は、 [IPSPPROB] によって提供されています。 IPsec ESPが、いかなるMAC無しに使われている場合、 攻撃者が同一マシン上の被害者宛の暗号化されたトラフィックを読むことは可能です。 攻撃者は、コントロールしているポートに対応するIPヘッダを、 暗号化されたIPパケットに添付します。 パケットがホストによって受信されるとき、これは自動的に復号され、 攻撃者のポートに転送されます。 同様のテクニックが、 セッションハイジャック攻撃をしかけるのに使われます。 両攻撃は、 暗号化する際に常にメッセージ認証を使うことによって避けることができます。 この攻撃は、以下の場合にのみ可能であることを銘記してください。
中間者による攻撃は、 上記テクニックを特別な形態で組み合わせます。： 攻撃者は、 「送信者から受信者宛」と「受信者から送信者宛」のふりをするために通信ストリームを破壊します。：
Alice と Bob が考えていること：
Alice <------------------------------------------> Bob
起きていること：
Alice <----------------> 攻撃者 <--------------> Bob
これは、上記の形態の攻撃とは根本的に異なります。 なぜならば、これは、データストリーム自体ではなく、 通信主体の身元を攻撃するからです。 したがって、通信ストリームのインテグリティを提供する多くのテクニックは、 中間者による攻撃に対して防護するのに不十分です。
中間者による攻撃は、 プロトコルが「エンティティ間認証」を欠いているとき、常に可能です。 例えば、攻撃者がTCPハンドシェイクにおけるクライアントTCPコネクションをハイジャックできる場合、 (おそらくサーバーが応答する前にクライアントのSYNに応答することによって)攻撃者は、 サーバーへのコネクションを開いて、 中間者による攻撃を始めることができます。 「中間者による攻撃をARP詐称によってローカルネットワーク上でしかけること」もよくあることです。 (攻撃者は、ARPを被害者のIPアドレスと自身のMACアドレスで詐称します。) この種の攻撃をしかけるためのツールが入手可能です。
「中間者による攻撃を予防するために、 トランザクションの一方を認証することのみが必要不可欠であること」を銘記してください。 このような状況において、両者は、 一方のみが認証されている協定を確立することができます。 このようなシステムにおいて、攻撃者は、 認証されていない相手のふりをして、協定を開始できますが、 正規のコネクション上を送られたデータを転送したり、 それにアクセスできません。 これは、Web電子商取引においては、許容可能な状況です。 ここでは、サーバーのみが認証される必要があります。(あるいは、 クライアントは、 クレジットカード番号のような何らかの非暗号技術的メカニズムによって別個に認証されます。)
実際には、 「攻撃者がすべてのパケットを読むことと生成することは同等に容易である」という想定は誤りです。 なぜならば、インターネットは、完全には接続されていないからです。 これには、ふたつの主要な示唆があります。
データグラムが、ホスト間を転送されるようにするためには、一般に、 何ヵ所か中間リンクやゲートウェイを通過しなければなりません。 このようなゲートウェイは、通常、 パス上を転送されるいかなるデータグラムをも読むこと、変更すること、 および削除することができます。 あなたがパス上にいる場合、これにより多様な攻撃をしかけることが、 はるかに容易になります。
当然ながら、パス外のホストは、 いかなるホストからでも来たように見える任意のデータグラムを転送できますが、 他のホストを意図したデータグラムを受け取ることができるとは限りませんません。 それゆえ、攻撃がデータを受け取ることができることに依拠する場合、 パス外のホストは、まず、自身をパス上におくために、 トポロジーを壊さなければなりません。 これは決して不可能ではありませんが、よくあるとも限りません。
アプリケーションプロトコル設計者は、 「すべての攻撃者はパス外にいる」と想定してはなりません(MUST NOT)。 可能であれば、プロトコルは、 ネットワークを完全にコントロールできる攻撃者からの攻撃に耐えるように設計される必要があります(SHOULD)。 しかし、設計者には、パス上の攻撃者のみならず、 パス外の攻撃者によってしかけられる攻撃をより重視することが期待されます。
パス上の特殊ケースは、同一リンク上にいることです。 状況によっては、ローカルネットワーク上のホストと、 そうでないホストを区別することが望まれます。 このための標準的テクニックは、IP TTLの値 [IP] を検証することです。 TTLは、各転送者によって、減算されなければならないので、 プロトコルは、「TTLが255にセットすること」と、 「すべての受信者がTTLを検証すること」を命令できます。 次に、受信者は、「確認しているパケットは、 同一のリンク上からのものである」と信じる根拠をもちます。 トンネリングシステムがある状態でこのテクニックを使用するときは注意が必要です。 そのようなシステムでは、 TTLを減算せずにパケットを通過させる可能性があるからです。
各システムのセキュリティ要件は固有ですが、 一定の共通要件が数多くのプロトコルにあります。 単純なプロトコル設計者がこれらの要件に直面したとき、しばしば、 彼らは、たとえより良いソリューションが利用可能でも、 明らかではあるがセキュアでないソリューションを選択します。 この章は、多くのプロトコルにある数多くの論点や、 それらに対応する際に有用である可能性があるセキュリティ技術の共通部分を記述します。
要するに、 資源に対するアクセスコントロールを行うすべてのシステムは、 ユーザを認証する何らかのやり方を必要とします。 ほとんど無数の、このようなメカニズムが、 この目的のために設計されてきました。 次節以降では、これらのテクニックのいくつかを記述しています。
最も普及したアクセスコントロールメカニズムは、 単純なユーザ名／パスワードです。 ユーザは、利用しようとしているホストに、 ユーザ名と再利用可能なパスワードを入力します。 このシステムは、単純な待ち伏せ攻撃に対して脆弱です。 ここで、攻撃者は、回線外でパスワードを盗聴し、 新しいセッションを開始し、そのパスワードを入力します。 この脅威は、TLSやIPSECのような暗号化されたコネクション上にそのプロトコルを置くことによって緩和できます。 防護されていない(平文)ユーザ名／パスワードシステムは、 IETF標準において許容されていません。
ユーザ名／パスワードよりも高いセキュリティを要求するシステムは、 しばしば、ワンタイムパスワード [OTP] スキームかチャレンジレスポンスのいずれかを採用します。 ワンタイムパスワードスキームにおいて、ユーザには、 パスワードのリストが提供され、これは、 順番に毎回ひとつずつ使わなければならないものです。 (しばしば、これらのパスワードは、何らかの秘密鍵から生成されるので、 ユーザは、単純に、順番に次のパスワードを計算できます。) SecureIDやDES Goldは、このスキームの流派です。 チャレンジレスポンスのスキームにおいて、ホストとユーザは、 何らかの秘密を共有します。(これは、しばしば、 パスワードとして現れます。)ユーザを認証するために、 ホストは、ユーザに(乱雑に生成された)チャレンジを提供します。 ユーザは、チャレンジとその秘密に基づくいくつかの関数を計算し、 それをホストに提供し、ホストはそれを検証します。 しばしば、この計算は、 DES Goldカードのような携帯デバイスで処理されます。
両種のスキームは、リプレイ攻撃に対する防護を提供しますが、しばしば、 「オフライン鍵検索攻撃」(待ち伏せ攻撃の 1 形態)に対して脆弱なままです。： 既述のように、しばしば、ワンタイムパスワードやレスポンスは、 共有された秘密から計算されます。 攻撃者が使われている関数を知っている場合、彼は、 正しい出力を作り出すものを発見するまで、 すべての共有された秘密の候補を単に試すことができます。 共有された秘密がパスワードであり、 「辞書攻撃」をしかけることができる場合、これは容易になります。 (「単なる乱雑な文字列ではなく、 通常の単語(もしくは文字列)のリストを試すこと」を意味します。) これらのシステムは、しばしば、積極的な攻撃に対しても脆弱です。 通信セキュリティがセッション全体について提供されない限り、 攻撃者は、単に、認証が行われるまで待って、 コネクションをハイジャックすることができます。
「チャレンジレスポンス」タイプのシステムは、 ユーザが生成したパスワードの代わりに乱雑に生成された共有鍵を使うことによって、 辞書攻撃に対してセキュアにできます。 鍵が十分に大きい場合、鍵検索攻撃は非現実的になります。 このアプローチは、ユーザによって記憶されたり打鍵されるときよりも、 鍵が終端に設定されるときに最もうまくいきます。 なぜならば、ユーザには、十分に長い鍵を覚えるのに問題があるからです。
パスワードに基づくシステムのように、共有鍵システムは、 管理問題をわずらいます。 通信主体の各ペアは、自らが合意した鍵をもたなければなりません。 これは、そこにたくさんの鍵がある状況をもたらします。
数多くの鍵の問題を解決するためのひとつのアプローチは、 認証する主体間を仲介するオンラインの「信用できる第三者(trusted third party)」を使うことです。(一般的に KDC(Key Distribution Center)と呼ばれる)信用できる第三者は、 共通鍵またはパスワードをシステム中の各主体と共有します。 各主体は、まず、KDCと連絡を取ります。 KDCは、ランダムに生成されて両者の鍵で暗号化された共通鍵を含むチケットを各主体に提供します。 正しいペアのみが共通鍵を復号できるので、 そのチケットを信用できる協定を確立するために使うことができます。 今日に至るまで最も普及したKDCシステムは、 [KERBEROS] です。
単純なアプローチは、[TLS] もしくは [S/MIME] のように、 すべてのユーザが何らかのプロトコル固有のやり方で認証するのに使う証明書 [PKIX] をもつようにすることです。 証明書は、 エンティティの身元をその公開鍵に結合する署名されたクレデンシャルです。 証明書の署名者は認証局(CA)であり、 この証明書自体は、何らかの上位CAによって署名される可能性があります。 このシステムが働くようにするために、ひとつ、 もしくは複数のCAにおける信頼は、オフラインで確立されなければなりません。 このようなCAは、「トラステッドルート」もしくは「ルートCA」と呼ばれます。 クライアント／サーバーシステムにおけるこのアプローチに対する主要な障害は、 「クライアントが証明書をもっていることを要求すること」であり、 これは採用の問題である可能性があります。
上記のスキームより良いやり方ありますが、それらは、典型的には、 通信セキュリティ(最低限、 メッセージインテグリティ)がコネクションをセキュアにするために採用されない限り、 あまりセキュリティを高めません。 なぜならば、そうしないと、攻撃者は、まれに、 認証が行われた後にコネクションをハイジャックできるからです。 数多くのプロトコル([EKE], [SPEKE], [SRP]) が、セキュアにユーザのパスワードを共有鍵に入れるようにすることができ、 これは、暗号技術的プロトコルへの入力として使うことができます。 これらのプロトコルの採用についての障害のひとつは、 「それらの知的財産権の状態が全く不明確であること」 でした。 同様に、そのユーザは、 公開鍵証明書を使って認証することができます(例：S-HTTPクライアント認証)。 これらの手法は、典型的には、 より完成されたセキュリティプロトコルの一部として使われています。
ホスト認証は、特別な問題をもたらします。 ごく普通に、サービスのアドレスは、例えばURL [URL] のように、 DNSホスト名を使って表現されます。 このようなサービスをリクエストするとき、 「相手が証明書をもっている者であることのみならず、 その証明書が期待されるサーバーの身元に対応することも」確認する必要があります。 重要なことは、 「証明書と期待されるホスト名をセキュアに結合すること」です。
例えば、通常、リクエストが一定のホスト名に対するものである場合、 証明書が身元をIPアドレスの形態で含むことは許容できません。 これは、「エンド to エンド」セキュリティを提供しません。 なぜならば、ホスト名とIPの対応付けは、 セキュアな名前解決 [DNSSEC] が使われない限りセキュアでないからです。 これは、ホスト名がアプリケーション層に現れながら、 認証が何らかの下位層において行われるとき、特別な問題です。
セキュリティ機能をプロトコル中に提供することは、 困難である可能性があります。 認証と鍵確立のメカニズムを選択する問題以外に、 それらをプロトコルに統合する必要があります。 (IPsecとTLSに組み込まれた)この問題に対する対応のひとつは、 下位層のセキュリティプロトコルを作り、 「新しいプロトコルは、 そのプロトコルの上で動作するようにする」と主張することです。 最近、普及したこれ以外のアプローチは、 「一般的なアプリケーション層のセキュリティフレームワークを設計すること」です。 このアイディアは、「あなたがプラグ可能な形態で、 様々なセキュリティメカニズムを交渉することを認めるプロトコルを設計すること」です。 次に、アプリケーションプロトコル設計者は、 セキュリティプロトコルPDUを、 そのアプリケーションプロトコルで運ぶようにします。 このようなフレームワークの例には、GSS-API [GSS] やSASL [SASL] が含まれます。
一般的なフレームワークアプローチには、数多くの問題があります。 まず、これは、「ダウングレード攻撃」に対してかなり影響を受けます。 ダウングレード攻撃において、積極的な攻撃者は、 両者がそのままの状態よりも弱い防護の状態で交渉するようにするために交渉過程を操作します。 インテグリティチェックを交渉と鍵確立の両方が完了した後に行うことは可能ですが、 このインテグリティチェックの強度は、 必然的に共通のアルゴリズムの最も弱いものに制限されます。 この問題は、いかなる交渉アプローチについても存在しますが、 一般的なフレームワークは、 アプリケーションプロトコルの著者が適切な基盤となっているメカニズムについて真剣に検討せずに、 単にフレームワークを仕様とすることによって悪化させます。 なぜならば、そのメカニズムは、 提供されるセキュリティの程度に応じて極めて広範になる可能性があるからです。
その他の問題は、「どのようにフレームワーク中の様々なセキュリティ機能がアプリケーション層プロトコルと相互作用するかが自明であるとは限らないこと」です。 例えば、SASLは、単なる認証フレームワークとして使うことができます。 (この場合、SASL交換がなされますが、 以降のコネクションは防護されません。)しかし、 GSS経由などのトラフィック防護をメカニズムとして交渉できます。 「どのような状況でトラフィックの防護がオプションになるか」および「何が必要か」を知ることが、 脅威モデルを考慮する上で要求されます。
一般に、認証フレームワークは、 新しいプロトコルが既存のレガシーな認証システムをもったシステムに追加される場合において最も有用です。 既存のサイトにより良い認証を提供するために、フレームワークは、 レガシーな認証システムと全く同じことを繰り返すことを強いずに新規インストールができるようにします。 システムのセキュリティ要件が明確に識別され、 数種類の形態の認証のみが使われているとき、 単一のセキュリティメカニズムを選択することは、 シンプルさと予測可能性をもたらします。 一定のフレームワークが使われる状況において、設計者は、 フレームワークのオプションを注意深く検討し、 特定の脅威モデルに対して適切なメカニズムのみを指定する必要があります(SHOULD)。 フレームワークが必要不可欠な場合、設計者は自ら設計せずに、 確立したものの中のひとつを選択する必要があります(SHOULD)。
否認防止のための単純なアプローチは、 単にコンテンツ上で公開鍵デジタル署名を使うことです。 発信者(署名者)であることを望む主体は、 当該メッセージにデジタル的に署名します。 相手(署名利用者)は、後で、 「一定時点において署名者が異議を唱えられているメッセージに合意していたこと」 の証明としてデジタル署名を指すことができます。 残念ながら、このアプローチでは不十分です。
署名する主体がメッセージを否認するための最も容易なやり方は、 「プライベート鍵が侵されてしまい、 どこかの攻撃者が(署名利用者であるとは限りませんが)異議を唱えられているメッセージに署名してしまった」と主張することによります。 この攻撃に対して防護するために、署名利用者は、 「署名者の鍵が署名時点において侵されていないこと」を実証する必要があります。 これは、証明書失効情報がアーカイブ化されたストレージ、および、 メッセージが署名された時刻を確立するためのタイムスタンプサーバーを含む実質的なインフラストラクチャを要求します。
さらに、署名利用者は、署名者を騙して、 署名しようとしているメッセージとは違うメッセージに署名させることを試みる可能性があります。 この問題は、キヨスクのような状況で、 特に署名利用者が署名者が署名に使うインフラストラクチャをコントロールするとき、 厳しくなります。 多くの状況において、署名する主体の鍵は、 スマートカードに保存されますが、署名されるメッセージは、 署名利用者によって示されます。
これらすべての複雑性は、 否認防止を実際に配備するのが困難なサービスにします。
認可は、 認証された主体が特定の資源もしくはサービスにアクセスする権限を有するか否かを判定する過程です。 密接に関連していますが、「認証と認可は、 別個のふたつのメカニズムであること」を認識することが重要です。 おそらく、この密接な組み合わせに起因して、認証は、 しばしば誤って認可を意味すると考えられています。 認証は単に主体を識別し、 認可は「人々が特定の行為をできる」か否かを定義します。
認可は、認証に依拠することが必要不可欠ですが、 認証単独では認可を意味しません。 むしろ、行為をするための認可をする前に、認可メカニズムは、 その行為が許可されているか否かを判定するように作られねばなりません。
認可メカニズムのよくある形態のひとつは、 ACL(アクセスコントロールリスト)です。 これは、資源にアクセスすることを認可されたユーザをリストするものです。 各資源に対する個々の認可を指定することは面倒であるので、資源は、 しばしば、親資源のACLが子資源に継承されるように階層的に配置されます。 これは、システム管理者に最高位のポリシーを設定し、 必要不可欠なときにそれらを優先することを許容します。
ユーザ名とパスワードのような単純な認証メカニズムを使うとき、 認証と認可の区別は、直感的に理解できますが(すなわち、 誰もがシステム管理者アカウントとユーザアカウントの相違を理解していますが)、 より複雑な認証メカニズムについては、しばしば、 その区別が無くなっています。
例えば、証明書について、有効な署名を示すことは、認可を意味しません。 署名は、信用できるルートを含む証明書チェインを辿らなければならず、 そのルートは、一定の条件の下で信用されなければなりません。 例えば、Acme MIS CAとAcme Accounting CAの両方がAcme Webサーバーによって「信用」されていても、 Acme MIS CAによって発行された証明書を保持するユーザは、 Acme Accounting CAによって発行された証明書を保持するユーザとは異なるWebアクセス権限をもつ可能性があります。
これらのより複雑な属性を強制するためのメカニズムは、 まだ完成していません。 ひとつのアプローチは、単に、 どの種類の証明書が浸透できるかを記述しているポリシーをACLに添付することです。 これ以外のアプローチは、証明書拡張 [PKIX, SPKI] としてか、 独立した「属性証明書」としてのいずれかによって、 その情報を証明書とともに運ぶことです。
セキュアな設計を施されたプロトコルは、 取り扱いに注意を要するすべてのトラフィックをセキュアにする何らかのメカニズムを適用しなければなりません。 (インテグリティ確保、認証および暗号化を意味します。) ひとつのアプローチは、[DNSSEC], [S/MIME], [S-HTTP] のように、 プロトコル自体をセキュアにすることです。 これは、そのプロトコルに最も適合するセキュリティを提供しますが、 正しく行うには相当な労力も要求します。
多くのプロトコルは、 利用可能なチャネルセキュリティシステムのひとつを使って、 適切にセキュアにすることができます。 我々は、最も普及しているふたつ(IPsec [AH, ESP] と [TLS] )を検討します。
ふたつのホスト間のトラフィックのためのIPsecプロトコル (具体的にはAHとESP)は、トランスポートセキュリティを提供できます。 IPsecプロトコルは、様々な粒度のユーザ認証をサポートします。 例えば、「IPサブネット」、「IPアドレス」、「FQDN (Fully Qualified Domain Name)」、個々のユーザ("Mailbox name")が含まれます。 これらの様々なレベルの識別は、 IPsecの本質的な部分であるアクセスコントロール機能に対する入力として採用されています。 しかし、IPsec実装によっては、 すべての身元タイプはサポートしていない可能性があります。 特に、セキュリティゲートウェイは、 「ユーザ to ユーザ」認証を提供しない可能性、または、 アプリケーションに認証情報を提供するメカニズムをもつ可能性があります。
AHもしくはESPが使われているとき、アプリケーションプログラマは、 (AHもしくはESPがシステム全体で利用可能とされている場合)何もしなくてよい可能性があり、 あるいは、特定のソフトウェアの変更を行う必要がある可能性があります。 (例：特定のsetsockopt()コールを追加する。) (使われているAHもしくはESPの実装に依存します。) 残念ながら、IPsec実装をコントロールするためのAPIは、 まだ標準化されていません。
他のプロトコルをセキュアにするためにIPsecを使うことについての主な障害は、 採用です。 現在、IPsecの主要な用途は、VPNアプリケーション用であり、 特にリモートネットワークアクセス用です。 セキュリティ管理者とアプリケーション開発者の間の極めて密接な調整無しには、 VPNの利用は、 個々のアプリケーションにセキュリティサービスを提供するのに適していません。 なぜならば、このようなアプリケーションには、 「どのセキュリティサービスが実際に提供されていたか」を判定することが困難であるからです。
「ホスト to ホスト」環境におけるIPsecの導入は、 はかばかしくありませんでした。 TLSのようなアプリケーションセキュリティシステムとは異なり、 非IPsecシステムにIPsecを追加することは、一般にカーネルを改変するか、 新しいドライバをインストールするか、いずれかによって、 OSの変更が必要です。 これは、 単に新しいアプリケーションをインストールすることより本質的に大きな労力を要します。 しかし、最近のバージョンの数多くの普及版OSは、 IPsecスタックをもっているので、配備は容易になりつつあります。
IPsecが確実に利用可能な環境において、これは、 アプリケーション通信トラフィックを防護するための可変的オプションを提供します。 保護されるべきトラフィックがUDPである場合、 IPsecやアプリケーション固有のオブジェクトセキュリティは、 唯一の選択肢です。 しかし、設計者は、 「IPsecが利用可能である」と想定してはなりません(MUST NOT)。 一般的なアプリケーション層プロトコルのためのセキュリティポリシーは、 「IPsecが意図された配備環境で利用可能である」と信じる何らかの根拠がない限り、 「IPsec が使われなければならない」と述べるだけではいけません(SHOULD NOT)。 IPsecが利用不能であり、かつ、トラフィックがTCPのみである環境において、 TLS は選択肢となる手法です。 なぜならば、アプリケーション開発者は、 TLS実装をパッケージに含めることによって、 容易にその存在を確保できるからです。
IPv6 の特別な事例において、AHとESPの両方を実装することが必須です。 それゆえ、「IPv6専用プロトコルまたはIPv6専用実装では、 AH/ESPはすでに利用可能である」と想定することは合理的です。 しかし、自動的鍵管理(IKE)は、実装することが要求されていないので、 プロトコル設計者は、 「これが在るであろう」と想定してはいけません(SHOULD NOT)。 [USEIPSEC] は、 IPsecが良い選択肢であるときのガイダンスの一端を提供します。
現在、最も普及したアプローチは、SSLもしくは、 その後継であるTLSを使うことです。 これらは、アプリケーション層においてTCPコネクションのためにチャネルセキュリティを提供します。 すなわち、これらは、TCP上で動作します。 SSLの実装は、プログラミングを容易にするために、 典型的にはバークレーのソケットのようなインターフェィスを提供します。 TLS関連のプロトコルソリューションを設計するとき、主要な論点は、 TLSを使って防護されたコネクションと、 そうでないものを区別することです。
使われているふたつの主要なアプローチは、 TLSコネクションについて別個の登録ポート番号を採用するアプローチ(例：HTTP over TLSのポートは、443番) [HTTPTLS] と、 [UPGRADE] もしくは [STARTTLS] のように基盤プロトコルからTLSに対して上方に交渉するためのメカニズムをもつアプローチです。 上方交渉アプローチが使われたとき、 「両者がTLSを使うことを望むとき、 攻撃者が平文によるコネクションを強いることができない」ように注意を払わなければなりません。
「TLSは、TCPまたはSCTPのような信頼できるプロトコルに依存すること」を銘記してください。 これは、2つの注目すべき困難をもたらします。 まず、これは、 UDPを使うデータグラムプロトコルをセキュアにするためには使えません。 次に、TLSは、IPsecが無いIP層の攻撃の影響を受けます。 典型的には、これらの攻撃は、 何らかのサービス妨害またはコネクション切断の形態をとります。 例えば、攻撃者は、SSLコネクションを切断するために、 TCP RSTを偽装する可能性があります。 TLSは、「切断攻撃」を検知するメカニズムをもっていますが、これらは、 被害者に攻撃されていることを単に知らせるだけで、 このような攻撃に直面したとき、コネクション存続性を提供しません。 逆に、IPsecが使われている場合、このような偽装されたRSTを、 TCPコネクションに影響を与えずに棄却できます。 偽装されたRSTもしくは、 TCPコネクション上の他のこのような攻撃が懸念される場合、 AH/ESPもしくはTCP MD5オプション [TCPMD5] が選好される選択肢です。
「ポート分離」アプローチがTLSに使われている場合、TLSは、 いかなるアプリケーション層トラフィックが送られる前に交渉されます。 これは、[HTTP] のようなバーチャルホストを使うプロトコルについて問題を起こす可能性があります。 なぜならば、サーバーは、「TLSハンドシェイクにおいて、 どの証明書をクライアントに提供するか」を知らないからです。 まだ広く普及するには新し過ぎますが、 TLSホスト名拡張 [TLSEXT] は、 この問題を解決するのに使うことができます。
TLSの利用における困難のひとつは、 「サーバーは証明書で認証されること」です。 これは、従前、 唯一の認証の形態がクライアントとサーバー間で共有されたパスワードであった環境において不便です。 認証されたサーバー無しにTLSを使うことを試みて(すなわち、 アノニマスDHもしくは、自己署名されたRSA証明書を使って)、 次に(SASL with CRAM-MD5のような)何らかのチャレンジレスポンスメカニズムを通じて認証します。
残念ながら、このSASLとTLSの組み合わせは、期待するほど強くはありません。 積極的な攻撃者が、このコネクションをハイジャックすることは容易です。 クライアントは、SSLコネクションの中間者となります。 (我々は、通常この攻撃を防ぐサーバーを認証しているのではないことを思い出してください。) 次に、単純に、SASLハンドシェイクをプロキシします。 以降、少なくとも攻撃者に関しては、 コネクションが平文であるかのようになります。 この攻撃を予防するために、クライアントは、 サーバーの証明書を検証する必要があります。
しかし、サーバーが認証された場合、チャレンジレスポンスは、 さほど望まれなくなります。 あなたが既に強化されたチャネルをもっている場合、 単純なパスワードが良いといえます。 事実、それらは、チャレンジレスポンスより優れていることを論証できます。 なぜならば、それらは、 「パスワードがサーバー上において平文で蓄積されること」を要求しないからです。 それゆえ、チャレンジレスポンスシステムを伴う鍵が侵されることは、 単純なパスワードが使われた場合よりも深刻です。
「クライアントが証明書をもっている場合、 SSLに基づくクライアント認証が使えること」を覚えておいてください。 これを容易にするためにSASLは、「外部」メカニズムを提供し、 これによって、SASLクライアントは、 サーバーに「私の身元については外部チャネルを調べて下さい」と伝えることができます。 明らかに、これは、上記の階層化(layering)による攻撃の対象ではありません。
特別な事例においては、IPsecまたはSSL/TLSを使うのではなく、 直接アプリケーション中においてチャネルレベルのセキュリティを提供する価値がある可能性があります。 そのような事例のひとつは、リモート端末セキュリティです。 キャラクタは、典型的には、 クライアントからサーバーに1キャラクタずつ送られます。 SSL/TLSとAH/ESPは、すべてのパケットを認証し、暗号化するので、 これは、20bitのデータ拡大を意味する可能性があります。 telnet暗号化オプション [ENCOPT] は、 メッセージインテグリティを断念することによって、 この拡大を予防します。
リモート端末サービスを利用するとき、しばしば、 「他種の通信サービスをセキュアに行うこと」が望まれます。 リモートログインを提供することに加えて、 SSH [SSH] も、 任意のTCPポートについてセキュアなポートフォワーディングを提供します。 それゆえ、ユーザに任意のTCPに基づくアプリケーションをSSHチャネル上で動作させることを許容します。 「ファイアウォールを迂回して不正に使われている場合や、 不正にセキュアでない内部アプリケーションを外界に露出している場合、 SSHポートフォワーディングは、 セキュリティ論点である可能性があること」を覚えておいてください。
サービス妨害攻撃は、日常避け難い現実と見なされています。 問題のひとつは、「攻撃者は、 しばしば被害者を迷惑させるために多くのサービス妨害攻撃から選択できること」であり、 これらの攻撃の大部分が阻止できないので、普通の有識者は、しばしば、 「可能性はあっても予防できない多くの他のサービス妨害攻撃があるとき、 サービス妨害攻撃のうちの一種を防護する点はない」と想定します。
しかし、サービス妨害攻撃のすべてが同等であったり、 より重要であるわけではありません。 非現実的でない場合、 サービス妨害攻撃がより困難になるようにプロトコルを設計することが可能です。
最近のSYNフラッド攻撃 [TCPSYN] は、 両方の属性を実証しています。： SYNフラッド攻撃は、容易・匿名・効果的であるので、 攻撃者にとって他の攻撃よりも魅力的です。 また、TCPの設計が、この攻撃を可能にしています。
完全なDoS防護は困難であるので、DoSに対するセキュリティは、 実用主義的に扱われなければなりません。 特に、防護することが望まれる攻撃には、 効率的に防護することができないものがあります。 目的は、防護する費用に対して十分に高い深刻さがある攻撃に対して防護することによってリスクを管理するものである必要があります。 攻撃の厳しさと防護の費用の両者は、技術変化に伴って変化し、 それゆえ防護しなければならない攻撃も変化します。
インターネット標準の著者は、 そのプロトコルが影響を受けるサービス妨害攻撃について記述しなければなりません(MUST)。 この記述は、このようなサービス妨害攻撃を避ける試みが、 非合理的である旨か、 範囲外であるかのいずれかの理由を含まなければなりません(MUST)。
ブラインドサービス妨害攻撃は、特に有害です。 ブラインド攻撃において、攻撃者は顕著な優位性をもちます。 攻撃者が、 被害者からのトラフィックを受け取ることができなければならない場合、 攻撃者は、ルーティング基盤を操作するか、 自身のIPアドレスを使うかのいずれかをしなければなりません。 両者は、被害者に攻撃者を追跡し、かつ／または、 攻撃者のトラフィックを棄却する機会を提供します。 ブラインド攻撃において、 攻撃者は偽装されたIPアドレスを使うことができ、 被害者が攻撃者のパケットをフィルタリングすることを極めて困難にしています。 TCP SYNフラッド攻撃は、ブラインド攻撃の一例です。 設計者は、 ブラインドサービス妨害攻撃を予防するためにあらゆる可能な試みを行う必要があります。
より危険なのは、分散型サービス妨害攻撃 [DDOS] です。 DDoSにおいて、攻撃者は、標的マシンを同時に攻撃するように、 数多くのマシンを準備します。 通常、これは、 数多くのマシンに攻撃のリモートによる開始ができるプログラムをしかけることによって達成されます。 実際に攻撃を行うマシンは、「ゾンビ」と呼ばれ、 真の攻撃者とは別の場所にいる善意の第三者によって保持されている可能性が高いものです。 DDoS攻撃は、対抗するのが極めて困難である可能性があります。 なぜならば、ゾンビは、しばしば、正規のプロトコル要求を行って、 単に本当のユーザを混雑によって押し出しているように見えるからです。 DDoS攻撃は阻止するのが困難ですが、プロトコル設計者は、 プロトコルを設計する際に、この種の攻撃を認識していることが期待されます。
サービス妨害攻撃をより困難にする卑近なアプローチがふたつあります。：
あなたよりも少ない資源しかもたない攻撃者が攻撃をしかけるとき、 あなたよりも多くの資源を消費する場合では、 攻撃者は効果的な攻撃をしかけることができません。 よくあるテクニックのひとつは、 攻撃者に暗号技術的操作のような時間がかかる操作を要求することです。 「攻撃者が本質的に十分なCPUの処理能力を集結できる場合、 サービス妨害攻撃をしかけ続けることができること」を銘記してください。 例えば、このテクニックは、 [TCPSYN] に記述されている分散型の攻撃をくい止めません。
ブラインド攻撃は、 攻撃者に「被害者からのデータを受信できること」を証明することを強いることによって打ち破ることができます。 よくあるテクニックのひとつは、 「攻撃者がメッセージ交換の初期に得られたはずの情報を使って返信すること」 を要求することです。 この対策が行われた場合、攻撃者は、 (追跡を容易にする)自身のアドレスを使うか、 攻撃を開始したホストまでの経路をたどれてしまうアドレス偽造を使用しなければなりません。
それゆえ、(少なくとも詐称攻撃においては)小さなサブネット上のホストは、 攻撃者にとって無用です。 なぜならば、この攻撃は、 攻撃対抗手段を配備できるようにサブネットにトレースバックできるからです。 (これは、攻撃者の位置を知るのに十分です。) (例えば、境界ルーターは、 そのサブネットからのトラフィックすべてを棄却するように設定できます。) よくあるテクニックのひとつは、 「攻撃者がメッセージ交換の初期に得られたはずの情報を使って返信すること」を要求することです。
TCP/IPは、3ウェイハンドシェイクの設計に起因して、 (3.3.2 に記述されている)SYNフラッド攻撃に対して脆弱です。 まず、攻撃者は、ひとつのパケットを送ることによって、 被害者に膨大な資源(この場合はメモリ)を浪費させることができます。 次に、攻撃者は、 この行為を被害者から全くデータを受け取らずに行うことができるので、 攻撃は、匿名で行うことができます。(それゆえ、 膨大な数の偽装された発信元アドレスを使います。)
[PHOTURIS] は、 PhoturisにおいてSYNフラッド攻撃に似ている攻撃を予防するものであり、 詰まり対策メカニズムを仕様としています。 Photurisは、攻撃者に返される「クッキー」を生成するために、 時間が可変の秘密を採用しています。 このクッキーは、処理を進めるための交換のために、 以降のメッセージにおいて返されなければなりません。 興味深い機能は、「このクッキーは、 後で交換において被害者によって再生成でき、それゆえ、 攻撃者が被害者からのパケットを受信できることが証明されるまでは、 被害者は状態を保持する必要はありません。
オブジェクトセキュリティとチャネルセキュリティを概念的に区別することが有用です。 オブジェクトセキュリティは、 データオブジェクト全体に適用されるセキュリティ手段をいいます。 チャネルセキュリティ手段は、 オブジェクトを透過的に運ぶことができるセキュアチャネルを提供しますが、そ のチャネルは、オブジェクト境界について特別な知識をもちません。
電子メールメッセージの事例を考えます。 メッセージがIPsecもしくはTLSによってセキュアにされたコネクション上を運ばれるとき、 そのメッセージは、転送中は防護されています。 しかし、これは、受信者のメールボックス中や、 途中の中間スプールファイルでは防護されていません。 さらに、メールサーバーは、一般に、 ユーザではなくデーモンとして動作するので、一般的に、メッセージの認証は、 ユーザ認証ではなく、単にデーモン認証を意味するに過ぎません。 さらに、メールのトランスポートは、「ホップ by ホップ」なので、 たとえユーザが中継の最初のホップを認証する場合でも、認証は、 受信者によって安全に検証されることができません。
逆に、電子メールメッセージがS/MIMEまたはOpenPGPで防護されているとき、 受信者によって検証・復号されるまで、メッセージ全体が暗号化され、 インテグリティが確保されます。 これは、メッセージを送ったマシンではなく、 実際の送信者についての強い認証も提供します。 これはオブジェクトセキュリティです。 さらに、受信者は、 署名されたメッセージの真正性を第三者に提供できます。
「オブジェクトセキュリティとチャネルセキュリティの相違は視点の問題であること」を銘記してください。 プロトコルスタックのある層におけるオブジェクトセキュリティは、 しばしば、直上の層からはチャネルセキュリティのように見えます。 それゆえ、IP層から見れば、各パケットは、 個々にセキュアにされたオブジェクトのように見えます。 しかし、Webクライアントの視点からは、IPsecは、 単にセキュアなチャネルを提供します。
区別は、いつも明確であるとは限りません。 例えば、S-HTTPは、 単一のHTTPトランザクションのためにはオブジェクトレベルセキュリティを提供しますが、 Web ページは、典型的には、 複数のHTTPトランザクション(基本ページと数多くのインラインのイメージ)から成ります。 それゆえ、Webページ全体の観点からは、これは、むしろ、 チャネルセキュリティのように見えます。 Webページ用のオブジェクトセキュリティは、 ページ毎の非開示のためのセキュリティと、 単一ユニットとして組み込まれているすべてのコンテンツから成ります。
ネットワークをファイアウォールを使って外部ネットワークと内部ネットワークに区切ることは、 現代のネットワークにおいて、よくあるセキュリティの実践です。 内部ネットワークは、セキュアであり、 限られたセキュリティ手段のみが使われていると想定されています。 このようなネットワークの内部部分は、 しばしば「壁内の庭園」と呼ばれます。
インターネットプロトコル設計者は、3つの理由によって、 「彼らのプロトコルがこのような環境に配備される」と安全に想定することはできません。 まず、当初、閉じた環境中で採用されるように設計されたプロトコルは、 しばしば、後でインターネット上に採用されるようになり、 それゆえ、深刻な脆弱性を作り出します。
次に、トポロジー的に接続されていないように見えるネットワークは、 接続されている可能性があります。 その理由のひとつは、 「ネットワークが外界からのアクセスを許可するように再設定された」可能性があります。 さらに、ファイアウォールは、ますます、 [SOAP] や [HTTP] のような一般的なアプリケーション層プロトコルを通過するようになってきています。 これらの一般的なプロトコルに基づいたネットワークプロトコルは、一般に、 「ファイアウォールがそれらを防いでくれる」と想定できません。 最後に、 システムに対する最も深刻なセキュリティ上の脅威は内部者からであり、 外部者からではありません。 内部者は、定義からして内部ネットワークにアクセスできるので、 ファイアウォールのようなトポロジーによる防護では、 それらを防いでくれません。
「あらゆるプロトコルもしくはシステムが、 すべての形態の攻撃に対して耐性があること」は、要件ではありませんが、 著者が可能な限り多くの形態を考慮することは必要不可欠です。 「セキュリティについての考慮事項」の章の目的の一部は、 「どのような攻撃が範囲外であるか」、 「それらを防ぐためにどのような対策が適用可能か」を説明することにあります。
記述されているプロトコルまたは技術についての脅威の種類の明確な記述が在る必要があります。 これは、潜在的な実装者とユーザに対するすべての既知の／可能性あるリスクと脅威を記述する「正当な注意(due diligence)」を払う努力としてアプローチされる必要があります。
著者は、次のことを記述しなければなりません(MUST)。
少なくとも、 下記の形態の攻撃が考慮されなければなりません(MUST)。： (盗聴、リプレイ、メッセージ挿入・削除・変更および中間者によるもの。) 潜在的なサービス妨害攻撃も識別されなければなりません(MUST)。 当該プロトコルが暗号技術的保護メカニズムを組み込んでいる場合、 「データのどの部分が防護されているか」と「どのような防護であるか(すなわち、 インテグリティのみ、守秘性、かつ／または、 終点認証等)」が明確に示される必要があります。 当該暗号技術的防護が影響を受ける種類の攻撃について、 いくつかの例示も提供される必要があります。 秘密に保たれる必要があるデータ(鍵とする素材、乱数生成の種等)は、 明確にラベル付けされる必要があります。
技術が認証(特にユーザ／ホスト認証)を含む場合、 認証手段のセキュリティは、 明確に仕様としなければなりません(MUST)。 すなわち、著者は、 この認証手法のセキュリティが前提としている仮定を文書化しなければなりません(MUST)。 例えば、UNIXユーザ名／パスワードによるログイン手法の場合、 以下の影響について表明します。：
システム中の認証は、 「最低限8文字の長さのASCIIパスワードを推測／入手することが困難である」という程度のセキュリティです。 これらのパスワードは、telnetセッションを盗聴することによって、 あるいは、/etc/passwdファイルの内容を使って'crack'プログラムを動作させることによって入手できます。 オンラインによるパスワード推測を防ぐ試みは、以下のやり方によります。
/etc/passwdファイルは、 ユーザ名をユーザIDやグループ等に対応させるので、 誰もが読める必要があります。 この用法を許しながら、crackの動作をより困難にするために、 このファイルは、しばしば、 /etc/passwdと「シャドー」パスワードファイルに分離されます。 シャドーファイルは、誰もが読めるものではなく、 暗号化されたパスワードを含みません。 普通の/etc/passwdファイルは、ここにダミーのパスワードを含んでいます。
「プロトコルは、 何らかの下位層のセキュリティプロトコル上で動作する必要がある」と述べるだけでは不十分です。 システムがセキュリティについて下位層のセキュリティサービスに依存している場合、 それらのサービスが提供することを期待されている防護は、 仕様とされなければなりません(MUST)。 さらに、 組み合わされたシステムの結果としての属性が仕様とされる必要があります。
注意：
一般に、IESGは、プロトコル内部のものであれ、
下位層のセキュリティプロトコルとの密な結合であれ、
強い認証を提供しないスタンダードトラックプロトコルを承認しません。
「セキュリティについての考慮事項」の章によって対応される脅威環境は、 たとえ「なぜ、 そのような考慮事項がそのプロトコルについて範囲外であるか」についての理由のみを提供する場合でも、最低限、 ファイアウォールがあることを想定せずに、 複数の運用管理上の境界をまたぐグローバルなインターネットにおける配備を想定しなければなりません(MUST)。 「LANにおいて想定可能な脅威のみを検討し、 より広範な脅威環境を無視すること」は許容できません。 すべてのIETFスタンダードトラックに乗っているプロトコルは、 グローバルなインターネットにおけて採用される可能性が高いと考えられています。 場合によっては、特定の環境において、 ある技術やプロトコルの利用を制約する「適用可能性表明」がある可能性があります。 それにもかかわらず、より広範な採用のセキュリティ論点が、 その文書において検討される必要があります。
脅威の緩和策が採用された後の当該プロトコルのユーザもしくはオペレータに対する残存リスクの明確な記述がある必要があります。 このようなリスクは、 関連プロトコルにおける侵害によって(例：鍵管理が侵された場合、 IPsecは無用)、誤った実装によって、 リスク低減のために使われたセキュリティ技術の侵害によって(例：40bitの鍵をもつ暗号)発生する可能性があり、あるいは、 プロトコル仕様によって対応されていないリスクがある可能性があります (例：基盤となっているリンクプロトコル上のサービス妨害攻撃)。 単一のシステムの侵害がプロトコル全体を侵害する状況において、 特別な注意が払われる必要があります。 例えば、一般に、プロトコル設計者は、 「エンドシステムは侵害されておらず物理的攻撃について心配しない」と想定します。 しかし、 (認証局のように)単一システムの侵害が広域な侵害もたらす可能性がある場合、 システムセキュリティと物理的セキュリティを同様に考慮するのが適切です。
プロトコルもしくはRFCに記述された技術についての潜在的に誤った応用に起因する潜在的なセキュリティリスクについても、 何らかの検討が必要です。 これは、 当該RFCについての適用可能性の表明と組み合わされる可能性があります。
本章は、いくつかの「セキュリティについての考慮事項」の章の例示から成り、 読者に本書が意図する雰囲気を提供することを意図しています。
最初の例は、 本書のクライテリアを既存の広く普及したプロトコルであるSMTPに適用した「回顧的」な例です。 2番目の例は、 現行プロトコルから抽出した良い「セキュリティについての考慮事項」の章です。
RFC 821が書かれたとき、「セキュリティについての考慮事項」の章は、 RFCにおいて要求されていませんでしたし、 その文書には何も含まれていません。 [RFC-2821] は、RFC 821を更新し、 詳細な「セキュリティについての考慮事項」の章を追加しました。 我々は、ここに、 その文書の「セキュリティについての考慮事項」の章を(新しい節番号で)再編集します。 我々のコメントは、インデントされ、 前に「注意：(Note:)」を付してあります。 また、我々は、重要と考える論点をカバーするために、 数多くの新しい節を追記します。これらの節は、 節の表題に [NEW] の印を付けてあります。
SMTPメールは、もともとセキュアではなく、通常のユーザでさえ、 受信・転送SMTPサーバーと直接交渉し、 単純な受信者を「それらはどこか別のところから来た」と信じるように騙すメッセージを作成することができます。 「詐称された」行為が達人によっても検知できないようにするために、 このようなメッセージを作成することは、より困難ですが、 意思と知識をもつ者を阻止するのに十分ではありません。 したがって、インターネットメールの知識が増えるにしたがって、 SMTPメールは、仕様上、トランスポート層において認証されたり、 インテグリティチェックが提供されたりすることができないという知識もつきます。 実際のメールセキュリティは、 デジタル署名を使うもののようにメッセージ本体を扱う「エンド to エンド」な手法においてのみ実現します。 ([14] および例：PGP [4] または S/MIME [31] 参照。)
注意：
送信者認証について悪いアプローチのひとつは、
[IDENT] です。
ここでは、受信メールサーバーは、送信者と連絡を取り、
送信者のユーザ名を尋ねます。
これは、数多くの理由で良くないアイディアです。
理由には、中継、TCPコネクションハイジャック、および、
発信元サーバーの単純な詐称が含まれますが、これらに限定されません。
「IDENTには、あまりセキュリティの価値が無い」事実とは別に、
受信サイトによるIDENTの利用は、運用上の問題をもたらす可能性があります。
多くの送信サイトは、IDENTリクエストを受けても反応しないようにするので、
メールが受信サーバーのIDENTリクエストのタイムアウトまで扱われるようにします。
トランスポート層で認証を提供する様々なプロトコル拡張と設定オプション (例：SMTPクライアントからSMTPサーバーに対するもの)は、 上記の古典的な状況を、ある程度、改善します。 しかし、注意深く設計された信頼できる環境において、 注意深い責任の連携を伴わない限り、それらは、 「エンド to エンド」なメカニズムよりも弱いままとなります。 それらは、トランスポートシステムのインテグリティに依存せずに、 デジタル的に署名されたメッセージを使います。
ユーザがメッセージのリターンパスとヘッダーの"From"フィールドを自身以外の有効なアドレスを指すように設定することを困難にする努力は、 大きく間違っています。： 彼らは、メールが他人に代わって送信される正規のアプリケーションや、 エラー(もしくは正常)の応答が特別なアドレスに指図される必要があるアプリケーションに不満をもっています。 (ユーザがメッセージ単位で、 これらのフィールドを置き換えるための便利なやり方を提供するシステムは、 メッセージデータ中の送信者フィールドがうまく生成できるように、 ユーザ用の主要かつ永続的なメールボックスアドレスを確立することを試みる必要があります。)
この仕様は、「偽のメールを試みる無知なユーザに対して、 何らかのわずかな防護の余裕を提供することを期待して、 有用な機能は無効にしてはならないこと」を提唱している以外は、 SMTPに関する認証の論点に対応しません。
注意：
我々は、通信セキュリティとSMTPについて、
6.1.2に追記しました。
最終仕様において、上記の文章は、
その事実を反映するために何らかの編集がなされるはずです。
メッセージヘッダー中に無いアドレスは、数多くの理由によって、 SMTPサーバーに対するRCPTコマンド中にある可能性があります。 ふたつの最もよくあるものは、 メールアドレスの「リスト爆弾(list exploder)」 (複数のアドレスに解決されるひとつのアドレス)としての利用と、 「ブラインドコピー」の外観に関するものです。 特に、複数のRCPTコマンドがあるとき、かつ、 これらのメカニズムの目的の阻害を避けるために、 SMTPのクライアントとサーバーは、トレースヘッダーの一部としても、 情報提供もしくはプライベート拡張ヘッダーとしても、 RCPTコマンドアーギュメントの全体をヘッダーにコピーしてはいけません(SHOULD NOT)。 なぜならば、このルールは、しばしば、実際に破られ、強制できませんし、 "bcc"の用途を知っているSMTP送信システムは、 それが各ブラインドコピーを単一のRCPTコマンドのみを含む分離されたメッセージトランザクションとして送信するのに有用であると気づく可能性がある(MAY)からです。
(MAIL, SAML等のコマンド中の) "reverse"かSMTPトランザクション("envelope")中の"forward" (RCPT)アドレスのいずれかと、 ヘッダー中のアドレスの間には、もともと関係がありません。 受信システムは、このような推論することを試みて、 配信メッセージのヘッダーを置き換えるために、 これらを使ってはいけません(SHOULD NOT)。 正規の"Apparently-to"ヘッダーは、 意図しない情報開示の源泉としてありがちなものであるとともに、 この原則の侵害であり、使ってはいけません(SHOULD NOT)。
3.5に記述したように、個々のサイトは、 セキュリティについての理由でVRFYとEXPNのいずれか、 または両方を不能にすることを望む可能性があります。 上記のこととは対称的に、これを許す実装は、 実際には検証されていないのに検証されたアドレスをもつように見えてはなりません(MUST NOT)。 サイトがセキュリティの理由によってこれらのコマンドを利用不能にする場合、 SMTPサーバーは、 検証が成功／失敗したか紛らわしい可能性があるコードではなく、 252レスポンスを返さなければなりません(MUST)。
構文のみをチェックした後にVRFYコマンド中に掲載されているアドレスを伴って250返信コードを返すことは、 このルールを侵害しています。 当然ながら、 アドレスが有効であるか否かにかかわらず常に550を返すことによってVRFYをサポートする実装は、同等に準拠していません。
近年、メーリングリストのコンテンツは、 いわゆる「スパマー」にとってアドレス情報の源泉としてよく使われるようになっています。 EXPNの"harvest"アドレスへの利用は、 メーリングリストのシステム管理者がメーリングリスト自体の不適切な利用に対する防護を導入しため、 増加しました。 実装者は、EXPNについてサポートし続ける必要があります(SHOULD)が、 サイトは、注意深く二律背反を評価する必要があります(SHOULD)。 認証メカニズムは、SMTPに導入されているので、サイトには、 認証された要求者のみにEXPNが利用可能であるようにする選択をするところがある可能性があります。
注意：
しばしば、RCPT TOを使って、
アドレスが有効であるか否かを発見することが可能であるので、
VRFYを無効にするによって防護を高めることは明らかではありません。
グリーティング用の応答またはHELPコマンドへの応答として、 サーバーのタイプとバージョンを(しばしば、 サーバーのドメイン名も)公表することのデバッグ上の利点と、 潜在的な敵意ある攻撃において有用である可能性がある情報を開示することの欠点の間の二律背反について、 継続中の議論があります。 デバッグ用情報の有用性には、疑いの余地はありません。 それを利用可能にすることを議論する人々は、 「サーバーの詳細な身元を隠すことによって既知の脆弱性を隠す試みの方が良い防護を提供すること」を望むより、 「実際にSMTPサーバーをセキュアにする方がはるかに良い」と指摘します。 各サイトには、 その論点について考えられる二律背反を評価することが強く薦められます。； 実装には、最低限、 他のネットワークホストに対してタイプとバージョンの情報を何らかの方法で利用可能にするために提供することが強く薦められます。
状況によっては、 ホストが公衆インターネットに直結されていないLAN内をメールが起点とするときのように、 この仕様に準拠して作成されたtrace ("Received")フィールドが、 通常は利用不能なホスト名や同様の情報を開示する可能性があります。 通常、これは問題を起こしませんが、 名前の開示について特別な関心を持つサイトは、 これを知っておく必要があります。 また、複数の受信者がいるとき、 他者に「ブラインドコピー」とした受信者の身元を開示してしまうことがないように、 オプションとしてのFOR情報は、注意を払って提供されるか、 全く提供しないようにする必要があります。
3.4に記述したように、 メールボックスと関連づけられた代替アドレスを識別するための251または551の返信コードの利用が、 不注意によって取扱に注意を要する情報を開示する可能性があります。 これらの論点に関心をもつサイトは、 「彼らがサーバーを適切に選択し設定していること」を確認する必要があります。
「SMTPサーバーは、あらゆる運用管理的／技術的な理由によって、 サーバーを提供しているサイトにとって合理的な場合、 メールを受信することを拒絶する可能性があること」は、 確立された原則です。 しかし、サイト間の協働と導入が、インターネットを可能にしています。 サイトがトラフィックを拒絶する権限をもつ優位性をもつ場合、 広範な電子メールの利用可能性(インターネットの強みのひとつ)が脅かされます。； サイトが受信し処理するトラフィックについて選択することを決定する場合、 相当な注意が払われ、バランスが維持される必要があります。
近年、 任意のサイトを通じた中継機能の利用が実際のメールの起点を隠すための敵意ある労力の一部として使われています。 サイトによっては、 既知もしくは識別可能な源泉についてのリレー機能の利用を制限することを決定しており、 各実装は、 この種のフィルタリングを行う能力を提供する必要があります(SHOULD)。 メールが、 これらの理由あるいは他のポリシーによる理由によって拒否されるとき、 適切である限り、EHLO, MAIL, RCPTに応答して550コードが使われる必要があります(SHOULD)。
SMTP自体は、 (spamとして知られている)頼まないのに送られてくる大量の商業的な電子メールに対する防護を提供しません。 事前にあるメッセージがspamであるか否かを判断することは、極めて困難です。 プロトコルの観点からは、spamは、他の電子メールと区別できません。 (この区別は、ほぼ社会的なものであり、しばしば微妙です。) (例えば、あなたが広告以前に物品を買ったことがある業者からのメッセージは、 spamと同様のものでしょうか？) SMTPのspam抑制メカニズムは、通常、既知のspam送信者を識別し、 彼らにサービスを提供することを拒否するか、 彼らを制裁／切断の対象とするかのいずれかにとどまります。 [RFC-2505] は、 SMTPサーバーをspam対抗とするための広範なガイダンスを提供します。 我々は、ここでは、その話題の簡潔な検討を提供します。
スパマーに対してサービスすることを拒否するための主要なツールは、 ブラックリストです。 [MAPS] のような機関は、既知のスパマーのリストを集め、公表しています。 そこで、個々のSMTPサーバーは、 ブラックリストに載っている攻撃者をブロックします。 (一般的にIPアドレスによります。)
ブラックリストに載ったり、あるいは識別されることを避けるために、 スパマーは、しばしば、単に、偽のSMTPの身元を送ることによるか、 オープンな中継(任意の送信者のために中継を行うSMTPサーバー)を通じてメールを転送することのいずれかによって、 彼らの身元を隠すことを試みます。 結果として、今日、オープンな中継のブラックリスト [ORBS] もあります。
spam転送に使われないようにするために、多くのSMTPサーバーは、 閉じた中継として運用され、 識別できるクライアントのためのみに中継サービスを提供します。 このような中継は、一般的に「送信者が彼らの知られている身元と整合する送信アドレスを告げること」を主張する必要があります。 中継が(企業内ネットワーク、もしくは、 ISPのネットワークのような)識別可能なネットワークのためのサービスを提供している場合、 すべての他のIPアドレスをブロックすることで十分です。 これ以外の場合、明示的な認証が使われなければなりません。 これについて、ふたつの標準的選択肢は、 TLS [STARTTLS] と SASL [SASLSMTP] です。
現実的には、SMTP終点は、 認証されていない送信者にサービスさせないことを拒否できません。 なぜならば、送信者の大部分は認証されていないので、 これではインターネットメールの相互運用可能性を損なうからです。 これの例外は、 終点サーバーが認証されていないメッセージを受け取ることができる他のサーバーからメールを受け取る必要があるときです。 例えば、ある企業は、公衆ゲートウェイを運用してはいるものの、 その内部サーバーをそのゲートウェイのみと通信するように設定している可能性があります。
SMTP自体は、セキュリティを提供しないので、数多くの攻撃が可能です。 待ち伏せ攻撃にとっては、 SMTPで転送されたメッセージのテキストを復元するのに十分です。 このプロトコルによって、終点認証は提供されません。 送信者詐称は、よくあることであり、それゆえ、 偽装された電子メールメッセージも、よくあることです。 これらのヘッダー行は、通常、ユーザには表示されませんが、 実装によっては、 逆引きの名前解決を通じて得られるホスト名をもったヘッダー行の追加を行うものがあります。 (これは、DNSを詐称するのが困難である程度にセキュアです。 高度ではありません。) 受信者詐称も、TCPコネクションハイジャックかDNS詐称のいずれかを使って、 ぼぼ直線的に行えます。 さらに、電子メールメッセージは、しばしば、 SMTPゲートウェイを通過するので、すべての中間ゲートウェイは、 信用されなければならず、グローバルなインターネット上では、 ほとんど不可能な条件です。
いくつかのアプローチが、これらの脅威を軽減するために利用可能です。 プロトコルスタックにおいて下位から上位への順に、我々は、 以下のものをもちます。：
IPsec上で動作するSMTPコネクションは、 送信者と最初のホップとなるSMTP ゲートウェイ間、あるいは、 あらゆる接続されたSMTPゲートウェイ間のメッセージについて守秘性を提供することができます。 すなわち、これは、 SMTPコネクションのためにチャネルセキュリティを提供します。 メッセージが直接、 クライアントから受信者のゲートウェイに行く状況において、 (受信者は、ゲートウェイを信用しなければなりませんが)これは、 実質的なセキュリティを提供する可能性があります。 リプレイ攻撃に対する防護は提供されています。 なぜならば、データ自体は防護されており、 パケットはリプレイできないからです。
しかし、終点識別は、 受信者のアドレスが直接暗号技術的に認証できない限り問題です。 送信者識別は、一般的に利用不能です。 なぜならば、通常、送信者のマシンのみが認証され、 送信者自身が認証されないからです。 さらに、送信者の身元は、 単純にメッセージのFromヘッダー中にあるので、 送信者によって簡単に詐称される可能性があります。 最後に、セキュリティ ポリシーが極めて厳格に設定されない限り、 平文攻撃に対する積極的なダウングレードもあります。
SMTPのためのセキュリティソリューションとしてのIPsecについて、 その他の問題は、標準IPsec APIの欠如です。 IPsecの利点を得るために、アプリケーションは、一般に、 彼らのセキュリティポリシーについてIPsec実装を指示し、 「どのような防護がそのコネクションに適用されているか」を発見できる必要があります。 標準API無しには、これは、移植可能性をもって行うことは非常に困難です。
SMTPサーバーの実装者もしくはSMTPのシステム管理者は、 IPsecが利用可能であると信じる根拠がない限り、 「IPsecが(2マシン間における既存の協定の存在のように)利用可能である」と想定してはなりません(MUST NOT)。 しかし、メールが配信されたとき、 タイミングをとらえて相手のサーバーとIPsec協定を構築することを試みることは、 合理的な手順である可能性があります。 「IPsecがふたつのサイト間にVPNを提供するために使用されている場合は、 上記の注意事項に対し、特に守秘性が提供される点において、 これは本質的なセキュリティの価値があること」を銘記してください。 IPsecの応用可能性についての一般的なガイダンスについては、 [USEIPSEC] も参照してください。
SMTPは、[STARTTLS] に記述されているように、
TLSと組み合わせることができます。
これは、IPsecを使うときに提供される防護と同様な防護を提供します。
TLS証明書は、典型的にはサーバーのホスト名が含まれているので、
受信者認証は、わずかにより明解ですが、DNS詐称攻撃の影響は受けます。
周知のように、よくあるTLSの実装は、米国輸出可能(かつ、
それゆえ低セキュリティ)なモードを含みます。
高いセキュリティを望むアプリケーションは、
「このモードが実行不能になっていること」を確認する必要があります。
データ自体が防護されており、パケットをリプレイできないので、
リプレイ攻撃に対して防護が提供されています。
[注意：SMTP over TLSの文書の「セキュリティについての考慮事項」の章は、
極めて良く書かれており、やり方の例として読むのに耐えます。]
S/MIMEとPGP/MIMEは、ともに、メッセージ指向のセキュリティプロトコルです。 これらは、個々のメッセージについてオブジェクトセキュリティを提供します。 送信者と受信者の認証と守秘性が様々な設定を伴って提供される可能性があります。 さらに重要なことに、識別は、送受信するマシンについてではなく、 送信者と受信者自身についてであることです。 (あるいは、少なくとも、 送信者と受信者に対応する暗号技術的鍵についてです。) したがって、「エンド to エンド」セキュリティが得られます。 しかし、 「リプレイ攻撃に対する防護は何もないこと」を覚えておいてください。 「S/MIMEやPGP/MIMEは、一般的に、 送信者と受信者の両方に識別する印を提供すること」も銘記してください。 それゆえ、たとえ守秘性が提供されているときでも、 トラフィック解析は可能です。
これらのセキュリティ手段には、 サービス妨害に対する実際の防護を提供するものはありません。 SMTPコネクションは、様々なやり方で、 簡単にシステム資源を使い切ってしまう可能性があり、 過剰にポートを消費し、(電子メールは、典型的には、 ハードディスク上のファイルに配信され)ディスク領域を過剰に使い、 (例えば、sendmailは、相当に大きく、典型的には、 各メッセージを扱うたびに新しいプロセスを起動するので)過剰にメモリを使用します。
トランスポート層、もしくは、 アプリケーション層のセキュリティがSMTPコネクションのために使われている場合、 個々のコネクションに様々な攻撃をしかけるために、 偽装されたRSTの利用、もしくは、他の種類のパケット注入が可能です。
2番目の例は、VRRP (Virtual Router Redundance Protocol [VRRP])からです。 我々は、ここに、 その文書から(新しい節番号で)「セキュリティについての考慮事項」の章を再作成します。 我々のコメントは、インデントされ、 「注意：(Note:)」と書き添えられています。
VRRPは、異なるセキュリティポリシーを採用する可能性がある、 インターネットワーク化する様々な環境のために設計されています。 このプロトコルは、いくつかの認証手法を含み、認証無しから、 単純な平文パスワード、MD5 HMACを伴うIP認証を使う強い認証に及びます。 可能性ある攻撃と推奨される環境を含む各アプローチについての詳細が続きます。
いかなる認証タイプVRRPと独立であることは、 その他の遠隔ネットワークから注入されるVRRPパケットから防護する(TTL=255を設定し、 受信時にチェックする)メカニズムを含みます。 これは、ローカル攻撃に対する大部分の脆弱性を制限します。
注意：
以降の節で検討されているセキュリティ手段は、
様々な種類の認証のみを提供します。
守秘性は、全く提供されていません。
これは、範囲外であると明確に記述される必要があります。
この認証タイプの利用は、 「VRRPプロトコル交換は認証されていないこと」を意味します。 この種の認証が使われるは、セキュリティリスクがほとんど無く、 設定エラーの可能性が低い環境においてのみである必要があります(SHOULD) 。 (例：LAN上のふたつのVRRPルーター)
この認証タイプの利用は、 「VRRPプロトコル交換は単純な平文パスワードによって認証されること」を意味します。
この種の認証は、 LAN上のルーターの偶発的な誤設定を防護するために有用です。 これは、 その他のルーターが不注意によって別のルーターをバックアップしてしまうことを防護します。 新しいルーターは、まず、 VRRPをその他のルーターとともに動作できる前に、 正しいパスワードで設定されなければなりません。 この種の認証は、 LAN上でVRRPパケットを盗聴しているノードによってパスワードが学習される可能性のある敵意ある攻撃を防いでくれません。 TTLチェックと組み合わされた単純なテキスト認証は、 VRRPの運用を阻害するために他のLANからVRRPパケットを送ことを困難にします。
この種の認証は、LAN上のノードに、 VRRP運用を妨げるリスクがほとんど無いとき、 推奨されます(RECOMMENDED)。 この種の認証が使われている場合、ユーザは、 「この平文パスワードが頻繁に送信されていること」を認識する必要があり、 それゆえ、 いかなるセキュリティが重要なパスワードと同一であってはいけません。
注意：
この節は、より明確である必要があります。
基本的な点は、「認証無しと平文の組み合わせは、
非常に限定された脅威モデルについてのみ、
まさにLAN上に敵意あるノードが無いとき、有用であること」です。
TTLチェックは、
LAN外の敵意あるノードが正規のノードを装うことは予防しますが、
LAN中の敵意あるノードが認可されたノードを装うことを止めるものはありません。
これは、多くの状況において特に現実的な脅威モデルではありません。
特に、次の場合、もろいといえます。：
いずれかのノードの侵害によって、
LANがVRRPノードの再設定を許してしまう場合。
この認証タイプの利用は、「VRRPプロトコル交換は、 [HMAC] を使うIP認証ヘッダーによって規定されるメカニズムを使って認証されること」を意味します。 これは、設定エラー、 リプレイ攻撃およびパケット変更に対する強固な防護を提供します。
この種の認証は、LAN上のノードの運用管理について、 コントロールが制限されているとき、推奨されます(RECOMMENDED)。 この種の認証はVRRPの運用を防護しますが、VRRPから独立し、 防護されていない共有メディアリンクに対する別の種類の攻撃を受ける可能性があります(例えば、 偽のARPリプライの生成など)。
注意：
この文脈に置いては、
AHが推奨される(RECOMMENDED)と書くことは誤りです。
なぜならば、AHは、
同一のLAN上の他のノードからの攻撃からVRRPを防護する唯一のメカニズムであり、
同一のネットワーク上に信用されていないノードがある場合においては必須(MUST)である必要があります。
いずれにせよ、AHは、実装されなければなりません(MUST)。
注意：
本書中ではヒントが示されているに留まる重要なセキュリティ分析の部分があります。
それは、まさに、VRRP認証の費用／便益の二律背反です。
[この節の以降は、新しい題材です。]
VRRP認証が予防することを意図している脅威は、
攻撃者がVRRPマスターになるように準備することです。
これは、グループに(おそらく複数回)参加し、マスターを黙らせ、
自身がマスターになることによって行われます。
このようなノードは、
トラフィックを任意の望まれないやり方で指図することができます。
しかし、攻撃者にとって、これを行うためには、 VRRPマスターであることは必要不可欠ではありません。 攻撃者は、ARPパケットを偽装するか、あるいは、 (スイッチによるネットワーク上で)これらの攻撃に対する実際の防護を何ら提供しないスイッチのVRRP認証を騙すことによって、 同種の被害をネットワークにもたらすことができます。
残念ながら、認証は、誤設定した場合、 VRRPネットワークを非常にもろいものにします。 ふたつのノードが異なるパスワードで設定された場合に何が起きるかを検討します。 各々は、相手からのメッセージを棄却し、それゆえ、両者は、 マスターになろうとします。 これは、本質的にネットワークの不安定性をもたらします。
この二律背反は、 「VRRP認証が良くないアイディアであること」を示唆します。 なぜならば、増大するセキュリティの便益が低減する一方、 増大するリスクは高いからです。 現在の一連の非VRRP脅威が除去された場合、 この判断は見直される必要があります。
本書は、 1997年にRan Atkinsonによって書かれたノートに大きく依拠しています。 このノートは、 1997年初頭に開催されたIABセキュリティワークショップの後に書かれたもので、 ワークショップに参加した全員からの情報に基づいています。 上記の特定の文章にはRanの原書から得たものがあり、 文章にはFred Bakerによって書かれた電子メールのメッセージから得たものもあります。 本書のこれ以外の主要な源泉は、 Steve Bellovinから受け取った具体的なコメントです。 本書の初期レビューは、 Lisa DusseaultとMark Schertlerによってなされました。 他の有用なコメントを、 Bill Fenner, Ned Freed, Lawrence Greenfield, Steve Kent, Allison Mankin, Kurt Zeilengaから受け取っています。
| [AH] |
Kent, S. and R. Atkinson, 「IP認証ヘッダ(IP Authentication Header)」, RFC 2402, 1998年11月. |
| [DNSSEC] |
Eastlake, D., 「DNSセキュリティ拡張(Domain Name System Security Extensions)」, RFC 2535(English), 1999年3月. |
| [ENCOPT] |
Tso, T., 「Telnetデータ暗号化オプション(Telnet Data Encryption Option)」, RFC 2946(English), 2000年9月. |
| [ESP] |
Kent, S. and R. Atkinson, 「IP暗号ペイロード(ESP) (IP Encapsulating Security Payload (ESP))」, RFC 2406, 1998年11月. |
| [GSS] |
Linn, J., 「GSSAPI v2アップデート1 (Generic Security Services Application Program Interface Version 2, Update 1)」, RFC 2743(English), 2000年1月. |
| [HTTP] |
Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P. and T. Berners-Lee, "HyperText Transfer Protocol", RFC 2616, 1999年6月. |
| [HTTPTLS] |
Rescorla, E., 「HTTPオーバーTLS (HTTP over TLS)」, RFC 2818, 2000年5月. |
| [HMAC] |
Madson, C. and R. Glenn, 「ESPおよびAHにおけるHMAC-MD5-96の使用法(The Use of HMAC-MD5-96 within ESP and AH)」, RFC 2403, 1998年11月. |
| [KERBEROS] |
Kohl, J. and C. Neuman, 「Kerberosネットワーク認証サービス v5(The Kerberos Network Authentication Service (V5))」, RFC 1510, 1993年9月. |
| [KEYWORDS] |
Bradner, S., 「RFCにおいて要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」, BCP 14, RFC 2119, 1997年3月. |
| [OTP] |
Haller, N., Metz, C., Nesser, P. and M. Straw, "A One-Time Password System", STD 61, RFC 2289(English), 1998年2月. |
| [PHOTURIS] |
Karn, P. and W. Simpson, "Photuris: Session-Key Management Protocol", RFC 2522(English), 1999年3月. |
| [PKIX] |
Housley, R., Polk, W., Ford, W. and D. Solo, 「インターネットX.509 PKI：証明書とCRLのプロファイル(Internet X.509 Public Key Infrastructure Certificate and CRL Profile)」, RFC 3280(English), 2002年4月. |
| [RFC-2223] |
Postel J. and J. Reynolds, 「RFCを書く人のために(Instructions to RFC Authors)」, RFC 2223(English), 1997年10月. |
| [RFC-2505] |
Lindberg, G., 「SMTP MTAについてのspam対策推奨事項(Anti-Spam Recommendations for SMTP MTAs)」, BCP 30, RFC 2505, 1999年2月. |
| [RFC-2821] |
Klensin, J., 「SMTP (Simple Mail Transfer Protocol)」, RFC 2821, 2001年4月. |
| [SASL] |
Myers, J., 「SASL(シンプル認証とセキュリティ層) (Simple Authentication and Security Layer (SASL))」, RFC 2222, 1997年10月. |
| [SPKI] |
Ellison, C., Frantz, B., Lampson, B., Rivest, R., Thomas,
B. and T. Ylonen, "SPKI Certificate Theory", RFC 2693(English), 1999年9月. |
| [SSH] |
Ylonen, T., "SSH - Secure Login Connections Over the Internet", 6th USENIX Security Symposium, p. 37-42, 1996年 7月. |
| [SASLSMTP] |
Myers, J., "SMTP Service Extension for Authentication", RFC 2554, 1999年3月. |
| [STARTTLS] |
Hoffman, P., "SMTP Service Extension for Secure SMTP over Transport Layer Security", RFC 3207, 2002年2月. |
| [S-HTTP] |
Rescorla, E. and A. Schiffman, "The Secure HyperText Transfer Protocol", RFC 2660(English), 1999年8月. |
| [S/MIME] |
Ramsdell, B., Editor, "S/MIME Version 3 Message Specification", RFC 2633(English), 1999年6月. |
| [TELNET] |
Postel, J. and J. Reynolds, "Telnet Protocol Specification", STD 8, RFC 854, 1983年5月. |
| [TLS] |
Dierks, T. and C. Allen, 「TLSプロトコルv1.0 (The TLS Protocol Version 1.0)」, RFC 2246, 1999年1月. |
| [TLSEXT] |
Blake-Wilson, S., Nystrom, M., Hopwood, D. and J.
Mikkelsen, "Transport Layer Security (TLS) Extensions", RFC 3546(English), 2003年5月. |
| [TCPSYN] |
"TCP SYN Flooding and IP Spoofing Attacks", CERT Advisory CA-1996-21, 19 1996年9月, CERT. http://www.cert.org/advisories/CA-1996-21.html |
| [UPGRADE] |
Khare, R. and S. Lawrence, "Upgrading to TLS Within HTTP/1.1", RFC 2817, 2000年5月. |
| [URL] |
Berners-Lee, T., Masinter, M. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, 1994年12月. |
| [VRRP] |
Knight, S., Weaver, D., Whipple, D., Hinden, R., Mitzel,
D., Hunt, P., Higginson, P., Shand, M. and A. Lindemn,
"Virtual Router Redundancy Protocol", RFC 2338, 1998年4月. |
| [DDOS] |
"Denial-Of-Service Tools" CERT Advisory CA-1999-17, 28
1999年12月, CERT.
http://www.cert.org/advisories/CA-1999-17.html |
| [EKE] |
Bellovin, S., Merritt, M., "Encrypted Key Exchange: Password-based protocols secure against dictionary attacks", Proceedings of the IEEE Symposium on Research in Security and Privacy, 1992年5月. |
| [IDENT] |
St. Johns, M. and M. Rose, "Identification Protocol", RFC 1414, 1993年2月. |
| [INTAUTH] |
Haller, N. and R. Atkinson, "On Internet Authentication", RFC 1704, 1994年10月. |
| [IPSPPROB] |
Bellovin, S. M., "Problem Areas for the IP Security Protocols", Proceedings of the 6th Usenix UNIX Security Symposium, 1996年7月. |
| [KLEIN] |
Klein, D.V., "Foiling the Cracker: A Survey of and Improvements to Password Security", 1990年. |
| [NNTP] |
Kantor, B. and P. Lapsley, "Network News Transfer Protocol", RFC 977, 1986年2月. |
| [POP] |
Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, 1996年5月. |
| [SEQNUM] |
Morris, R.T., "A Weakness in the 4.2 BSD UNIX TCP/IP Software", AT&T Bell Laboratories, CSTR 117, 1985年. |
| [SOAP] |
Box, D., Ehnebuske, D., Kakivaya, G., Layman, A.,
Mendelsoh, N., Nielsen, H., Thatte, S., Winer, D., "Simple Object Access Protocol (SOAP) 1.1", 2000年5月. |
| [SPEKE] |
Jablon, D., "Strong Password-Only Authenticated Key Exchange", Computer Communication Review, ACM SIGCOMM, vol. 26, no. 5, pp. 5-26, 1996年10月. |
| [SRP] |
Wu T., "The Secure Remote Password Protocol", ISOC NDSS Symposium, 1998年. |
| [USEIPSEC] |
Bellovin, S., "Guidelines for Mandating the Use of IPsec", 作業中。 |
| [WEP] |
Borisov, N., Goldberg, I., Wagner, D., "Intercepting Mobile Communications: The Insecurity of 802.11", http://www.isaac.cs.berkeley.edu/isaac/wep-draft.pdf |
本書全体が、「セキュリティについての考慮事項」についてのものです。
執筆時点におけるIABメンバー
Harald Alvestrand
Ran Atkinson
Rob Austein
Fred Baker
Leslie Daigle
Steve Deering
Sally Floyd
Ted Hardie
Geoff Huston
Charlie Kaufman
James Kempf
Eric Rescorla
Mike St. Johns
Eric Rescorla
RTFM, Inc.
2439 Alvin Drive
Mountain View, CA 94043
電話： (650)-320-8549
EMail： ekr＠rtfm.com
Brian Korver
Xythos Software, Inc.
77 Maiden Lane, 6th Floor
San Francisco, CA, 94108
電話： (415)-248-3800
EMail： briank＠xythos.com
Internet Architecture Board
IAB
EMail: iab＠iab.org
宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター
Email： miyakawa＠ipa.go.jp
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 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.
Funding for the RFC Editor function is currently provided by the Internet Society.