IKEの位置付け
IKE (Internet Key Exchange) とは盗聴リスクのあるネットワーク上で暗号化のための共通鍵を交換するためのプロトコルスイートです。実態として IPsec の共通鍵を交換するためにに使わることがほとんどです。
IKE の主な仕事は、IPsec が使う以下 2 種類のデータベースを完成させることです。
- SPD (Security Policy Database) : ルータに入ってきたパケットをどのように扱うか (IPsec で暗号化するか、暗号化せず通常のルーティングテーブルに渡すか、破棄するか) を決めるテーブル
- SAD (Security Association Database) : SPD で「IPsec で暗号化する」と判断された際に、どのような暗号化をしてどの対向ルータに送るかを決めるテーブル(暗号化用の共通鍵はこのデータベースに含まれる)
なお、SPD のうち IPsec で暗号化する条件=セレクタ [送信元 IP, 宛先 IP, プロトコル, 送信元 Port, 宛先 Port の組合せ] については IKE から取得しますが、暗号化せず通常のルーティングテーブルに渡す条件、破棄する条件については一般にはルータ設定から取得します。つまり、SPD は一部が IKE により作られ、一部が config から作られます。
IKEv1 と v2 の比較
IKEv1 と v2 のシーケンスを以下に示します。
実際のパケットキャプチャを見たい方は、以下の記事もご参照下さい。
鍵交換には DH (Diffie Hellman) 鍵交換プロトコルが使われますが、DH 鍵交換は成り済ましに弱いため、基本的には DH とは別の方法で相手を認証してから、鍵交換を行います。
IKEv1 においてはフェーズ 1 が認証、フェーズ 2 が本番 (IPsec) 用の鍵交換、データベース作成のための素データ交換です。
フェーズ 1 でも DH 鍵交換を行いますが、これは主に認証用途です。(フェーズ 2 で交換する DH 鍵交換を秘匿するためにも使われ、さらなるセキュリティ強化の側面もありますが。)
一方、IKEv2 においては基本的にはフェーズ 1、フェーズ 2 という概念は無くなり、フェーズ 1 の 2 往復分を [IKE_SA_INIT] という 1 往復のメッセージに圧縮し、さらにフェーズ 1 の最後の 1 往復とフェーズ 2 の 1 往復半を [IKE_AUTH] という 1 往復のメッセージに圧縮しました。
また、ある 2 つのルータ間で複数の IPsec SA が必要な場合 (例えばルータ#1 の 10.1.1.1/24 とルータ#2 の 10.2.2.0/24 で 1 つの IPsec SA を構成しつつ、さらにルータ#1 の 10.11.11.0/24 とルータ#2 の 10.22.22.0/24 でも 1 つの IPsec SA を構成する場合) は 2 番目以降の IPsec SA を [CREATE_CHILD_SA] というメッセージによって構築します。
また、IKEv1 と IKEv2 の比較表を以下に示します。
| IKEv1 | IKEv2 | |||
| RFC | RFC2407 (DOI) RFC2408 (isakmp) RFC2409 (IKE) RFC2412 (Oakley) | 1998年 | RFC4306 RFC5996(改定) RFC7296(さらに改定) | 2005年 2010年 2014年 |
| 互換性 | なし | |||
| フェーズ | フェーズ1&フェーズ2 | なし (画一化) | ||
| モード | Main/Aggresive/Quick | なし (画一化) | ||
| パケット数 | 9パケット※Main+Quick 7パケット※Aggressive+Quick | 4パケット※IPsec SA が1つのとき 2+2nパケット※IPsec SA がnつのとき | ||
| DPD (keepalive) | RFC3706で追加で規定 | IKEv2 の中で規定 | ||
| NAT Traversal | RFC3947で追加で規定 | IKEv2 の中で規定 | ||
| その他特徴 | 複雑で曖昧な仕様のため、 ベンダ間での実装差異が大きい | IKEv1の反省を踏まえ、 シンプルで明確な仕様 | ||
IKEv1の構造とパケットフォーマット
RFC2408 から引用
While Oakley defines "modes", ISAKMP defines "phases".
IKEv1の構造
IKEv1 はその策定時における目標は、『用途を IPsec に限定しない、汎用的な鍵交換プロトコル』でした。
策定時は『オブジェクト指向』や『モジュール指向』を他分野へ応用する潮流にあり、おそらくそれも手伝ってか、IKEv1 は複数の RFC 規格から構成されています。
isakmp とは
isakmp とは抽象的なフレームワークであり、パケットフォーマットやフェーズ等を規定しています。
パケットフォーマットは以下の通りです。
Initiator SPI ＆ Responder SPI
isakmp のセッション開始 (Initiator) 側は Initiator SPI にランダム bit 列, Responder SPI に all 0 bit 列を格納してピアに送信し、ピア (Responder) 側は Initiator SPI はそのまま、Responder SPI にランダム bit 列を格納して返信します。
以降のやり取りはこの 2 つの SPI を固定したまま送信しあいます。これによりお互いがセッションを識別します。
Next Payload
Next Payload には、次のフィールドに格納されるデータの型 (isakmp で交換し合う具体的な情報) を定義します。例えば SA 構成のパラメータ (SA) であれば 1、鍵交換 (Key Exchange) であれば 4、認証ハッシュ (Hash) であれば 8、といった値が格納されます。
MajorVer ＆ MinorVer
メジャーバージョンとマイナーバージョンを示します。IKEv1 の場合は常に MajorVer=1、MinorVer=0 となります。
Exchange Type
交換時のモードを示します。Main モードの場合は 2、Aggressive モードの場合は 4 が格納されます。
Flags
3 つのフラグが定義されていますが (5 つは予約)、実際に使われることが多いのは Encryption Flag です。暗号化されたパケットについては、この bit を 1 にセットします。
Message ID
このフィールドはフェーズ 1 では常に 0 となります。フェーズ 2 では構築する IPsec SA 毎に 1 つ、ランダム bit 列が生成され、格納されます。これにより、どの IPsec SA に関するパケットかを識別します。
DOI とは
DOI (Domain Of Interpretation) とは isakmp で定められたフレームワークに具体性を与えるパラメータを規定したものです。例えば Protocol ID に入る値として、AH なら 2、ESP なら 3、といった定義がされています。
パラメータを変えることによって、IPsec 以外のプロトコルにも使えるようになります。つまり、DOI は汎用性を高めるために isakmp と分離されているのです。
例えば TLS に isakmp を使う試みもあったようですが、少なくとも今は実装されていません。
Oakley dh-group とは
Oakley では DH に関する『DH グループ』と『モード』を規定しています。
『DH グループ』では DH 鍵交換の具体的な方式とパラメータを規定しており、グループ番号さえ指定すれば互いに条件を揃えることができます。
DH グループはセキュリティ強度に関わるモジュールであり、新たなグループがどんどん追加されています。また、番号は IANA で管理されています。
DH グループの 3,4,7-13 はほとんどの機器で実装されていません。これに関する個人的な考察を本記事の最後に掲載しています。
Oakley モードとは
『モード』には以下の 3 種類が使われます。
- Main モード : DH 鍵交換を行い、ID と認証情報を暗号化した状態で認証を行う
- Aggressive モード : DH 鍵交換と ID 交換を行い、認証情報を暗号化した状態で認証を行う
- Quick モード : 認証無しで DH 鍵交換のみを行う
「isakmp のフェーズ 1 ではメインモード、もしくはアグレッシブモードしか使ってはならない、フェーズ 2 ではクイックモードしか使ってはならない」という isakmp のフェーズと Oakley のモードの話が IKEv1 に規定されています。
デジタル署名等の秘密鍵/公開鍵を使った認証方式においては、秘密鍵を持っていることで ID (唯一の存在であること) を証明しますが、事前共有鍵を使った認証方式では唯一性は示せず、ピア毎に決めた合言葉をもって相手を認証します。
また、メインモードにおいては認証情報を暗号化した状態で送ります。さらに、『PreShared Key (事前共有鍵)』で認証する場合は、この暗号化・復号化には『DH で生成した共有鍵』単体ではなく『PreShared Key (事前共有鍵)』をも混ぜ合わせた鍵を使います。
すると、相手から ID を通知される前に、『どの PreShared Key を使って暗号化するか』を決めなければなりません。
この関係で、Main モードかつ PreShared Key 認証の場合は必ず【 ID = IP アドレス】となります。
ID を秘匿するためのモードなのに、公開情報の IP アドレスを使うので、不思議に思いますが、これも汎用性を求めて細かくモジュール化した弊害の 1 つでしょう。
IKEv1 で動的 IP かつ事前共有鍵認証を使う場合はアグレッシブモードを使います。アグレッシブモードでは最初のパケット交換で ID を平文で提示します。
なお、後述しますが、IKEv2 ではモードの概念は廃止されました。また、暗号化には PreShared Key を使うことをやめたため、ID も自由に設定できます。つまり、動的 IP であっても問題無く動作します。
IKEv1の2種類のID
IKEv1 で言うところの ID は、フェーズ 1 とフェーズ 2 でそれぞれ存在します。
フェーズ 1 の ID は、ピアを認証するためにあり、つい先ほど説明の通り、メインモードの場合は IP アドレスが ID として使われます。
フェーズ 2 の ID とはいわゆる Proxy ID のことです。これは非常に紛らわしいため、IKEv2 では『Traffic Selector (トラフィックセレクタ)』に定義し直され、ID というニュアンスは無くなりました。
この Proxy ID および Traffic Selector は IKE 用語ですが、IPsec 用語では SPD や SAD に登場する『セレクタ (送信元IP, 宛先IP, プロトコル, 送信元Port, 宛先Portの組合せ)』のことです。IKEv1 ではメーカの実装次第ではピアと対称になるよう設定することが要求されますが、IKEv2 ではネゴシエーションをすることになっており、ハードルが下がっています。
Proxy ID とトラフィックセレクタのもう少し詳細については以下の記事をご参照下さい。
IKEv2の構造とパケットフォーマット
構造
IKEv1 ではメーカ実装の差異により、異なるメーカの NW 機器で IPsec がうまく動作しない例が多く存在しました。
主な原因として挙げられているのが、プロトコル仕様の曖昧さと複雑さです。
そこで IKEv2 では 4 つの RFC 規格を 1 つの RFC 規格にまとめました。
DOI を削除することにより、(汎用性はなくなりましたが)、IPsec 専用の鍵交換プロトコルとしてシンプルかつ一意的なプロトコルとなりました。
なお、isakmp のフェーズと Oakley のモードは削除されましたが、isakmp のパケットフォーマットと Oakley の DH グループは IKEv2 に引き継がれています。
また、拡張機能となっていた DPD (keepalive) や NAT-Traversal、XAUTH (EAP) といった機能が IKEv2 の規格として正式にサポートされました。
シーケンス
IPsec 専用となったため、シーケンスが大幅に見直されました。シーケンスは序盤に示した図の通りです。
- IKE_SA_INIT : 平文で IKE SA 用の DH 鍵交換
- IKE_AUTH : ピアを認証しつつ、1つ目の IPsec SA 用の DH 鍵交換
- CREATE_CHILD_SA : 2つ目以降の IPsec SA 用の DH 鍵交換
RFC4306 によると、IKE_SA_INIT と IKE_AUTH はフェーズ 1 相当、CREATE_CHILD_SA はフェーズ 2 相当と記載されています。
Communication using IKE always begins with IKE_SA_INIT and IKE_AUTH exchanges (known in IKEv1 as Phase 1).
1.3. The CREATE_CHILD_SA Exchange
This exchange consists of a single request/response pair, and was referred to as a phase 2 exchange in IKEv1.
ただし、最初の IPsec SA 確立については IKE_AUTH に含まれます。
The second pair of messages (IKE_AUTH) authenticate the previous messages, exchange identities and certificates, and establish the first CHILD_SA.
前述の通り、isakmp の『フェーズ』の概念は削除されましたが、便宜的にメーカの説明などでは『フェーズ 1 = 認証 + IKE SA 確立』、『フェーズ 2 = IPsec SA 確立』という意味で使われることがあります。
PFSとは
PFS (Perfect Forward Secretary) とは、あるタイミングで 1 つの鍵が破られて暗号化通信を解読された際でも、それより前に生成した鍵を使っている暗号化通信については解読できない性質を指します。
IPsec 設定において、PFS を無効にすると、IKE SA で使った共通鍵をベースに、IPsec SA の共通鍵を作ります。
これによるメリットは CPU 負荷を抑えられることです。(DH 鍵交換は CPU リソースを多く使うが、PFS を無効化することで鍵の素の使い回しにより、DH 鍵交換の回数を減らすことができる。)
一方 PFS 無効化のデメリットは、IKE SA の鍵が破られた際に、芋づる式に IPsec SA の通信も解読されてしまうことです。
IPsec SA の数がそんなに多くなければ、PFS 有効化による負荷はそこまで気にすることはないでしょう。
なお、SSL/TLS でも PFS の説明が出てきますが、IPsec とは規模が違います。
SSL/TLS では、秘密鍵による暗号化を使って通信暗号化用の共通鍵を受け渡している時期がありました。ですがこの方式では秘密鍵が漏洩した際に、それまでの全ての通信が解読されてしまいます。
俗に言うスノーデン事件では、国家規模で通信を盗聴、保管しておき、秘密鍵の解読を試みることがスノーデン氏により告発され、それ以降は SSL/TLS の共通鍵の受け渡しも DH 鍵交換方式のみが使われるようになりました。
ただし、SSL/TLS の認証については昔から今でも、秘密鍵/公開鍵によるデジタル署名方式がよく使われています。
SSL/TLS については以下の記事をご参照下さい。
おまけ その1 : IKE? isakmp?
IKEv2 のパケットキャプチャを見ると、プロトコルが『isakmp』となっています。
これはパケットフォーマットが isakmp から流用されているため、この名称を引き継いでいるようですが、RFC 的には IKEv2 には isakmp の概念は無くなっています。なので isakmp ではなく IKEv2 のパケットフォーマットです。
例えば RFC2407 にはフェーズ 1 の SA は『isakmp SA』という言葉が使われていますが、RFC4306 には『IKE SA』という言葉に変わっています。
おまけ その2 : 実装されていないDHグループ
DH グループの中で 3, 4, 6～13 のグループはほとんどのメーカーで実装されていません。これらに共通しているのは、アルゴリズム方式が EC2N (Elliptic Curve groups modulo a power 2) であることです。
6～13 は RFC のドラフトで終わっています。3 と 4 は RFC2409 で明確にサポートすべき (SHOULD support) と書かれていますが、RFC4109 で MAY に上書きされています。その理由として以下の記載があります。
Tiger for hashing, Diffie-Hellman MODP groups with elliptic curves, DSA for authentication with signatures, and RSA for authentication with encryption are dropped due to lack of any significant deployment and interoperability.
同 RFC4109 を見ると分かりますが、EC2N は展開の欠如 (lack of deployment) のため、サポートを推奨まではしない方針となりました。展開の欠如が何を意味するかは不明ですが、ハードウェア工学の金額的なコスト面の問題かもしれません。また、この論文には次のような記載があります。
The binary curves ec2n_155 and ec2n_185 also have weak twists which reduce the attack cost to 2^33 and 2^47, respectively.
ec2n_155 と ec2n_185 はそれぞれまさに DH グループ 3 と 4 のアルゴリズムを指しているのですが、『それぞれ 155 bit および 185 bit レベルの強度の暗号をそれぞれ 33 bit および 47 bit まで攻撃コストを減らすことができる』ということのようです。
計算コストの割にセキュリティ強度が伴わない、というのが実装から敬遠された理由なのかもしれません。
IT/インフラエンジニアの地位とスキル向上のために
あなたが成長の日々を歩めますように。
コメント
いつも参考になる記事をありがとうございます。VPNは色々なパラメータや問題などあって、なかなか難しいです。。
質問ですが、IPsecのIKEv2はあまり使われてないのでしょうか。
古いikev1でのVPNしか見たことありません。(私の周りだけ？？)
SNMPv3みたいなイメージでした。
しょみさん
コメントありがとうございます。
私が設計するとしたら、間違いなくIKEv2を選択するのですが、実際、私が引き継ぐ案件を見るとv1で構築してることも多いです。ただ、v2になっていることもそれなりにはあります。
1つの仮説ですが、デフォルト設定でv1になっている機器も多く、エンジニア界隈では検証した結果をそのままパラメータシートに落とし込む習慣もあり、さらには特別検証項目に入らないパラメータはデフォルトにすることが多いからではないかと思います。
あと、確かにSNMPv3もなかなか流行りませんね笑
こちらは昔は結構不具合が多かったと記憶しています。あとはそもそもサーバ室内の通信で暗号化が必要か？とか監視のためにcpu使うことになるんじゃないか？というのもあります。
まあ、実装がUDPなので送信元偽装は比較的簡単なのでDoS攻撃の対象としては狙われやすいかもしれませんが、こちらもインターネットから直接アクセスできるような構成になっていないはずなので、あるとしても内部犯。。これも考えづらいですね。。
nesukeさん
ご回答ありがとうございます。
>1つの仮説ですが、デフォルト設定でv1になっている機器も多く、エンジニア界隈では検証した結果をそのままパラメータシートに落とし込む習慣もあり、さらには特別検証項目に入らないパラメータはデフォルトにすることが多いからではないかと思います。
考えてみるとたしかにそうですね・・・恐らくこれだと思います！
SNMPv3は不具合が多かったのですね。知りませんでした。
確かに、基本的には内部ネットワークでしか使わないため暗号化は無くても問題ないですね。
以前、インターネットRTでACL無し、コミュニティ名Publicの裸単騎待ちを見たことがあります・・・笑
たまに恐ろしい設定になっているのに出くわすと硬直しますよね。
まあ、ルータのsnmpのroだけならまだましですかね。。rwを開けてたり、telnet開けてたりしてたら目も当てられない。。
今後も当サイトをどうぞ宜しくお願いします。