要約

  • RFC 1446では、SNMPv2 partyが自分の秘密値を先に更新し、新しい値で応答を作る一方、管理局は応答受信まで古い値を正としていた。
  • 応答がない場合、要求未達と、更新済みだが応答だけ喪失した場合を区別できず、秘密値そのものも読み戻せなかった。
  • 認識可能な公開値が別の証拠となり、解決まで管理局は古い鍵と新しい鍵を再起動後も保持する必要があった。

順序が認証を追い越した

RFC 1446で既存の秘密を変えるとき、責任を持つ管理局は新しい値を生成し、保護されたsetRequestを送る。受信側は要求を処理して応答する。管理局側のローカル表が新しい値になるのは、応答を受けた後である。

同じpartyが自分の秘密を変える場合、受信側の書き込みが先に起きる。続く応答は新しい秘密に従って作られる。しかし検証側は古い秘密のままだ。移行中の二候補を扱わなければ、真正な応答を不真正として捨てかねない。

要求生成、配達、遠隔書き込み、応答生成、応答配達、応答受理は別々の事実である。一つのdigestがその全てを同時に証明するわけではない。

返答なしは一つの状態ではない

応答が届かなければ、要求自体が失われた可能性がある。この場合は両端とも旧鍵である。もう一つは、要求が届いて鍵が変わり、帰りの応答だけが失われた場合だ。こちらではエージェントだけが新鍵へ進んでいる。

旧鍵で単純に再送すると、最初の更新が成功したからこそ認証に失敗することがある。その失敗をネットワーク障害や攻撃の証拠へ直結させることはできない。

秘密値は読み出せない。保護すべき鍵を照合のために取得できれば設計が矛盾するからだ。観測面を閉じた以上、別の読める証拠が必要になった。

RFC Editorの記録ではRFC 1446はHistoricである。MD5とDESは1993年の選択としてのみ扱うべきで、現在の暗号運用を勧める根拠ではない。残る論点は、更新と確認の非同期性だ。

秘密を見せずに更新を見せる

RFC 1446は、秘密更新と同時に、識別しやすい新規の公開値も書く方法を勧めた。認証秘密なら公開認証値、privacy秘密なら公開privacy値を変える。応答がなければ、その値を読み戻す。

RFC 1447のParty MIBは、privateとpublicの各項目、party固有時計、lifetimeを分けた。公開マーカーは秘密の一部ではない。見えない更新に対応させた、読める取引証跡である。

マーカー一致が示す範囲も限定される。対象がその更新を処理したことは支えるが、管理局表の更新、再起動後の保持、次の要求の認可、機器や回線への効果までは示さない。

二つの候補を再起動の向こうへ運ぶ

要求送信から確認まで、管理局は旧秘密と新秘密を両方追跡しなければならない。遅延の原因はネットワーク障害かもしれず、長引く可能性がある。RFC 1446は再起動を越えた保持まで求めた。

コントローラが望む結果だけを保存するのは危険だ。要求未達なのに旧鍵を消せば戻れない。更新済みなのに新鍵を失っても戻れない。未確定取引は単なる再試行対象ではなく、二つの遠隔状態を抱える。

crash recoveryではparty identity、authentication clock、private authentication key、private privacy keyに不揮発で壊れない表現が必要とされた。時計は停電後も後退してはならない。時刻状態を失えば、正しい通信が許容窓の外へ落ちる。

プロセスが起動しただけでは関係は復旧しない。identity、時計、二候補の秘密、lifetime、公開マーカーを両端で再び一致させる作業が残る。

認証はメッセージ順序を作らない

共有秘密によるdigestはoriginとintegrityを支え、時計とlifetimeは過度な遅延やreplayを抑えた。しかし削除や抑止は防がない。RFCは、認証付き通信への無応答をエージェントまたはネットワーク障害の決定的証拠にしてはならないとした。時計ずれや秘密の不一致で、失敗通知さえ失われ得る。

状態変更メッセージにも一般的順序はない。前の肯定応答または期限切れまで次を待つべきだとされた。RFC 1450のSNMPv2 MIBにあるsnmpSetSerialNoはSet処理の順序を助ける別機構で、永続化や作用の証明ではない。

RFC 1445の管理モデルはparty、context、access policyを置いた。メッセージ認証が通ることと、対象objectへの認可、書き込みの定着、運用結果は同じ判定ではない。

公開マーカーはUSMにも残った

party方式は最終形ではなかった。RFC 1910はuser、agent identity、boot count、time window、access policyへ構成を動かした。RFC 2574と後継のRFC 3414はSNMPv3のUSMを定めた。

後の仕組みでも、読めない鍵を一方向のKeyChangeで更新し、spin lockで競合を抑え、usmUserPublicにrandom markerを置いた。応答がなければ公開値をGETし、要求喪失か応答喪失かを判断する。

これは古い方式の継続採用を意味しない。秘密を不信頼な通信路越しに更新するとき、応答とは独立した観測証拠が必要だという設計課題が残ったのである。

出典