IPsec

ウィキペディアから、無料の百科事典
ナビゲーションにジャンプ 検索にジャンプ

コンピューティングにおいて、インターネットプロトコルセキュリティIPsec )は、データのパケット認証および暗号化して、インターネットプロトコルネットワークを介した2台のコンピュータ間の安全な暗号化通信を提供する安全なネットワークプロトコルスイートです。仮想プライベートネットワーク(VPN) で使用されます。

IPsecには、セッションの開始時にエージェント間の相互認証を確立するためのプロトコルと、セッションに使用する暗号化キーのネゴシエーションが含まれています。IPsecは、ホストのペア(host-to-host)間、セキュリティゲートウェイのペア(network-to-network)間、またはセキュリティゲートウェイとホスト(network-to-host)間のデータフローを保護できます。[2] IPsecは、暗号化セキュリティサービスを使用して、インターネットプロトコル(IP)ネットワーク を介した通信を保護します。ネットワークレベルのピア認証、データ発信元認証データ整合性をサポートします、データの機密性(暗号化)、およびリプレイ保護。

初期のIPv4スイートは、いくつかのセキュリティ対策を講じて開発されました。IPv4拡張の一部として、IPsecはレイヤー3OSIモデルまたはインターネットレイヤーエンドツーエンドセキュリティスキームです。対照的に、広く使用されている他のインターネットセキュリティシステムの中には、トランスポート層の上で動作するトランスポート層セキュリティ(TLS)やアプリケーション層で動作するセキュアシェル(SSH)など、ネットワーク層の上動作するものあります IPsecはアプリケーションを自動的に保護できますインターネット層

歴史

1970年代初頭から、Advanced Research Projects Agencyは、最初はネイティブARPANETパケット暗号化、続いてTCP / IPパケット暗号化のために、一連の実験的なARPANET暗号化デバイスを後援しました。これらのいくつかは認定され、守られました。1986年から1991年まで、NSAは、Secure Data Network Systems(SDNS)プログラムの下でインターネットのセキュリティプロトコルの開発を後援しました。[3]これにより、1988年にネットワーク暗号化デバイスを製造したモトローラを含むさまざまなベンダーが集まりました。この作業は、1988年頃からNISTによって公開され、そのうち、レイヤー3のセキュリティプロトコルが公開されました。(SP3)は、最終的にISO標準のネットワーク層セキュリティプロトコル(NLSP)に変形します。[4]

1992年から1995年まで、さまざまなグループがIP層の暗号化に関する研究を行いました。

  • 1. 1992年、米国海軍研究所(NRL)は、IP暗号化を調査および実装するためのSimple Internet Protocol Plus(SIPP)プロジェクトを開始しました。
  • 2. 1993年、コロンビア大学AT&Tベル研究所で、ジョン・イオアニディスらがSunOSでソフトウェア実験用ソフトウェアIP暗号化プロトコル(swIPe)を研究しました
  • 3. 1993年、Whitehouseインターネットサービスプロジェクトが後援し、Trusted Information Systems(TIS)のWei Xuは、ソフトウェアIPセキュリティプロトコルをさらに調査し、BSDでコード化されたトリプルDESデータ暗号規格[5]のハードウェアサポートを開発しました。 4.1カーネルであり、x86アーキテクチャとSUNOSアーキテクチャの両方をサポートしています。1994年12月までに、TISは、 T1を超える速度で統合された3DESハードウェア暗号化を備えたDARPAが後援するオープンソースのガントレットファイアウォール製品をリリースしました。これは、最初の商用IPSec VPN製品として知られる、米国の東海岸と西海岸の間で初めてIPSecVPN接続を使用したものです。
  • 4. NRLのDARPA資金による研究努力の下で、NRLはIPsecのIETF標準トラック仕様(RFC1825からRFC1827)を開発しました。これは、BSD 4.4カーネルでコーディングされ、x86とSPARCCPUアーキテクチャの両方をサポートしていました。[6] NRLのIPsec実装は、1996年のUSENIX ConferenceProceedingsの論文で説明されています。[7] NRLのオープンソースIPsec実装は、MITによってオンラインで利用可能になり、ほとんどの初期の商用実装の基礎となりました。[6]

