4. Common Issues (よくある論点)

各システムのセキュリティ要件は一意だが, 一定の共通要件が多数のプロトコルに現れる. しばしば, 素朴なプロトコル設計者がこれらの要件に直面すると, より良い解が利用可能であっても明白だが不安全な解を選ぶ. 本節は多くのプロトコルで見られる論点のいくつかと, それらに対処するのに有用であり得る共通のセキュリティ技術の要素を記述する.

4.1. User Authentication (ユーザー認証)

実質的にすべてのリソースへのアクセスを制御したいシステムは, ユーザーを認証する何らかの方法を要する. その目的のために設計されたそのような機構は数え切れないほどある. 次の数節はその技法のいくつかを記述する.

4.1.1. Username/Password (ユーザー名/パスワード)

最も一般的なアクセス制御機構は単純な USERNAME/PASSWORD (ユーザー名/パスワード) である. ユーザーは使用したいホストにユーザー名と再利用可能なパスワードを提供する. このシステムは, 攻撃者が回線からパスワードを盗聴し新しいセッションを開始してパスワードを提示する単純な受動的攻撃に脆弱である. この脅威は TLS や IPSEC のような暗号化接続上でプロトコルをホストすることで緩和できる. 保護されていない (平文) ユーザー名/パスワード方式は IETF 標準では許容されない.

4.1.2. Challenge Response and One Time Passwords (チャレンジ応答とワンタイムパスワード)

USERNAME/PASSWORD より高いセキュリティを望むシステムは, ONE TIME PASSWORD (ワンタイムパスワード) [OTP] 方式または CHALLENGE-RESPONSE (チャレンジ応答) をしばしば用いる. ワンタイムパスワード方式では, ユーザーにパスワードのリストが与えられ, 順に 1 回ずつ使用されなければならない. (しばしばこれらのパスワードはある秘密鍵から生成されるため, ユーザーは列の次のパスワードを単に計算できる.) SecureID と DES Gold はこの方式の変種である. チャレンジ応答方式では, ホストとユーザーは何らかの秘密 (しばしばパスワードとして表される) を共有する. ユーザーを認証するために, ホストはユーザーに (乱数生成された) チャレンジを提示する. ユーザーはチャレンジと秘密に基づく何らかの関数を計算しホストに提供し, ホストが検証する. しばしばこの計算は DES Gold カードなどの手持ちデバイスで行われる.

両タイプの方式は再生攻撃に対する保護を提供するが, しばしば OFFLINE KEYSEARCH ATTACK (オフライン鍵探索攻撃) (受動的攻撃の一形態) に依然脆弱である: 前述のとおり, しばしばワンタイムパスワードまたは応答は共有秘密から計算される. 攻撃者が用いる関数を知っていれば, 正しい出力を生成する共有秘密が見つかるまで可能な共有秘密をすべて試せる. 共有秘密がパスワードなら DICTIONARY ATTACK (辞書攻撃) を実施でき, すなわちランダムな文字列だけでなく一般的な語 (または文字列) のリストを試す.

これらのシステムは能動的攻撃にもしばしば脆弱である. セキュリティがセッション全体に提供されない限り, 攻撃者は認証が完了するまで待ち接続をハイジャックできる.

4.1.3. Shared Keys (共有鍵)

CHALLENGE-RESPONSE 型のシステムは, ユーザー生成パスワードの代わりに乱数生成された共有鍵を用いることで辞書攻撃に対して安全にできる. 鍵が十分大きければ鍵探索攻撃は非現実的になる. このアプローチは, ユーザーが十分長い鍵を記憶して入力するのに苦労するため, 鍵がエンドノードに設定されユーザーが覚えて打ち込むのではないときに最もよく機能する.

パスワードベースのシステムと同様, 共有鍵システムは管理の問題に悩まされる. 通信する各当事者のペアは合意した独自の鍵を持たなければならず, 鍵が非常に多くなる.

4.1.4. Key Distribution Centers (鍵配布センター)

鍵数過多の問題を解く 1 つのアプローチは, 認証当事者の間を仲介するオンラインの「信頼できる第三者」を用いることである. 信頼できる第三者 (一般に KEY DISTRIBUTION CENTER (KDC, 鍵配布センター) と呼ばれる) はシステムの各当事者と対称鍵またはパスワードを共有する. まず KDC に接触し, KDC は両ピアの鍵で暗号化されたランダム生成対称鍵を含む TICKET (チケット) を与える. 適切なピアだけが対称鍵を復号できるため, チケットは信頼できる関連付けの確立に用いられ得る. 圧倒的に最も普及している KDC システムは Kerberos [KERBEROS] である.

