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