6. Examples (例)

6. Examples (例)

本節は Security Considerations セクションの例をいくつか含み, 読者に本書の意図の雰囲気を与えることを意図する.

最初の例は「回顧的」例であり, 本書の基準を広く展開された既存プロトコル SMTP に適用する. 第 2 の例は現行プロトコルから抜粋した優れた Security Considerations セクションである.

6.1. SMTP

RFC 821 が書かれたとき, RFC に Security Considerations セクションは必須ではなく, その文書には含まれていない. [RFC 2821] が RFC 821 を更新し詳細な security considerations セクションを追加した. ここではその文書の Security Considerations セクションを再掲する (新しい節番号付き). コメントは字下げし 'NOTE:' を前置する. 重要だと考える論題を扱う新しい節もいくつか追加する. それらの節は節見出しに [NEW] と記す.

6.1.1. Security Considerations (セキュリティに関する考慮事項)

6.1.1.1. Mail Security and Spoofing (メールセキュリティとスプーフィング)

SMTP メールは本質的に不安全である. 比較的カジュアルなユーザーでさえ受信および中継 SMTP サーバーと直接交渉し, 素朴な受信者を別の場所から来たと信じ込ませるメッセージを作成することが現実的である. そのような「スプーフ」行動が専門家によって検出できないようメッセージを構成することはやや難しいが, 決意と知識のある誰かを抑止するほどではない. したがって, インターネットメールに関する知識が増すにつれ, SMTP メールは本質的に転送レベルでは認証も完全性検査も提供できないという知識も増す. 真のメールセキュリティはデジタル署名を用いるなどメッセージ本体に関するエンドツーエンド方式にのみ存在する ([14] およびたとえば PGP [4] または S/MIME [31] を参照).

NOTE: 送信者認証への悪いアプローチの 1 つは [IDENT] である. 受信メールサーバーが主張される送信者に連絡し送信者のユーザー名を尋ねる. これは中継, TCP 接続ハイジャック, 起源サーバーの単純な嘘を含むがこれらに限定されない多数の理由で悪い考えである. IDENT のセキュリティ価値が低いという事実とは別に, 受信サイトによる IDENT の利用は運用上の問題につながり得る. 多くの送信サイトが IDENT リクエストをブラックホールし, 受信サーバーの IDENT リクエストがタイムアウトするまでメールが保持される原因となる.

転送レベルで認証を提供する様々なプロトコル拡張と設定オプション (たとえば SMTP クライアントから SMTP サーバーへ) は上で記述された従来の状況を多少改善する. しかし, 慎重に設計された信頼環境における責任の慎重な引き渡しに伴わない限り, 転送システムの完全性に依存するのではなくデジタル署名メッセージを用いるエンドツーエンド機構より本質的に弱いままである.

ユーザーがエンベロープの返送パスとヘッダの「From」フィールドを自分以外の有効アドレスに設定することをより困難にする努力は, 大きく誤った方向である: 別のユーザーに代わってメールを送る正当なアプリケーションや, エラー (または通常) の返信を特別なアドレスに向けるべき場合を妨げる. (ユーザーがメッセージごとにこれらのフィールドを便利に変更できるシステムは, メッセージデータ内の Sender フィールドを合理的に生成できるようユーザーの主要かつ恒久的なメールボックスアドレスを確立しようと試みるべきである.)

本仕様は SMTP に関連する認証問題をこれ以上扱わず, 偽メールに対するわずかな保護を提供しようとして有用な機能を無効にしないことを提唱する以外はない.

NOTE: 通信セキュリティと SMTP についての追加資料を 6.1.2 節に追加した. 最終仕様では上記テキストはその事実を反映するようやや編集されるであろう.

6.1.1.2. Blind Copies (Bcc)

メッセージヘッダに現れないアドレスが SMTP サーバーへの RCPT コマンドに現れ得る理由はいくつかある. 最も一般的な 2 つはメーリングアドレスを「リスト展開器」 (単一アドレスが複数アドレスに解決される) として用いることと「blind copy」の出現である. 特に複数の RCPT コマンドがあるとき, これらの機構の目的の一部を無効にしないため, SMTP クライアントとサーバーは RCPT コマンド引数の完全集合をトレースヘッダの一部として, または情報用またはプライベート拡張ヘッダとしてヘッダにコピーすべきではない (SHOULD NOT). この規則は実務でしばしば違反され強制できないため, 「bcc」使用を認識する送信 SMTP システムは, 単一の RCPT コマンドだけを含む別々のメッセージトランザクションとして各 blind copy を送ることが助けになる場合がある (MAY).