インターネット技術特別調査委員会(IETF)は、 IPsecと呼ばれるIPに対する公然と指定されたセキュリティ拡張機能を標準化するために1992年にIPセキュリティワーキンググループを結成しました[8][9] 1995年、ワーキンググループは5社(TIS、CISCO、FTP、チェックポイントなど)のメンバーとのワークショップをいくつか開催しました。IPSecワークショップでは、NRLの標準とCiscoおよびTISのソフトウェアが公開参照として標準化され、RFC-1825からRFC-1827として公開されます。[10]

セキュリティアーキテクチャ

IPsecは、IPv4スイートの一部としてのオープンスタンダードです。IPsecは、次のプロトコルを使用してさまざまな機能を実行します。[11] [12]

認証ヘッダー

トンネルモードとトランスポートモードでのIPsec認証ヘッダー形式の使用

セキュリティ認証ヘッダー(AH)は、1990年代初頭に米国海軍調査研究所で開発され、簡易ネットワーク管理プロトコル(SNMP)バージョン2の認証に関する以前のIETF標準の作業から部分的に派生しています。認証ヘッダー(AH)はIPsecプロトコルスイートのメンバー。AHは、AHアルゴリズムでハッシュ関数と秘密共有キーを使用することにより、コネクションレス型の整合性を保証します。AHは、IPパケットを認証することにより、データの発信元も保証します。オプションで、シーケンス番号は、スライディングウィンドウを使用してIPsecパケットのコンテンツをリプレイ攻撃から保護することができます[20]。テクニックと古いパケットの破棄。

  • IPv4では、AHはオプション挿入攻撃を防ぎます。IPv6では、AHはヘッダー挿入攻撃とオプション挿入攻撃の両方から保護します。
  • IPv4では、AHはIPペイロードとIPデータグラムのすべてのヘッダーフィールドを保護します。ただし、可変フィールド(つまり、転送中に変更される可能性のあるフィールド)と、IPセキュリティオプション(RFC 1108)などのIPオプションは除きます。変更可能な(したがって認証されていない)IPv4ヘッダーフィールドは、DSCP / ToSECN、フラグ、フラグメント オフセットTTL、およびヘッダーチェックサムです。[14]
  • IPv6では、AHは、ほとんどのIPv6ベースヘッダー、AH自体、AHの後の変更不可能な拡張ヘッダー、およびIPペイロードを保護します。IPv6ヘッダーの保護では、可変フィールド( DSCPECN、フローラベル、およびホップ制限)が除外されます。[14]

AHは、 IPプロトコル番号51を使用して、IP上で直接動作します[21]

次のAHパケット図は、AHパケットがどのように構築および解釈されるかを示しています。[13] [14]

認証ヘッダー形式
オフセット オクテット16 0 1 2 3
オクテット16 ビット10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 次のヘッダー ペイロードレン 予約済み
4 32 セキュリティパラメータインデックス(SPI)
8 64 シーケンス番号
C 96 整合性チェック値(ICV)
..。
..。 ..。
次のヘッダー(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ずつ増加リプレイ検出が有効になっている場合、シーケンス番号を最大値を超えてインクリメントする前に、新しいセキュリティアソシエーションを再ネゴシエートする必要があるため、シーケンス番号が再利用されることはありません。[14]
整合性チェック値(32ビットの倍数)
可変長チェック値。フィールドをIPv6の場合は8オクテットの境界に、 IPv4の場合は4オクテットの境界に揃えるためのパディングが含まれる場合があります

セキュリティペイロードのカプセル化

トンネルモードとトランスポートモードでのIPsecカプセル化セキュリティペイロード(ESP)の使用

IPカプセル化セキュリティペイロード(ESP)[22]は、 DARPAが後援する研究プロジェクトの一環として1992年に海軍研究所で開発され、 1993年12月にセキュリティとして起草されたIETF SIPP [23]ワーキンググループによって公開されました。 SIPPの拡張。このESPは、ISOネットワーク層セキュリティプロトコル(NLSP)から派生したものではなく、元々は米国国防総省のSP3Dプロトコルから派生したものです。SP3Dプロトコル仕様はNISTによって公開されました1980年代後半に、しかし米国国防総省のセキュアデータネットワークシステムプロジェクトによって設計されました。Encapsulating Security Payload(ESP)は、IPsecプロトコルスイートのメンバーです。ソース認証によるオリジン信頼性ハッシュ関数によるデータの整合性、IPパケットの暗号化保護による機密性を提供します。ESPは暗号化のみおよび認証のみの構成もサポートしますが、認証なしで暗号化を使用することは安全ではないため、強くお勧めしません。[24] [25] [26]

認証ヘッダー(AH)とは異なり、トランスポートモードのESPは、 IPパケット全体の整合性と認証を提供しませんただし、元のIPパケット全体が新しいパケットヘッダーが追加されてカプセル化されるトンネルモードでは、ESP保護は内部IPパケット全体(内部ヘッダーを含む)に提供され、外部ヘッダー(外部IPv4オプションまたはIPv6拡張を含む)はヘッダー)は保護されません。ESPは、IPプロトコル番号50を使用して、IP上で直接動作します。[21]