4.1.5. Certificates (証明書)

単純なアプローチは, すべてのユーザーが CERTIFICATES (証明書) [PKIX] を持ち, [TLS] や [S/MIME] のようにプロトコル固有の方法で認証に用いることである. 証明書は実体の身元を公開鍵に結び付けた署名付きクレデンシャルである. 証明書の署名者は CERTIFICATE AUTHORITY (CA, 認証局) であり, その証明書は上位 CA によって署名され得る. このシステムが機能するには, 1 つ以上の CA への信頼を帯域外で確立しなければならない. そのような CA は TRUSTED ROOTS または ROOT CAS と呼ばれる. クライアント・サーバー型システムにおけるこのアプローチの主な障害はクライアントが証明書を持つことを要し, それが展開上の問題になり得ることである.

4.1.6. Some Uncommon Systems (やや珍しいシステム)

前述の方式より良い仕事をする方法はあるが, 通信セキュリティ (少なくともメッセージ完全性) が接続を保護するために用いられない限り, 典型としてはあまりセキュリティを加えない. そうでなければ攻撃者は認証後に接続をハイジャックするだけでよい. ([EKE], [SPEKE], [SRP] を含む) 多数のプロトコルは, ユーザーのパスワードを暗号プロトコルへの入力として用い得る共有鍵へ安全にブートストラップできる. これらのプロトコルの展開への大きな障害の 1 つは知的財産の地位が極めて不明瞭であることであった. 同様に, ユーザーは公開鍵証明書 (たとえば S-HTTP クライアント認証) を用いて認証できる. 典型としてこれらの方法はより完全なセキュリティプロトコルの一部として用いられる.

4.1.7. Host Authentication (ホスト認証)

ホスト認証は特別な問題を提示する. かなり一般的に, サービスのアドレスは DNS ホスト名で提示される. たとえば URL [URL] として. そのようなサービスを要求するとき, 話している相手が証明書を持つだけでなくその証明書がサーバーの期待される身元に対応することを確保しなければならない. 重要なのは証明書と期待ホスト名との安全な結合である.

たとえば, リクエストが所与のホスト名に対するものであったとき, 証明書が IP アドレス形式の身元を含むことは通常許容されない. セキュアな名前解決 [DNSSEC] が用いられない限りホスト名と IP のマッピングは安全でないため, エンドツーエンドのセキュリティを提供しない. これはホスト名がアプリケーション層で提示されるが認証がより低い層で行われるときの特別な問題である.

4.2. Generic Security Frameworks (汎用セキュリティ枠組み)

プロトコルにセキュリティ機能を提供することは困難であり得る. 認証と鍵確立機構の選択に加え, プロトコルに統合する必要がある. この問題への 1 つの応答 (IPsec と TLS に体現される) は下位レベルのセキュリティプロトコルを作成し, 新しいプロトコルをそのプロトコル上で実行することを要求することである. 最近人気になった別のアプローチは汎用アプリケーション層セキュリティ枠組みを設計することである. アイデアは, 差し替え可能な様々なセキュリティ機構を交渉できるプロトコルを設計することである. アプリケーションプロトコル設計者はその後セキュリティプロトコル PDU をアプリケーションプロトコルで運ぶよう手配する. そのような枠組みの例には GSS-API [GSS] と SASL [SASL] がある.

汎用枠組みアプローチにはいくつかの問題がある. 第一に, DOWNGRADE ATTACK (ダウングレード攻撃) に非常に脆弱である. ダウングレード攻撃では, 能動的攻撃者が交渉を改ざんし, 当事者がさもなければ交渉するより弱い保護を強制する. 交渉と鍵確立の両方が完了した後に完全性検査を含めることは可能だが, その完全性検査の強度は必然的に最弱の共通アルゴリズムに限定される. この問題は交渉アプローチすべてに存在するが,

汎用枠組みはアプリケーションプロトコル作成者が適切な下位機構について深く考えるより枠組みだけを指定することを助長するため, 特に悪化する. 機構は提供するセキュリティの度合いが大きく異なり得るからである.