SMTP トランザクション (「エンベロープ」) 内の「逆」 (MAIL, SAML などのコマンドから) または「順」 (RCPT) アドレスとヘッダ内のアドレスとの間に本質的な関係はない. 受信システムはそのような関係を推論してメッセージのヘッダを配送のために変更しようとしてはならない (SHOULD NOT). 普及した「Apparently-to」ヘッダはこの原則違反であると同様に意図しない情報開示の一般的な原因であり, 用いてはならない (SHOULD NOT).

6.1.1.3. VRFY, EXPN, and Security (VRFY, EXPN, およびセキュリティ)

3.5 節で論じたとおり, 個々のサイトはセキュリティ上の理由で VRFY または EXPN のいずれかまたは両方を無効にしたい場合がある. 上記の帰結として, これを許す実装は, 実際には検証されていないアドレスを検証されたように見せてはならない (MUST NOT). サイトがセキュリティ上の理由でこれらのコマンドを無効にする場合, SMTP サーバーは成功または失敗した検証と混同され得るコードではなく 252 応答を返さなければならない (MUST).

VRFY コマンドにリストされたアドレスについて構文だけを検査した後 250 応答コードを返す実装はこの規則に違反する. もちろん, アドレスが有効かどうかに関わらず常に 550 を返すことで VRFY を「サポートする」実装も同様に適合しない.

ここ数年, メーリングリストの内容はいわゆる「スパマー」のアドレス情報源として普及した. リスト自体の不適切な使用に対する保護がリスト管理者によって導入されるにつれ, アドレスを「収集」する EXPN の使用が増えた. 実装は依然 EXPN のサポートを提供すべきである (SHOULD) が, サイトはトレードオフを慎重に評価すべきである (SHOULD). SMTP に認証機構が導入されるにつれ, 一部のサイトは EXPN を認証された要求者にのみ利用可能にすることを選び得る.

NOTE: VRFY を無効にすることがどれだけ保護を加えるかは不明である. RCPT TO を用いてアドレスが有効かどうかを発見できることが多いからである.

6.1.1.4. Information Disclosure in Announcements (アナウンスにおける情報開示)

グリーティング応答または HELP コマンドへの応答でサーバータイプとバージョン (時にはサーバードメイン名まで) をアナウンスするデバッグ上の利点と, 潜在的に敵対的な攻撃に有用な情報を晒す欠点のトレードオフについて継続的な議論があった. デバッグ情報の有用性は疑いようがない. 利用可能にすべきと主張する者は, サーバーの正確な身元を隠して既知の脆弱性を隠すことより実際に SMTP サーバーを安全にすることがはるかに優れていると指摘する. サイトはその問題を念頭にトレードオフを評価することが奨励される. 実装は他のネットワークホストにタイプとバージョン情報を何らかの方法で最低限提供することが強く奨励される.

6.1.1.5. Information Disclosure in Trace Fields (トレースフィールドにおける情報開示)

一部の状況では, たとえばメールが公衆インターネットに直接ない LAN 内から発信されるときなど, 本仕様に従って生成されたトレース (「Received」) フィールドは通常利用可能でないホスト名や類似の情報を開示し得る. これは通常問題にならないが, 名前開示に特別な懸念があるサイトはそれを認識すべきである. また, 複数受信者が関与するときオプションの FOR 句は慎重に供与するか, まったく供与しないべきである. そうでなければ「blind copy」受信者の身元を他に意図せず開示し得る.

6.1.1.6. Information Disclosure in Message Forwarding (メッセージ転送における情報開示)

3.4 節で論じたとおり, メールボックスに関連付けられた置換アドレスを識別する 251 または 551 応答コードの使用は, 機密情報を意図せず開示し得る. それらの問題を懸念するサイトはサーバーを適切に選択し設定すべきである.

6.1.1.7. Scope of Operation of SMTP Servers (SMTP サーバーの運用範囲)

SMTP サーバーはサーバーを提供するサイトにとって合理的な運用上または技術上の理由であればメール受け入れを拒否し得るという確立された原則がある. しかし, サイトと設置間の協力がインターネットを可能にする. サイトがトラフィック拒否の権利を過度に行使すると, メールの普遍性 (インターネットの強みの 1 つ) が脅かされる. サイトが受け入れ処理するトラフィックについて選択的であることに決めたなら, 細心の注意を払いバランスを保つべきである.

