3 Minutes NetWorking Supplement
No.24

3Minutes NetWorking Supplement

補講第24回IPsec(4) IKEv2(IKE_SA)

■ SAの構築

おねーさん

おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3 Minutes Networking、

ほげたん

Supplement !!

おねーさん

さてさて? IPsecの概要、SA、SAのパラメータと話が続いてるわけなんだけど。今回もSAがらみの話。

ほげたん

IPsecを行うために、そこで使用する「パラメータの合意」による「セキュアな仮想的な通信路」がSAだったよね。前回出した図をどうぞ。

セキュア化パラメータ

[FigureSP23-01:SAとセキュア化パラメータ]

おねーさん

そう、パラメータを送受側で一致させることにより作られる、セキュアな通信路がSAよね。この図ではXとYはパラメータが一致するから、Xが送ったパケットのセキュア化をYは解除できる。

ほげたん

一方、Zはパラメータが一致しないから、セキュア化を解除できない。よってセキュアな通信路ができていない、ってわけだね。

おねーさん

そういうことね。で、今回はパラメータの合意を行う方法、つまりSAの構築方法を説明しようかな、と。

ほげたん

ん〜っと、前聞いた話では、事前にパラメータをセットしておく静的な方法と、自動でパラメータが決定される動的な方法があるって話だけど?

おねーさん

そうね、その2種類があるわけね。静的な決定はわかりやすいわよね、セキュリティゲートウェイやIPsecクライアントソフトで、送受側で使用するパラメータを最初からセットしておけばいいんだから。

ほげたん

まぁ、そうだよね。

おねーさん

ただ、この方法はいいんだけど、欠点が2つ。1つ目、暗号化・メッセージ認証で使用する鍵を変更できない。できるけど手動だから、管理負荷がかかるっていうか、簡単にいえば面倒。

ほげたん

鍵を変更できないと何か問題が?

おねーさん

どんな暗号でもおなじ鍵を長時間使用するのはよろしくないってこと。鍵を解読できる時間と、材料である暗号化されたパケットを多く入手できちゃうからね。

ほげたん

パスワードを定期的に変更しなきゃいけないようなものかな? で、もう1つは?

おねーさん

もう1つは前回話したわね。リプレイ防御が有効にならない

ほげたん

シーケンス番号カウンタのサイズの問題だっけ。シーケンス番号がゼロに戻っちゃうって話の。

おねーさん

そう、それ。その場合違うパラメータの新しいSAを構築しなきゃダメなんだけど、静的ではそれができない。よってリプレイ防御が効かない。

ほげたん

リプレイ防御を使いたかったら、動的なSAの構築、ってことだね。

おねーさん

そういうことね。さて、今回説明するのはその「動的なSAの構築」の方法ね。これはIKEを使って行う。 ▼ link

ほげたん

インターネットキーエクスチェンジ。インターネット鍵交換、アイク?

おねーさん

そう、そのIKE。そのバージョン2、IKEv2を説明するわ。

ほげたん

バージョン1は?

おねーさん

バージョン1、IKEv1はIKEv2と互換性がない別のIKEと思った方がいいわ。で、まぁIPsecの最新バージョンであるIPsecバージョン3はIKEv2を使用するし、IKEv1は拡張のおかげでかなりカオスな規格になっちゃってるし。だからIKEv2だけにしようかな、と。

ほげたん

ふ〜ん。IKEv1って使われてないの?

おねーさん

使われてるけどね。拡張とか無理な標準化のおかげでかなり難解なのよね〜。だからIKEv1はなしで、IKEv2だけ説明しちゃいます。機会があったらIKEv1もやろうかな、って感じかな。で、以後特に明記しない限り「IKE」って書いたら「IKEv2」のことね。

ほげたん

うん、了解。

おねーさん

さて、IKEの中身を説明する前に、IKEを使うタイミングを話さないとね。

[FigureSP24-01:IKEの使用]

ほげたん

ふむふむ、SPDキャッシュになくて、SPD-Sにあって、SADにない場合?

おねーさん

SPDキャッシュにない、ってのはまだセキュリティポリシーが使われたことがない状態ってこと。使われた後、つまりキャッシュに残っているならばそれは既にIKEによりSAが構築された後だから。

ほげたん

