IKE - プログラミング探して！

IKE †

IKE = Internet Key Exchange インターネット鍵交換

IKEv1は Internet Key Exchange protocol version 1 の意味であり、UDPポート番号500上で通信される鍵交換プロトコルである。
開発時には ISAKMP/Oakley と呼ばれた過去があり、これはISAKMP(Internet Security Association and Key Management Protocol)プロトコルの上でOakley鍵交換手順を実装したものという意味である。
すなわち、IKEv1はISAKMPと必ずしも同じものではない。

＠IT：管理者のためのインターネットVPNの接続環境とその機

↑

IPSec標準における接続先相手認証 †

IPsecでは、実際にデータの暗号化通信の開始に先立ち、IKE（Internet Key Exchange）プロトコル（暗号化方式の決定や鍵の交換や相互認証に使われるプロトコル）を使用した通信の中で接続先相手の認証を行う。

↑

●IKEプロトコルの目的 †

（1）VPN接続のエンドポイント間でプロポーサルを交換する。

自身のVPNゲートウェイが提供可能なパラメータ（暗号化アルゴリズムやハッシュアルゴリズムなど）を提案し、互いに接続先相手が使用可能なパラメータを認識、共有する。

（2）鍵交換

エンドポイント間で以降のIKEプロトコルを使用した通信の暗号化に使用する鍵を交換し、共有する。

（3）接続先相手認証

エンドポイント間でIDを交換することで接続先相手を認証する。

上記の目的を実現するために、IKEプロトコルは2つの実行モードを用意している。
メイン・モード（Main Mode：フェーズ1メイン・モードなどと記述される）とアグレッシブ・モード（Aggressive Mode：フェーズ1アグレッシブ・モードなどと記述される）である。

図2 メイン・モード

図3 アグレッシブ・モード

↑

●接続先認証に使用するIDの暗号化 †

　上図に示したように2つのモードの大きな違いは、接続先認証に使用されるID情報に対するセキュリティである。
メイン・モードではIDが暗号化されて送信されるのに対して、アグレッシブ・モードでは平文のまま送信される。

　IDの暗号化を実現するために、メイン・モードではエンドポイント間でID交換をする前に接続先相手の事前秘密鍵（Pre-Shared Secret Key）を知る必要がある。
しかし、図2にあるように、鍵交換フェーズではVPNゲートウェイは接続先相手のIDを知らないため、この時点では接続先相手の事前秘密鍵を特定することができない。
そのために、IKEプロトコルの実装では、IKEの通信中に送受信されるIPパケットの送信元アドレスをIDとして事前秘密鍵の特定に使用している。

　この場合、メイン・モードでは、鍵交換の段階で接続先相手のエンドポイントのIPアドレスを持つオブジェクト（VPN製品に定義される要素）がVPNゲートウェイ上で定義されている必要がある（事前に接続先相手のIPアドレスが定義される。つまり、接続先相手のIPアドレスが固定されている必要がある）。

　一方、図3にあるように、アグレッシブ・モードでは鍵交換情報と同じメッセージの中で接続先相手のIDが送受信される。そのため、IDは暗号化されずに送受信される。

　ここで、2つのモードを実際のVPN接続環境に対応させてみる。
一般に、サイト間接続型VPNでは、互いのVPNゲートウェイのIPアドレスが固定されるため、メイン・モードを利用することが可能である（アグレッシブ・モードでも可能であるが、通常はIDが暗号化されるメイン・モードを利用する場合が多い）。
リモートアクセス型VPNでは、ダイヤルアップ接続などを使用してアクセスポイントに接続した後、VPNコネクションを確立する。VPNクライアントに割り当てられるIPアドレスは、アクセスポイントに接続するたびに変化するため、VPNゲートウェイ側ではVPNクライアントのIPアドレスを特定することができない。
そのため、リモートアクセス型VPNでは、メイン・モードは利用できず、アグレッシブ・モードを利用することになる。

↑

●接続先認証に使用するID †

　リモートアクセス型VPNの接続先相手の認証に使用するIDは、サイト間接続型VPNと異なる要件を持つ。
サイト間接続型VPNでは、IDとしてVPNゲートウェイのIPアドレスを使用する。
リモートアクセス型VPNでは、認証に使用するIDとして利用者個人を認証できる情報を使用する必要がある。
つまり、利用者が使用するクライアントのIPアドレスをIDとしても、実際に認証対象となるのはあくまでもクライアントである。
認証の対象にする必要があるのは、そのクライアントを利用している利用者である。
そのため実際には、IDとして、利用者のユーザー名やメールアドレスを使用する。

↑

●リモートアクセス型VPNとIPSec標準 †

　前述したように、リモートアクセス型VPNでは利用者固有のIDを使用して接続先認証を実現する必要があるが、現在のIPSec標準（RFC）では、接続先相手の認証に利用者固有のIDを使用するフレームワークが含まれていない。
そのため、IPSec標準のみを実装してもリモートアクセス型VPNが要求する技術要件には対応できないのである。
そのため、リモートアクセス型VPNの場合にも、サイト間接続と同じように各クライアントのIPアドレスを固定にしたり、すべての利用者間で事前秘密鍵を同一にするなどして構築しなければならないVPN製品も見受けられる。
しかし、クライアントのIPアドレスの固定化や、事前秘密鍵の共有などは、実際のリモートアクセス環境が求める管理面とセキュリティ面の要件との隔たりが大きく現実的でない。

　これを解決するために、IETF（The Internet Engineering Task Force）では、IKEプロトコルを拡張することにより、ユーザー固有のIDによる相手認証のフレームワークをインターネットドラフトとして提案している。

　提案の1つにXAUTH（Extended Authentication within ISAKMP／Oakley）がある。
XAUTHは、IKEプロトコルを拡張することで、従来組織内で利用してきたワンタイムパスワードやRADIUSなどを使用した認証サービスを利用できるようにするものである。
実際に、XAUTHは多くのVPN製品で実装されているが、いまだにIPSec標準に組み込まれる予定はない。
なぜならば、IPSec標準を策定しているグループの基本ポリシーとして、IKEプロトコルを拡張すること自体を認めていないためである。

↑