近年, 任意のサイトを通じた中継機能の使用はメールの実際の起源を隠す敵対的努力の一部として用いられてきた. 一部のサイトは中継機能の使用を既知または識別可能なソースに限定することに決めた. 実装はこの種のフィルタリングを実行する能力を提供すべきである (SHOULD). メールがこれらまたは他の方針上の理由で拒否されるとき, 550 コードを EHLO, MAIL, または RCPT に適宜応答して用いるべきである (SHOULD).

6.1.1.8. Inappropriate Usage (不適切な使用)

SMTP 自体は未承諾の商業大量電子メール (通称 spam) に対する保護を提供しない. 所与のメッセージが spam かどうかを事前に告げることは極めて困難である. プロトコルの観点から spam は他の電子メールと区別がつかない, 区別はほぼ完全に社会的でしばしばかなり微妙である. (たとえば以前に商品を購入した商人からの類似商品の広告メッセージは spam か?) SMTP の spam 抑制機構は一般に既知の spam 送信者を識別しサービスを拒否するか処罰/切断の対象にすることに限定される. [RFC-2505] は SMTP サーバーを spam に強くする広範な指針を提供する. ここでは簡潔に論じる.

スパマーへのサービス拒否の主要ツールはブラックリストである. [MAPS] などの権威が既知のスパマーのリストを収集し公開する. 個々の SMTP サーバーはその後ブラックリスト入りの違反者をブロックする (一般に IP アドレスで).

ブラックリスト入りまたはその他の方法で識別されるのを避けるため, スパマーはしばしば身元を隠そうとする. 単純に偽の SMTP 身元を送るか, 任意の送信者にメール中継を実行する SMTP サーバー (オープンリレー) を通じてメールを転送する. その結果, オープンリレーのブラックリスト [ORBS] も存在する.

6.1.1.8.1. Closed Relaying (クローズドリレー)

spam 転送に用いられるのを避けるため, 多くの SMTP サーバーはクローズドリレーとして動作し, 識別できるクライアントにのみ中継サービスを提供する. そのようなリレーは一般に送信者が既知の身元と整合する送信アドレスを宣伝することを要求すべきである. リレーが識別可能なネットワーク (企業ネットワークや ISP ネットワークなど) 向けにサービスを提供するなら, 他のすべての IP アドレスをブロックすれば十分である. 他の場合は明示的認証を用いなければならない. そのための 2 つの標準的選択肢は TLS [STARTTLS] と SASL [SASLSMTP] である.

6.1.1.8.2. Endpoints (エンドポイント)

現実的に, SMTP エンドポイントは未認証の送信者へのサービスを拒否できない. 圧倒的多数の送信者が未認証であるため, これはインターネットメールの相互運用性を破る. 例外は, エンドポイントサーバーが未認証メッセージを自ら受信できる別のサーバーからのメールだけを受けるべきときである. たとえば企業は公開ゲートウェイを運用し内部サーバーがゲートウェイとのみ通信するよう設定し得る.

6.1.2. Communications security issues (通信セキュリティ上の論点)

SMTP 自体は通信セキュリティを提供しないため, 多数の攻撃が可能である. 受動的攻撃は SMTP で送信されたメッセージのテキストを回復するのに十分である. プロトコルはエンドポイント認証を提供しない. 送信者スプーフィングは容易であるため, メールメッセージの偽造も容易である. 一部の実装は逆引き名前解決 (DNS のスプーフィングが困難である範囲でのみ安全, あまり安全でない) で得たホスト名由来のヘッダ行を追加するが, これらのヘッダ行は一般にユーザーに表示されない. 受信者スプーフィングも TCP 接続ハイジャックまたは DNS スプーフィングによりかなり直接的である. さらに, メールメッセージはしばしば SMTP ゲートウェイを通過するため, すべての中間ゲートウェイを信頼しなければならず, グローバルインターネットではほぼ不可能な条件である.

これらの脅威を緩和するいくつかのアプローチがある. プロトコルスタックの上に行くほど高レベルの順に:

SMTP over IPSEC SMTP/TLS S/MIME and PGP/MIME

6.1.2.1. SMTP over IPSEC

IPSEC 上で動作する SMTP 接続は, 送信者と最初のホップ SMTP ゲートウェイの間, または接続された SMTP ゲートウェイの任意のペア間でメッセージに機密性を提供し得る. すなわち SMTP 接続にチャネルセキュリティを提供する. メッセージがクライアントから受信者のゲートウェイへ直接行く状況では, これは実質的なセキュリティを提供し得る (ただし受信者は依然ゲートウェイを信頼しなければならない). データ自体が保護されパケットを再生できないため, 再生攻撃に対する保護が提供される.

