要約

  • RFC 7474は、32-bitのboot countと32-bitのpacket counterを一つの64-bit sequenceにする。前者は不揮発性storageに残り、後者は送信ごとに増え、receiverはpacket typeごとに直前の受理値を超えないpacketをreplayとして捨てる。
  • Acee Lindemは、Manav Bhatia、Sam Hartman、Dacheng Zhangと共同で作られた標準のeditorである。永続履歴をrepairやreplacementで失えば旧keyも交換しなければならず、通常のrolloverもsend/accept lifetimeと両端の実選択を証明して初めて成立する。

偽物ではなく、古い本物

有効なOSPF Database Description packetを誰かが記録したとする。keyを知らないため改ざんも新規作成もできない。receiverがより大きいsequenceを保持している間、その記録は役に立たない。ところがadjacencyが消え、processが再起動し、neighborに結び付いたvolatile stateが初期化される。packetに新しい権限が加わったのではない。検証側が古さを忘れたのである。

2015年4月にStandards Trackとして公開されたRFC 7474は、この境界を修正する。それ以前のOSPFv2 cryptographic authenticationでは、sequence stateがneighbor adjacency stateの一部だった。adjacencyが落ちると値が再初期化され、digestが正しくても、過去のsessionから持ち込まれたpacketを見分けられない余地があった。

著者はManav Bhatia、Sam Hartman、Dacheng Zhang、editorのAcee Lindemである。IETF DatatrackerはLindemの参加と広いrouting RFC記録を確認できるが、単独発明、OSPFの所有、implementation品質を証明しない。確認できる意味は限定的だ。再起動で消えていたsecurity chronologyを、共同標準の一員として永続化した。

強いhashだけでは「いつ」を答えられない

RFC 5709はOSPFv2にHMAC-SHAを導入した。著者はManav Bhatia、Vishwas Manral、Michael Fanto、Russ White、Michael Barnes、Tony Li、Randall Atkinsonで、Lindemではない。forgeへの耐性は高まっても、過去に正しく生成されたpacketが自動的に期限切れになるわけではない。

RFC 6039はVishwas Manral、Manav Bhatia、Joel Jaeggli、Russ Whiteが、routing protocolのmanual keyに関する長期secret、rollover、replay、context不足を整理した文書である。ここではthreat modelとして使い、Lindemの著作とは扱わない。

運用画面の「authentication success」は、protected bytesとkeyの整合を示すにすぎない。そのpacketが現在のboot epochに属するか、neighbor識別に使うsourceから来たか、OSPFv2というdomainで使われたkeyかは別の証拠である。integrity、freshness、contextを一つのgreen badgeに潰してはいけない。

暗転を越えるepoch

RFC 7474はcryptographic sequenceを64 bitへ拡張する。上位32 bitはboot count、下位32 bitは厳密に増えるpacket counterである。上位がprotocol lifeのepochを表し、下位がその中の位置を表す。

boot countはOSPFv2 routerのdeployment life全体で不揮発性storageに保持する。cold restartを含め、以前のpacket sequence stateを失うたびにincrementする。SNMPv3のsnmpEngineBootsを利用してもよいが、SNMPとOSPFは異なる理由で再初期化されるため、OSPF専用countが推奨される。

下位counterはpacket送信ごとに進む。receiverは、そのneighborから受け入れた同じOSPF packet typeの直前値より大きいことを要求する。大きくなければreplayとしてdropする。type別に比較するのは、priority処理によりHelloとLink State Updateなどの到着順が入れ替わる可能性があるからだ。

下位32 bitがwrapするときは上位を進め、aggregateの単調性を守れる。再起動を隠すのではない。再起動そのものを認証されたepoch changeに変え、古いcaptureが追い越せないようにする。

64-bit sequenceはOSPF packetの後ろ8 octetに置かれ、digestに含まれる。Authentication type 3が新形式を示し、Key IDは32 bitへ拡張される。epochが認証外なら書き換えられ、typeを分けなければ正当なreorderを攻撃と誤る。packet layoutもsecurity contractである。

IP sourceをneighbor証明へ入れる

従来の計算はIPv4 headerを覆っていなかった。しかしbroadcastやNBMA networkでは、OSPFはIP source addressから送信neighborを判定する。captureのsourceだけを変えられると、digestを壊さず別neighborのreceive sequence stateへ影響を与えられた。