次のESPパケット図は、ESPパケットがどのように構築および解釈されるかを示しています。[2] [27]

セキュリティペイロード形式 のカプセル化
オフセット オクテット16 0 1 2 3
オクテット16 ビット10 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 セキュリティパラメータインデックス(SPI)
4 32 シーケンス番号
8 64 ペイロードデータ
..。 ..。
..。 ..。    
..。 ..。   パディング(0-255オクテット)  
..。 ..。   パッドの長さ 次のヘッダー
..。 ..。 整合性チェック値(ICV)
..。
..。 ..。
セキュリティパラメータインデックス(32ビット)
受信側のセキュリティアソシエーションを識別するために(宛先IPアドレスとともに)使用される任意の値
シーケンス番号(32ビット)
リプレイ攻撃から保護するために、単調に増加するシーケンス番号(送信されるパケットごとに1ずつ増加)セキュリティアソシエーションごとに個別のカウンターがあります。
ペイロードデータ(可変)
内容を保護するために使用されるデータを含む、元のIPパケットの保護された内容(たとえば、暗号化アルゴリズムの初期化ベクトル)。保護されたコンテンツのタイプは、[次のヘッダー]フィールドで示されます。
パディング(0-255オクテット)
暗号化のためのパディング、ペイロードデータを暗号化の暗号ブロックサイズに適合するサイズに拡張し、次のフィールドを整列させます。
パッド長(8ビット)
パディングのサイズ(オクテット単位)。
次のヘッダー(8ビット)
次のヘッダーのタイプ。値は、IPプロトコル番号のリストから取得されます。
整合性チェック値(32ビットの倍数)
可変長チェック値。フィールドをIPv6の場合は8オクテットの境界に、 IPv4の場合は4オクテットの境界に揃えるためのパディングが含まれる場合があります

セキュリティアソシエーション

IPsecプロトコルは、通信当事者がアルゴリズムやキーなどの共有セキュリティ属性を確立するセキュリティアソシエーションを使用します。そのため、AHまたはESPのどちらを使用するかが決定されると、IPsecはさまざまなオプションを提供します。データを交換する前に、2つのホストは、IPパケットの暗号化に使用される対称暗号化アルゴリズム( AESChaCha20など)と、データの整合性を確保するために使用されるハッシュ関数(BLAKE2SHA256など)について合意します。これらのパラメータは、特定のセッションで合意されます。このセッションでは、存続期間とセッションキーについて合意する必要があります[28]

認証のアルゴリズムも、データ転送が行われる前に合意され、IPsecはさまざまな方法をサポートします。認証は事前共有キーを介して可能です。対称キーはすでに両方のホストを所有しており、ホストは共有キーのハッシュを相互に送信して、同じキーを所有していることを証明します。IPsecは、公開鍵暗号化もサポートしています。各ホストには公開鍵と秘密鍵があり、公開鍵を交換し、各ホストは他のホストの公開鍵で暗号化されたナンスを他のホストに送信します。または、両方のホストが認証局からの公開鍵証明書を保持している場合これIPsec認証に使用できます。[29]