んで、SPD-Sにあって、SADにない。SADはSA用のパラメータセットの集合体だから、SA用のパラメータがないってことだよね。

おねーさん

そう、だからIKEによりSAのパラメータを決定する、ってことね。

■ IKEv2の動作

おねーさん

さて、じゃあIKEの動作について話そうかな。まず、IKEが何をするためにあるか、という話から。

ほげたん

それはIPsecのSAのパラメータを合意するためにあるんでしょ?

おねーさん

まぁ、結論から言えばそうね。IKEは2つの事を行う。「相手認証」と「SAの交渉と管理」。

ほげたん

SAの交渉と管理ってのはIPsecのSAのパラメータの合意と管理だよね。相手認証って何?

おねーさん

IKEではSAで使用するパラメータ、暗号化方式とか鍵を決定するでしょ。なので正しい相手とパラメータをやりとりしないと困るわけ。だから、相手の認証機能があるってこと。

ほげたん

ふむふむ、なるほど。

おねーさん

さて、IKEは500/udpのポートを利用するってことはまず知っておいてね。それで、IKEでは3つの交換を行うの

ほげたん

3つの交換? 何を交換するの?

おねーさん

IKEのためのパラメータ交換」「相手認証」「IPsecのためのパラメータ交換」の3つ。

ほげたん

んん? 相手認証とIPsecのためのパラメータ交換はわかるけど、IKEのためのパラメータ交換?

おねーさん

そう、IKEでは相手認証とIPsecのパラメータ交換は暗号化されてやりとりされるの。つまり、IKE用のSAが構築される必要があるのね。それを行うのが「IKEのためのパラメータの交換」。

ほげたん

IKEのためのSA? なんで?

おねーさん

だって、IKEではIPsecのパラメータが、つまり暗号化や認証で使う鍵が交換されるのよ? それが平文で流れちゃったら意味ないでしょ。だから、そのためにIKEでSAを構築してセキュアにやりとりできるようにしないと。

ほげたん

なるほど。そうか、鍵を交換するんだから、セキュアじゃないとまずいよね。

おねーさん

そういうこと。この3つの交換、実際はエラーなどの情報の交換もあるから、IKEでは都合4つの交換があるんだけど、まずこれの名前を覚えてね。

  • IKE_SA_INIT … IKEのSAを構築するためのパラメータの交換
  • IKE_AUTH … 相手認証を行うための交換
  • CREATE_CHILD_SA … IPsecのSAを構築するためのパラメータの交換
  • INFORMATIONAL … エラーや情報、SAの削除のための交換
おねーさん

この4つ。そして、IKE_SA_INITで構築される「IKE用のSA」をIKE_SA、CREATE_CHILD_SAで構築される、「IPsec用のSA」をCHILD_SAと呼ぶ。

[FigureSP24-02:IKEの基本動作]

ほげたん

送信する側がイニシエータ。受け取る側がレスポンダ。で、IKE_SAとCHILD_SA?

おねーさん

IKEから見れば、IKEによって作られるIPsecのSAは子供みたいなもんだから、CHILD_SAって呼ばれてるんじゃないかしら?

ほげたん

ふ〜ん。IKE_SAが作られて、IPsecのパラメータがやりとりされて、CHILD_SAができるって流れなんだね。

おねーさん

そゆことね。詳しい動作は個々の交換のところで話すとして、基本として、IKE_SA_INIT、IKE_AUTH、CREATE_CHILD_SAって順番で、IKE_SAとCHILD_SAが作られるってことね。

ほげたん

了解。2本のSAが作られるんだね。

■ IKEv2ヘッダ

おねーさん

さてさて。このIKEv2でやりとりされるデータ、IKEv2メッセージの中身を確認しましょう。さっきも言ったとおり、IKEv2は500/udpポートを使うので、UDPでカプセル化されるのね。

ほげたん

へぇ、UDPを使うんだね。ってことはレイヤ7プロトコルなんだね、IKEって。IPsecはレイヤ3プロトコルだから、IKEもそうだと思ってたよ。

おねーさん

……、そう言われればそうね。だからIKEv2パケットではなく、IKEv2「メッセージ」なのかな。ともかく、IKEv2メッセージは次のような形ね。

IKEv2メッセージ

[FigureSP24-03:IKEv2メッセージ]

ほげたん

