Loading article…
| インターネット プロトコル セキュリティ | |
| 開始年 | 1996 |
|---|---|
| 組織 | インターネットエンジニアリングタスクフォース |
| 基本基準 | 各種、IETFドキュメントの章を参照 |
コンピューティングにおいて、インターネット プロトコル セキュリティ( IPsec ) は、データのパケットを認証および暗号化して、インターネット プロトコル ネットワーク上の 2 台のコンピュータ間で安全な暗号化通信を提供する、安全なネットワーク プロトコル スイートです。これは、仮想プライベートネットワーク( VPN ) で使用されます。
IPsec には、セッションの開始時にエージェント間の相互認証を確立し、セッション中に使用する暗号キーをネゴシエートするためのプロトコルが含まれています。IPsec は、ホストのペア (ホスト間)、セキュリティ ゲートウェイのペア (ネットワーク間)、またはセキュリティ ゲートウェイとホスト (ネットワーク間)間のデータ フローを保護できます。 [1] IPsec は、暗号化セキュリティ サービスを使用して、インターネット プロトコル(IP) ネットワーク上の通信を保護します。ネットワーク レベルのピア認証、データ発信元認証、データ整合性、データ機密性 (暗号化)、およびリプレイ攻撃からの保護をサポートします。
歴史
1970年代初頭から、高等研究計画局は、最初はネイティブARPANETパケット暗号化用、その後TCP/IPパケット暗号化用の一連の実験的なARPANET暗号化デバイスを後援し、これらのいくつかは認定され、配備されました。1986年から1991年にかけて、 NSAはSecure Data Network Systems (SDNS)プログラムの下でインターネットのセキュリティプロトコルの開発を後援しました。[2]これにより、 1988年にネットワーク暗号化デバイスを製造したMotorolaを含むさまざまなベンダーが集まりました。この作業は1988年頃からNISTによって公開され、そのうちのレイヤー3セキュリティプロトコル(SP3)は最終的にISO標準のネットワークレイヤーセキュリティプロトコル(NLSP)に変化しました。[3]
1992年、米国海軍研究所(NRL) は DARPA CSTO から資金提供を受け、IPv6 を実装し、SPARC と x86 CPU アーキテクチャの両方をサポートする4.4 BSDで IP 暗号化を研究および実装しました。DARPA は、その実装を MIT を通じて無料で利用できるようにしました。NRL のDARPA資金提供による研究活動の下、NRL はIPsec のIETF標準化トラック仕様 (RFC 1825 から RFC 1827) を開発しました。[4] NRL の IPsec 実装は、1996 年のUSENIX 会議議事録 に掲載された論文で説明されました。[5] NRL のオープンソース IPsec 実装はMITによってオンラインで利用可能になり、初期の商用実装のほとんどの基礎となりました。[4]
インターネット技術特別調査委員会（IETF）は、1992年にIPセキュリティワーキンググループを結成し[6] 、 IPsecと呼ばれるIPの公開セキュリティ拡張を標準化しました。[7] NRLが開発した標準は、IETFによってRFC-1825からRFC-1827として公開されました。[8]
セキュリティアーキテクチャ
初期のIPv4スイートは、セキュリティ対策がほとんど施されていない状態で開発されました。IPv4 拡張機能の一部として、IPsec はレイヤー 3 OSI モデル、つまりインターネット レイヤーのエンドツーエンドのセキュリティ スキームです。対照的に、トランスポートレイヤー上で動作するトランスポート レイヤー セキュリティ(TLS)やアプリケーションレイヤーで動作するセキュア シェル(SSH)など、広く使用されている他のインターネット セキュリティ システムはネットワーク レイヤー上で動作しますが、IPsec はインターネット レイヤーでアプリケーションを自動的に保護できます。
IPsecはIPv4スイートの一部としてオープンスタンダードであり、以下のプロトコルを使用してさまざまな機能を実行します。[9] [10]
- 認証ヘッダー（AH）は、IPデータグラムのコネクションレス型データの整合性とデータ発信元の認証を提供し、IPヘッダー変更攻撃やリプレイ攻撃に対する保護を提供します。[11] [12]
- カプセル化セキュリティペイロード（ESP）は、機密性、コネクションレス型データ整合性、データ発信元認証、リプレイ防止サービス（部分的なシーケンス整合性の一種）、および限定的なトラフィックフロー機密性を提供します。[1]
- インターネット セキュリティ アソシエーションおよびキー管理プロトコル(ISAKMP) は、認証とキー交換のフレームワークを提供します。[13]実際の認証済みキー マテリアルは、事前共有キー、インターネット キー交換(IKE および IKEv2)、Kerberos 化されたインターネット キー ネゴシエーション(KINK)、または IPSECKEY DNS レコードを使用した手動構成によって提供されます。[14] [15] [16] [17]その目的は、AH や ESP の操作に必要なアルゴリズムとパラメータのバンドルを使用してセキュリティ アソシエーション (SA) を生成することです。
認証ヘッダー
セキュリティ認証ヘッダー (AH)は、1990 年代初頭に米国海軍研究所で開発され、SNMP ( Simple Network Management Protocol ) バージョン 2 の認証に関する以前の IETF 標準の作業から部分的に派生しています。認証ヘッダー (AH) は、IPsec プロトコル スイートのメンバーです。AH は、AH アルゴリズムでハッシュ関数と秘密共有キーを使用して、コネクションレスの整合性を保証します。また、AH はIPパケットを認証してデータの送信元を保証します。オプションで、シーケンス番号を使用して、スライディング ウィンドウ手法と古いパケットの破棄を 使用して、 IPsec パケットの内容をリプレイ攻撃から保護できます。[18] [19]
- IPv4では、 AH はオプション挿入攻撃を防ぎます。IPv6では、 AH はヘッダー挿入攻撃とオプション挿入攻撃の両方から保護します。
- IPv4では、AHはIPペイロードとIPデータグラムのすべてのヘッダーフィールドを保護しますが、変更可能なフィールド（つまり、転送中に変更される可能性があるフィールド）は除きます。また、IPセキュリティオプション（RFC 1108）などのIPオプションも保護します。変更可能な（したがって認証されていない）IPv4ヘッダーフィールドは、DSCP / ToS、ECN、フラグ、フラグメント オフセット、TTL、ヘッダーチェックサムです。[12]
- IPv6では、AHはIPv6ベースヘッダー、AH自体、AHに続く変更不可能な拡張ヘッダー、およびIPペイロードの大部分を保護します。IPv6ヘッダーの保護では、変更可能なフィールドであるDSCP、ECN、フローラベル、ホップリミットは除外されます。[12]
AHはIPプロトコル番号51を使用してIP上で直接動作します。[20]
次のAHパケット図は、AHパケットがどのように構築され解釈されるかを示しています。[11] [12]
- 次のヘッダー（8ビット）
- 次のヘッダーのタイプ。保護された上位層プロトコルを示します。値はIP プロトコル番号のリストから取得されます。
- ペイロード長(8 ビット)
- この認証ヘッダーの長さは4 オクテット単位で、2 を引いた値です。たとえば、AH 値 4 は 3×(32 ビット固定長 AH フィールド) + 3×(32 ビット ICV フィールド) − 2 に等しいため、AH 値 4 は 24 オクテットを意味します。サイズは 4 オクテット単位で測定されますが、このヘッダーが IPv6 パケットで伝送される場合、その長さは 8 オクテットの倍数である必要があります。この制限は、IPv4 パケットで伝送される認証ヘッダーには適用されません。
- 予約済み（16ビット）
- 将来の使用のために予約されています (それまではすべてゼロ)。
- セキュリティ パラメータ インデックス(32 ビット)
- 受信側のセキュリティ アソシエーションを識別するために (宛先 IP アドレスとともに) 使用される任意の値。
- シーケンス番号(32 ビット)
- リプレイ攻撃を防ぐための単調に増加するシーケンス番号（パケットが送信されるたびに1ずつ増加する）。リプレイ検出が有効になっている場合、シーケンス番号を最大値を超えて増加させる前に、新しいセキュリティアソシエーションを再交渉する必要があるため、シーケンス番号が再利用されることはありません。[12]
- 整合性チェック値（32 ビットの倍数）
- 可変長のチェック値。 IPv6の場合は 8 オクテット境界に、 IPv4の場合は 4 オクテット境界にフィールドを合わせるためのパディングが含まれる場合があります。
セキュリティペイロードのカプセル化
IP カプセル化セキュリティ ペイロード (ESP) [21] は、1992 年にDARPAが後援する研究プロジェクトの一環として海軍研究所で開発され、 1993 年 12 月にIETF SIPP [22]ワーキング グループによって SIPP のセキュリティ拡張機能として草案が公開されました。この ESP はもともと、ISO ネットワーク層セキュリティ プロトコル (NLSP) からではなく、米国国防総省の SP3D プロトコルから派生したものです。SP3D プロトコル仕様は、1980 年代後半にNISTによって公開されましたが、米国国防総省のセキュア データ ネットワーク システム プロジェクトによって設計されました。カプセル化セキュリティ ペイロード (ESP) は、IPsec プロトコル スイートのメンバーです。ソース認証による発信元の信頼性、ハッシュ関数によるデータ整合性、およびIPパケットの暗号化保護による機密性を提供します。ESP は暗号化のみの構成と認証のみの構成もサポートしていますが、認証なしの暗号化は安全ではないため強く推奨されません。[23] [24] [25]
認証ヘッダー (AH)とは異なり、トランスポート モードの ESP はIP パケット全体の整合性と認証を提供しません。ただし、元の IP パケット全体が新しいパケット ヘッダーを追加してカプセル化されるトンネル モードでは、内部 IP パケット全体 (内部ヘッダーを含む) に対して ESP 保護が提供されますが、外部ヘッダー (外部 IPv4 オプションまたは IPv6 拡張ヘッダーを含む) は保護されません。
ESPはIPプロトコル番号50を使用してIP上で直接動作します。[20]
次のESPパケット図は、ESPパケットがどのように構築され解釈されるかを示しています。[1] [26]
- セキュリティ パラメータ インデックス(32 ビット)
- 受信側のセキュリティ アソシエーションを識別するために (宛先 IP アドレスとともに) 使用される任意の値。
- シーケンス番号(32 ビット)
- リプレイ攻撃から保護するために単調に増加するシーケンス番号(パケットが送信されるたびに 1 ずつ増加) 。セキュリティ アソシエーションごとに個別のカウンターが保持されます。
- ペイロードデータ（変数）
- 元の IP パケットの保護されたコンテンツ。これには、コンテンツを保護するために使用されるデータ (暗号化アルゴリズムの初期化ベクトルなど) が含まれます。保護されたコンテンツの種類は、次のヘッダーフィールドによって示されます。
- パディング（0〜255オクテット）
- 暗号化のためのパディング。ペイロード データを暗号化の暗号 ブロック サイズに合うサイズに拡張し、次のフィールドを揃えます。
- パッド長(8 ビット)
- パディングのサイズ（オクテット単位）。
- 次のヘッダー（8ビット）
- 次のヘッダーのタイプ。値はIP プロトコル番号のリストから取得されます。
- 整合性チェック値（変数）
- 可変長のチェック値。 IPv6の場合は 8 オクテット境界に、 IPv4の場合は 4 オクテット境界にフィールドを合わせるためのパディングが含まれる場合があります。
セキュリティ協会
IPsec プロトコルはセキュリティ アソシエーションを使用し、通信当事者はアルゴリズムやキーなどのセキュリティ属性を共有します。そのため、IPsec は、AH または ESP のどちらを使用するかを決定すると、さまざまなオプションを提供します。データを交換する前に、2 つのホストは、IP パケットの暗号化に使用する対称暗号化アルゴリズム(AESまたはChaCha20など) と、データの整合性を保証するために使用するハッシュ関数 ( BLAKE2またはSHA256など) について合意します。これらのパラメータは特定のセッションに対して合意され、そのセッションの有効期間とセッション キーについて合意する必要があります。[27]
認証アルゴリズムもデータ転送が行われる前に合意され、IPsec はさまざまな方法をサポートしています。認証は事前共有キーを介して可能であり、対称キーは両方のホストで既に所有されており、ホストは共有キーのハッシュを互いに送信して、同じキーを所有していることを証明します。IPsec は公開キー暗号化もサポートしており、各ホストが公開キーと秘密キーを持ち、公開キーを交換し、各ホストが他のホストの公開キーで暗号化されたnonce を相手に送信します。または、両方のホストが証明機関からの公開キー証明書を保持している場合は、これを IPsec 認証に使用できます。[28]
IPsec のセキュリティ アソシエーションは、インターネット セキュリティ アソシエーションおよびキー管理プロトコル(ISAKMP) を使用して確立されます。ISAKMP は、事前共有秘密、インターネット キー交換(IKE および IKEv2)、Kerberos 化されたインターネット キーのネゴシエーション(KINK)、および IPSECKEY DNS レコードの使用による手動構成によって実装されます。[17] [29] [30] RFC 5386 では、拡張 IKE プロトコルを使用した IPsec の非認証モードとして Better-Than-Nothing Security (BTNS) が定義されています。C. Meadows、C. Cremers らは、形式手法を使用して、IKEv1 および IKEv2 に存在するさまざまな異常を特定しました。[31]
送信パケットにどのような保護を施すかを決定するために、IPsec は、セキュリティ アソシエーション データベース (SADB) へのインデックスであるセキュリティ パラメータ インデックス(SPI) と、パケット ヘッダー内の宛先アドレスを使用します。これらを組み合わせることで、そのパケットのセキュリティ アソシエーションが一意に識別されます。受信パケットに対しても同様の手順が実行され、IPsec はセキュリティ アソシエーション データベースから復号化キーと検証キーを収集します。
IP マルチキャストの場合、グループにセキュリティ アソシエーションが提供され、グループのすべての承認された受信者間で複製されます。グループには、異なる SPI を使用して複数のセキュリティ アソシエーションが存在する場合があり、これにより、グループ内で複数のレベルとセキュリティ セットが可能になります。実際、各送信者は複数のセキュリティ アソシエーションを持つことができ、受信者はキーを知っている誰かがデータを送信したことしか知らないため、認証が可能になります。関連する標準では、アソシエーションの選択方法とグループ全体での複製方法については説明されていないことに注意してください。責任ある当事者が選択を行うものと想定されています。
キープアライブ
2 つのエンドポイント間の接続が中断されていないことを確認するために、エンドポイントは定期的にキープアライブメッセージを交換します。これは、接続の中断により失われたトンネルを自動的に再確立するためにも使用できます。
デッド ピア検出 (DPD) は、デッドインターネット キー交換(IKE) ピアを検出する方法です。この方法では、IPsec トラフィック パターンを使用して、ピアの可用性を確認するために必要なメッセージの数を最小限に抑えます。DPD は、ピアがデッドであることがわかった場合に失われたリソースを再利用するために使用され、IKE ピア フェールオーバーを実行するためにも使用されます。
UDP キープアライブは DPD の代替手段です。
動作モード
IPsec プロトコル AH および ESP は、ホスト間トランスポート モードとネットワーク トンネリング モードで実装できます。
輸送モード
トランスポート モードでは、通常、IP パケットのペイロードのみが暗号化または認証されます。IP ヘッダーは変更も暗号化もされないため、ルーティングはそのままです。ただし、認証ヘッダーが使用される場合、ネットワーク アドレス変換によって IP アドレスを変更することはできません。これは、ハッシュ値が常に無効になるためです。トランスポート層とアプリケーション層は常にハッシュによって保護されているため、ポート番号を変換するなど、いかなる方法でも変更することはできません。
NAT トラバーサル{NAT-T}用に IPsec メッセージをカプセル化する手段は、NAT-T メカニズムを説明する RFCドキュメントによって定義されています。
トンネルモード
トンネルモードでは、IPパケット全体が暗号化され、認証されます。その後、新しいIPヘッダーを持つ新しいIPパケットにカプセル化されます。トンネルモードは、ネットワーク間通信（例：ルータからサイトへのリンク）、ホスト間通信（例：リモートユーザーアクセス）、ホスト間通信（例：プライベートチャット）用の仮想プライベートネットワークを作成するために使用されます。[32]
トンネル モードは NAT トラバーサルをサポートします。
アルゴリズム
対称暗号化アルゴリズム
IPsec で使用するために定義されている暗号化アルゴリズムには次のものがあります。
- 整合性保護と信頼性のためのHMAC - SHA1 / SHA2。
- TripleDES -機密性のためのCBC
- 機密性を保つためにAES- CBCとAES-CTR を使用します。
- AES - GCMとChaCha20-Poly1305 が機密性と認証を効率的に組み合わせて提供します。
詳細については、RFC 8221 を参照してください。
鍵交換アルゴリズム
- ディフィー・ヘルマン（RFC 3526）
- ECDH (RFC 4753)
認証アルゴリズム
実装
IPsec は、オペレーティング システムの IP スタックに実装できます。この実装方法は、ホストとセキュリティ ゲートウェイに対して行われます。HP や IBM などの企業から、さまざまな IPsec 対応 IP スタックが提供されています。[33]もう 1 つの方法は、いわゆる Bump-in-the-Stack (BITS) 実装です。この実装では、オペレーティング システムのソース コードを変更する必要はありません。この場合、IPsec は IP スタックとネットワークドライバーの間にインストールされます。この方法では、オペレーティング システムに IPsec を後付けできます。この実装方法は、ホストとゲートウェイの両方にも使用されます。ただし、IPsec を後付けする場合、IP パケットのカプセル化によって、 2 つの IP ホスト間のネットワーク パス上の最大転送単位(MTU) サイズが確立される自動パス MTU 検出に問題が発生する可能性があります。ホストまたはゲートウェイに別の暗号プロセッサがある場合(これは軍事では一般的であり、商用システムにも見られます)、IPsec のいわゆるBump-in-the-Wire (BITW) 実装が可能です。[34]
IPsec がカーネルに実装されている場合、キー管理とISAKMP / IKEネゴシエーションはユーザー空間から実行されます。NRL が開発し、公開仕様を定めた「PF_KEY キー管理 API バージョン 2」は、アプリケーション空間のキー管理アプリケーションがカーネル空間の IPsec 実装内に格納されている IPsec セキュリティ アソシエーションを更新できるようにするためによく使用されます。[35]既存の IPsec 実装には通常、ESP、AH、IKE バージョン 2 が含まれています。SolarisやLinuxなどのUnix 系オペレーティング システム上の既存の IPsec 実装には、通常、 PF_KEY バージョン 2 が含まれています。
組み込みIPsecは、小さなオーバーヘッドで、制約のあるリソースシステム上で実行されるアプリケーション間の安全な通信を確保するために使用できます。[36]
標準ステータス
IPsecはIPv6と連携して開発され、 RFC 6434で勧告に留まるまでは、IPv6の標準に準拠したすべての実装でサポートされることが義務付けられていました。 [37] IPsecはIPv4実装でもオプションです。IPsecはIPv4トラフィックのセキュリティ保護に最もよく使用されます。[引用が必要]
IPsec プロトコルは、もともと 1995 年に公開された RFC 1825 から RFC 1829 で定義されました。1998 年に、これらのドキュメントは、概念的には同じであったものの、互換性のないエンジニアリングの詳細がいくつかある RFC 2401 と RFC 2412 に置き換えられました。さらに、セキュリティ アソシエーションを作成および管理するために、相互認証およびキー交換プロトコルのインターネット キー交換(IKE) が定義されました。2005 年 12 月、新しい標準が RFC 4301 および RFC 4309 で定義されました。これらは、インターネット キー交換標準IKEv2の第 2バージョンを含む、以前のエディションのスーパーセットです。これらの第 3 世代のドキュメントでは、IPsec の略語が大文字の「IP」と小文字の「sec」に標準化されました。「ESP」は通常、仕様の最新バージョンである RFC 4303 を指します。
2008年半ば以降、IETFではIPsecメンテナンスおよび拡張（ipsecme）ワーキンググループが活動している。[38] [39]
NSAの干渉疑惑
2013年、スノーデンの漏洩により 、米国国家安全保障局がブルラン計画の一環として「標的が使用する商用暗号化システム、ITシステム、ネットワーク、エンドポイント通信デバイスに脆弱性を挿入する」ことに積極的に取り組んでいたことが明らかになった。[40] IPsecが標的型暗号化システムだったとの主張がある。[41]
OpenBSD IPsec スタックは後から登場し、これも広くコピーされました。OpenBSDの主任開発者Theo de Raadtが2010 年 12 月 11 日に Gregory Perry から受け取った手紙には、FBI で働く Jason Wright らが OpenBSD の暗号コードに「多数のバックドアとサイド チャネルキー漏洩メカニズム」を挿入したとされています。2010 年から転送された電子メールでは、Theo de Raadt は、電子メールを転送したことによる暗黙の支持を除いて、当初は主張の正当性について公式の立場を表明していませんでした。[42] Jason Wright の申し立てに対する回答: 「すべての都市伝説は、実名、日付、時刻を含めることでより現実味を帯びます。Gregory Perry の電子メールはこのカテゴリに分類されます。… OpenBSD オペレーティング システムやOpenBSD 暗号化フレームワーク(OCF)にバックドアを追加していないことを明確に述べます。」[43]数日後、デ・ラートは「NETSECはおそらく、申し立てられた通りバックドアを作成するために契約されたのだと思います。…もしそれが書かれたとしても、私たちのツリーには入っていないと思います」とコメントしました。 [44]これはスノーデンの漏洩前に公開されました。
Logjam 攻撃の作者らが提唱する別の説明では、NSA が鍵交換で使用されたDiffie-Hellmanアルゴリズムを弱体化させることで IPsec VPN を侵害したと示唆している。彼らの論文[45]では、 NSA が RFC 2409 で定義された第 2 Oakley グループなどの特定の素数とジェネレータの乗法サブグループを事前計算するためのコンピューティング クラスターを特別に構築したと主張している。2015 年 5 月の時点で、アドレス指定可能な IPsec VPN の 90% が IKE の一部として第 2 Oakley グループをサポートしていた。組織がこのグループを事前計算すると、交換される鍵を導出し、ソフトウェア バックドアを挿入することなくトラフィックを復号化できる。
2 番目に提案された説明は、Equation Group が複数のメーカーの VPN 機器に対してゼロデイ エクスプロイトを使用したというもので、そのエクスプロイトはKaspersky LabによってEquation Group と関連があると確認され[46]、メーカーによって実際のエクスプロイトであると確認されており、その一部は暴露時点ではゼロデイ エクスプロイトであった[47] [48] [49] 。Cisco PIXおよび ASAファイアウォールには、NSA による盗聴に使用された脆弱性があった[要出典]。
さらに、「アグレッシブモード」設定を使用する IPsec VPN は PSK のハッシュを暗号化せずに送信します。これは NSA がオフライン辞書攻撃を使用して標的にする可能性があります。[45] [50] [51]
参照
参考文献
- ^ abc Kent, S.; Atkinson, R. (1998 年 11 月). IP カプセル化セキュリティ ペイロード (ESP). IETF . doi : 10.17487/RFC2406 . RFC 2406.
- ^ Dhall, Hitesh; Dhall, Dolly; Batra, Sonia; Rani, Pooja ( 2012). 「IPSec プロトコルの実装」。2012年第 2 回先進コンピューティング & 通信技術に関する国際会議。IEEE。pp . 176–181。doi :10.1109/ ACCT.2012.64。ISBN 978-1-4673-0471-9. S2CID 16526652。
- ^ Gilmore, John. 「ネットワーク暗号化 - 歴史と特許」。2014年9月3日時点のオリジナルよりアーカイブ。2014年2月18日閲覧。
- ^ ab 「IPv6 + IPSEC + ISAKMP 配布ページ」。web.mit.edu。
- ^ 「USENIX 1996 年次技術会議」www.usenix.org。
- ^ 「IP セキュリティ プロトコル (ipsec) -」. datatracker.ietf.org .
- ^ Seo, Karen; Kent, Stephen (2005 年 12 月)。 インターネットプロトコルのセキュリティ アーキテクチャ。IETF のネットワーク ワーキング グループ。p. 4。doi : 10.17487 /RFC4301。RFC 4301。この
IPsec 標準および関連するすべての IPsec 標準では、「IPsec」という綴りが推奨され、使用されています。IPsec の他の大文字表記は [...] 非推奨です。
- ^ 「NRL ITD の成果 - IPSec と IPv6」(PDF)。米国海軍研究所。2015年 9 月 15 日時点のオリジナルよりアーカイブ(PDF) 。
- ^ Thayer, R.; Doraswamy, N.; Glenn, R. (1998 年 11 月). IP セキュリティ ドキュメント ロードマップ. IETF . doi : 10.17487/RFC2411 . RFC 2411.
- ^ Hoffman, P. (2005 年 12 月). IPsec の暗号化スイート. IETF . doi : 10.17487/RFC4308 . RFC 4308.
- ^ ab Kent, S.; Atkinson, R. (1998 年 11 月). IP 認証ヘッダー. IETF . doi : 10.17487/RFC2402 . RFC 2402.
- ^ abcde Kent, S. (2005 年 12 月). IP 認証ヘッダー. IETF . doi : 10.17487/RFC4302 . RFC 4302.
- ^ インターネット鍵交換(IKE)、RFC 2409、§1 概要
- ^ Harkins, D.; Carrel, D. (1998 年 11 月). インターネット鍵交換 (IKE). IETF . doi : 10.17487/RFC2409 . RFC 2409.
- ^ Kaufman, C. (編). IKE バージョン 2. IETF . doi : 10.17487/RFC4306 . RFC 4306.
- ^ Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (1998 年 11 月). Kerberos によるインターネット鍵ネゴシエーション (KINK). IETF . doi : 10.17487/RFC4430 . RFC 4430.
- ^ ab Richardson , M. (2005年2 月). DNS に IPsec キーマテリアルを保存する方法。IETF。doi : 10.17487/RFC4025。RFC 4025 。
- ^ Peter Willis (2001)。キャリアスケール IP ネットワーク: インターネット ネットワークの設計と運用。IET。p. 270。ISBN 9780852969823。
- ^ R. Shirey (2007 年 8 月). インターネット セキュリティ用語集、バージョン 2. ネットワーク ワーキング グループ. doi : 10.17487/RFC4949 . RFC 4949. 情報提供。
- ^ ab "Protocol Numbers". IANA . 2010-05-27. 2010-05-29時点のオリジナルよりアーカイブ。
- ^ 「SIPP Encapsulating Security Payload」。IETF SIPP Working Group。1993年。2016年9月9日時点のオリジナルよりアーカイブ。2013年8月7日閲覧。
- ^ Deering, Steve E. (1993). 「SIPP 仕様草案」. IETF. p. 21.
- ^ Bellovin, Steven M. (1996). 「IP セキュリティ プロトコルの問題点」( PostScript ) .第 6 回 Usenix Unix セキュリティ シンポジウムの議事録. サンノゼ、カリフォルニア州 . pp. 1–16 . 2007 年 7 月 9 日閲覧。
- ^ Paterson, Kenneth G.; Yau, Arnold KL (2006-04-24). 「理論と実践における暗号化: IPsec における暗号化のケース」(PDF)。Eurocrypt 2006、Lecture Notes in Computer Science Vol. 4004。ベルリン。pp. 12–29 。2007-08-13に取得。
- ^ Degabriele, Jean Paul; Paterson, Kenneth G. (2007-08-09). 「暗号化のみの構成での IPsec 標準への攻撃」(PDF) . IEEE Symposium on Security and Privacy、IEEE Computer Society . オークランド、カリフォルニア州。pp. 335–349 . 2007-08-13に取得。
- ^ Kent, S. (2005 年 12 月). IP カプセル化セキュリティ ペイロード (ESP). IETF . doi : 10.17487/RFC4303 . RFC 4303.
- ^ Peter Willis (2001)。キャリアスケール IP ネットワーク: インターネット ネットワークの設計と運用。IET。p. 271。ISBN 9780852969823。
- ^ Peter Willis (2001)。キャリアスケール IP ネットワーク: インターネット ネットワークの設計と運用。IET。pp. 272–3。ISBN 9780852969823。
- ^ RFC 2406、§1、2ページ
- ^ Thomas, M. (2001 年 6月). Kerberos 化されたインターネット鍵ネゴシエーションの要件。doi : 10.17487/ RFC3129。RFC 3129 。
- ^ C. Cremers (2011)。IPsec における鍵交換の再考: IKEv1 と IKEv2 の形式的分析、ESORICS 2011。コンピュータサイエンスの講義ノート。Springer。pp. 315–334。doi :10.1007/978-3-642-23822-2_18。hdl : 20.500.11850/69608。ISBN 9783642238222.S2CID 18222662 。
- ^ William, S., & Stallings, W. (2006). 暗号化とネットワークセキュリティ、4/E. Pearson Education India. p. 492-493
- ^ Peter Willis (2001)。キャリアスケール IP ネットワーク: インターネット ネットワークの設計と運用。IET。p. 266。ISBN 9780852969823。
- ^ Peter Willis (2001)。キャリアスケール IP ネットワーク: インターネット ネットワークの設計と運用。IET。p. 267。ISBN 9780852969823。
- ^ RFC 2367、PF_KEYv2 キー管理 API、Dan McDonald、Bao Phan、Craig Metz (1998 年 7 月)
- ^ Hamad, Mohammad; Prevelakis, Vassilis (2015). 「マイクロカーネル OS への組み込み IPsec の実装とパフォーマンス評価」 2015 World Symposium on Computer Networks and Information Security (WSCNIS). IEEE. pp. 1–7. doi :10.1109/wscnis.2015.7368294. ISBN 9781479999064.S2CID 16935000 。
- ^ RFC 6434、「IPv6 ノード要件」、E. Jankiewicz、J. Loughney、T. Narten (2011 年 12 月)
- ^ 「ipsecme charter」 。 2015年10月26日閲覧。
- ^ 「ipsecme status」。2015年10月26日閲覧。
- ^ 「秘密文書がNSAの暗号化反対運動を明らかにする」ニューヨークタイムズ。
- ^ John Gilmore. 「Re: [暗号化] 冒頭の議論: 「BULLRUN」に関する推測」
- ^ テオ・デ・ラート。 「OpenBSD IPSECに関する疑惑」。
- ^ Jason Wright. 「OpenBSD IPSEC に関する申し立て」
- ^ テオ・デ・ラート。 「OpenBSD IPSEC バックドア疑惑に関する最新情報」。
- ^ ab Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; Vandersloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (2015). 「Imperfect Forward Secrecy」。第 22 回 ACM SIGSAC コンピューターおよび通信セキュリティ会議の議事録。pp . 5–17。doi : 10.1145 /2810103.2813707。ISBN 9781450338325.S2CID 347988 。
- ^ Goodin, Dan (2016年8月16日). 「確認：ハッキングツールの漏洩は「全能の」NSA関連グループによるもの」Ars Technica . 2016年8月19日閲覧。
- ^ Thomson, Iain (2016 年 8 月 17 日)。「シスコ、Shadow Brokers の 2 つの「NSA」脆弱性が本物であると確認」The Register。2016年9 月 16 日閲覧。
- ^ Pauli, Darren (2016 年 8 月 24 日)。「Equation Group のエクスプロイトが新しい Cisco ASA、Juniper Netscreen に影響を及ぼす」The Register。2016年9 月 16 日閲覧。
- ^ Chirgwin, Richard (2016 年 8 月 18 日)。「Fortinet が Cisco に続き Shadow Broker の脆弱性を確認」The Register。2016年9 月 16 日閲覧。
- ^ 「キー交換 - IKEv1 アグレッシブ モードの問題点は何ですか (IKEv1 メイン モードまたは IKEv2 と比較して)?」。Cryptography Stack Exchange。
- ^ 「IPsec の使用をまだやめないでください」。No Hats。2014 年 12 月 29 日。
さらに読む
標準トラック
- RFC 1829: ESP DES-CBC 変換
- RFC 2403: ESP および AH 内での HMAC-MD5-96 の使用
- RFC 2404: ESP および AH 内での HMAC-SHA-1-96 の使用
- RFC 2405: 明示的なIVを使用したESP DES-CBC暗号アルゴリズム
- RFC 2410: NULL 暗号化アルゴリズムと IPsec での使用
- RFC 2451: ESP CBC モード暗号アルゴリズム
- RFC 2857: ESP および AH 内での HMAC-RIPEMD-160-96 の使用
- RFC 3526:インターネット鍵交換 (IKE) 用のModular Exponential (MODP) Diffie-Hellmanグループ
- RFC 3602: AES-CBC暗号アルゴリズムと IPsec での使用
- RFC 3686: IPsec カプセル化セキュリティ ペイロード (ESP) を使用した Advanced Encryption Standard (AES) カウンター モードの使用
- RFC 3947: IKE における NAT トラバーサルのネゴシエーション
- RFC 3948: IPsec ESP パケットの UDP カプセル化
- RFC 4106: IPsec カプセル化セキュリティ ペイロード (ESP) におけるガロア/カウンター モード (GCM) の使用
- RFC 4301: インターネット プロトコルのセキュリティ アーキテクチャ
- RFC 4302: IP 認証ヘッダー
- RFC 4303: IP カプセル化セキュリティ ペイロード
- RFC 4304: インターネット セキュリティ アソシエーションおよびキー管理プロトコル (ISAKMP) の IPsec 解釈ドメイン (DOI) に対する拡張シーケンス番号 (ESN) の補足
- RFC 4307: インターネット鍵交換バージョン 2 ( IKEv2 )で使用する暗号化アルゴリズム
- RFC 4308: IPsec の暗号化スイート
- RFC 4309: IPsec カプセル化セキュリティ ペイロード (ESP) を使用したAdvanced Encryption Standard (AES) CCM モードの使用
- RFC 4543: IPsec ESP および AH におけるガロア メッセージ認証コード(GMAC)の使用
- RFC 4555: IKEv2 モビリティおよびマルチホーミング プロトコル (MOBIKE)
- RFC 4806: IKEv2 へのオンライン証明書ステータス プロトコル (OCSP) 拡張
- RFC 4868: IPsec でのHMAC-SHA-256、HMAC-SHA-384、および HMAC-SHA-512の使用
- RFC 4945: IKEv1/ISAKMP、IKEv2、および PKIX のインターネット IP セキュリティ PKI プロファイル
- RFC 5280: インターネット X.509 公開鍵インフラストラクチャ証明書および証明書失効リスト (CRL) プロファイル
- RFC 5282: インターネット鍵交換バージョン 2 (IKEv2) プロトコルの暗号化ペイロードでの認証暗号化アルゴリズムの使用
- RFC 5386: 何もないよりはましなセキュリティ: IPsec の非認証モード
- RFC 5529: IPsec で使用するためのCamelliaの動作モード
- RFC 5685: インターネット鍵交換プロトコル バージョン 2 (IKEv2) のリダイレクト メカニズム
- RFC 5723: インターネット鍵交換プロトコル バージョン 2 (IKEv2) セッション再開
- RFC 5857: IPsec 上で堅牢なヘッダー圧縮をサポートする IKEv2 拡張
- RFC 5858: IPsec 上での堅牢なヘッダー圧縮をサポートする IPsec 拡張
- RFC 7296: インターネット鍵交換プロトコル バージョン 2 (IKEv2)
- RFC 7321: カプセル化セキュリティ ペイロード (ESP) と認証ヘッダー (AH) の暗号化アルゴリズム実装要件と使用ガイドライン
- RFC 7383: インターネット鍵交換プロトコル バージョン 2 (IKEv2) メッセージの断片化
- RFC 7427: インターネット鍵交換バージョン 2 (IKEv2) における署名認証
- RFC 7634: ChaCha20、Poly1305、およびインターネット鍵交換プロトコル (IKE) と IPsec でのそれらの使用
実験的なRFC
- RFC 4478: インターネット鍵交換 (IKEv2) プロトコルにおける繰り返し認証
情報RFC
- RFC 2367: PF_KEY インターフェース
- RFC 2412: OAKLEY 鍵決定プロトコル
- RFC 3706: トラフィックベースのデッドインターネットキー交換 (IKE) ピア検出方法
- RFC 3715: IPsec-ネットワーク アドレス変換 (NAT) 互換性要件
- RFC 4621: IKEv2 モビリティおよびマルチホーミング (MOBIKE) プロトコルの設計
- RFC 4809: IPsec 証明書管理プロファイルの要件
- RFC 5387: Better-Than-Nothing Security (BTNS) の問題と適用性に関する声明
- RFC 5856: IPsec セキュリティ アソシエーションを介した堅牢なヘッダー圧縮の統合
- RFC 5930: インターネット キー交換バージョン 02 (IKEv2) プロトコルでの Advanced Encryption Standard Counter Mode (AES-CTR) の使用
- RFC 6027: IPsec クラスタ問題ステートメント
- RFC 6071: IPsec および IKE ドキュメント ロードマップ
- RFC 6379: IPsec のスイート B暗号化スイート
- RFC 6380: インターネット プロトコル セキュリティ (IPsec) の Suite B プロファイル
- RFC 6467: インターネット キー交換バージョン 2 (IKEv2) の安全なパスワード フレームワーク
現在のベストプラクティス RFC
- RFC 5406: IPsec バージョン 2 の使用を指定するためのガイドライン
廃止された/歴史的な RFC
- RFC 1825: インターネット プロトコルのセキュリティ アーキテクチャ (RFC 2401 により廃止)
- RFC 1826: IP 認証ヘッダー (RFC 2402 により廃止)
- RFC 1827: IP カプセル化セキュリティ ペイロード (ESP) (RFC 2406 により廃止)
- RFC 1828: キー付きMD5を使用した IP 認証(履歴)
- RFC 2401: インターネット プロトコルのセキュリティ アーキテクチャ (IPsec の概要) (RFC 4301 により廃止)
- RFC 2406: IP カプセル化セキュリティ ペイロード (ESP) (RFC 4303 および RFC 4305 により廃止)
- RFC 2407: ISAKMP のインターネット IP セキュリティ解釈ドメイン (RFC 4306 により廃止)
- RFC 2409: インターネット鍵交換 (RFC 4306 により廃止)
- RFC 4305: セキュリティ ペイロード (ESP) と認証ヘッダー (AH) をカプセル化するための暗号化アルゴリズム実装要件 (RFC 4835 により廃止)
- RFC 4306: インターネット キー交換 (IKEv2) プロトコル (RFC 5996 により廃止)
- RFC 4718: IKEv2 の明確化と実装ガイドライン (RFC 7296 により廃止)
- RFC 4835: セキュリティ ペイロード (ESP) と認証ヘッダー (AH) をカプセル化するための暗号化アルゴリズム実装要件 (RFC 7321 により廃止)
- RFC 5996: インターネット キー交換プロトコル バージョン 2 (IKEv2) (RFC 7296 により廃止)
外部リンク
- Curlieのコンピュータ セキュリティ
- すべてのIETFアクティブセキュリティWG
- IETF ipsecme WG (「IP セキュリティの保守と拡張」ワーキング グループ)
- IETF btns WG (「Better-Than-Nothing Security」ワーキング グループ) (認証されていない IPsec、IPsec API、接続ラッチに関する作業を行うために設立)]
- IPsec による転送中のデータの保護 2008-10-13 にWayback MachineでアーカイブWindowsSecurity.com の記事 Deb Shinder
- Microsoft TechNet の IPsec
- Microsoft ダウンロード センターの Microsoft IPsec 診断ツール
- IPsec の図解ガイド (Steve Friedl 著)
- IP (IPsec) データ通信のセキュリティアーキテクチャ Manfred Lindner による講義 パート IPsec
- IPsec と SSL/TLS を使用した VPN の作成 Linux Journal の記事 (Rami Rosen 著)