要約

  • 共通 group key の MAC を検証できても、鍵を持つ全メンバーが同じ tag を生成できるため、特定の Group Sender の証明にはならない。
  • 個別の data-origin authentication には digital signature や TESLA が必要で、anti-replay state も送信者単位の別問題である。
  • 認証済み GCKS の権限は GPAD が group identifier と traffic selector に限定し、address preservation は routing 用の構造整合性だけを検証する。

replay window が示す信頼モデル

RFC 5374 は複数の Group Sender がいる場合、通常は送信者ごとに IPsec SA を持たせる。sequence number と anti-replay state を混ぜないためだ。全送信者が一つの SA を共有できるのは、IPsec の anti-replay service に依存しない場合に限られる。

この条件は単なる実装上の注意ではない。同じ暗号検証に成功した二つの packet が、同じ送信者の再送なのか、別の正当な送信者による新規送信なのかを判定するには、誰の state を参照するかが必要になる。共有 SA はその境界を弱くする。

大規模 ASM では、receiver が全ての潜在 sender の state を持つことが現実的でない場合がある。RFC は、その規模でも replay rejection が必要なら、application-layer multicast protocol を検討するよう述べる。暗号 tag の有効性と時系列上の一意性は別の証拠だ。

共通 MAC が証明するのは鍵の集合

二者間の MAC は、相手だけがもう一人の鍵保持者だという前提で起源の手掛かりになる。group では前提が違う。全メンバーが verification key と生成能力を共有する。valid tag は「この group secret を使える誰か」を示すが、その誰かを一人に絞れない。

RFC 5374 は group source authentication と data origin authentication を区別する。前者は外部者の改ざんを排除する強い価値を持つ。後者は、claimed sender が message を作ったと receiver が確信できる性質である。source address をログに添えても、内部者が peer に見える packet を生成できる事実は消えない。

個別起源が必要なら digital signature または TESLA のような仕組みを追加する。signature verification は高コストになり得るため、外側の共通 MAC で outsider を先に落とし、内側で高価な origin proof を検証する二重 encapsulation も示される。

外側成功は group credential、内側成功は individual origin についての receipt である。payload の正しさ、業務命令の権限、application の実行結果はさらに上の層に残る。

GCKS にも local mandate があった

Group Controller/Key Server は policy と keying material を配る。しかし認証できた controller が、任意の group や flow を支配できるわけではない。各 member の GPAD は、許可する GCKS identity、認証方式、Group Identifier、source/destination selector の範囲を保持する。

registration ではまず asserted identity を認証する。その後、その GCKS が対象 group を担当できるかを調べる。届いた SA policy の各 data flow は local range と比較され、範囲外なら破棄され、理由を audit log に残すべきとされる。

credential validity と jurisdiction は別だ。前者が正しくても後者は拒否できる。これにより、controller の交代、複数 controller への分担、protocol version の更新を、権限範囲の自動拡張なしに行える。

tunnel の address equality は本人確認ではない

multicast routing は outer destination に group address が見えることを必要とする。SSM tree や RPF check は source にも依存し得る。そこで address preservation は inner destination と、必要なら inner source を outer header にコピーする。

受信側は保存対象の外側と内側を比較し、不一致を破棄して監査する。この検査は、routing が見た group と保護された内側 group が同じだという構造的事実を守る。

address ownership、device control、human identity、delivery は証明しない。さらに source preservation により、gateway 自身へ向かう ICMP Path MTU message が届かないこともある。routing compatibility は有用だが、万能な security assertion ではない。

SSM sender が NAT、mobility、multihoming で locator を変えると、GSPD は古くなる。新 source が BYPASS に落ちれば data leak になり得るため、RFC は未許可 source を default DISCARD にするよう勧める。過去の sender authorization は未来の locator 全てへの白紙委任ではない。

group に入る三つの意味

IGMP/MLD join は routing interest であり、GKM registration の trigger にはなっても application membership の認証ではない。GKM により group key を得ることは cryptographic membership だが、必ずしも sender role を与えない。GSPD の sender only、receiver only、symmetric がその差を保持する。

そして packet が receiver の IPsec boundary を通っても、全 branch の delivery は保証されない。中間 router は IPsec に参加する必要がなく、侵害された router は downstream traffic を消せる。route observation と application acknowledgement は別に集めなければならない。

証拠の境界

監査記録には GCKS identity と認証結果、GPAD entry、Group Identifier、許可 selector、受領 policy と採否理由を残す。member role、GSA/SA、SPI、algorithm、key epoch、sender 別 replay state も必要だ。

packet 単位では shared-MAC verification と signature/TESLA verification を別項目にし、inner/outer address と比較結果を保持する。routing、application receipt、content approval、business action はそれぞれ独立した event とする。

この分離により、「現行 group key の下で有効だった」と正確に言える。特定の sender への帰属は、その先の証拠がある場合だけだ。