要約

  • RFC 9918はNETCONF over TLSの相互認証を維持し、信頼リストのCAがNETCONFアクセスを許された主体だけに証明書を発行すべきだと警告する。
  • RFC 7589の順序付きリストは、リーフ証明書またはチェーン中のCAの指紋をNETCONF usernameへ対応付ける。パス検証、規則一致、username生成は別の結果である。
  • username生成後にもサーバ権限とNACMがある。TLS成功はRPC許可、datastore更新、commit、装置動作を証明しない。

正しい署名でも、用途は広げられない

認証パス検証は、指定した時刻、信頼アンカー、ポリシー、失効情報の下でチェーンが成立するかを判定する。そこに暗号上の欠陥がなくても、証明書がNETCONF管理用に発行されたとは限らない。

RFC 9918は、信頼するCAの一覧を使うなら、そのCAはNETCONFサーバへのアクセスを許された当事者だけに証明書を発行すべきだとする。別用途にも発行するCAを同じ入口に置けば、その別用途の証明書まで不適切に受理され得る。

これはTLS 1.3への更新だけでは解けない。RFC 9918はTLS 1.2相互認証を必須のまま残し、TLS 1.3を推奨し、対応時は新しい版を優先させ、early dataを禁止する。一方で、RFC 7589の証明書検証とidentity規則は変更しない。新しいhandshakeと狭い用途設計は別課題である。

順序付き対応表がusernameを作る

RFC 7589では、サーバが証明書からNETCONF usernameを導く順序付きリストを持つ。提示されたリーフの指紋だけでなく、そのチェーンに入った信頼CAの指紋でも一致できる。次に、明示文字列、subjectAltNameのメール名、DNS名、IPアドレス、または非推奨のCommonNameからusernameを作る。

チェーンが有効でも一致規則がない場合がある。CA規則は一致しても必要な値がない場合がある。値があってもNETCONFのusername要件を満たさない場合がある。そのときは後続規則を試し、最後まで名前を作れなければsessionを終了する。

したがって順序変更はidentity変更である。広いCA規則を個別リーフ規則より前へ移せば、証明書そのものが変わらなくても別のusernameが選ばれ得る。監査記録に「mTLS成功」しかなければ、どの規則が制御面の名前を作ったかを再現できない。

名前ができても、操作権限はまだない

RFC 6241はtransportが認証済みNETCONF usernameを渡し、サーバがその権限をsession中に強制することを求める。RFC 8341のNACMは、username、group、operation、data、action、notificationを基にアクセスを制御する。

このため記録は段階を分ける必要がある。証明書チェーン、対応規則、username、group、NACM規則、RPC応答、対象datastore、candidateからrunningへのcommit、変更後readback、装置・通信・serviceの観測である。

<edit-config>の成功応答は必ずしもcommitではない。commitは装置内部の全実装を証明しない。readbackもservice結果ではない。最初の認証成功を最後の効果まで拡張すると、障害箇所も責任者も見えなくなる。

CAローテーション前に影を照らす

信頼アンカーを替える前に、新しいCA配下のどの証明書が規則に一致するかを影実行するべきである。発行用途、リーフ/チェーンhash、検証時刻、失効結果、対応表version、規則順序、match対象、map type、username、NACM判定まで保存する。実変更を許さないcanaryで結果を比較すれば、共有CAの余分な発行範囲を本番権限に変える前に発見できる。

情報源