IPsec、IKE v2についての質問です。参考図書はマスタリングTCP/IP IPsec編を使用しています。

念のため、質問のあとにページ番号を入れていますが、回答可能であれば、特にこの本に即している必要はありません。

①手動管理だと、リプレイ防止機能が使えないのはなぜでしょうか?カウンターがフルになるとリセットするため、古いパケットが再送されても見分けがつかなくなるという説明を読みましたが、それは手動でもIKEでも同じことではないのでしょうか?
(p22)

②RFC4301において、IKE v1のISAKMPと異なり、IKE v2のIKE_SAは一方向のSAの2本のペアとなっています。CHILD_SAも一方向のSAの2本のペアと理解しています。
そうすると、IKE_SA_INIT、IKE_AUTHでイニシエータが提示する複数のアルゴリズムの組み合わせから、イニシエータ→レスポンダ用とレスポンダ→イニシエータ用の「2つのSA」を、レスポンダは選択して、レスポンスのメッセージとしてProposalを2つ返すのでしょうか?(p241)

以上です。よろしくお願いいたします。

回答の条件
  • 1人2回まで
  • 登録:2006/08/29 11:19:52
  • 終了:2006/09/05 11:20:05

回答(2件)

id:ttamo No.1

たも回答回数175ベストアンサー獲得回数292006/08/29 17:49:52

ポイント35pt

最初の質問だけですが、ぐぐってみたところ、こんな RFC がありました。

http://www.ipa.go.jp/security/rfc/RFC2402JA.html#2.5


これによると、

  • IKE: カウンタがあふれそうになったら、新しい鍵で SA を再確立する。
  • 手動の場合: 再確立する手段がない。だからあふれたらカウンタをゼロにするだけ。

ということのようです。つまり、おっしゃるとおり「カウンタがゼロに戻るならリプレイ防御ができない」のです。

それで、IKE があれば SA を使い捨てにできるため、カウンタが限界にいく前に新しい SA でゼロからやり直せるわけですね。

この場合、使っている鍵は新しいわけですから、リプレイしたところで無意味です。

id:blueblue

ご回答ありがとうございます。

IKEだとカウンタがフルになる前にリキーを行うということで、リプレイ攻撃防御機能が有効に働くという論理が理解できました。

ご紹介いただいたRFCはAHのものですが、プロトコルに依存する話でもないと思いますので、論理は同じでしょうね。

2006/08/30 11:18:10
id:ttamo No.2

たも回答回数175ベストアンサー獲得回数292006/08/29 22:24:56

ポイント35pt

二度目の回答ごめんなさい。

IKEv2 の initiator/responder 間における具体的なやりとりについては

http://www.ipa.go.jp/security/rfc/RFC4306EN.html#102

(IKE_SA_INIT と IKE_AUTH)

http://www.ipa.go.jp/security/rfc/RFC4306EN.html#103

(CREATE_CHILD_SA)

にわかりやすく図示されています。

IKE_SA_INIT や IKE_AUTH が二つぶんのアルゴリズムを返すとは書いていないようですね。

id:blueblue

ご紹介ありがとうございます。

あとでじっくり該当箇所を見てみますが、そうすると、いつイニシエータ→レスポンダ、レスポンダ→イニシエータの別々のSAを交換するのか疑問です。。。

2006/08/30 11:22:14

コメントはまだありません

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません