■ SAの構築

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

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

IPsecを行うために、そこで使用する「パラメータの合意」による「セキュアな仮想的な通信路」が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を使うタイミングを話さないとね。

ふむふむ、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つの交換があるんだけど、まずこれの名前を覚えてね。

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

送信する側がイニシエータ。受け取る側がレスポンダ。で、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ヘッダと、IKEv2ペイロード？

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

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

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

うん、まぁ、わかるよ。

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

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

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

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

そう、それね。IKEで使用しているパラメータを決定するための値ってことね。IPsecと違って、イニシエータ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メッセージがどの交換タイプで使用されているかを示す値ね。

あとは、メッセージ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種類。

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

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

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

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

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

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

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

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

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

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

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

う、う〜ん。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ペイロードを返すのね。

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

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

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

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

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

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

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

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

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

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

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

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

りょ〜かい。

■ IKE_SA_INITの動作

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

うん。

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

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

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

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

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

何？

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

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

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を入れるの。

動作はこんな感じ。

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

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

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

ん、まぁだいたいは。

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

ほげたんのっ!!

3分間ネットワーク、

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