別の問題は, 枠組みの様々なセキュリティ機能がアプリケーション層プロトコルとどう相互作用するかが常に明白でないことである. たとえば SASL は認証枠組みとしてのみ用いられ得る, その場合 SASL 交換は行われるが接続の残りは保護されないが, 機構として GSS などによるトラフィック保護も交渉し得る. どの状況でトラフィック保護が任意でどれで必須かを知るには脅威モデルについて考える必要がある.

一般に, 認証枠組みはレガシー認証システムを既に備えたシステムに新しいプロトコルを追加する状況で最も有用である. 枠組みは新規設置により良い認証を提供しつつ既存サイトにレガシー認証システムを完全にやり直させない. システムのセキュリティ要件が明確に特定でき認証形態が少数に限られるとき, 単一のセキュリティ機構を選ぶことはより大きな単純性と予測可能性につながる. 枠組みを用いる状況では, 設計者は枠組みのオプションを慎重に検査し, 特定の脅威モデルに適した機構だけを指定すべきである (SHOULD). 枠組みが必要なら, 設計者は独自設計ではなく確立されたものの 1 つを選ぶべきである (SHOULD).

4.3. Non-repudiation (否認防止)

否認防止への素朴なアプローチは単に内容への公開鍵デジタル署名を用いることである. 拘束されたい当事者 (SIGNING PARTY, 署名当事者) は問題のメッセージにデジタル署名する. 相手方 (RELYING PARTY, 依拠当事者) は後で署名当事者が一度は争ったメッセージに同意した証拠としてデジタル署名を指し示せる. 残念ながら, このアプローチは不十分である.

署名当事者がメッセージを否認する最も容易な方法は, 秘密鍵が侵害され, 何らかの攻撃者 (必ずしも依拠当事者ではない) が争ったメッセージに署名したと主張することである. この攻撃に対して防御するには, 依拠当事者は署名時点で署名当事者の鍵が侵害されていなかったことを示す必要がある. これには証明書失効情報のアーカイブ保管やメッセージ署名時刻を確立するタイムスタンプサーバーを含む相当な基盤が要る.

さらに, 依拠当事者は署名当事者にあるメッセージに署名させながら別のメッセージに署名していると思わせようとし得る. この問題は依拠当事者が署名当事者の署名用インフラを制御するキオスク状況で特に深刻である. そのような状況の多くでは署名当事者の鍵はスマートカードに保持されるが署名対象メッセージは依拠当事者が表示する.

これらの複雑さすべてが, 否認防止を実務で展開することが困難なサービスにする.

4.4. Authorization vs. Authentication (認可対認証)

AUTHORIZATION (認可) は, 認証された当事者が特定のリソースまたはサービスにアクセスする許可を持つかを決定する過程である. 密接に結びついているが, 認証と認可は 2 つの別機構であることを理解することが重要である. この密接な結合のため, 認証が認可を意味すると誤って考えられることがある. 認証は当事者を特定するだけであり, 認可はある行為を実行できるかを定義する.

認可は認証に必然的に依存するが, 認証だけでは認可を意味しない. むしろ, 行為の許可を与える前に認可機構にその行為が許されるかを問い合わせなければならない.

4.4.1. Access Control Lists (アクセス制御リスト)

認可機構の一般的な形はアクセス制御リスト (ACL) であり, リソースへのアクセスが許されたユーザーを列挙する. 各リソースに個別の認可権限を割り当てるのは煩雑なため, リソースはしばしば階層的に配置され親リソースの ACL が子に継承される. これにより管理者はトップレベル方針を設定し必要に応じて上書きできる.

4.4.2. Certificate Based Systems (証明書ベースのシステム)

ユーザー名とパスワードなど単純な認証機構を用いるとき認証と認可の区別は直観的だが, より複雑な認証機構では区別が失われることがある.

たとえば証明書では, 有効な署名の提示は認可を意味しない. 署名は信頼できるルートを含む証明書チェーンによって裏付けられなければならず, そのルートは所与の文脈で信頼されなければならない. たとえば Acme MIS CA が発行した証明書を持つユーザーは, Acme Accounting CA が発行した証明書を持つユーザーとは異なる Web アクセス特権を持ち得る. 両方の CA が Acme Web サーバーに「信頼されている」場合でも.