しかし, 受信者のアドレスを暗号的に直接認証できない限りエンドポイント識別は問題である. 送信者識別は一般に利用できない. 一般に送信者の機械だけが認証され, 送信者本人は認証されないからである. さらに, 送信者の身元は単にメッセージの From ヘッダに現れるため, 送信者によって容易にスプーフ可能である. 最後に, セキュリティ方針が極めて厳格に設定されない限り, 平文への能動的ダウングレード攻撃もある.

SMTP に対するセキュリティ解として IPsec の別の問題は標準 IPsec API の欠如である. IPsec を利用するために, アプリケーションは一般に IPsec 実装にセキュリティ方針を指示し接続にどの保護が適用されたかを発見できなければならない. 標準 API なしにこれを移植的に行うことは非常に困難である.

SMTP サーバの実装者または SMTP 管理者は, (2 つの機械間の既存の関連付けの存在など) IPsec が利用可能であると信じる理由がない限り IPsec が利用可能であると仮定してはならない (MUST NOT). しかし, メール配送時にピアサーバーへの IPsec 関連付けを機会主義的に作成しようとすることが合理的な手続きであり得る. IPsec が 2 サイト間に VPN トンネルを提供するために用いられる場合, 上で述べた注意書きに従えば, 特に機密性が提供される範囲で実質的なセキュリティ価値があることに注意せよ. IPsec の適用可能性に関する一般的な指針は [USEIPSEC] も参照せよ.

6.1.2.2. SMTP/TLS

SMTP は [STARTTLS] に記述されるとおり TLS と組み合わせられ得る. これは IPSEC を用いる場合と類似の保護を提供する. TLS 証明書は典型としてサーバーのホスト名を含むため, 受信者認証はやや明白になり得るが, 依然 DNS スプーフィング攻撃に脆弱である. 特に, 一般的 TLS 実装には米国輸出可能 (したがって低セキュリティ) モードが含まれる. 高セキュリティを望むアプリケーションはこのモードが無効であることを確保すべきである. データ自体が保護されパケットを再生できないため, 再生攻撃に対する保護が提供される. [注: SMTP over TLS 文書の Security Considerations セクションはかなり優れており, 物事の行い方の例として読む価値がある.]

6.1.2.3. S/MIME and PGP/MIME

S/MIME と PGP/MIME はいずれもメッセージ指向のセキュリティプロトコルである. 個々のメッセージにオブジェクトセキュリティを提供する. 様々な設定で, 送信者と受信者の認証と機密性が提供され得る. より重要に, 識別は送受信機械ではなく送信者と受信者自身のものである (または少なくとも送信者と受信者に対応する暗号鍵のもの). したがってエンドツーエンドセキュリティが得られ得る. しかしながら, 再生攻撃に対する保護は提供されないことに注意せよ. さらに S/MIME と PGP/MIME は一般に送信者と受信者の両方の識別印を提供する. したがって機密性が提供されてもトラフィック解析は依然可能である.

6.1.3. Denial of Service (サービス拒否)

これらのセキュリティ対策のいずれもサービス拒否に対する実質的保護を提供しない. SMTP 接続は過剰なポート消費, 過剰なディスク使用 (電子メールは典型としてディスクファイルに配送される), 過剰なメモリ消費 (sendmail はかなり大きく, 典型としてメッセージごとに新しいプロセスを fork する) を含む多数の方法でシステムリソースを占有するのに容易に用いられ得る.

転送またはアプリケーションレイヤセキュリティが SMTP 接続に用いられると, 偽造 RST または他の種類のパケット注入を用いて個々の接続に対する様々な攻撃を実施することが可能である.

6.2. VRRP

第 2 の例は Virtual Router Redundance Protocol (仮想ルータ冗長プロトコル) ([VRRP]) からである. ここではその文書の Security Considerations セクションを再掲する (新しい節番号付き). コメントは字下げし 'NOTE:' を前置する.

6.2.1. Security Considerations (セキュリティに関する考慮事項)

VRRP は異なるセキュリティ方針を採用し得るインターネットワーク環境の範囲向けに設計されている. プロトコルには認証なし, 単純な平文パスワード, MD5 HMAC を用いる IP Authentication による強力な認証まで, いくつかの認証方式が含まれる. 各アプローチの詳細, 可能な攻撃, 推奨環境が続く.