IPsecのセキュリティアソシエーションは、インターネットセキュリティアソシエーションおよびキー管理プロトコル(ISAKMP)を使用して確立されます。ISAKMPは、事前共有シークレット、インターネットキー交換(IKEおよびIKEv2)、キーのケルバライズドインターネットネゴシエーション(KINK)、およびIPSECKEYDNSレコードの使用を使用した手動構成によって実装されます。[19] [30] [31] RFC 5386は、拡張IKEプロトコルを使用するIPsecの非認証モードとしてBetter-Than-Nothing Security(BTNS)を定義しています。C. Meadows、C。Cremersなどは、形式手法を使用して、IKEv1およびIKEv2に存在するさまざまな異常を識別しました。[32]

送信パケットに提供する保護を決定するために、IPsecは、セキュリティアソシエーションデータベース(SADB)へのインデックスであるセキュリティパラメータインデックス(SPI)と、パケットヘッダー内の宛先アドレスを使用します。そのパケットのセキュリティアソシエーション。同様の手順が着信パケットに対して実行され、IPsecはセキュリティアソシエーションデータベースから復号化キーと検証キーを収集します。

IPマルチキャストの場合、セキュリティアソシエーションがグループに提供され、グループのすべての許可された受信者間で複製されます。異なるSPIを使用して、グループに複数のセキュリティアソシエーションが存在する場合があります。これにより、グループ内で複数のレベルとセキュリティセットが可能になります。実際、受信者はキーを知っている誰かがデータを送信したことしか知ることができないため、各送信者は複数のセキュリティアソシエーションを持つことができ、認証が可能になります。関連する標準では、グループ全体で関連付けがどのように選択および複製されるかについては説明されていないことに注意してください。責任者が選択を行ったと想定されます。

動作モード

IPsecプロトコルAHおよびESPは、ホスト間トランスポートモード、およびネットワークトンネリングモードで実装できます。

IPsecモード

輸送モード

トランスポートモードでは、通常、IPパケットのペイロードのみが暗号化または認証されます。IPヘッダーは変更も暗号化もされていないため、ルーティングはそのままです。ただし、認証ヘッダーが使用されている場合、IPアドレスはネットワークアドレス変換によって変更できません。これは常にハッシュ値を無効にするためです。トランスポート層とアプリケーション層は常にハッシュで保護されているためポート番号 を変換するなどの方法で変更することはできません。

NATトラバーサル用にIPsecメッセージをカプセル化する手段は、 NAT-Tメカニズム を説明するRFCドキュメントによって定義されています。

トンネルモード

トンネルモードでは、IPパケット全体が暗号化および認証されます。次に、新しいIPヘッダーを持つ新しいIPパケットにカプセル化されます。トンネルモードは、ネットワーク間通信(ルーター間など)、ホスト間通信(リモートユーザーアクセスなど)、ホスト間通信(プライベートチャットなど)用の仮想プライベートネットワークを作成するために使用されます。[33]

トンネルモードはNATトラバーサルをサポートします。

アルゴリズム

対称暗号化アルゴリズム

IPsecで使用するために定義された暗号化アルゴリズムには、次のものがあります。

詳細については、RFC8221を参照してください。

鍵交換アルゴリズム

認証アルゴリズム

実装

IPsecは、オペレーティングシステムのIPスタックに実装できます。これには、ソースコードの変更が必要です。この実装方法は、ホストとセキュリティゲートウェイに対して行われます。HPやIBMなどの企業からさまざまなIPsec対応IPスタックを入手できます。[34]代替手段は、オペレーティングシステムのソースコードを変更する必要がない、いわゆるスタック内バンプ(BITS)実装です。ここでは、IPsecがIPスタックとネットワークドライバの間にインストールされています。このようにして、オペレーティングシステムをIPsecで後付けすることができます。この実装方法は、ホストとゲートウェイの両方にも使用されます。ただし、IPsecを再適合させる場合、IPパケットのカプセル化により、自動で問題が発生する可能性があります。パスMTUディスカバリー。ここで、2つのIPホスト間のネットワークパス上の最大伝送ユニット(MTU)サイズが確立されます。ホストまたはゲートウェイに、軍隊で一般的であり、商用システムでも見られる別個の暗号化プロセッサがある場合、IPsecのいわゆるバンプインザワイヤー(BITW)実装が可能です。[35]