IKEv2ヘッダと、IKEv2ペイロード?

おねーさん

そう、IKEv2ヘッダ必要な数のIKEv2ペイロード。これから成り立つのがIKEv2メッセージね。ペイロードには種類があって、必要なものを必要なだけメッセージに入れるわけ。どんなものがあるかというと、次の表を見てね。

ペイロード番号ペイロードの種類英略語
0ペイロードなし
1〜32IKEv1で使用
33SAペイロードSA
34鍵交換ペイロードKE
35IDペイロード(イニシエータ)IDi
36IDペイロード(レスポンダ)IDr
37証明書ペイロードCERT
38認証要求ペイロードCERTREQ
39認証ペイロードAUTH
40乱数ペイロードNi
41通知ペイロードN
42削除ペイロードD
43ベンダIDペイロードV
44TSペイロード(イニシエータ)TSi
45TSペイロード(レスポンダ)TSr
46暗号化ペイロードE
47設定ペイロードCP
48EAPペイロードEAP
49〜127未割り当て
128〜255プライベート利用

[TableSP24-01:IKEv2ペイロードのタイプ]

ほげたん

……、おね〜さん、見事に意味がわからないよ。

おねーさん

まぁまぁ。つまり、機能に応じて「ペイロード」があって、それを複数運ぶってことね。ほら、DNSメッセージだってリソースレコードを複数入れて運ぶでしょ? あれとおなじってこと。

ほげたん

うん、まぁ、わかるよ。

おねーさん

じゃあ、実際の中身といきましょう。まず、IKEv2ヘッダね。

ビット数フィールド名意味
64IKE_SAイニシエータSPIIKE_SAのSPI値
64IKE_SAレスポンダSPIIKE_SAのSPI値
8次ペイロード番号次のペイロードのペイロード番号
8バージョンIKEのバージョン
8交換タイプ交換の種類
8フラグ3〜5ビット目を使用。I、V、Rビットがある
32メッセージIDメッセージのID
32メッセージ長IKEv2メッセージ全体の長さ

[TableSP24-02:IKEv2ヘッダ]

ほげたん

っていうか、おね〜さん。ヘッダの中身だけみてもいまいちピンとこないよ。

おねーさん

文句が多いわねぇ。ちゃんと説明するから待ってってばてば。ともかく、IKEv2ヘッダは224ビット、28バイト長ね。で、説明するけど、まずSPIね。これはIPsecにもあったSPIと同じ役割ね。

ほげたん

IPsecのSPI? え〜〜っと、セキュリティポリシーのところで出てきたやつかな? パケットが使用しているパラメータをSADから検索するための値?

おねーさん

そう、それね。IKEで使用しているパラメータを決定するための値ってことね。IPsecと違って、イニシエータSPI、レスポンダSPIがあるんだけど、これはこういう作りになっているの。

[FigureSP24-04:イニシエータSPIとレスポンダSPI]

ほげたん

なんか、変なやりとりだね。イニシエータSPIとレスポンダSPIでおなじ値を使えばいいのに。

おねーさん

おね〜さんもそう思わないことはないけど。う〜んと、おね〜さんの想像での解釈でいい? SPIはSA毎に別の値じゃないとダメよね。例えば上の図で、セキュリティゲートウェイYが別のゲートウェイZともIKE_SAを構築してたとする。つまりYには2つのIKE_SAがある。

ほげたん

そうすると、それぞれ別のSPIをつけなきゃダメだよね。

おねーさん

そう、そこで、ゲートウェイXとゲートウェイZがおなじSPIで送ってきちゃったら? SPIを1つだけしか使わないなら、ゲートウェイYで2つのIKE_SAに対し、1つのSPIしかないわけだから、混在しちゃうわよね。

ほげたん

う〜〜〜ん。だから、ゲートウェイが個別にSPIをつける、か。確かにおね〜さんの想像上の解釈であってるかな?

おねーさん

たぶんだからね。あと「交換タイプ」は名前の通り、送信しているIKEv2メッセージがどの交換タイプで使用されているかを示す値ね。

交換タイプ内容
0〜33IKEv1で使用
34IKE_SA_INIT
35IKE_SA_AUTH
36CRATE_CHILD_SA
37INFORMATIONAL
38〜239未割り当て
240〜255プライベート利用

[TableSP24-03:交換タイプ]