これらのより複雑な性質を強制する機構はまだ完全には探求されていない. 1 つのアプローチは単にどの種類の証明書が信頼されるかを記述する方針を ACL に付けることである. 別のアプローチはその情報を証明書拡張/属性 [PKIX, SPKI] として証明書に載せるか, 別の「属性証明書」として運ぶことである.

4.5. Providing Traffic Security (トラフィックセキュリティの提供)

安全に設計されたプロトコルは, 機密なすべてのトラフィックを保護する (すなわち完全性保護, 認証, おそらく暗号化する) 何らかの機構を提供すべきである. 1 つのアプローチは [DNSSEC], [S/MIME], [S-HTTP] のようにプロトコル自体を保護することである. これはプロトコルに最も適合したセキュリティを提供するが, 正しく行うには相当な努力を要する.

多くのプロトコルは利用可能なチャネルセキュリティシステムの 1 つで十分保護され得る. 最も一般的な 2 つ IPsec [AH, ESP] と [TLS] を論じる.

4.5.1. IPsec

IPsec プロトコル (具体的には AH と ESP) は 2 つのホスト間のすべてのトラフィックに転送セキュリティを提供し得る. IPsec は可変の粒度のユーザー識別をサポートする. たとえば「IP サブネット」,「IP アドレス」,「完全修飾ドメイン名」, 個々のユーザー (「メールボックス名」) を含む. これらの可変レベルの識別は IPsec の本質的部分であるアクセス制御機能への入力として用いられる. しかし, 所与の IPsec 実装がすべての身元タイプをサポートしないことがある. 特にセキュリティゲートウェイはユーザー間認証を提供しないか, アプリケーションにその認証情報を提供する機構を持たないことがある.

AH または ESP が用いられると, アプリケーションプログラマは (AH または ESP がシステム全体で有効なら) 何もしなくてよいか, (特定の setsockopt() 呼び出しを追加するなど) 特定のソフトウェア変更が必要かもしれない, 用いる AH または ESP 実装に依存する. 残念ながら IPsec 実装を制御する API はまだ標準化されていない.

他のプロトコルを IPsec で保護することの主な障害は展開である. 現在 IPsec の主な用途は VPN アプリケーション, 特にリモートネットワークアクセスである. セキュリティ管理者とアプリケーション開発者の間の極めて緊密な調整なしに, VPN の利用は個々のアプリケーションにセキュリティサービスを提供するのにあまり適さない. そのようなアプリケーションが実際に提供されたセキュリティサービスを判断することが困難だからである.

ホスト間環境での IPsec の展開は遅かった. TLS のようなアプリケーションレベルのセキュリティシステムと異なり, 非 IPsec システムに IPsec を追加することは一般にオペレーティングシステムを変更することを伴う. カーネルを変更するか新しいドライバをインストールするかである. これは新しいアプリケーションを単にインストールするより実質的に大きな作業である. しかし, 多数の汎用 OS の最近のバージョンは IPsec スタックを含むため, 展開は容易になりつつある.

IPsec が確実に利用可能な環境では, アプリケーション通信トラフィックを保護する実行可能な選択肢となる. 保護対象トラフィックが UDP なら, IPsec とアプリケーション固有のオブジェクトセキュリティだけが選択肢である. しかし, 設計者は IPsec が利用可能であると仮定してはならない (MUST NOT). 汎用アプリケーションレイヤプロトコルのセキュリティ方針は, 意図した展開環境で IPsec が利用可能である理由がない限り, 単に IPsec を用いなければならないと述べるべきではない (SHOULD NOT). IPsec が利用可能でない可能性がありトラフィックが TCP のみなら, TLS が選択肢である. アプリケーションディベロッパーはパッケージに TLS 実装を含めることでその存在を容易に保証できるからである.

IPv6 の特別な場合, AH と ESP の両方が実装必須である. したがって AH/ESP が IPv6 のみのプロトコルまたは IPv6 のみの展開ですでに利用可能であると仮定することは合理的である. しかし, 自動鍵管理 (IKE) は実装必須ではないため, プロトコル設計者はそれが存在すると仮定すべきではない (SHOULD NOT, すべきではない). [USEIPSEC] は IPsec が良い選択である状況についてかなりの指針を提供する.

4.5.2. SSL/TLS

現在, 最も一般的なアプローチは SSL またはその後継 TLS を用いることである. これらはアプリケーションレベルで TCP 接続にチャネルセキュリティを提供する. すなわち TCP 上で動作する. SSL 実装は典型としてプログラミングを容易にする Berkeley Sockets に似たインターフェースを提供する. TLS を中心にプロトコル解を設計するときの主な論点は TLS を用いて保護された接続とそうでない接続を区別することである.