IPsecがカーネルに実装されている場合、キー管理とISAKMP / IKEネゴシエーションはユーザースペースから実行されます。NRLで開発され、オープンに指定された「PF_KEYキー管理APIバージョン2」は、アプリケーションスペースキー管理アプリケーションがカーネルスペースIPsec実装内に格納されているIPsecセキュリティアソシエーションを更新できるようにするためによく使用されます。[36]既存のIPsec実装には、通常、ESP、AH、およびIKEバージョン2が含まれます。UNIXライクなオペレーティングシステム(SolarisやLinuxなど)での既存のIPsec実装には、通常、PF_KEYバージョン2が含まれます。

組み込みIPsecを使用すると、制約のあるリソースシステム上で実行されているアプリケーション間の安全な通信をわずかなオーバーヘッドで保証できます。[37]

標準ステータス

IPsecはIPv6と組み合わせて開発され、 RFC 6434が推奨する前に、 IPv6のすべての標準準拠の実装でサポートされる必要がありました。[38] IPv4の実装ではIPsecもオプションです。IPsecは、IPv4トラフィックを保護するために最も一般的に使用されます。[要出典]

IPsecプロトコルは、1995年に公開されたRFC1825からRFC1829で最初に定義されました。1998年に、これらのドキュメントは、概念的には同一でしたが、いくつかの互換性のないエンジニアリングの詳細でRFC2401とRFC2412に取って代わられました。さらに、セキュリティアソシエーションを作成および管理するために、相互認証およびキー交換プロトコルであるインターネットキー交換(IKE)が定義されました。2005年12月、RFC4301およびRFC4309で新しい標準が定義されました。これらは、インターネットキー交換標準IKEv2の2番目のバージョンを備えた以前のエディションの大部分のスーパーセットです。これらの第3世代のドキュメントでは、IPsecの略語が大文字の「IP」と小文字の「sec」に標準化されています。「ESP」は通常、仕様の最新バージョンであるRFC4303を指します。

2008年半ば以降、IPsec Maintenance and Extensions(ipsecme)ワーキンググループがIETFでアクティブになっています。[39] [40]

NSA干渉の疑い

2013年、 スノーデンのリークの一環として、米国国家安全保障局がブルランプログラムの一環として、「ターゲットが使用する商用暗号化システム、ITシステム、ネットワーク、エンドポイント通信デバイスに脆弱性を挿入する」ことに積極的に取り組んでいることが明らかになりました。 [41] IPsecが標的とされた暗号化システムであったという主張があります。[42]

OpenBSD IPsecスタックは後で登場し、広くコピーされました。OpenBSDのリード開発者であるTheodeRaadtが2010年12月11日にGregoryPerryから受け取った手紙の中で、FBIで働いているJasonWrightと他の人がOpenBSD暗号に「多くのバックドアサイドチャネルキー漏洩メカニズム」を挿入したと言われています。コード。2010年から転送された電子メールでは、テオ・デ・ラートは、電子メールの転送からの暗黙の承認を除いて、最初はクレームの有効性に関する公式の見解を表明していませんでした。[43]申し立てに対するJasonWrightの回答:「都市伝説はすべて、本名、日付、時刻を含めることでより現実的になります。GregoryPerryのメールはこのカテゴリに分類されます。…OpenBSDオペレーティングにバックドアを追加しなかったことを明確に述べます。システムまたはOpenBSD暗号フレームワーク(OCF)。」[44]数日後、de Raadtは、「NETSECは、おそらくバックドアを作成するように契約されていたと思います。…それらが作成された場合、それらが私たちのツリーに組み込まれたとは思いません」とコメントしました。[45]これはスノーデンがリークする前に公開されました。