おねーさん

あとは、メッセージIDか。これはやりとりするメッセージの順番、といってもいいかな。

[FigureSP24-05:メッセージID]

ほげたん

またなんか変なことしてるね。素直にやりとりしたメッセージの数でいいと思うんだけどな。っていうか、この値何に使うの?

おねーさん

まぁ、シーケンス番号みたいなものよね、やりとりしているメッセージの数だから。リプレイ防御?

ほげたん

リプレイ防御…、まあ確かにその役目にならないこともないかな。

■ IKE_SA_INITでのIKEv2ペイロード

おねーさん

さて、ここでIKEv2ペイロードのフォーマットを全部説明してもいいんだけど。飽きる。

ほげたん

飽きるとか。おね〜さん…。

おねーさん

だってねぇ、10種類以上あるのよ? それのフォーマットを延々と説明しても読み飛ばすだけだってばてば。なので、実際の交換を説明しつつの、フォーマットを説明していこうかな、と。まず、IKE_SA_INIT。

ほげたん

IKE_SAを構築するための交換だよね。

おねーさん

そう。IKE_SAのための交渉と鍵交換を行う交換ね。えっと、ややこしいからイニシエータが送るのを「IKE_SA_INITリクエスト」、レスポンダが返すのを「IKE_SA_INITレスポンス」って呼ぶわね。

ほげたん

リクエストとレスポンスね。了解。

おねーさん

さて、IKE_SA_INITのリクエストとレスポンスで使う、IKEv2ペイロードは3種類+1種類。

IKE_SA_INITメッセージ

[FigureSP24-06:IKE_SA_INITメッセージ]

ほげたん

ええっと、SA「SAペイロード」、KE「鍵交換ペイロード」、N「乱数ペイロード」とCERTREQ「認証要求ペイロード」の3つ+1つだね。

おねーさん

そう。では順番に中身を説明しちゃおうかな。まずIKE_SAのパラメータを交渉する役割がSAペイロード。ここには使用する暗号化や認証などの方式を入れるわけね。その中身はこう。

内容ビット数フィールド名意味
共通ヘッダ8次ペイロード次のペイロードのペイロード番号
1C(Critical)現在はゼロを入れる
7予約-
16ペイロード長IKEのバージョン
プロポーザルプロポーザル
ヘッダ
8次プロポーザル次のプロポーザルの有無
8予約-
16プロポーザル長プロポーザルの長さ
8プロポーザル番号プロポーザルの優先度
8プロトコル使用するプロトコルのID
8SPI長SPIの長さ
8トランスフォーム数トランスフォームの数
32SPISPI(CHILD_SA)
トランスフォーム8次トランスフォーム次のトランスフォームの有無
8予約-
16トランスフォーム長トランスフォームの長さ
8トランスフォームタイプトランスフォームのタイプ
8予約-
16トランスフォームID使用するパラメータのID
可変トランスフォーム属性トランスフォームの属性

[TableSP24-04:SAペイロード]

ほげたん

わわわ。何コレ? プロポーザルとトランスフォーム?

おねーさん

ん〜、ちょっとわかりづらいかな? まずペイロードの共通のヘッダがあって。SAペイロードは複数のプロポーザルから成り、プロポーザルはプロポーザルヘッダと複数のトランスフォームから成るの。図の方がいいわね。

IKE_SA_INITメッセージ

[FigureSP24-07:SAペイロードの構造]

ほげたん

ふむふむ。で、このプロポーザルとトランスフォームって何なの?

おねーさん

トランスフォームが使用するパラメータ。これが複数集まってできるプロポーザルはパラメータセットってわけね。SAペイロードは複数のパラメータセットを送ることができる、ってわけ。

ほげたん

パラメータってどんなの?

おねーさん

トランスフォームの「トランスフォームタイプ」と「トランスフォームID」で指定する、SAに使用する暗号化アルゴリズムなどね。流石に全部説明するのはアレなので、例だしていこうか。

IKE_SA_INITリクエストの例

[FigureSP24-08:IKE_SA_INITリクエストの例]

おねーさん

ちょっとごちゃごちゃしてるけど。えっと、まずこのSAペイロードには、プロポーザルが2つ入ってる。プロポーザル番号1と、プロポーザル番号2ね。で、それぞれ5つと4つのトランスフォームが入ってる、と。