用いられる 2 つの主要アプローチは, TLS 接続用に別の well-known ポートを持つこと (たとえば TLS 上の HTTP のポートは 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] が望ましい選択肢である.

4.5.2.1. Virtual Hosts (バーチャルホスト)

TLS に「別ポート」アプローチが用いられるなら, 任意のアプリケーションレイヤトラフィックが送られる前に TLS が交渉される. これは [HTTP] のようにバーチャルホストを用いるプロトコルで問題を起こし得る. TLS ハンドシェイク中にサーバーがどの証明書をクライアントに提示すべきか分からないからである. TLS ホスト名拡張 [TLSEXT] はこの問題を解決するのに用いられ得るが, 新しすぎて広く展開されていない.

4.5.2.2. Remote Authentication and TLS (リモート認証と TLS)

TLS を用いることの 1 つの困難は, サーバーが証明書を介して認証されることである. これは以前クライアントとサーバー間で共有されたパスワードだけが認証の形であった環境では不便になり得る. 匿名 DH または自己署名 RSA 証明書でサーバーを認証せずに TLS を用い, その後 SASL と CRAM-MD5 などのチャレンジ応答で認証することが誘惑となる.

残念ながら SASL と TLS のこの合成は期待ほど強くない. 能動的攻撃者がこの接続をハイジャックすることは容易である. クライアントが SSL 接続を中間者化し (サーバーを認証していないことを思い出せ, 通常これがこの攻撃を防ぐ), その後 SASL ハンドシェイクを単にプロキシする. それ以降, 少なくともその攻撃者にとって接続は平文であるかのようである. この攻撃を防ぐには, クライアントはサーバーの証明書を検証する必要がある.

しかし, サーバーが認証されるなら, チャレンジ応答は望ましくなくなる. すでに強化されたチャネルがあれば単純なパスワードで十分である. 実際, サーバー上にパスワードを平文で保存する必要がないため, チャレンジ応答より優れていると主張し得る. したがって, チャレンジ応答システムでの鍵ファイルの侵害は単純なパスワードを用いた場合より深刻である.

クライアントが証明書を持つなら SSL ベースのクライアント認証が用いられ得ることに注意せよ. これを容易にするため, SASL は EXTERNAL 機構を提供し, SASL クライアントはサーバーに「外側のチャネルで私の身元を調べよ」と伝えられる. 明らかに, これは上で述べたレイヤリング攻撃の対象にならない.

特別な場合には IPSEC や SSL/TLS を用いずアプリケーション内で直接チャネルレベルのセキュリティを提供する価値がある. 1 つはリモート端末セキュリティである. 文字は典型としてクライアントからサーバーへ 1 文字ずつ送られる. SSL/TLS と AH/ESP はすべてのパケットを認証し暗号化するため, これは 20 倍のデータ拡大を意味し得る. telnet 暗号化オプション [ENCOPT] はメッセージ完全性を犠牲にすることでこの拡大を防ぐ.

リモート端末サービスを用いるとき, 他の種類の通信サービスを安全に実行したいことが多い. リモートログインに加え, SSH [SSH] は任意の TCP ポートの安全なポート転送も提供し, ユーザーが SSH チャネル上で任意の TCP ベースのアプリケーションを実行できる. SSH ポート転送がファイアウォールを不当に迂回し不安全な内部アプリケーションを外部に不当に晒すために不当に用いられるとセキュリティ上の問題になり得ることに注意せよ.

4.6. Denial of Service Attacks and Countermeasures (サービス拒否攻撃と対抗策)

サービス拒否攻撃はあまりにも頻繁に人生の事実のように見なされる. 1 つの問題は, 攻撃者は被害者に加えるサービス拒否攻撃を多数から選べることが多く, これらの攻撃のほとんどは阻止できないため, 防止できない他のサービス拒否攻撃が可能なときに 1 種のサービス拒否攻撃から保護しても意味がないという共通の知恵がしばしば前提とされる.

しかし, すべてのサービス拒否攻撃が同等ではなく, より重要に, プロトコルを設計してサービス拒否攻撃を困難に, 非現実的にすることは可能である. 最近の SYN flood 攻撃 [TCPSYN] は両方の性質を示す: SYN flood 攻撃は非常に容易で匿名かつ効果的なため攻撃者にとって他の攻撃より魅力的である, そして TCP の設計がこの攻撃を可能にするからである.