Logjam攻撃の作成者によって提唱された別の説明は、NSAが鍵交換で使用されるDiffie-Hellmanアルゴリズムを弱体化させることによってIPsecVPNを侵害したことを示唆しています。彼らの論文[46]で、彼らは、RFC 2409で定義された2番目のOakleyグループなど、特定の素数とジェネレーターの乗法サブグループを事前計算するためにNSAが特別に構築したコンピューティングクラスターを主張しています。2015年5月の時点で、アドレス可能なIPsec VPNの90%がサポートされていますIKEの一部としての2番目のOakleyグループ。組織がこのグループを事前に計算する場合、ソフトウェアのバックドアを挿入することなく、交換されるキーを取得し、トラフィックを復号化できます。

提唱された2番目の代替説明は、Equation GroupがいくつかのメーカーのVPN機器に対してゼロデイエクスプロイトを使用し、 KasperskyLabによってEquationGroup [47]に関連付けられていると検証され、それらのメーカーによって実際のエクスプロイトであると検証されたというものでした。そのうちのいくつかは、エクスプロイトの時点でゼロデイエクスプロイトでした。[48] [49] [50] Cisco PIXおよびASAファイアウォールには、NSAによる盗聴に使用される脆弱性がありました[出典]

さらに、「アグレッシブモード」設定を使用するIPsec VPNは、PSKのハッシュを平文で送信します。これは、オフライン辞書攻撃を使用するNSAの標的となる可能性があり、明らかに標的にされています。[46] [51] [52]

IETFドキュメント

標準トラック

  • RFC  1829:ESPDES-CBC変換
  • RFC  2403:ESPおよびAH内でのHMAC-MD5-96の使用
  • RFC  2404:ESPおよびAH内でのHMAC-SHA-1-96の使用
  • RFC  2405:明示的なIVを使用したESPDES-CBC暗号アルゴリズム
  • RFC  2410:NULL暗号化アルゴリズムとIPsecでのその使用
  • RFC  2451:ESPCBCモード暗号アルゴリズム
  • RFC  2857:ESPおよびAH内でのHMAC-RIPEMD-160-96の使用
  • RFC  3526:インターネットキー交換(IKE)用の冪剰余(MODP)Diffie-Hellmanグループ
  • RFC  3602:AES-CBC暗号化アルゴリズムとIPsecでのその使用
  • RFC  3686:IPsecカプセル化セキュリティペイロード(ESP)でのAdvanced Encryption Standard(AES)カウンターモードの使用
  • RFC  3947:IKEでのNATトラバーサルの交渉
  • RFC  3948:IPsecESPパケットの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:何もないセキュリティ(BTNS)の問題と適用性に関する声明
  • RFC  5856:IPsecセキュリティアソシエーションを介した堅牢なヘッダー圧縮の統合
  • RFC  5930:Internet Key Exchangeバージョン02(IKEv2)プロトコルでのAdvanced Encryption Standard Counter Mode(AES-CTR)の使用
  • RFC  6027:IPsecクラスターの問題の説明
  • RFC  6071:IPsecおよびIKEドキュメントのロードマップ
  • RFC  6379:IPsec用のスイートB暗号化スイート
  • RFC  6380:インターネットプロトコルセキュリティ(IPsec)のスイート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)(RFC4303およびRFC4305で廃止)
  • 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で廃止)

も参照してください