ほげたん

トランスフォームには…、暗号化、PRF、完全性、DHグループ?

おねーさん

うん。たとえば、プロポーザル番号1の1つ目のトランスフォームを見ると、タイプ「暗号化」、ID「ENCR_AES_CBC」だから「暗号化にAESのCBC、鍵長128ビット」を提案しているわけね。トランスフォームのタイプには、次のようなものがある、と。

トランスフォーム番号トランスフォームタイプ内容
1暗号化アルゴリズム使用する暗号化アルゴリズム
2擬似乱数関数(PRF)鍵を生成する際に使用するアルゴリズム
3完全性アルゴリズムメッセージ認証(HMAC)で使用するアルゴリズム
4DHグループDH鍵交換で使用する鍵長
5拡張シーケンス番号IPsecでシーケンス番号の拡張(64ビット化)をするか

[TableSP24-05:トランスフォームタイプ]

ほげたん

う、う〜ん。PRFって何? 例をみると、HMACやAES-XCBC使ってるけど?

おねーさん

PRFは鍵を生成する際に乱数を発生させるために使用するアルゴリズムのこと。HMACを使うと、ビット列ができあがるでしょ? それを鍵として使用するの。

ほげたん

ふ〜ん。なんで普通の擬似乱数発生関数使わないの?

おねーさん

さぁ? たぶん、セキュリティゲートウェイの仕様が違っても、HMACは必ず使えるからそれを擬似乱数発生関数として代用してるのじゃないかしら。想像だけど。

ほげたん

なるほど。で、プロポーザル番号1番には、2つ暗号化のトランスフォームがあるけど?

おねーさん

そういう場合は、先に書かれた方が第一候補、ダメなら次に書かれている方ってことね。ともかく、このIKE_SA_INITでは2つのパラメータセットを提案しているのがわかる? プロポーザル番号1番の「AESまたは3DES、HMAC-SHA1、HMAC-SHA1、RFC4306」のパラメータセットと?

ほげたん

「RC5、AES_XCBC、AES_XCBC、RFC3526」の2つだね。

おねーさん

そう。それでプロポーザル番号が小さい方が優先したいプロポーザルだから、1番のプロポーザルによるパラメータセットが優先で、2つのパラメータセットを提案してる、ってことね。

ほげたん

なるほど。

おねーさん

そして、リクエストを受けたレスポンダはレスポンスを返すんだけど、その際のSAペイロードにはイニシエータが提示したプロポーザル、トランスフォームから使用するものを選んで返すことになるわけ。例えばさっきの図24-08のリクエストに対するレスポンスとして次の図のSAペイロードを返すのね。

IKE_SA_INITレスポンスの例

[FigureSP24-09:IKE_SA_INITレスポンスの例]

ほげたん

これだと、リクエストのプロポーザル1番で、暗号化をAES_CBCのトランスフォームを選んだってことだね。

おねーさん

そゆこと。さて、次の「鍵交換ペイロード」。これはDH鍵交換法で使用する値を入れるペイロードね。

内容ビット数フィールド名意味
共通ヘッダ8次ペイロード次のペイロードのペイロード番号
1C(Critical)現在はゼロを入れる
7予約-
16ペイロード長IKEのバージョン
鍵交換16DHグループプロポーザルで指定しているDHグループ
16予約-
可変鍵交換データDHで使用する鍵データ

[TableSP24-06:鍵交換ペイロード]

ほげたん

DH鍵交換? PKIの公開鍵方式のところで説明した奴だよね。えっと、双方が公開情報と秘密情報を持っていて。公開情報を交換して?

おねーさん

交換した公開情報と秘密情報から同一の鍵データを生成する。その「公開情報の交換」に使うのが「鍵交換ペイロード」

ほげたん

なるほどなるほど。SAペイロードでは暗号化や認証に使う鍵は設定してなかったよね。そうか、この鍵交換ペイロードとDH鍵交換で暗号化や認証に使う鍵を決めるんだ。

おねーさん

そういうこと。鍵の生成は後で話すから、ちょっと待ってね。鍵交換ペイロードで話しておくことがあるとすれば、鍵交換ペイロードの値は「プロポーザルで一番優先度が高いDHグループで使用する値」ってこと。

ほげたん

