Security Gateway and IPsec release 3
| 作成日 | 1999/Jul/23 |
| 最終変更日 | 2018/Nov/06 |
| 文書サイズ | 14KB |
本文書では、最近新しく提案された RFC2407、 RFC2408、 RFC2409に基づき、 IKEを概観する。 IKEは、Internet Key Exchangeの略であり、 インターネットという安全でない通信路において、 安全に鍵を交換するためのプロトコルである。 IKEは、従来はISAKMP/Oakleyという名前で呼ばれていた。 それが最近になって標準的な鍵交換プロトコルと考えられるようになり、 1998年にIKEの名称が与えられることになった。
IKEに関するRFCのうち、IKEの名を冠したRFCは RFC2409 である。 そして、 RFC2407や RFC2408は、 RFC2409を読むための付随ドキュメントである。 RFC2408はIKEの基になった プロトコルであるISAKMPについての記述である。 ISAKMPは、主にメッセージの書式や動作ガイドラインを示している。 RFC2407には、 IPsecでISAKMPを利用するときのISAKMPの解釈が示されている。
PFSとは、ある鍵を知られてしまったときの被害が、 その鍵で暗号化したメッセージ以外には及ばないという性質を指す。 例えば、たくさんの鍵を使っていても、マスターキーを奪われてしまえば、 全ての鍵が無効になってしまうのと似ている。
IKEでは、鍵を作るために、鍵を利用する。したがって、鍵には、 作ったものと作られたものの親子関係が存在する。このよう な場合、親の鍵が知られてしまうと、子の鍵も知られやすくなる。
PFSを保証するには、次に挙げることを遵守する必要がある。 1つは、メッセージの暗号化に使った鍵で、 別の鍵を作らないことであり、もう1つは、メッセージの 暗号化に使われている鍵があるときに、 その鍵を作った親鍵で別の鍵を作ってはいけないということである。
セキュリティ・アソシエーション(SA)は、 セキュリティを互いに保護し合うための関係を表している。 このような関係を持つためには、 鍵やアルゴリズムなどの、セキュリティサービスに関する情報を 秘密に共有することが必要である。
SAは、鍵を管理するときの単位となる概念である。鍵は、それ自体には 何の意味もなく、鍵のみを知っていても役に立つものではない。 例えば、鍵が、どのようなアルゴリズムで、どの相手に対して利用する かなど、鍵に付随する情報が必要である。 SAはこれらの情報を集めた鍵の管理単位である。
ノンス(nonce)は乱数を意味する。乱数を用いることの主な目的は、 リプレイ攻撃に対する防御である。 リプレイ攻撃は、 毎回決まった情報をやり取りするようなセッションがあるときに、 そのセッションを乗っ取るための手口である。 仮に、どんなに意味不明な符牒で修飾されたセッションでも、 それをそっくり真似することは簡単である。 そこで、攻撃者はセッションを記録しておいて、それを真似し、 あたかも自分が符牒を知っている仲間だと偽るのである。
毎回のセッションにノンスを使うことで、こうした攻撃を防御することができる。 ノンスの含まれたメッセージを受け取ったものは、 そのノンスに対して正しい処理をしなければならないため、 単純なリプレイ攻撃を適用することはできない。
IKEは、フェーズ1とフェーズ2という2つのフェーズによって、 必要なSAを生成する。 フェーズ1の目的は、とりあえずホスト間に安全な通信路を張ることである。 この時に作られるSAは、ISAKMP SAと呼ばれる。 ISAKMP SAは専らIKEのために用いられ、 引き続くフェーズ2の鍵交換を支援するために使われる。すなわち、 フェーズ2のメッセージを暗号化して、セキュリティ的な保護を与える。
フェーズ1には、 メインモード(main mode)とアグレッシブモード(aggressive mode) という2つのモードがある。 どちらのモードを用いても良いが、標準的にはメインモードが使われる。 両者の主な差は、SAを作るために必要なメッセージの数である。 アグレッシブモードは、メインモードに比べて、 より少ないメッセージを交換してSAを作ることができる。
フェーズ2の目的は、認証ヘッダ(AH)や暗号ペイロード(ESP)のような、 IKE以外のプロトコルの鍵を作ることである。 フェーズ2は、必ずフェーズ1に引き続いて生起する。この理由は、 フェーズ2のメッセージが、フェーズ1で作ったISAKMP SAで保護されるためである。 もっとも、ISAKMP SAが既に存在するならば、すぐにフェーズ2が生起することもある。
ISAKMP SAは双方向のSAである。つまり、 1つのSAで内向きと外向きのトラヒックを処理することができる。 したがって、フェーズ2を行うには、ただ1つのISAKMP SAがあればよい。 フェーズ2のメッセージは、その方向に関係なく、1つのISAKMP SAで保護される。
また、ISAKMP SAは、2つの、8byteのクッキーで識別される。 2つのクッキーのうち、1つはフェーズ1を始動したホストが決めるものであり、 もう1つはフェーズ1に応答したホストが決めるものである。 これらのクッキーは、メッセージのヘッダにいつも格納されているため、 ヘッダを見れば、そのメッセージがどのISAKMP SAに関係するかを知ることができる。
IKEは、UDPの500番ポートを使って、メッセージを交換する。
ここでは、フェーズ1として、メインモードについて説明する。 認証方式は事前共有鍵(pre-shared key)によるものと仮定する。 事前共有鍵は、鍵交換に先立ち、あらかじめ共有されるべき鍵である。
メインモードは、全部で6つのメッセージを送受信して完了する。
(1) 始動側 → 応答側 「ヘッダ 提案」 (2) 応答側 → 始動側 「ヘッダ 提案」
最初の2つのメッセージでは、ISAKMP SAの属性をネゴシエーションする。 始動側は、ISAKMP SAの属性を幾つか格納した提案を送り、 応答側はその中から受理できるものを選択して送り返す。
ヘッダを用いて、始動側と応答側は、自分のクッキーを相手に送信する。 クッキーの意味は、サービス拒否に対する防御である。 悪意を持ったものは、サーバに無意味で大量の要求を送り付けて、 サーバのCPU資源を不当に占有してしまう。 そこで、CPU資源のかかる鍵情報の生成をする前に、 クッキーを交換することで、こうした攻撃を防ぐ。
以後、フェーズ1、フェーズ2を通して、ヘッダには両者のクッキーが 格納される。こうすることで、両者はヘッダを見ただけで、 そのメッセージがどのセッションに属するのかを識別することができる。
(3) 始動側 → 応答側 「ヘッダ 鍵情報1 ノンス1」 (4) 応答側 → 始動側 「ヘッダ 鍵情報2 ノンス2」
次に両者は、互いに鍵情報を送信する。 両者は、鍵情報に基づいて共通の値(鍵)を得る。なお、 ここで送信される鍵情報は平文であるが、 この情報のみに基づいて鍵を計算することは困難であるため、 鍵の安全性が保証される。
(5) 始動側 → 応答側 「ヘッダ ID1 ハッシュ1 」 (6) 応答側 → 始動側 「ヘッダ ID2 ハッシュ2 」
最後に両者が、識別情報とハッシュを送信し、鍵交換の成功を確認する。 ID1には始動側の、ID2には応答側のIPアドレスが格納される。なお、 アグレッシブモードでは、IPアドレス以外のIDを格納することができる。
フェーズ1でネゴシエーションされるISAKMP SAの属性には以下のものがある。 このうち、上の4つは必須の属性であり、それより下はオプションの属性である。
暗号アルゴリズムは、IKEのメッセージを暗号化するために使われる アルゴリズムであり、必ずDESがサポートされる必要がある。他の 選択肢としては、3DESやIDEAなどがある。
ハッシュアルゴリズムは、 主にIKEのメッセージを認証するために使われるアルゴリズムであり、 MD5とSHAがサポートされる必要がある。
認証方式は、事前共有鍵(pre-shared key)による方式がサポート される必要がある。認証方式は、フェーズ1やフェーズ2のメッセ ージの書式に影響を与える。事前共有鍵以外の認証方式には、 DSS、RSAなどがあるが、 これらのメッセージの書式はそれぞれ異なるものである。
グループは、鍵交換の核となるパラメータの集合である。 パラメータを個々にネゴシエーションすることも可能であるが、 あらかじめ定義されたパラメータの集合を使うことができる。
寿命には、2種類のタイプがある。1つは秒数でカウントする寿命であり、 もう1つはSAが処理した情報量(キロバイト数)でカウントする寿命である。 SAが処理した情報量とは、SAの鍵がアルゴリズムと組み合わせて使われたときに、 そのアルゴリズムに入力された情報の総量である。
擬似乱数関数(PRF)は、現仕様ではネゴシエーションする必要のない属性である。 ネゴシエーションされない場合には、 上述のハッシュアルゴリズムのHMAC版を利用することになっている。 例えば、ハッシュアルゴリズムとしてMD5がネゴシエーションされた場合には、 擬似乱数関数としてHMAC-MD5が利用される。
ここでは、フェーズ2として、クイックモードについて説明する。 クイックモードは、フェーズ1で作られたISAKMP SAを利用する。 すなわち、ISAKMP SAが存在しない場合には、先にフェーズ1を 起動し完了するのを待つ必要がある。
ISAKMP SAがあるとき、同じISAKMP SAを使って、 複数のクイックモードを同時に実行することができる。 複数のクイックモードを識別するために、メッセージIDを用いる。 メッセージIDは、クイックモードを始動するときに、始動側が決定するものである。
クイックモードで作られるSAは、 IPsecやその他のプロトコルで利用されるが、これらは片方向のSAであり、 片方向の通信しか保護することはできない。クイックモードでは、 同時に2つのSAを作り、両方向の通信に対応できるようにSAを用意する。
同時に作られる2つのSAは、保護できる通信の方向、鍵、SPIが異なるが、 アルゴリズムや鍵の寿命は同じ値である。 SPIは、通信の終端となるホストが決定する。 下の図で、SA1とSA2のSPIを、それぞれspi1とspi2とすると、 spi1はIKEd Bが、spi2はIKEd Aが決定する。
+----------+ +----------+ | | ----- SA1(SPI = spi1) ----> | | | IKEd A | | IKEd B | | | <---- SA2(SPI = spi2) ----- | | +----------+ +----------+
クイックモードは、以下に示す3つのメッセージを送受信して完了する。 なお、全てのメッセージは、ヘッダ以降が暗号化される。
(1) 始動側 → 応答側 「ヘッダ ハッシュ1 提案 ノンス1 [鍵情報1]」 (2) 応答側 → 始動側 「ヘッダ ハッシュ2 提案 ノンス2 [鍵情報2]」 (3) 始動側 → 応答側 「ヘッダ ハッシュ3」
まず、始動側が、SAの属性を格納した提案を応答側に送信する。 応答側は、 提案の中から受理できるものを選択し、それを始動側に送り返す。 最後に、始動側は、確認のハッシュ情報を応答側に送信する。
セキュリティ・ゲートウェイの状態を通知するためには、報告メッセージを送信する。
報告メッセージは、通常はISAKMP SAの保護の下で、 専用のペイロードに格納されて送信される。 このペイロードは、 メインモードやクイックモードのメッセージに織り込んで送信することができる。 あるいは、このペイロードだけを、以下のようなメッセージで交換してもよい。
「ヘッダ ハッシュ ペイロード」