念のため、質問のあとにページ番号を入れていますが、回答可能であれば、特にこの本に即している必要はありません。
①手動管理だと、リプレイ防止機能が使えないのはなぜでしょうか？カウンターがフルになるとリセットするため、古いパケットが再送されても見分けがつかなくなるという説明を読みましたが、それは手動でもIKEでも同じことではないのでしょうか？
(p22)
②RFC4301において、IKE v1のISAKMPと異なり、IKE v2のIKE_SAは一方向のSAの2本のペアとなっています。CHILD_SAも一方向のSAの2本のペアと理解しています。
そうすると、IKE_SA_INIT、IKE_AUTHでイニシエータが提示する複数のアルゴリズムの組み合わせから、イニシエータ→レスポンダ用とレスポンダ→イニシエータ用の「２つのSA」を、レスポンダは選択して、レスポンスのメッセージとしてProposalを２つ返すのでしょうか？(p241)
以上です。よろしくお願いいたします。
No.1
175
29
35pt
最初の質問だけですが、ぐぐってみたところ、こんな RFC がありました。
http://www.ipa.go.jp/security/rfc/RFC2402JA.html#2.5
これによると、
ということのようです。つまり、おっしゃるとおり「カウンタがゼロに戻るならリプレイ防御ができない」のです。
それで、IKE があれば SA を使い捨てにできるため、カウンタが限界にいく前に新しい SA でゼロからやり直せるわけですね。
この場合、使っている鍵は新しいわけですから、リプレイしたところで無意味です。
No.2
17529
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 が二つぶんのアルゴリズムを返すとは書いていないようですね。
ご紹介ありがとうございます。
あとでじっくり該当箇所を見てみますが、そうすると、いつイニシエータ→レスポンダ、レスポンダ→イニシエータの別々のSAを交換するのか疑問です。。。
9
9
2
1
1
ご回答ありがとうございます。
IKEだとカウンタがフルになる前にリキーを行うということで、リプレイ攻撃防御機能が有効に働くという論理が理解できました。
ご紹介いただいたRFCはAHのものですが、プロトコルに依存する話でもないと思いますので、論理は同じでしょうね。