神田 充
東芝 研究開発センター


　後編では、IPsecに必要な鍵などの情報を交換するためのプロトコル「IKE」の概略を説明する。また、現在IETFのIPsec WGで進められているIPsecの規格の改訂についても紹介する。


IPsecにおける鍵交換

　前編では、IPsecにおけるAHとESPという2つのセキュリティプロトコル、トンネルモードとトランスポートモードという2つのモード、それらを設定するためのセキュリティポリシー（SP）とセキュリティアソシエーション（SA）について説明してきた。
　AHやESPでは、使用する認証アルゴリズム、暗号化アルゴリズムを設定するための鍵が必要となる。どちらのセキュリティプロトコルにおいても、使用するアルゴリズムは接続する相手と共有する秘密鍵を必要とする。
　もちろん、IPsecシステムを管理する人間同士が共有する秘密鍵をネットワークを介さず、例えばメモリカードなどに入れて交換し、それぞれのシステムに設定することも可能ではあるが、これでは大規模な環境には煩雑すぎて対応できない。
　そのため、何らかの自動的な鍵交換システムが必要となる。IPsecにおいて標準的に使用されているのが、IKE（Internet Key Exchange）と呼ばれているプロトコルである。


IKE

　IKEは、秘密鍵などIPsec SAの設定に必要なパラメータを通信相手と交渉し、得られた値をシステムに設定する。IKEの通信には、通常UDPのポート500番を使用する。

IKEの動作

　IKEはRFC2407、2408、2409、2412において規定されている。プロトコルは、大きく「フェーズ1」と「フェーズ2」という2つのフェーズ（phase）に分けられている。

フェーズ1

　フェーズ1では、まずISAKMP SAと呼ばれるIKE自身のメッセージをやりとりする安全な通信路を確立するためのSA（IPsec SAとは異なる）を交渉する。このフェーズにおいては、IKEのメッセージを暗号化するための鍵やIKE自身の認証を行う。
　フェーズ1には、メインモードとアグレッシブモードという2つのモードがあり、どちらかを使用する。
　メインモードは、全部で6つのメッセージを交換することによってISAKMP SAを確立する（図1）。
　アグレッシブモードは、メインモードと比べて少ない3つのメッセージ交換によって同じようにISAKMP SAを確立するが（図2）、事前共有秘密鍵を認証に使用した場合には自分自身のID（IPアドレスやサブネット情報など）が保護されないなどの制限がある。

IKEの認証方式
フェーズ1におけるIKE自身の認証方式には、事前共有秘密鍵（pre-shared key）認証、デジタル署名認証、公開鍵認証（2方式）の4つの方式がある。この中でいちばん簡便な方法は事前共有秘密鍵認証であるが、この方法だと読んで字のごとく事前に鍵を共有する必要があるため、スケーラビリティがない。それに比べて、デジタル署名認証方式ではPKI（Public Key Infrastructure）の利用が可能なため、スケーラビリティがある。また、RSAなどの公開鍵暗号の仕組みそのものを使用した認証方式も利用できる。

フェーズ2

　フェーズ1でISAKMP SAによって確立した安全な通信路上で、次にIPsecで使用するSAの交換を行う。
　フェーズ2では、クイックモードと呼ばれるモードを使用する（図3）。このモードでは、IKEの本来の目的であるIPsec SAに必要なAH、ESPなどのセキュリティプロトコルや、アルゴリズム、そのIPsec SA自身のライフタイムなどが交渉される。

IKEのプロトコルを2つのフェーズに分けている理由
ISAKMP SAにおいては、Diffie-Hellman鍵交換を利用しているため、使用する秘密鍵を得るために多くの計算を要する。そこで、フェーズ1で確立したISAKMP SAの使い回しをすることにより、Diffie-Hellman鍵交換の計算を減らし、複数組のIPsec SAを交渉する場合の高速化を図っている。


図1 メインモード（事前共有秘密鍵認証）

[0]
図2 アグレッシブモード（事前共有秘密鍵認証）

[0]
図3 クイックモード


IPsecの改訂

　現在、IETFのIPsec WGにおいてIPsecの規格改訂作業が進んでいる。この改訂では、セキュリティプロトコルであるAHおよびESPの改訂、次期IKEの策定、IPsecのアーキテクチャを記述したRFC2401の改訂などが進んでいる。

AH、ESPの改訂

　現状のAH、ESPには、32ビットのシーケンス番号フィールドがある。このフィールドは、リプレイ攻撃を防ぐために、パケットを送信するごとに値を1増やしていくことになっている。しかしフィールド自体が32ビットしかなく、現在の高速ネットワークでは容易にオーバフローしてしまうため、64ビットに拡張するなどの改良がなされている。

次期IKE（IKEv2）

　現状のIKE（IKEv1と呼ばれる）では、その仕様が複雑であり（かつ規定されているRFCが複数にわたっている）、それに起因する各実装の互換性が低いことから、IKEv2ではヘッダフォーマットやメッセージ交換方式の簡略化が図られている。
　具体的なIKEv2の特徴を、以下に示す。

• IKEv2もIKEv1と同じくUDPのポート500番を使用するが、メッセージ自体に互換性はない^注1 [0]
  
• 現在IPsec/IKEが多く使用されるシーンであるVPN（トンネルモード）により重点を置いた記述^注2 [0]になっている
  
• IPv6ではあまり関係がないが、NAT環境に対応するための機能（NAT Traversal）が追加されている
  
• DOS攻撃防御のため、ステートレス化の徹底が図られている
  
• 認証方式としてEAP（RFC2284）が追加されている

　これらは仕様策定の最終段階になってきているため、まもなくRFC化されるものと思われる。

^注1バージョン番号フィールド自体の位置は変わらないため、バージョン番号でどちらのバージョンのIKEのメッセージであるかは判別が可能。

^注2トランスポートモードでの使用ができなくなるわけではない。