んん? あ、そうか。プロポーザルで複数のDHグループを指定することができるんだっけ。その中で優先度が最も高いものだけ? たとえば図24-08はプロポーザルが2つあって、それぞれにDHグループが設定してあるよね? その中で1つだけ?

おねーさん

そう、例でいえば「RFC4306」のDHグループで使用する値だけ。もう1つ「RFC3526」のDHグループもプロポーザルで指定しているけど、鍵交換ペイロードで送るのは優先度が高い「RFC4306」だけね。

ほげたん

じゃあ、優先度が低い「RFC3526」の値を使いたかったらどうするの?

おねーさん

その場合、レスポンダがエラーを返して、再送してもらうのよ。さて、あとIKE_SA_INITで使うもう1つのペイロード、「乱数ペイロード」ね。

内容ビット数フィールド名意味
共通ヘッダ8次ペイロード次のペイロードのペイロード番号
1C(Critical)現在はゼロを入れる
7予約-
16ペイロード長IKEのバージョン
乱数可変乱数データ任意の乱数

[TableSP24-07:乱数ペイロード]

ほげたん

乱数しか入ってない、ずいぶんとシンプルなペイロードだね。何に使うの?

おねーさん

鍵を生成するために使うのよ。ともかく、この3つのペイロードでIKE_SA_INITは行われるわけね。認証要求ペイロードはIKE_AUTHのときにまとめて話すわね。

ほげたん

りょ〜かい。

■ IKE_SA_INITの動作

おねーさん

さて。IKE_SA_INITでは、SAペイロードで「SA構築に使用するパラメータ」を、鍵交換・乱数ペイロードで「SAで使用する鍵の生成に必要な値」を運ぶってことがわかった思うけど?

ほげたん

うん。

おねーさん

じゃ、実際の動作を見てみましょう。

[FigureSP24-10:IKE_SA_INIT]

おねーさん

ま、ペイロードの中身がわかればIKE_SA_INITで何が行われているかわかるわよね。

ほげたん

大体ね。で、おね〜さん。鍵を生成するって言ったけど、生成する鍵って「暗号化」の鍵と、「メッセージ認証」の鍵のどっち?

おねーさん

両方。5つの値から、7つの鍵を生成するの。さっきでてきたPRFを使ってね。使用する値と、生成される鍵は次の通り。

  • 鍵生成の値
    1. gxy … 鍵交換ペイロードにより交換された値からDH鍵交換方式によって生成された値
    2. Ni … イニシエータが送信した乱数ペイロードの値
    3. Nr … レスポンダが送信した乱数ペイロードの値
    4. SPIi … イニシエータSPI番号
    5. SPIr … レスポンダSPI番号
  • 生成される鍵
    1. SK_d … CHILD_SA生成の際に使用する
    2. SK_ai … イニシエータが送信するIKEv2メッセージのメッセージ認証に使用する
    3. SK_ar … レスポンダが送信するIKEv2メッセージのメッセージ認証に使用する
    4. SK_ei … イニシエータが送信するIKEv2メッセージの暗号化に使用する
    5. SK_er … レスポンダが送信するIKEv2メッセージの暗号化に使用する
    6. SK_pi … イニシエータが送信するIKEv2メッセージの相手認証に使用する
    7. SK_pr … レスポンダが送信するIKEv2メッセージの相手認証に使用する
ほげたん

へぇ、DH鍵交換で作られる鍵だけじゃなくて、他の値も使うんだね。あと、7つも鍵作るんだ、へ〜。………ちょっと待って、おね〜さん。

おねーさん

何?

ほげたん

「メッセージ認証」「暗号化」「相手認証」で使用する鍵って、イニシエータとレスポンダで違う鍵を使用するの?

おねーさん

そうよ。え〜っと、これを見て?

SAの方向

[FigureSP22-06:SAの方向]

おねーさん

CHILD_SA、つまりIPsecのSAは一方通行で、双方向でやりとりするためにはそれぞれ違うパラメータを持つSAが2つ必要だったでしょ。それと同じように、IKE_SAでもイニシエータ→レスポンダと、レスポンダ→イニシエータでは異なる鍵を使用するの。

ほげたん

なるほど。IKE_SAも一方通行のSAを2本作るってことだね。

おねーさん