いかなる認証タイプから独立に, VRRP は (TTL=255 の設定と受信時の検査により) 別のリモートネットワークから VRRP パケットが注入されるのを防ぐ機構を含む. これはほとんどの脆弱性をローカル攻撃に限定する.

NOTE: 以下の節で論じるセキュリティ対策は様々な種類の認証のみを提供する. 機密性はまったく提供されない. これは明示的に範囲外として記述されるべきである.

6.2.1.1. No Authentication (認証なし)

この認証タイプの使用は VRRP プロトコル交換が認証されないことを意味する. この認証タイプはセキュリティリスクが最小で設定ミスの可能性が小さい環境 (たとえば LAN 上の 2 つの VRRP ルータ) にのみ用いるべきである (SHOULD only).

6.2.1.2. Simple Text Password (単純テキストパスワード)

この認証タイプの使用は VRRP プロトコル交換が単純な平文パスワードで認証されることを意味する.

この認証タイプは LAN 上のルータの偶発的誤設定から保護するのに有用である. 別のルータを誤ってバックアップするルータから保護する. 新しいルータは別のルータと VRRP を実行する前にまず正しいパスワードで設定されなければならない. この認証タイプは, パスワードが LAN 上で VRRP パケットを盗聴するノードによって学習され得る敵対的攻撃からは保護しない. 単純テキスト認証と TTL 検査の組合せは, 別の LAN から VRRP パケットが送られ VRRP 動作を妨害することを困難にする.

この認証タイプは LAN 上のノードが VRRP 動作を能動的に妨害するリスクが最小のとき推奨される (RECOMMENDED). この認証タイプが用いられる場合, ユーザーはこの平文パスワードが頻繁に送られるため, いかなるセキュリティ上重要なパスワードと同じであってはならないことを認識すべきである.

NOTE: 本節はより明確であるべきである. 基本点は, 認証なしと単純テキストは非常に限定的脅威モデル, すなわちローカル LAN 上のノードがいずれも敵対的でない場合にのみ有用であるということである. TTL 検査は LAN 外の敵対的ノードが正当ノードを装うのを防ぐが, LAN 上の敵対的ノードが認可されたノードを偽装するのを止めない. これは多くの状況で特に現実的な脅威モデルではない. 特に極めて脆い: LAN 上のいずれかのノードの侵害が VRRP ノードの再設定を許す.

6.2.1.3. IP Authentication Header (IP 認証ヘッダ)

この認証タイプの使用は VRRP プロトコル交換が IP Authentication Header [AH] で定義される機構を用いて [HMAC] により認証されることを意味する. これは設定ミス, 再生攻撃, パケット破損/改変に対する強力な保護を提供する.

この認証タイプは LAN 上のノードの管理に限定的な制御があるとき推奨される (RECOMMENDED). この認証タイプは VRRP の動作を保護するが, 共有メディアリンクに対して用いられ得る VRRP とは独立の他の種類の攻撃 (たとえば偽の ARP 応答の生成) があり, 保護されない.

NOTE: この文脈で AH を RECOMMENDED とすることが誤りである. AH は同一 LAN 上の他ノードからの VRRP 攻撃に対して VRRP を保護する唯一の機構であるため, 同一ネットワークに信頼できないノードがある場合は MUST であるべきである. いずれにせよ AH は MUST implement であるべきである.

NOTE: この文書ではほのめかされているに過ぎない重要なセキュリティ分析の一部, すなわち VRRP 認証の費用/便益トレードオフがある.

[本節の残りは新規資料] VRRP 認証が防ごうとする脅威は, 攻撃者が VRRP マスターになろうと手配することである. これはグループに参加し (おそらく複数回), マスターを黙らせ, 自分をマスターに選出することで行われる. そのようなノードは望ましくない方法でトラフィックを任意に誘導し得る.

しかし, 攻撃者が VRRP マスターである必要はない. 攻撃者は ARP パケットを偽造するか (スイッチネットワークでは) スイッチを欺くことでネットワークに類似の損害を与えられ, VRRP 認証はこれらの攻撃に対して実質的保護を提供しない.

不幸にも, 認証は誤設定に直面した VRRP ネットワークを非常に脆くする. 2 つのノードが異なるパスワードで設定されていると何が起きるか考えよ. 各ノードは他方からのメッセージを拒否し両方がマスターになろうとする. これは実質的なネットワーク不安定性を生む.

この費用/便益トレードオフの集合は, 増分セキュリティ便益は限定的だが増分リスクは高いため, VRRP 認証は悪い考えであることを示唆する. 現在の VRRP 以外の脅威の集合が除去されればこの判断は再検討されるべきである.