要約

  • RFC 2085 の64ビット Replay Prevention フィールドは SA ごとの選択であり、SPI がフィールドの有無を含む処理状態を選んだ。
  • カウンターは1から始まり、同じ鍵の下で周回してはならない。窓の深さは各受信者が決めても、受理済みの値は二度と受理できない。
  • 正しい HMAC と未受信番号が示すのは共有 SA の下での局所的な受理可能性であり、マルチキャスト送信者、世界共通の時刻、配送、権限、アプリケーション結果ではない。

正しい認証値を持つ IP パケットでも、回線から複製された古いパケットかもしれない。バイトが同じなら MAC は再び一致する。RFC 2085 は狭い対策を示した。カウンターも認証対象に入れ、受信者が一度許可した値を覚える方式である。

SPI がフィールドの存在を選んだ

オプションの64ビット値は SPI と Authentication Data の間に置かれた。リプレイ防止を使わない SA では、認証データが SPI の直後に来た。RFC 1826 では、受信者は SPI から一方向 SA のアルゴリズム、鍵、モード、状態を検索する。SPI は人の身元ではなく、処理契約の選択子だった。

カウンターは1から増加し、一つの共有鍵は 2^64 の周回前に交換する必要があった。存在する値は HMAC に含まれるため、鍵を持たない者は古い番号だけを新しくして認証を維持できない。それでも認証と新鮮さは別である。HMAC はパケットと番号を共有秘密に結び付け、受信者の履歴がその認証済み番号をまだ許可できるか決めた。

増加は順番どおりの到着を意味しなかった

RFC は順不同を認め、許容幅を実装に委ねた。固定された条件は、窓内で受理する値が過去に受理されていないことだった。

最大値より小さくても、窓内で seen 状態が空なら正当な遅延パケットになり得る。左端より古ければ拒否し、印があれば重複し、右端を超える認証済み値なら窓を進められる。RFC 6479 は後に範囲と受信ビットとしてこの機構を説明し、並列暗号処理が大きな窓を必要とし得ることを示した。

窓は受信者の局所政策であり、世界時計ではない。二つの受信者は同じ流れを別順序で見て、違う幅を使える。欠番は損失を証明せず、遅着は攻撃を証明せず、A の受理は B の受理を証明しない。正確な証拠は「この SA とこの状態では、この認証番号をまだ受理していなかった」である。

共有マルチキャスト SA は系譜を失った

RFC 2085 は限界も明記した。複数送信者が同じマルチキャスト宛て SA を共有するなら replay protection を有効にすべきではなく、必要なら送信者ごとに SA を分けるべきだとした。

HMAC が壊れるのではない。共有秘密の全保持者が正しい値を作れる。失われるのは番号の所有者である。各送信者が1から始めれば直ちに衝突する。各ローカルカウンターが正常に増えても、合成流は同じ値を繰り返す。RFC 2085 は複数送信者へ重ならない番号を割り当てる仕組みを定義しなかった。

送信者別 SA は SPI によって正しい履歴を選び、系譜を回復する。リプレイ検査を止める選択は、グループ認証は残るが初回利用は判断できないと認める選択だった。

RFC 4302 は後に必須 Sequence Number と論理64ビット ESN を導入しつつ、multi-sender SA に標準内の anti-replay 機構がないという境界を維持した。ただし RFC 2085 のワイヤ形式は、オプションの64ビット値を直接送信していた。

共有 MAC は鍵保持を示し、唯一の話者を示さない

RFC 1826 は、対称鍵の保持者が別の正当参加者に見えるトラフィックも作れると警告した。HMAC 成功は共有秘密の保持と対象バイトの完全性を示すが、グループ内の誰が話したかは区別しない。

カウンターはその後の受理を狭めるだけで、集団秘密を個人署名に変えない。AH は機密性も与えない。SA に対して真正で窓に対して新鮮なパケットでも、アプリケーション権限、配送、永続的な効果は別問題である。

監査では SA 検索、フィールド有無、番号、窓位置、seen 状態、HMAC、受理、上位層受信、権限、確定効果を分けるべきだ。カウンターが示したのは送信者の名ではなく、一受信者の受理履歴上の位置だった。

出典