要約

  • RFC 9838の基本的なforward access controlでは、所属変更のrekeyがまず新しいKEKを作り、その後のrekeyが新KEKの下でTEKポリシーと鍵を届ける。
  • マルチキャストGSA_REKEYには応答がなく、失われ得る。同一暗号文の反復送信やGSA_NEXT_SPIは回復を助けるが、全メンバーの導入済み状態を証明しない。
  • ATDは新SAの利用を遅らせ、DTDは旧SAの削除を遅らせる。排除の証拠は、この意図的な重複期間を含まなければならない。

管理画面に「削除済み」と表示された時点は、権限判断の時刻である。旧鍵が最後に機能した時刻ではない。

RFC 9838は、IKEv2を使うグループ鍵管理G-IKEv2を規定する。RFC Editorの記録では2025年11月発行、Standards Track、RFC 6407を廃止とされる。これは仕様の成立を示すが、実装や排除成功を示さない。

基礎にはRFC 3740、RFC 4046、RFC 5374のMSECアーキテクチャがある。Group Controller/Key Server（GCKS）はGroup Member（GM）を認証・認可し、Data-Security SAや必要ならMulticast Rekey SAのポリシーと鍵を含むGroup Security Associationを渡す。

登録が初期状態を作り、rekeyが状態を変える。IKEv2は二者間の安全な関係を、IPsec、AH、ESPはSAとパケット保護を定める。グループでは、一つの送信に全員が応答するとは限らない。

排除を始めるメッセージは旧KEKで読める

forward access controlは、外されたメンバーに新しいグループ鍵を与えない性質である。backward access controlは、新参加者に古い鍵を与えない性質である。RFC 9838は、どちらもIKEv2のPerfect Forward Secrecyとは別だと明記する。

所属を変更するrekeyは現行KEKで保護される。その中に新しいTEKポリシーと鍵を入れれば、削除対象も読めてしまう。そのためforward access controlが必要な場合、最初のメッセージに新TEKを含めてはならない。新KEKで保護された二通目がTEKを届ける。

変更後ポリシー自体も隠すなら、GCKSはKEKを変更するrekeyを二つ続けて送る。第一段で対象外の新KEKを作り、第二段で再びKEKを変更しながら新ポリシーを送る。新KEKなしのポリシー変更は禁止される。

二通は永遠の普遍則ではない。単一メッセージでも性質を維持する方法を明記すれば、将来のLKH等は制約を外せる。RFC 2627は論理鍵階層の背景を示す。ここで検証すべきなのは、RFC 9838の基本手順を採用した実装の二段階である。

再送回数は受信確認の数ではない

GCKSはunicast in-band rekeyか、マルチキャストGSA_REKEYを使える。後者は一方向の擬似exchangeで、acknowledgementがない。ネットワークが捨てれば、正規メンバーが旧ポリシーに残る。

損失を和らげるため、数秒以内に暗号化済みの完全同一メッセージを複数回送れる。またGSA_NEXT_SPIで将来のSPIを知らせ、受信者が飛びを検出して回復できる。これは配送可能性を高めるが、沈黙した端末の導入状態は返さない。

RFC 7383のIKE fragmentationにも同じ制約が表れる。応答がないので、まず非分割で試すことも、応答型PMTUで閾値を学ぶこともできない。事前設定値が必要であり、グループ規模や鍵階層が排除メッセージの到達性を左右する。

継続性のための重なりはリスクでもある

Activation Time Delay（ATD）は、新SAを受け取った送信者が利用開始まで待つ時間である。Deactivation Time Delay（DTD）は、削除要求後も旧Data-Security SAを保持する時間である。可用性を守る仕組みだが、「削除」の実効時刻を一つにできない。

記録は少なくとも、認可取消、新KEK生成、新TEK導入、新SA有効化、旧SA削除を分けるべきだ。削除済み資格での最後の通信試験を加えれば、動作上の境界を測れる。

counter modeにはSender-IDとnonceの台帳が要る。RFC 6054を踏まえ、RFC 9838は送信者ごとに固有IDを割り当て、登録のたびに新IDを渡す。GCKSは端末が使用済みのnonceを確実には把握できないからだ。ID空間が尽きれば全員を除外し、新Data-Security SAで再登録させる。RFC 8221やRFC 8750も、この状態管理を代替しない。

replay protectionも一律ではない。複数送信者が一つのSAを共有すると、それぞれが独立にsequence numberを進め、共通windowを作れない場合がある。受信者がローカルに検査可否を決め、必要ならGCKSが送信者別SAへ分離する。

IANA IKEv2レジストリは割当値を、RFC 8174はMUST等の規範語を、RFC 6407は旧仕様を記録する。どれも個別端末の導入証跡ではない。

Heng Luの最小初期仕様と局所的な将来判断は、標準に安全な意味を、運用者に期限と測定責任を置く。running-code primacyなら、チケットより導入鍵と実測通信が強い証拠になる。現実を製品とする報道は、Standards Trackを導入保証に言い換えない。

出典