5. Security Considerations (セキュリティに関する考慮)
5. Security Considerations (セキュリティに関する考慮)
本プロトコルは未認証ピアへの構成情報開示を最小化するよう設計されているが, ある程度の開示は避けられない. どちらか一方が先に身元を示し先に証明しなければならない. 探索を避けるため, 交換の発起側が先に身元を示すことが要求され, 通常は先に自身を認証することが要求される. しかし発起側は応答側が IKE をサポートしどの暗号プロトコルをサポートするかを知り得る. 応答側 (または応答側を装う者) は発起側の身元を探索できるだけでなく, CERTREQ ペイロードにより発起側が使用しうる証明書を特定し得る.
EAP 認証を用いると探索の可能性がやや変わる. EAP 認証では応答側が発起側より先に身元を証明するため, 有効な発起側名を知る発起側は応答側の名前と証明書の両方を探索し得る.
追加の Diffie-Hellman 交換なしに CREATE_CHILD_SA を繰り返し再鍵すると, すべての SA が単一鍵の暗号解析に脆弱になる. 実装者はこの事実に留意し, 指数演算の間の CREATE_CHILD_SA 交換の上限を設けるべきである. 本ドキュメントはその上限を規定しない.
ここで定義されたグループのいずれかを用いた Diffie-Hellman 交換から導出される鍵の強度は, グループの固有強度, 用いる指数の大きさ, 使用する乱数生成器が提供するエントロピーに依存する. これらの入力により, 定義された各グループの鍵強度を決定するのは難しい. 強い乱数生成器と 200 ビット未満でない指数とともに用いる場合, Diffie-Hellman グループ番号 2 は 3DES と共に一般的である. グループ 5 はグループ 2 より高いセキュリティを提供する. グループ 1 は歴史的目的のみであり, 同様に歴史的用途のみの DES との使用を除き十分な強度を提供しない. 実装者はポリシー設定とセキュリティパラメータ交渉時にこれらの見積もりに留意すべきである.
これらの制限は Diffie-Hellman グループ自体に関するものである. IKE によりより強いグループの使用が禁止されるものは何もなく, より強いグループから得られる強度を薄めるものもない (交渉された他のアルゴリズム PRF (Pseudorandom Function) を含む強度で上限がある). 実際 IKE の拡張可能な枠組みはより多くのグループの定義を奨励し, 楕円曲線グループの使用ははるかに小さな数で強度を大きく高め得る.
すべての Diffie-Hellman 指数は使用後にメモリから消去されると仮定する.
IKE_SA_INIT と IKE_AUTH 交換は発起側が認証される前に行われる. したがって本プロトコルの実装は, いかなる非セキュアネットワークに展開される場合も完全に堅牢でなければならない. 実装の脆弱性, 特に DoS (Denial of Service) 攻撃は未認証ピアによって悪用され得る. EAP ベース認証ではメッセージ数に上限がないためこの問題は特に憂慮すべきである.
すべての鍵の強度は交渉された PRF の出力サイズによって制限される. この理由から, 出力が 128 ビット未満の PRF (例: 3DES-CBC) を本プロトコルとともに用いてはならない.
本プロトコルのセキュリティはランダムに選ばれたパラメータのランダム性に重大に依存する. これらは強い乱数源または適切にシードされた疑似乱数源により生成すべきである ([RANDOMNESS] を参照). 実装者は鍵と nonce の両方への乱数使用が鍵のセキュリティを損なわないよう設計することに注意すべきである.
本プロトコルの多くの暗号設計選択の根拠については [SIGMA] および [SKEME] を参照. 交渉された Child SA のセキュリティは IKE SA で交渉された暗号化と完全性保護の強度に依存しないが, 実装は IKE 完全性保護アルゴリズムとして NONE, IKE 暗号アルゴリズムとして ENCR_NULL を交渉してはならない.
事前共有鍵を用いる場合, これらの秘密のランダム性をどう保証するかが重要な考慮事項である. 最も強い慣行は, 事前共有鍵が交渉される最強の鍵と同程度のランダム性を含むことを保証することである. パスワード, 名前, その他の低エントロピー源から共有秘密を導出することはセキュアではない. これらの源は辞書攻撃やソーシャルエンジニアリング攻撃などの対象となる.
NAT_DETECTION_*_IP 通知は NAT の背後にある内部 IP アドレスを隠す試みとしてアドレスとポートのハッシュを含む. IPv4 アドレス空間は 32 ビットのみであり通常は非常に疎であるため, 攻撃者はすべての IP アドレスを試して一致するハッシュを見つけることで NAT ボックス背後で用いられる内部アドレスを突き止め得る. ポート番号は通常 500 に固定され, SPI はパケットから抽出できる. これによりハッシュ計算回数は 2^32 に減る. プライベートアドレス空間の使用について教育的推測をすれば, ハッシュ計算回数ははるかに小さくなる. 設計者は IKE の使用が内部アドレス情報を漏らさないと仮定すべきではない.
後続の AUTH ペイロードを保護する共有鍵を生成しない EAP 認証方式を用いる場合, 特定の中間者およびサーバ偽装攻撃が可能である [EAPMITM]. これらの脆弱性は EAP がセキュアトンネルで保護されていないプロトコルでも用いられるときに生じる. EAP は汎用認証プロトコルでありしばしばシングルサインオンを提供するために用いられるため, 共有鍵を生成しない EAP 認証方式 (非鍵生成 EAP 方式とも呼ばれる) に依存する展開済み IPsec ソリューションは, 同じ非鍵生成 EAP 方式を保護なしで用いるまったく無関係なアプリケーションの展開により侵害され得る. この脆弱性は EAP に限定されず, 認証インフラを再利用する他のシナリオでも起こり得る. 例えば IKEv2 が用いる EAP メカニズムがトークン認証器を用いる場合, 中間者攻撃者は Web サーバを装いトークン認証交換を傍受して IKEv2 接続を開始し得る. この理由から可能な限り非鍵生成 EAP 方式の使用は避けるべきである. 用いる場合, これらの EAP 方式のすべての使用が保護されたトンネルを用い, 発起側が EAP 認証を開始する前に応答側の証明書を検証することが極めて重要である. 実装者は IPsec ソリューションを展開する管理者がこれらの危険を認識できるよう, 非鍵生成 EAP 方式使用の脆弱性を実装ドキュメントに記述すべきである.
EAP を用いる実装は, EAP 方式が相互認証を提供する場合であっても, EAP 認証が始まる前にクライアントへのサーバの公開鍵ベース認証も用いなければならない. これにより追加の IKEv2 プロトコル変種を避け, EAP データを積極的攻撃者から保護する.
IKEv2 メッセージが IP レベルのフラグメンテーションを要するほど長い場合, 攻撃者が再構成バッファを枯渇させて交換完了を妨げ得る. 証明書を送る代わりに Hash and URL エンコーディングを用いるとこの可能性を最小化できる (第 3.6 節参照). 追加の緩和策は [DOSUDPPROT] で論じられている.
アドミッションコントロールはプロトコルのセキュリティにとって重要である. 例えば IKE ピアを識別するためのトラストアンカは, 公開 Web サーバを識別するために用いるものなど他の信頼形態用のアンカとは異なるべきである. さらに IKE は信頼できるピアの身元, 資格情報, それらの相関に関するセキュリティポリシーを定義する際に大きな自由度を与えるが, そのようなセキュリティポリシーを明示的に定義することがセキュアな実装に不可欠である.