参考文献

  1. ^ W. Richard Stevens、 TCP / IP Illustrated、Volume 1:The Protocols、Addison Wesley、1994、ISBN0-201-63346-9。
  2. ^ a b c Kent、S。; Atkinson、R。(1998年11月)。IPカプセル化セキュリティペイロード(ESP)IETF土井10.17487 / RFC2406RFC2406_
  3. ^ 「IPSecプロトコルの実装-IEEE会議の出版物」。土井10.1109 /ACCT.2012.64S2CID16526652_  {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  4. ^ ギルモア、ジョン。「ネットワーク暗号化–歴史と特許」2014-09-03にオリジナルからアーカイブされました2014年2月18日取得
  5. ^ 「VPN作成の歴史| VPNの目的」LeVPN2018年8月17日。
  6. ^ a b "IPv6 + IPSEC + ISAKMP配布ページ"web.mit.edu
  7. ^ 「USENIX1996年次技術会議」www.usenix.org
  8. ^ 「IPセキュリティプロトコル(ipsec)-」datatracker.ietf.org
  9. ^ ソ、カレン; ケント、スティーブン(2005年12月)。「RFC4301:インターネットプロトコルのセキュリティアーキテクチャ」IETFのネットワークワーキンググループ:4 。スペル「IPsec」が推奨され、このおよび関連するすべてのIPsec標準全体で使用されます。IPsec [...]の他のすべての大文字化は非推奨になりました。 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  10. ^ 「NRLITDの成果-IPSecとIPv6」(PDF)米国海軍研究所
  11. ^ Thayer、R。; Doraswamy、N。; グレン、R。(1998年11月)。IPセキュリティドキュメントロードマップIETF土井10.17487 / RFC2411RFC2411_
  12. ^ Hoffman、P。(2005年12月)。IPsec用の暗号化スイートIETF土井10.17487 / RFC4308RFC4308_
  13. ^ a b Kent、S。; Atkinson、R。(1998年11月)。IP認証ヘッダーIETF土井10.17487 / RFC2402RFC2402_
  14. ^ a b c d e Kent、S。(2005年12月)。IP認証ヘッダーIETF土井10.17487 / RFC4302RFC4302_
  15. ^ インターネットキーエクスチェンジIKE)、RFC 2409、§1要約
  16. ^ ハーキンス、D。; キャレル、D。(1998年11月)。インターネットキーエクスチェンジ(IKE)IETF土井10.17487 / RFC2409RFC2409_
  17. ^ Kaufman、C。(ed。)IKEバージョン2IETF土井10.17487 / RFC4306RFC4306_
  18. ^ 坂根聡; 鎌田健一; トーマス、M。; Vilhuber、J。(1998年11月)。キーのKerberizedインターネットネゴシエーション(KINK)IETF土井10.17487 / RFC4430RFC4430_
  19. ^ a b Richardson、M。(2005年2月)。DNSにIPsecキー情報を保存する方法IETF土井10.17487 / RFC4025RFC4025_
  20. ^ ピーターウィリス(2001)。キャリア規模のIPネットワーク:インターネットネットワークの設計と運用IET。p。270. ISBN 9780852969823
  21. ^ a b "プロトコル番号"IANAIANA2010-05-27。2010年5月29日にオリジナルからアーカイブされました
  22. ^ 「SIPPカプセル化セキュリティペイロード」IETFSIPPワーキンググループ。1993年。2016年9月9日のオリジナルからアーカイブ2013年8月7日取得
  23. ^ Deering、Steve E.(1993)。「ドラフトSIPP仕様」IETF:21。 {{cite journal}}引用ジャーナルには|journal=ヘルプ)が必要です
  24. ^ Bellovin、Steven M.(1996)。「IPセキュリティプロトコルの問題領域」PostScript第6回UsenixUnixセキュリティシンポジウムの議事録カリフォルニア州サンノゼ。pp。1–16 2007年7月9日取得
  25. ^ Paterson、Kenneth G。; ヤウ、アーノルドKL(2006-04-24)。「理論と実践における暗号化:IPsecでの暗号化の場合」(PDF)Eurocrypt 2006、コンピュータサイエンスのレクチャーノートVol。4004ベルリン。pp。12–29 2007年8月13日取得
  26. ^ デガブリエレ、ジャンポール; パターソン、ケネスG.(2007-08-09)。「暗号化のみの構成でのIPsec標準への攻撃」(PDF)セキュリティとプライバシーに関するIEEEシンポジウム、IEEE ComputerSocietyカリフォルニア州オークランド。pp。335–349 2007年8月13日取得
  27. ^ Kent、S。(2005年12月)。IPカプセル化セキュリティペイロード(ESP)IETF土井10.17487 / RFC4303RFC4303_
  28. ^ ピーターウィリス(2001)。キャリア規模のIPネットワーク:インターネットネットワークの設計と運用IET。p。271. ISBN 9780852969823
  29. ^ ピーターウィリス(2001)。キャリア規模のIPネットワーク:インターネットネットワークの設計と運用IET。pp。272–3。ISBN 9780852969823
  30. ^ RFC 2406、§1、2ページ
  31. ^ Thomas、M。(2001年6月)。キーのKerberizedインターネットネゴシエーションの要件土井10.17487 / RFC3129RFC3129_
  32. ^ C. Cremers(2011)。IPsecでの鍵交換の再検討:IKEv1およびIKEv2の正式な分析、ESORICS2011コンピュータサイエンスの講義ノート。スプリンガー。pp。315–334。土井10.1007 / 978-3-642-23822-2_18hdl20.500.11850 / 69608ISBN 9783642238222
  33. ^ William、S。、およびStallings、W。(2006)。暗号化とネットワークセキュリティ、4 / E。ピアソンエデュケーションインディア。p。492-493
  34. ^ ピーターウィリス(2001)。キャリア規模のIPネットワーク:インターネットネットワークの設計と運用IET。p。266. ISBN 9780852969823
  35. ^ ピーターウィリス(2001)。キャリア規模のIPネットワーク:インターネットネットワークの設計と運用IET。p。267. ISBN 9780852969823
  36. ^ RFC 2367、 PF_KEYv2 Key Management API、Dan McDonald、Bao Phan、およびCraig Metz(1998年7月)
  37. ^ ハマド、モハマド; Prevelakis、Vassilis(2015)。マイクロカーネルOSに組み込まれたIPsecの実装とパフォーマンス評価コンピュータネットワークと情報セキュリティに関する2015年世界シンポジウム(WSCNIS)IEEE。土井10.1109 /wscnis.2015.7368294ISBN 9781479999064S2CID16935000 _
  38. ^ RFC 6434、「IPv6ノード要件」、E。Jankiewicz、J。Loughney、T。Narten(2011年12月)
  39. ^ 「ipsecme憲章」2015年10月26日取得
  40. ^ 「ipsecmeステータス」2015年10月26日取得
  41. ^ 「秘密文書は暗号化に対するNSAキャンペーンを明らかにする」ニューヨークタイムズ
  42. ^ ジョン・ギルモア。「Re:[暗号化]オープニングディスカッション:「BULLRUN」に関する憶測"
  43. ^ テオ・デ・ラート。「OpenBSDIPSECに関する申し立て」
  44. ^ ジェイソンライト。「OpenBSDIPSECに関する申し立て」
  45. ^ テオ・デ・ラート。「OpenBSDIPSECバックドアの主張に関する最新情報」
  46. ^ a b エイドリアン、デビッド; Bhargavan、Karthikeyan; Durumeric、Zakir; ゴードリー、ピエリック; グリーン、マシュー; ハルダーマン、J。アレックス; ヘニンガー、ナディア; Springall、Drew; トメ、エマニュエル; バレンタ、ルーク; ヴァンダースルート、ベンジャミン; ヴストロ、エリック; Zanella-Béguelin、サンティアゴ; Zimmermann、Paul(2015)。「不完全なForwardSecrecy」コンピュータと通信のセキュリティに関する第22回ACMSIGSAC会議の議事録pp。5–17。土井10.1145 /2810103.2813707ISBN 9781450338325S2CID347988 _
  47. ^ Goodin、Dan(2016年8月16日)。「確認済み:ハッキングツールのリークは、「全能の」NSAに拘束されたグループから発生しました」ArsTechnica 2016年8月19日取得
  48. ^ トムソン、イアン(2016年8月17日)。「シスコは、ShadowBrokersの「NSA」の脆弱性のうち2つが本物であることを確認しています」レジスター2016年9月16日取得
  49. ^ Pauli、Darren(2016年8月24日)。「EquationGroupのエクスプロイトは、新しいCisco ASA、JuniperNetscreenに影響を与えます」レジスター2016年9月16日取得
  50. ^ Chirgwin、Richard(2016年8月18日)。「フォーティネットは、シャドウブローカーの脆弱性を確認する際にシスコをフォローしています」レジスター2016年9月16日取得
  51. ^ 「キー交換-IKEv1アグレッシブモードの問題は何ですか(IKEv1メインモードまたはIKEv2と比較して)?」暗号化スタック交換
  52. ^ 「まだIPsecの使用をやめないでください」帽子はありません2014年12月29日。

外部リンク