IPsec (Security Architecture for Internet Protocol又 また はInternet Protocol Security、アイピーセック)は、データストリームの各 かく IPパケットを認証 にんしょう /暗号 あんごう 化 か することにより、ネットワーク層 そう でIP通信 つうしん を保護 ほご するためのプロトコル群 ぐん である[1] 。 暗号 あんごう 技術 ぎじゅつ を用 もち いることで、IP パケット単位 たんい で改竄 かいざん 検知 けんち や秘匿 ひとく 機能 きのう を提供 ていきょう するプロトコル である。これによって、暗号 あんごう 化 か をサポートしていないトランスポート層 そう やアプリケーション を用 もち いても、通信 つうしん 路 みち の途中 とちゅう で、通信 つうしん 内容 ないよう を覗 のぞ き見 み られたり改竄 かいざん されることを防止 ぼうし できる。
IPsecは、IPv6 では必須 ひっす とされた時期 じき [2] があり、専用 せんよう の拡張 かくちょう ヘッダが定義 ていぎ されている。一方 いっぽう 、IPv4 では、利用 りよう 可能 かのう だが必須 ひっす ではなく、IP ヘッダオプションを利用 りよう する。
IPsecの規格 きかく はIETF の ipsec wg にて策定 さくてい し、RFC として公開 こうかい している。IETF ではIPsecにバージョン番号 ばんごう を与 あた えていないが、非公式 ひこうしき に下記 かき のバージョンが与 あた えられて[3] おり、2016年 ねん 現在 げんざい のバージョンはIPsec-v3である:
IPsec-v1:RFC182x 形式 けいしき のもの
IPsec-v2:RFC240x 形式 けいしき のもの
IPsec-v3:RFC430x 形式 けいしき のもの
IPsecは、2つのピア の間 あいだ にSA (Security Association )という単 たん 方向 ほうこう コネクション を確立 かくりつ することで、ピア間 あいだ にセキュアな通信 つうしん を確立 かくりつ する(詳細 しょうさい 後述 こうじゅつ )。なお、SAは、単 たん 方向 ほうこう であるため、双方向 そうほうこう 通信 つうしん を行 おこな う場合 ばあい には、上 のぼ りと下 くだ りの2つのSAを確立 かくりつ する必要 ひつよう がある。
ピアは、ホスト とセキュリティ・ゲートウェイ の二 に 種類 しゅるい に分類 ぶんるい できる。前者 ぜんしゃ は、個人 こじん 端末 たんまつ やサーバのようなIP通信 つうしん の端点 たんてん に相当 そうとう する機器 きき である。後者 こうしゃ は、ルータのようなIP通信 つうしん の中継 ちゅうけい を担 にな う機器 きき である。
IPsecは、原理 げんり 的 てき にはピアがどちらのタイプであるのかを問 と わない。したがって、ホストからホストまでの通信 つうしん 全体 ぜんたい を直接 ちょくせつ 1つのSAで保護 ほご することもできるし、2つの中継 ちゅうけい 地点 ちてん 間 あいだ 毎 ごと に別々 べつべつ のSAを確立 かくりつ して通信 つうしん を保護 ほご するリレー形態 けいたい の運用 うんよう も可能 かのう である。しかし後述 こうじゅつ するように、ピアがどちらのタイプであるかによって推奨 すいしょう される通信 つうしん モードが存在 そんざい する。
IPsecの各 かく ピアは、SPD (security policy database)、SAD (security association database)という2つのデータベースを管理 かんり する。
SPDは、IPアドレス、プロトコル(TCP/UDP/ICMP等 とう )、TCPポートといった情報 じょうほう に応 おう じて、パケットを破棄 はき (discard)するのか、IPsecを使 つか わずに送信 そうしん (bypass IPsec)するのか、IPsecを使 つか って送信 そうしん (apply IPsec)するのかを決 き めるセキュリティポリシー のデータベースである。
一方 いっぽう 、SADは、各 かく ピアとSAを確立 かくりつ する際 さい に用 もち いるパラメータのデータベースである。
ピアSがピアRに向 む けてIPsecで通信 つうしん するには、以下 いか の3ステップを踏 ふ む。
SからRへのSAを確立 かくりつ する。
SAを使 つか ってパケットをSがRに暗号 あんごう 通信 つうしん する。
Rがデータを受信 じゅしん し、復号 ふくごう などの必要 ひつよう 処理 しょり を行 おこな う。
第 だい 一 いち ステップであるSAを確立 かくりつ する段階 だんかい では、鍵 かぎ 共有 きょうゆう プロトコルが実行 じっこう される。このときに共有 きょうゆう された鍵 かぎ を用 もち いて、第 だい 二 に ステップで通信 つうしん を暗号 あんごう 化 か し、第 だい 三 さん ステップで復号 ふくごう する。
以下 いか では、この3つのステップの概略 がいりゃく を述 の べる。
ピアSは、自身 じしん のSPDを参照 さんしょう することで、上位 じょうい レイヤのプロトコルがRに送 おく ることを要求 ようきゅう したパケットを廃棄 はいき するのか、そのまま送 おく るのか、それともIPsecで保護 ほご して送 おく るのかを決定 けってい する。
IPsecで保護 ほご して送 おく ることに決定 けってい した場合 ばあい 、ピアSは、SAの確立 かくりつ に必要 ひつよう なデータがすでにSADに存在 そんざい するかどうかを確認 かくにん する。データが揃 そろ っていれば、それらのデータをSADから読 よ み込 こ む。
一方 いっぽう 、SAの確立 かくりつ に必要 ひつよう なデータがSADにすべて揃 そろ っていない場合 ばあい は、SAに必要 ひつよう な情報 じょうほう を確立 かくりつ するプロトコルであるIKE (Internet Key Exchange)をピアRとともに実行 じっこう する。2016年 ねん 現在 げんざい 、IKEの最新 さいしん 版 ばん はIKEv2である。
IKEは、上述 じょうじゅつ のように、SAに必要 ひつよう な情報 じょうほう を確立 かくりつ するプロトコルであるが、その中 なか でメインとなるのはその名称 めいしょう が示 しめ す通 とお り、ピアRとの鍵 かぎ 共有 きょうゆう である。
なお、SAに必要 ひつよう な情報 じょうほう を確立 かくりつ するプロトコルとして、IKEの代 か わりにKerberized Internet Negotiation of Keys (英語 えいご 版 ばん ) (KINK)やIPSECKEY DNS recordsを使用 しよう することもできる[4] [5] [6] [7] 。
SAが確立 かくりつ された後 のち 、ピアSとRは、以下 いか の2つのうちいずれかのプロトコル用 もち いて、通信 つうしん を行 おこな う(原理 げんり 的 てき には、両方 りょうほう のプロトコルを適用 てきよう することも可能 かのう である):
AHやESPの暗号 あんごう 処理 しょり に必要 ひつよう な共通 きょうつう 鍵 かぎ は、SAの確立 かくりつ の際 さい に生成 せいせい もしくは読 よ み込 こ んだものを用 もち いる。
認証 にんしょう 暗号 あんごう は、平文 へいぶん の暗号 あんごう 化 か とメッセージ認証 にんしょう の両方 りょうほう を実行 じっこう できる共通 きょうつう 鍵 かぎ 暗号 あんごう 方式 ほうしき である。したがって、ESPを用 もち いた場合 ばあい 、パケットの秘匿 ひとく 性 せい と改竄 かいざん 検知 けんち の両方 りょうほう が担保 たんぽ される。一方 いっぽう 、AHを用 もち いた場合 ばあい 、改竄 かいざん 検知 けんち しか担保 たんぽ されない。
通信 つうしん は、以下 いか の2つのいずれかの動作 どうさ モードに従 したが って行 おこな う:
トランスポートモード :パケットデータ部 ぶ のみを暗号 あんごう 処理 しょり を施 ほどこ す。
トンネルモード :ヘッダを含 ふく めたパケット全体 ぜんたい を丸 まる ごと「データ」として暗号 あんごう 処理 しょり を施 ほどこ し新 あら たなIPヘッダ を付加 ふか 。
トランスポートモードは、主 おも に2つのホスト間 あいだ の通信 つうしん で使 つか われ、トンネルモードは、主 おも にセキュリティ・ゲートウェイとセキュリティ・ゲートウェイ、およびセキュリティ・ゲートウェイとホストの間 あいだ の通信 つうしん で使 つか われる。
ピアRは、パケットを受 う け取 と り、SADの記載 きさい に従 したが って、パケットを破棄 はき するか否 ひ かを決 き める。そして、パケットがIPsecのものであれば、パケットを復号 ふくごう し(暗号 あんごう 化 か されている場合 ばあい )、さらにメッセージ認証 にんしょう の検証 けんしょう を行 おこな った上 うえ で、上位 じょうい レイヤーのプロトコルにパケットを渡 わた す。パケットがIPsecではなく通常 つうじょう のIPのものである場合 ばあい 、復号 ふくごう などの処理 しょり を施 ほどこ さず、直接 ちょくせつ 上位 じょうい レイヤーのプロトコルにパケットを渡 わた す。
特 とく に断 ことわ りがない限 かぎ り本節 ほんぶし の記述 きじゅつ はRFC 7321 2.3-2.4節 せつ で要求 ようきゅう レベルがSHOULD以上 いじょう のものに基 もと づいた。
AHのMACとしてAES -GMAC がSHOULD+、AES-XCBC-MAC の出力 しゅつりょく を96ビットに切 き り詰 つ めたもの(AES-XCBC-MAC-96)がSHOULDである。NULL(=MAC無 な し)もMAYである。
ESPの認証 にんしょう 暗号 あんごう としてAES -GCM がSHOULD+である。Encryption-then-Mac (EtM)型 がた の認証 にんしょう 暗号 あんごう としては、暗号 あんごう 部分 ぶぶん はNULL (=暗号 あんごう 化 か しない)とAES-CBCがMUSTであり、MAC部分 ぶぶん はHMAC-SHA1の出力 しゅつりょく を96ビットに切 き り詰 つ めたもの(HMAC-SHA1-96)がMUST、鍵 かぎ 長 ちょう 128ビットのAES-GMACがSHOULD+、AES-XCBC-MAC の出力 しゅつりょく を96ビットに切 き り詰 つ めたもの(AES-XCBC-MAC-96)がSHOULDである。
ただし以上 いじょう の要求 ようきゅう レベルは過去 かこ の経緯 けいい にも基 もと づいており、安全 あんぜん 性 せい や効率 こうりつ の観点 かんてん から見 み た場合 ばあい はAHにはAES-GMAC、ESPにはAES-GCMを推奨 すいしょう している(RFC 7321 4.1節 せつ 、4.3節 せつ )。
AH (Authentication Header) は、認証 にんしょう および改竄 かいざん 防止 ぼうし 機能 きのう を提供 ていきょう する。データそのものは暗号 あんごう 化 か されないので、盗聴 とうちょう 防止 ぼうし には利用 りよう できない。RFC 1826 形式 けいしき の AH には再送 さいそう 防止 ぼうし 機能 きのう (Anti Replay Counter) が無 な いが、RFC 2402 では 32 bit の、RFC 4302 では 64 bit のカウンタが付 つ けられており、過去 かこ に送信 そうしん されたパケットがコピー再送 さいそう されても多重 たじゅう 受信 じゅしん しない機能 きのう がオプションとして利用 りよう できる。
Authentication (AH)ヘッダー フォーマット (RFC2402/RFC4302形式 けいしき )
Offsets
Octet16
0
1
2
3
Octet16
Bit10
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
Next Header
ペイロード 長 なが
予約 よやく 済 ず み
4
32
Security Parameters Index (SPI)
8
64
順序 じゅんじょ 番号 ばんごう
C
96
Integrity Check Value (ICV) …
…
…
ESP (Encapsulated Security Payload) は ペイロード 部 ぶ を暗号 あんごう 化 か する。正確 せいかく には、IP ヘッダ、経路 けいろ ヘッダ、ホップバイホップオプションヘッダを除 のぞ いた部分 ぶぶん が暗号 あんごう 化 か される。RFC 1827 形式 けいしき の ESP には認証 にんしょう 機能 きのう が無 な いが、RFC 2406 / RFC 4303 形式 けいしき の ESP にはオプションとして「認証 にんしょう トレイラー」機能 きのう があり、AH を併用 へいよう せずとも改竄 かいざん 防止 ぼうし 機能 きのう を利用 りよう することが可能 かのう となっている (ただし保証 ほしょう されるのはデータ部分 ぶぶん だけで、IP ヘッダ部分 ぶぶん の改竄 かいざん を検出 けんしゅつ することはできない)。また後者 こうしゃ には AH 同様 どうよう に再送 さいそう 防止 ぼうし 機能 きのう も追加 ついか されている。
RFC 1826 / RFC 1827 形式 けいしき の AH/ESP はそれ以降 いこう の RFC とヘッダ長 ちょう が異 こと なるため互換 ごかん 性 せい がない。RFC 4302 / RFC 4303 形式 けいしき の 64 bit カウンタは ESN (Extended Sequence Number) とも呼 よ ばれるが、実際 じっさい にパケットに付加 ふか されるのは下位 かい 32 bit だけで、見 み た目 め は RFC 2402 形式 けいしき のパケットと区別 くべつ が付 つ かない。ただし認証 にんしょう ベクタ (ICV) の算出 さんしゅつ には全 ぜん 64 bit が使用 しよう されるため、RFC 2402 / RFC 2406 形式 けいしき の IPsec と RFC 4302 / RFC 4303 形式 けいしき の IPsec の間 あいだ にも直接 ちょくせつ の互換 ごかん 性 せい はない。RFC 4302 / RFC 4303 仕様 しよう の IPsec 実装 じっそう で RFC 2402 / RFC 2406 形式 けいしき と通信 つうしん するためには、32 bit の互換 ごかん カウンタ使用 しよう を明示 めいじ 指定 してい する必要 ひつよう がある。
Encapsulating Security Payload (ESP) フォーマット (RFC2406/RFC4303形式 けいしき )
Offsets
Octet16
0
1
2
3
Octet16
Bit10
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
Security Parameters Index (SPI)
4
32
順序 じゅんじょ 番号 ばんごう
8
64
ペイロード
…
…
…
…
…
…
Padding (0-255 octets)
…
…
Pad Length
Next Header
…
…
Integrity Check Value (ICV) …
…
…
IKE (Internet Key Exchange protocol) は SAを構築 こうちく するのに必要 ひつよう な情報 じょうほう の交換 こうかん を安全 あんぜん に行 おこな うプロトコル。IKEv1 (RFC 2409 ) と IKEv2 (RFC 4306 ) が定義 ていぎ されており、2016年 ねん 現在 げんざい の最新 さいしん 版 ばん は後者 こうしゃ である。
また IKEv1/v2 以外 いがい にも Photuris (RFC 2522 ), KINK (RFC 4430 ) などの鍵 かぎ 交換 こうかん プロトコルが提案 ていあん されている。
この
節 ふし の
加筆 かひつ が
望 のぞ まれています。
(2016年 ねん 8月 がつ )
IKEv1は Internet Key Exchange protocol version 1 の意味 いみ であり、UDP ポート番号 ばんごう 500上 じょう で通信 つうしん される鍵 かぎ 交換 こうかん プロトコル である。開発 かいはつ 時 じ には ISAKMP/Oakley と呼 よ ばれた過去 かこ があり、これはISAKMP(Internet Security Association and Key Management Protocol)プロトコルの上 うえ で Oakley 鍵 かぎ 交換 こうかん 手順 てじゅん を実装 じっそう したものという意味 いみ である。すなわち、IKEv1 は ISAKMP と必 かなら ずしも同 おな じものではない。
IKEv1 はフェーズ1、フェーズ2と呼 よ ばれる二 に 段階 だんかい の手順 てじゅん で鍵 かぎ 交換 こうかん を行 おこな う。まずフェーズ1で IKE プロトコル同士 どうし の認証 にんしょう と暗号 あんごう 交換 こうかん を行 おこな い(これをISAKMP SA交換 こうかん とも呼 よ ぶ)、フェーズ2で IPsec の適用 てきよう 条件 じょうけん と鍵 かぎ 情報 じょうほう の交換 こうかん を行 おこな う(IPsec SA 交換 こうかん とも呼 よ ぶ)。
フェーズ1には Main Mode,Aggressive Mode と呼 よ ばれる2つの手順 てじゅん がある。前者 ぜんしゃ は ISAKMP 仕様 しよう における Identity Protection Exchange 手順 てじゅん の呼 よ び名 な であり、後者 こうしゃ は ISAKMP 仕様 しよう における Aggressive Exchange 手順 てじゅん の呼 よ び名 な である。(用語 ようご 定義 ていぎ の錯綜 さくそう と難解 なんかい さも IKE の理解 りかい を難 むずか しくしている理由 りゆう の一 ひと つである)。
フェーズ2の通信 つうしん はフェーズ1において成立 せいりつ した共有 きょうゆう 鍵 かぎ を用 もち いて暗号 あんごう 化 か される。フェーズ2の手順 てじゅん は Quick Mode と呼 よ ばれ、これは ISAKMP にはなく IKEv1 で新 あら たに定義 ていぎ されたものである。IKEv1 の規格 きかく 上 じょう では New Group Mode という手順 てじゅん も定義 ていぎ されているが、実際 じっさい には殆 ほとん ど使 つか われていない。
Oakley 鍵 かぎ 交換 こうかん 手順 てじゅん は公開 こうかい 鍵 かぎ 暗号 あんごう を用 もち いた鍵 かぎ 交換 こうかん 手順 てじゅん のアルゴリズムとパラメータのセットをいくつか定 さだ めたもので、アルゴリズムは大 おお きく分 わ けて Diffie-Hellman鍵 かぎ 共有 きょうゆう (DH-MODP) と楕円 だえん 曲線 きょくせん 暗号 あんごう (EC2N) の2種 しゅ がある。鍵 かぎ 長 ちょう は DH-MODP で768,1024,1536,2048,3072,4096,6144,8192bit、EC2N で155,188,163,283,409,571bit が定義 ていぎ されている。
IKE の通信 つうしん を行 おこな うノード を IKE ピアと呼 よ び、IKE 要求 ようきゅう を発行 はっこう する側 がわ をイニシエータ、受信 じゅしん した側 がわ をレスポンダと呼 よ ぶ。Oakley のパラメータや IPsec SA の詳細 しょうさい はイニシエータ側 がわ が使用 しよう 可能 かのう な組 く み合 あ わせを提示 ていじ し(これをプロポーザルと呼 よ ぶ)、レスポンダ側 がわ が最 もっと も適切 てきせつ と判断 はんだん したものを選択 せんたく して合意 ごうい を取 と るという手順 てじゅん を踏 ふ む。何 なに をもって「適切 てきせつ 」とみなすかは実装 じっそう と設定 せってい に依存 いぞん し、これを「ポリシー」と呼 よ ぶ場合 ばあい もあるが、狭義 きょうぎ の意味 いみ における IPsec Security Policy とは必 かなら ずしも同 おな じニュアンスではないので混同 こんどう しないよう注意 ちゅうい が必要 ひつよう である。用語 ようご の混同 こんどう を避 さ けるため、RFC 4301 においてはこれら「鍵 かぎ 交換 こうかん 時 じ の挙動 きょどう を定 さだ めるパラメータの一覧 いちらん 」を Peer Authorization Database (PAD) と呼 よ んでいる。
Aggressive Mode はフェーズ1におけるプロポーザル手順 てじゅん の一部 いちぶ を削減 さくげん し、パラメータの一部 いちぶ を決 き め打 う ちとすることで Main Mode にくらべパケット交換 こうかん 回数 かいすう を減 へ らし(3往復 おうふく 6パケット → 1.5往復 おうふく 3パケット)通信 つうしん 効率 こうりつ を向上 こうじょう している。ただし Main Mode では最後 さいご に交換 こうかん される ID パケットが暗号 あんごう 化 か されるのに対 たい し、Agressive ModeではID情報 じょうほう が暗号 あんごう 化 か されないまま送信 そうしん されるので、盗聴 とうちょう によるセキュリティホールを招 まね きかねないというリスクもある。フェーズ1にどちらのモードを用 もち いるかはイニシエータに依存 いぞん し、やはりそのネットワークにおけるポリシー (PAD) によって決定 けってい される。
IKEv1 では鍵 かぎ 交換 こうかん と同時 どうじ に相手 あいて ピアの認証 にんしょう を行 おこな う。認証 にんしょう アルゴリズムもフェーズ1において提示 ていじ -合意 ごうい のプロセスを踏 ふ んで実行 じっこう され、認証 にんしょう 方式 ほうしき には事前 じぜん 鍵 かぎ 共有 きょうゆう 方式 ほうしき (PSK:Pre Shared Key)、デジタル署名 しょめい 方式 ほうしき (Digital Signatures)、公開 こうかい 鍵 かぎ 暗号 あんごう 方式 ほうしき (Public Key Encryption) などがある。
フェーズ2で生成 せいせい される IPsec SA の鍵 かぎ 情報 じょうほう は、原則 げんそく としてフェーズ1で生成 せいせい された共有 きょうゆう 鍵 かぎ 情報 じょうほう から生成 せいせい される。しかし複数個 ふくすうこ の IPsec SA をまとめて生成 せいせい するような使用 しよう 法 ほう の場合 ばあい 、全 すべ ての IPsec SA 情報 じょうほう が1つの秘密 ひみつ 情報 じょうほう に依存 いぞん することは好 この ましくない場合 ばあい がある。このような場合 ばあい 、IKEv1 では Perfect Forward Secrecy (PFS) と呼 よ ばれるオプション機能 きのう の利用 りよう が(通信 つうしん ピア双方 そうほう に実装 じっそう されていれば)可能 かのう である。PFS は個々 ここ のフェーズ2交換 こうかん 時 じ に新 あら たな Oakley 鍵 かぎ 交換 こうかん を行 おこな い、個々 ここ に異 こと なった共有 きょうゆう 鍵 かぎ を生成 せいせい して IPsec SA の秘密 ひみつ 鍵 かぎ 生成 せいせい 時 じ に適用 てきよう するものである。PFSは一般 いっぱん に通信 つうしん 秘匿 ひとく 性 せい を向上 こうじょう させるがピアの処理 しょり 負荷 ふか も向上 こうじょう させるため、これを適用 てきよう すべきか否 ひ かもポリシー(あるいはPAD)に応 おう じて決定 けってい すべきとされている。
なお1回 かい のフェーズ1交換 こうかん に付随 ふずい するフェーズ2の回数 かいすう を1回 かい かぎりに制限 せいげん することにより、結果 けっか 的 てき に全 すべ てのフェーズ2生成 せいせい 鍵 かぎ を異 こと なったものにすることで PFS と同等 どうとう の秘匿 ひとく 性 せい を得 え る実装 じっそう もあり、これを Master PFS と呼 よ ぶこともある。この場合 ばあい 、上記 じょうき の「狭義 きょうぎ のPFS」は Session PFS と呼 よ ばれて区別 くべつ される。
このように IKEv1 には数 すう 多 おお くのモードとパラメータとオプションの組 く み合 あ わせがあり、さらに多 おお くの拡張 かくちょう 仕様 しよう が存在 そんざい する。その中 なか には標準 ひょうじゅん 案 あん として提案 ていあん されたもののドラフトを通過 つうか できず、正式 せいしき な RFC として記載 きさい されずに終 お わったものも少 すく なくない。また IKEv1 仕様 しよう には難解 なんかい で紛 まぎ らわしい用語 ようご が錯綜 さくそう しているため、実装 じっそう 系 けい において独自 どくじ の名前 なまえ を与 あた えている場合 ばあい もある(例 たと えば Microsoft Windows では IPsec におけるセレクタをフィルタと呼 よ び、ポリシーをアクションと呼 よ んでいる)。このため「IETF標準 ひょうじゅん 」であるはずの IKEv1 同士 どうし でも異 い 機種 きしゅ 間 あいだ 接続 せつぞく のためにはプロトコルおよび製品 せいひん 実装 じっそう の深遠 しんえん な理解 りかい が必要 ひつよう になってしまい、「IPsec でネットワークを組 く む場合 ばあい は同 おな じメーカーの同 おな じ機器 きき を使用 しよう することが最 もっと も確実 かくじつ 」という慣習 かんしゅう を生 う むことになってしまった。
IETF は混沌 こんとん としてしまった IKEv1 の整理 せいり を諦 あきら め、IKEv2 をもって標準 ひょうじゅん 化 か の仕切 しき り直 なお しを図 はか っている。
IPsecはネットワーク層 そう でセキュリティを実現 じつげん するプロトコルであるため、アプリケーションなどの上位 じょうい 層 そう が暗号 あんごう 化 か をサポートしていない場合 ばあい でも通信 つうしん 全体 ぜんたい としてのセキュリティを担保 たんぽ することが出来 でき る。なおセキュリティをネットワーク層 そう で実現 じつげん しているため、アプリケーション層 そう でセキュリティを実現 じつげん しているTLS のように暗号 あんごう 化 か がどのプロトコルで行 おこな われているかをユーザーが容易 ようい に知 し ることはできない(TLSではwebブラウザに鍵 かぎ マークが表示 ひょうじ されるなど一見 いっけん してそれが分 わ かる表示 ひょうじ がされる場合 ばあい がある)。
PCやスマートフォンなどのコンシューマ端末 たんまつ でもIPsecを利用 りよう することは可能 かのう であるが、現状 げんじょう は専 せん 門 もん の技術 ぎじゅつ 者 しゃ が管理 かんり するGateway間 あいだ でVPN として利用 りよう されることが多 おお い。IPsecをVPNで利用 りよう する場合 ばあい はIPアドレスを二 に 重 じゅう に付加 ふか するトンネルモードが利用 りよう できるが、IP 以外 いがい のパケットも伝達 でんたつ するためL2TP などのプロトコルと併用 へいよう される場合 ばあい もある。
IPsecはAHの認証 にんしょう 機能 きのう 、ESPの暗号 あんごう 機能 きのう を組 く み合 あ わせて使 つか うことができ、AH/ESPそれぞれに様々 さまざま なアルゴリズムを指定 してい することができる。この柔軟 じゅうなん さが IPsec の利点 りてん ではあるが、設定 せってい 可能 かのう な組 く み合 あ わせは膨大 ぼうだい となり、通信 つうしん する二 に 点 てん 間 あいだ で全 すべ ての設定 せってい が一致 いっち していなければ通信 つうしん が成立 せいりつ しない。多 た 台数 だいすう 間 あいだ のIPsec情報 じょうほう を手動 しゅどう で設定 せってい することは非常 ひじょう に手間 てま がかかる上 うえ に、手動 しゅどう 設定 せってい の場合 ばあい は同 おな じ鍵 かぎ 情報 じょうほう を長期間 ちょうきかん 使 つか い続 つづ けることになるため、セキュリティ強度 きょうど の観点 かんてん からも好 この ましくない。IPsecが上述 じょうじゅつ したVPNで利用 りよう されることが多 おお いのはこのためである。
この手間 てま を軽減 けいげん するためネットワークで自動 じどう 鍵 かぎ 交換 こうかん を行 おこな うIKEv 1,IKEv2,KINK ,Photuris などのプロトコルも提案 ていあん されているが、各 かく プロトコルには互換 ごかん 性 せい が無 な い。最 もっと も普及 ふきゅう しているIKEv1でも動作 どうさ モード、認証 にんしょう パラメータ、認証 にんしょう 方式 ほうしき 、鍵 かぎ 交換 こうかん アルゴリズム、暗号 あんごう アルゴリズム及 およ び認証 にんしょう アルゴリズムなど設定 せってい 項目 こうもく の組 く み合 あ わせは多岐 たき に渡 わた り、IPsecを使 つか いこなすには総 そう じて高度 こうど な専門 せんもん 知識 ちしき が要求 ようきゅう される。
1993年 ねん 12月、ソフトウェアIP暗号 あんごう 化 か プロトコルen:swIPe (protocol) はコロンビア大学 ころんびあだいがく とAT&Tベル研究所 けんきゅうじょ でジョン・ヨアニディス他 た によって研究 けんきゅう されていた。
クリントン 政権 せいけん がwhitehouse.govの電子 でんし メールをトラスディド・インフォメーション・システムズ にホスティングした資金 しきん によって(1993年 ねん 6月 がつ 1日 にち から1995年 ねん 1月 がつ 20日 はつか )、ウェイ・シューは1994年 ねん 7月 がつ 、IPセキュリティの研究 けんきゅう に着手 ちゃくしゅ 、IPプロトコルの機能 きのう を拡張 かくちょう し、BSDI プラットフォーム上 じょう にIPSecを開発 かいはつ 、すぐにSunOS 、HP-UX 、その他 た UNIXシステムにも移植 いしょく した。その成功 せいこう にもとづいてウェイはDES とトリプルDES の計算 けいさん 速度 そくど 改善 かいぜん にも取 と り組 く んだ。アセンブリ言語 げんご によるソフトウェア暗号 あんごう 化 か はIntel 80386 アーキテクチャではT1 の通信 つうしん 速度 そくど にさえ対応 たいおう できなかった。ドイツからCryptoカードを輸出 ゆしゅつ 、ウェイはさらに今日 きょう プラグアンドプレイ と呼 よ ばれる、自動 じどう 化 か されたデバイスドライバも開発 かいはつ し、ハードウェアのCryptoと統合 とうごう した。T1を超 こ えるスループットを実現 じつげん した後 のち 、ウェイ・シューはついに実用 じつよう に耐 た える商品 しょうひん を作成 さくせい 、著名 ちょめい なGauntletファイアーウォールの一部 いちぶ としてリリースした。1994年 ねん 12月、米国 べいこく の東海岸 ひがしかいがん 、西海岸 にしかいがん にある遠隔 えんかく 拠点 きょてん を結 むす ぶ通信 つうしん を暗号 あんごう 化 か するために初 はじ めて本番 ほんばん 導入 どうにゅう された。
一方 いっぽう 、IPカプセル化 か セキュリティ・ペイロード (ESP) [8] はDARPA の資金 しきん による研究 けんきゅう プロジェクトの一部 いちぶ としてアメリカ海軍 かいぐん 調査 ちょうさ 研究所 けんきゅうじょ で研究 けんきゅう され、1993年 ねん 12月、IETF のSIPP作業 さぎょう 部会 ぶかい によってSIPPに対 たい するセキュリティ拡張 かくちょう としてドラフトが公開 こうかい された[9] 。このESP はもともとISOのネットワーク層 そう セキュリティプロトコル(NLSP)ではなく、アメリカ国防総省 こくぼうそうしょう のSP3Dプロトコルから派生 はせい したものだった。SP3Dプロトコルの仕様 しよう はNIST により公開 こうかい されたが、アメリカ国防総省 こくぼうそうしょう のセキュアデータ・ネットワークシステム・プロジェクトにより設計 せっけい されたものだった。セキュリティ認証 にんしょう ヘッダ(AH )の一部 いちぶ は、以前 いぜん のSimple Network Management Protocol (SNMP)バージョン2の認証 にんしょう のためのIETF標準 ひょうじゅん 策定 さくてい 作業 さぎょう から派生 はせい したものである。
1995年 ねん 、IETFのIPsec作業 さぎょう 部会 ぶかい はオープンかつ自由 じゆう に利用 りよう できるバージョンのプロトコル作成 さくせい を開始 かいし 、セキュアデータ・ネットワークシステム (SDNS)プロジェクトに関 かん するアメリカ国家 こっか 安全 あんぜん 保障 ほしょう 局 きょく の契約 けいやく の下 した で開発 かいはつ された。SDNSプロジェクトが定義 ていぎ したセキュリティプロトコル・レイヤー3(SP3)はNISTによって公開 こうかい され、ISOのネットワーク層 そう セキュリティ・プロトコル(NLSP)[10] の基礎 きそ にもなった。SP3の鍵 かぎ 管理 かんり は鍵 かぎ 管理 かんり プロトコル(KMP)によって提供 ていきょう され、これらに続 つづ くIPsec委員 いいん 会 かい の作業 さぎょう のベースラインを提供 ていきょう した。
IPsecは公式 こうしき にはインターネット・エンジニアリング・タスクフォース (IETF)のRequest for Comments (RFC)の一連 いちれん の文書 ぶんしょ として標準 ひょうじゅん 化 か され、さまざまなコンポーネントや拡張 かくちょう に対応 たいおう している。その文書 ぶんしょ でプロトコルの名称 めいしょう はIPsec と表記 ひょうき すると定 さだ められている。[11]
標準 ひょうじゅん 化 か 過程 かてい (Standards Track)[ 編集 へんしゅう ]
RFC 1829 : The ESP DES-CBC Transform
RFC 2403 : The Use of HMAC-MD5-96 within ESP and AH
RFC 2404 : The Use of HMAC-SHA-1-96 within ESP and AH
RFC 2405 : The ESP DES-CBC Cipher Algorithm With Explicit IV
RFC 2410 : The NULL Encryption Algorithm and Its Use With IPsec
RFC 2451 : The ESP CBC-Mode Cipher Algorithms
RFC 2857 : The Use of HMAC-RIPEMD-160-96 within ESP and AH
RFC 3526 : More Modular Exponential (MODP) Diffie-Hellman groups for Internet Key Exchange (IKE)
RFC 3602 : The AES-CBC Cipher Algorithm and Its Use with IPsec
RFC 3686 : Using Advanced Encryption Standard (AES) Counter Mode With IPsec Encapsulating Security Payload (ESP)
RFC 3947 : Negotiation of NAT-Traversal in the IKE
RFC 3948 : UDP Encapsulation of IPsec ESP Packets
RFC 4106 : The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP)
RFC 4301 : Security Architecture for the Internet Protocol
RFC 4302 : IP Authentication Header
RFC 4303 : IP Encapsulating Security Payload
RFC 4304 : Extended Sequence Number (ESN) Addendum to IPsec Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP)
RFC 4307 : Cryptographic Algorithms for Use in the Internet Key Exchange Version 2 (IKEv2 )
RFC 4308 : Cryptographic Suites for IPsec
RFC 4309 : Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP)
RFC 4543 : The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH
RFC 4555 : IKEv2 Mobility and Multihoming Protocol (MOBIKE)
RFC 4806 : Online Certificate Status Protocol (OCSP) Extensions to IKEv2
RFC 4868 : Using HMAC-SHA-256, HMAC-SHA-384, and HMAC-SHA-512 with IPsec
RFC 4945 : The Internet IP Security PKI Profile of IKEv1/ISAKMP, IKEv2, and PKIX
RFC 5282 : Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol
RFC 5386 : Better-Than-Nothing Security: An Unauthenticated Mode of IPsec
RFC 5529 : Modes of Operation for Camellia for Use with IPsec
RFC 5685 : Redirect Mechanism for the Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 5723 : Internet Key Exchange Protocol Version 2 (IKEv2) Session Resumption
RFC 5857 : IKEv2 Extensions to Support Robust Header Compression over IPsec
RFC 5858 : IPsec Extensions to Support Robust Header Compression over IPsec
RFC 7296 : Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 7321 : Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH)
RFC 7383 : Internet Key Exchange Protocol Version 2 (IKEv2) Message Fragmentation
RFC 7427 : Signature Authentication in the Internet Key Exchange Version 2 (IKEv2)
RFC 7634 : ChaCha20, Poly1305, and Their Use in the Internet Key Exchange Protocol (IKE) and IPsec
RFC 4478 : Repeated Authentication in Internet Key Exchange (IKEv2) Protocol
RFC 2367 : PF_KEY Interface
RFC 2412 : The OAKLEY Key Determination Protocol
RFC 3706 : A Traffic-Based Method of Detecting Dead Internet Key Exchange (IKE) Peers
RFC 3715 : IPsec-Network Address Translation (NAT) Compatibility Requirements
RFC 4621 : Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol
RFC 4809 : Requirements for an IPsec Certificate Management Profile
RFC 5387 : Problem and Applicability Statement for Better-Than-Nothing Security (BTNS)
RFC 5856 : Integration of Robust Header Compression over IPsec Security Associations
RFC 5930 : Using Advanced Encryption Standard Counter Mode (AES-CTR) with the Internet Key Exchange version 02 (IKEv2) Protocol
RFC 6027 : IPsec Cluster Problem Statement
RFC 6071 : IPsec and IKE Document Roadmap
RFC 6467 : Secure Password Framework for Internet Key Exchange Version 2 (IKEv2)
Best Current Practice RFCs [ 編集 へんしゅう ]
RFC 5406 : Guidelines for Specifying the Use of IPsec Version 2
廃止 はいし (Obsolete)/歴史 れきし 的 てき (Historic)[ 編集 へんしゅう ]
RFC 1825 : Security Architecture for the Internet Protocol (obsoleted by RFC 2401 )
RFC 1826 : IP Authentication Header (obsoleted by RFC 2402 )
RFC 1827 : IP Encapsulating Security Payload (ESP) (obsoleted by RFC 2406 )
RFC 1828 : IP Authentication using Keyed MD5 (historic)
RFC 2401 : Security Architecture for the Internet Protocol (IPsec overview) (obsoleted by RFC 4301 )
RFC 2406 : IP Encapsulating Security Payload (ESP) (obsoleted by RFC 4303 and RFC 4305 )
RFC 2407 : The Internet IP Security Domain of Interpretation for ISAKMP (obsoleted by RFC 4306 )
RFC 2409 : The Internet Key Exchange (obsoleted by RFC 4306 )
RFC 4305 : Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (obsoleted by RFC 4835 )
RFC 4306 : Internet Key Exchange (IKEv2) Protocol (obsoleted by RFC 5996 )
RFC 4718 : IKEv2 Clarifications and Implementation Guidelines (obsoleted by RFC 7296 )
RFC 4835 : Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH) (obsoleted by RFC 7321 )
RFC 5996 : Internet Key Exchange Protocol Version 2 (IKEv2) (obsoleted by RFC 7296 )
RFC 6379 : Suite B Cryptographic Suites for IPsec
RFC 6380 : Suite B Profile for Internet Protocol Security (IPsec)
^ Stallings, William (2016). Foundations of modern networking : SDN, NFV, QoE, IoT, and Cloud . Florence Agboma, Sofiene Jelassi. Indianapolis, Indiana. ISBN 978-0-13-417547-8 . OCLC 927715441 . https://www.worldcat.org/oclc/927715441
^ 『RFC6434』「Previously, IPv6 mandated implementation of IPsec and recommended the key management approach of IKE. This document updates that recommendation by making support of the IPsec Architecture [RFC4301] a SHOULD for all IPv6 nodes.」
^ RFC6071等 とう の記述 きじゅつ に使用 しよう されている。
^ Harkins, D.; Carrel, D. (November 1998). The Internet Key Exchange (IKE) (英語 えいご ). IETF . doi :10.17487/RFC2409 . RFC 2409 。
^ Kaufman, C. (ed.). IKE Version 2 (英語 えいご ). IETF . doi :10.17487/RFC4306 . RFC 4306 。
^ Sakane, S.; Kamada, K.; Thomas, M.; Vilhuber, J. (November 1998). Kerberized Internet Negotiation of Keys (KINK) (英語 えいご ). IETF . doi :10.17487/RFC4430 . RFC 4430 。
^ Richardson, M. (February 2005). A Method for Storing IPsec Keying Material in DNS (英語 えいご ). IETF . doi :10.17487/RFC4025 . RFC 4025 。
^ “SIPP Encapsulating Security Payload ”. IETF SIPP Working Group (1993年 ねん ). 2017年 ねん 1月 がつ 31日 にち 閲覧 えつらん 。
^ “Draft SIPP Specification ”. IETF. p. 21 (1993年 ねん ). 2017年 ねん 1月 がつ 31日 にち 閲覧 えつらん 。
^ http://www.toad.com/gnu/netcrypt.html
^
“RFC4301: Security Architecture for the Internet Protocol ”. Network Working Group of the IETF. p. 4 (December 2005). 2020年 ねん 10月 がつ 27日 にち 閲覧 えつらん 。 “The spelling "IPsec" is preferred and used throughout this and all related IPsec standards. All other capitalizations of IPsec [...] are deprecated.”