う、う〜〜〜ん。一概にそうとも言えないのよね、これが。確かに暗号化・認証に使用する鍵は方向によって異なるからSAが別とも言えるけど。でも、それ以外のパラメータは全く同一でしょ。それにSAを識別するSPIも1つしかないし。

ほげたん

え? イニシエータSPIとレスポンダSPIで2つじゃない?

おねーさん

そういう点で見れば2つだけど、イニシエータはイニシエータSPIのSAとレスポンダSPIのSAという2つという形では使用してないのよね。あくまでもイニシエータはイニシエータSPIしかみないから、SAは1つだけって識別してる。なので、IKE_SAは「双方向」で、「一方通行」のSA、という感じなのかなぁ、って。

ほげたん

SPIやアルゴリズムから見れば「1本」、鍵だけみれば「2本」。う〜〜ん。

おねーさん

あと、IKE_SA_INITではDoS攻撃に対しての防御としてCookieを使ったIKE_SAの構築方法があるの。

ほげたん

DoS? どういうDoS?

おねーさん

送信元IPアドレスを偽装して、IKE_SA_INITリクエストを送るっていうDoS。それにより、IKE_SAを作らさせリソースを消費させるのね。TCP SYN-FLOODに似た攻撃ね。これを防ぐために、「通知ペイロード」にCOOKIEを入れるの。

内容ビット数フィールド名意味
共通ヘッダ8次ペイロード次のペイロードのペイロード番号
1C(Critical)現在はゼロを入れる
7予約-
16ペイロード長IKEのバージョン
通知8プロトコル使用するプロトコル
8SPI長SPIの長さ
16メッセージタイプ使用するメッセージの種類
32SPISAのSPI
可変通知データ通知するデータ

[TableSP24-08:通知ペイロード]

おねーさん

動作はこんな感じ。

[FigureSP24-11:Cookieの利用による防御]

おねーさん

つまり、IKE_SA_INITリクエストが正規のセキュリティゲートウェイのものかわからないし、リクエスト→レスポンスでIKE_SAが簡単に構築されちゃうのが問題だったわけ。

ほげたん

ふむふむ。なので、IKE_SAの構築の前にひと手間入れて、簡単な認証をやった感じだね。

おねーさん

そういうことね。さて、これでIKE_SAが構築されて、さぁCHILD_SAの構築なんだけど。随分長くなったからそれはまた次回にしましょ。IKEの役割と、IKE_SAの構築はわかった、ほげたん?

ほげたん

ん、まぁだいたいは。

おねーさん

じゃあ次回は残りの、IKE_AUTHとCREATE_CHILD_SAを説明しましょ。また次回っと。
おね〜さんと、

ほげたん

ほげたんのっ!!

おねーさん

3分間ネットワーク、

ほげたん

サプリメントでした〜〜〜っ!!

IKE
[Internet Key Exchange]。読みは「アイク」。IKEバージョン2(IKEv2)はRFC4306で規定。
イニシエータ
[Initiator]。始動者とも呼ぶ。
レスポンダ
[Resopnder]。応答者とも呼ぶ。
PRF
[Pseudo-Random Function]
DoS攻撃
[Denial of Service Attack]。サービス拒否攻撃、またはサービス妨害攻撃。大量のリクエストなどを送信し、負荷を増大させることによりサービスを使用できなくさせる攻撃。
TCP SYN-FLOOD
TCPハーフオープン攻撃とも呼ぶ。スリーウェイハンドシェイクのSYNだけを送信し、受信側をACK+SYN後のACK待ち状態にしリソースを消費させる攻撃。
ほげたんほげたんの今日のポイント
  • IPsecのSAのためのパラメータを動的に決定するのがIKE。
  • IKEにはIKEバージョン1とバージョン2があり、互換性がない。
  • IKEv2では3つの交換により、IPsecのSAを構築する。
  • IKEv2メッセージはヘッダとペイロードからなる。
  • IKEv2ではIKE_SAとCHILD_SAの2つのSAを構築する。
  • IKE_SAを構築するのがIKE_SA_INIT。
    • SAペイロードで使用するアルゴリズムを決定する。
    • 鍵交換・乱数ペイロードで鍵生成に必要な値を交換する。

3 Minutes NetWorking Supplement No.24

管理人:aji-ssz(at)selene.is.dream.jp