完全な DoS 保護がこれほど困難なため, DoS に対するセキュリティは実用的に扱わなければならない. 特に, 防御したい一部の攻撃は経済的に防御できない. 目標は, 深刻度対防御コストの比が十分高い攻撃に対して防御することでリスクを管理することである. 攻撃の深刻度と防御コストは技術とともに変化するため, 防御すべき攻撃の集合も変化する.

インターネット標準の著者は, プロトコルがどのサービス拒否攻撃に脆弱かを記述しなければならない (MUST). この記述には, これらのサービス拒否攻撃を回避しようとしないことが不合理であったか範囲外であったかの理由を含めなければならない (MUST).

BLIND (ブラインド) サービス拒否攻撃は特に悪質である. ブラインド攻撃では攻撃者は大きな優位を持つ. 攻撃者が被害者からトラフィックを受信できなければ, ルーティング基盤を侵害するか自らの IP アドレスを用いなければならない. いずれも被害者が攻撃者を追跡しそのトラフィックをフィルタする機会を与える. ブラインド攻撃では攻撃者は偽造 IP アドレスを用い得, 被害者がパケットをフィルタすることが極めて困難になる. TCP SYN flood 攻撃はブラインド攻撃の例である. 設計者はブラインドサービス拒否攻撃を防ぐために可能なあらゆる試みをすべきである.

4.6.2. Distributed Denial of Service (分散サービス拒否)

さらに危険なのは DISTRIBUTED (分散) サービス拒否攻撃 (DDoS) [DDOS] である. DDoS では攻撃者は多数の機械が同時に対象機械を攻撃するよう手配する. 通常これは多数の機械にリモートで攻撃を開始できるプログラムを感染させることで達成される. 実際に攻撃を行う機械は ZOMBIE (ゾンビ) と呼ばれ, 真の攻撃者とは全く別の場所にある気付かぬ第三者が所有している可能性が高い. DDoS 攻撃はゾンビが正当なプロトコルリクエストを行っているように見え,

実ユーザーを単に押しのけることが多いため対抗が非常に困難である. DDoS 攻撃は阻止が困難だが, プロトコル設計者はプロトコル設計中にこれらの攻撃形態を認識することが期待される.

4.6.3. Avoiding Denial of Service (サービス拒否の回避)

サービス拒否攻撃をより困難にする 2 つの一般的アプローチがある:

4.6.3.1. Make your attacker do more work than you do (攻撃者に自分より多く働かせる)

攻撃者が攻撃を開始するときに自分のリソースをあなたのリソースより多く消費すれば, あなたより少ないリソースの攻撃者は効果的な攻撃を開始できない. 一般的技法の 1 つは攻撃者に暗号操作など時間集約的操作を実行させることである. 攻撃者が実質的に十分な CPU 力を集めれば依然サービス拒否攻撃を実施し得ることに注意せよ. たとえばこの技法は [TCPSYN] で記述された分散攻撃を止めない.

4.6.3.2. Make your attacker prove they can receive data from you (攻撃者にあなたからデータを受信できることを証明させる)

ブラインド攻撃は, 攻撃者に被害者からデータを受信できることを証明させることで挫けさせられ得る. 一般的技法は攻撃者がメッセージ交換の早い段階で得た情報を用いて応答することを要求することである. この対抗策が用いられると, 攻撃者は自らのアドレスを用いる (追跡が容易になる) か, 攻撃が開始されているホストからの経路を横断するようルーティングされるアドレスを偽造しなければならない.

小さなサブネット上のホストはしたがって攻撃者にとって (少なくともスプーフィング攻撃の文脈では) 無用である. 攻撃はサブネットまで追跡でき (攻撃者の特定に十分であるべき), 対抗攻撃措置が講じられ得る (たとえば境界ルータがそのサブネットからのすべてのトラフィックを破棄するよう設定される). 一般的技法は攻撃者がメッセージ交換の早い段階で得た情報を用いて応答することを要求することである.

4.6.4. Example: TCP SYN Floods (例: TCP SYN flood)