RFC 7474はRFC 5709のauthentication paddingの先頭4 octetにIPv4 sourceを入れる。senderは使用予定のaddress、receiverは実際に届いたaddressを使う。sourceを変更すればauthentication failureになる。one-wayに見せるreflectionやDatabase Description exchangeの妨害が対象である。

全IPv4 fieldを固定する設計ではない。OSPFがneighbor identityに使う一つの事実を保護する。共有すべき最小意味を選び、その外側の運用判断を奪わない設計になっている。

secretにprotocol domainを付ける

long-lived key databaseでは、同じsecretが複数protocolに使われることがある。domain separationがなければ、別用途のvalid constructionがOSPFv2へ移される余地ができる。RFC 7474はkeyを使う前に2-octetのOSPFv2 Cryptographic Protocol IDを追加する。

storage上のsecretが同一でも、effective contextはOSPFv2に限定される。ただしkey共有を推奨する規則ではない。underlying secretのcompromiseは依然として共通であり、独立keyのほうがblast radiusは小さい。protocol IDは共有基盤に境界を足すもので、共有を安全運用の証明にはしない。

rolloverは瞬間ではなく重なり

送信keyはSendLifetime、受信keyはAcceptLifetimeの範囲でのみ有効になる。二つは同じでなくてよい。新keyを先にacceptし、後でsend preferenceを移し、旧keyを限られた時間だけacceptし続ければ、全routerが同じ瞬間に切り替わらなくてもadjacencyを守れる。

選択にはalgorithm、peerまたはarea、interface、directionも使う。明示matchはallより優先される。複数の送信keyが残れば、send startが最も新しいものを選び、段階的rolloverを実現する。packetの32-bit Key IDは受信key探索に使うが、receiverはscopeとaccept windowも確認する。

したがって、変更手順は配布、accept開始、send移行、両端観測、旧accept終了となる。configにkeyが二つ見えるだけでは、window overlap、clock、実際の選択を証明できない。

compatibilityは明確な拒否として現れる

Authentication type 3はsilent downgradeしない。interfaceに設定されたtypeと受信typeが違えば、既存OSPF ruleでpacketを捨てる。partial rolloutではadjacencyが上がらないかもしれない。しかし、両端がfreshnessを別の意味で解釈しながらFullになるより安全である。

change unitは両端を含む。compatible code、type、algorithm、Key ID、secret、lifetime、epochが揃う必要がある。最初のrouterでconfig saveが成功しても移行は終わらない。新packetの相互受理、旧captureの拒否、安定したadjacency、実forwardingまでがgateである。

boot historyを失えばkeyも過去になる

RFC 7474の最も厳しい規則はrepair、upgrade、replacementにある。不揮発性boot countを失った場合、authentication keyを変更しなければならない。同じRouter ID、area、address、secret fileをrestoreしても、今日のpacketを昨日から分けたepochはrestoreされない。

古いkeyとresetされたepochを組み合わせると、過去のcaptureが新しい低sequence空間へ戻る。hardware replacementはconfiguration作業だけでなく、cryptographic lifecycle eventになる。

残る限界も明記されている。完全にserviceから外れたrouterについて、同一のsession establishment全体をreplayする余地は極めて小さいが残る。rekeyはそれも止める。同一source IPと一つのsequenceを二本のunnumbered point-to-point linkで使い、active tapの脅威があるなら、interfaceごとに別keyが推奨される。automatic key managementはscope外である。

小さな共有規則と、localなcustody

Lu Hengの後年のMinimum Initial Specification, Localized Future Decision, and Voluntary Adoptionは、Sofia Renの分析枠として使える。sequence form、authenticated source、protocol ID、Key ID、reject semanticsは共有する。key生成、保管、interface scope、rollout unit、clock、recoveryは各networkが決める。

Running-Code Primacyは、persistent count、送信sequence、選択key、source-bound digest、受信判断、replay drop、adjacency、forwardingを一つのproof chainにする。この比較はSofia Renによる後年の分析であり、Lindemの私的意図やRFCを超えるIETF意図ではない。

攻撃者はrouterより長く過去を覚えられる。RFC 7474は、その非対称を逆転させようとする。routerが自分の過去を証明できないなら、古いkeyも新しい生を認証してはならない。

情報源