TCP/IP は 3 ウェイ・ハンドシェイクの設計のため (3.3.2 節で記述される) SYN flood 攻撃に脆弱である. 第一に, 攻撃者は単一パケットを送ることで被害者に相当なリソース (この場合メモリ) の消費を強制できる. 第二に, 攻撃者が被害者からデータを受信しなくてもこの行動を実行できるため, 攻撃は匿名で実施でき (したがって多数の偽造送信元アドレスを用いる).

4.6.5. Example: Photuris (例: Photuris)

[PHOTURIS] は SYN flood 攻撃に似た Photuris への攻撃を防ぐアンチクロッギング機構を規定する. Photuris は時変秘密を用いて攻撃者に返す「クッキー」を生成する. このクッキーは後続メッセージで返されなければ交換は進まない. 興味深い特徴は, このクッキーが交換の後で被害者によって再生成でき, したがって攻撃者が被害者からパケットを受信できることを証明するまで被害者は状態を保持する必要がないことである.

4.7. Object vs. Channel Security (オブジェクト対チャネルセキュリティ)

オブジェクトセキュリティとチャネルセキュリティの概念的区別を立てることは有用である. オブジェクトセキュリティはデータオブジェクト全体に適用されるセキュリティ対策を指す. チャネルセキュリティ対策はオブジェクトを透過的に運べる安全なチャネルを提供するが, チャネルはオブジェクト境界について特別な知識を持たない.

電子メールメッセージの場合を考えよ. IPSEC または TLS で保護された接続上で運ばれるとき, メッセージは転送中は保護される. しかし受信者のメールボックスや途中のスプールファイルでは保護されない. さらに, メールサーバーは一般にユーザではなくデーモンとして動作するため, メッセージの認証は一般にユーザではなくデーモンの認証を意味するだけである. 最後に, メール転送はホップ・バイ・ホップであるため, ユーザーが最初のホップ中継に認証しても受信者はその認証を安全に検証できない.

対照的に, メールメッセージが S/MIME または OpenPGP で保護されるとき, メッセージ全体は受信者が検査し復号するまで暗号化され完全性保護される. また実際の送信者の強力な認証も提供し, メッセージが来た機械ではない. これがオブジェクトセキュリティである. さらに受信者は署名付きメッセージの真正性を第三者に証明できる.

オブジェクトとチャネルセキュリティの違いは視点の問題であることが多い. プロトコルスタックの 1 層でのオブジェクトセキュリティは, 上の層からはチャネルセキュリティに見える. したがって IP 層の視点からは各パケットは個別に保護されたオブジェクトに見える. しかし Web クライアントの視点から IPSEC は単に安全なチャネルを提供する.

区別は常に明確ではない. たとえば S-HTTP は単一の HTTP トランザクションに対するオブジェクトレベルのセキュリティを提供するが, Web ページは典型として複数の HTTP トランザクション (ベースページと

多数のインライン画像) から成る. したがって Web ページ全体の視点からは, これはむしろチャネルセキュリティに見える. Web ページに対するオブジェクトセキュリティは, ページと埋め込まれたすべての内容の推移的閉包を単一単位としてのセキュリティであろう.

4.8. Firewalls and Network Topology (ファイアウォールとネットワークトポロジ)

現代のネットワークではファイアウォールを用いてネットワークを外部と内部に分割することが一般的なセキュリティ実践である. 内部ネットワークはその後安全であると仮定され, そこでは限定的なセキュリティ対策だけが用いられる. そのようなネットワークの内部部分はしばしば WALLED GARDEN (囲い込み庭) と呼ばれる.

インターネットプロトコル設計者はプロトコルがそのような環境に展開されると安全に仮定できない. 3 つの理由がある. 第一に, もともと閉じた環境に展開されるよう設計されたプロトコルが後にインターネットに展開され, 深刻な脆弱性を生むことがある.

第二に, トポロジ的に切断されているように見えるネットワークがそうでないことがある. 理由の 1 つはネットワークが再構成され外部からのアクセスが許されたことである. さらに, ファイアウォールは [SOAP] や [HTTP] など汎用アプリケーションレイヤプロトコルをますます通過させている. これらの汎用プロトコルに基づくネットワークプロトコルは一般にファイアウォールが保護すると仮定できない. 最後に, システムに対する最も深刻なセキュリティ脅威の 1 つは外部ではなく内部からである. 内部者は定義上内部ネットワークにアクセスするため, ファイアウォールなどのトポロジ的保護は彼らを保護しない.