要約

  • RFC 2367は、特権を持つ鍵管理アプリケーションとローカルKey Engineの間にPF_KEY socket APIを置いた。応答の証言範囲はそのローカル境界までである。
  • SADB_GET、SADB_DUMP、LARVAL、MATURE、DYING、DEADはデータベース状態であり、相手の権限、現行ポリシー、パケット利用を示す結果ではない。
  • 結論には、呼出主体、PF_KEY取引、鍵管理、遠隔交渉、SPD選択、AH/ESP処理、相手側観測、アプリケーション応答を時刻付きで結ぶ必要がある。

RFC 2367のモデルでは、鍵管理デーモンはPF_KEYでローカルKey Engineと話し、PF_INETまたはPF_INET6で遠隔の鍵管理主体と話す。カーネル内のIPsec処理は、さらに内部インターフェースからSAを取得する。三つの経路は接続しているが、同じ証拠ではない。

SADB_ADDは完成したSAを登録できる。別の流れではSADB_GETSPIでSPIを得て、SADB_UPDATEで内容を完成させる。SADB_GETはローカルコピーを返し、ACQUIRE、EXPIRE、DELETE、FLUSHは要求、期限、削除、消去を表す。PF_KEYが標準化したのは、このローカル操作語彙である。

状態名は遠隔へ届かない

LARVALはGETSPI後、MATUREはADDまたはUPDATE後、DYINGとDEADはsoft/hard lifetime後の状態だ。成熟という語は、相手が逆方向のSAを導入したことも、正しいIDを認証・許可したことも、パケットがSAを選択したことも意味しない。

SPIは検索座標であり資格情報ではない。アルゴリズム番号は設定であり、鍵の保管や演算成功の証明ではない。寿命はローカル計数である。認証または暗号化がゼロなら、そのサービスを使わない意味にもなる。項目が埋まっていることと、安全サービスが実行されたことを分けなければならない。

全体像に見えるSADB_DUMPも、RFCではデバッグ専用で、本番運用の基本動作に依存してはならない。PF_KEYメッセージ配送も保証されず、カーネルやsocketのbuffer枯渇で欠落し得る。正しいsnapshotが完全な履歴とは限らず、相手の現在値とも限らない。

誰が書いたかを先に問う

PF_KEY raw socketを開くのは信頼された特権プロセスである。手動インターフェースはローカルSAを広く操作できる。RFC 2367は、非特権ユーザーが作成、読取、変更、削除できるなら、OSは関連する安全サービスを提供できないと警告する。

したがって監査は、プロセスID、実行ファイル、設定世代、承認者、実効権限から始まる。鍵の生成元、平文が存在した境界、読取権限は、秘密を公開せず別に立証する。UPDATEの返答が鍵素材を除くのは、状態を聞けるlistenerが鍵を読む権限を持つとは限らないからだ。

APIの後にも判断が続く

RFC 4301のSPDはBYPASS、DISCARD、PROTECTを選ぶ。SAD entryは元のSPD規則が変わった後も残り、手動SAには対応するSPDがない場合もある。存在は適用可能性ではない。

RFC 7296のIKEv2は、相手IDの認証、PADによる許可、traffic selector、方向別Child SAを扱う。損失時には両端の状態が一時的にずれる。ローカルのMATUREだけでは、その遠隔判断は再現できない。

RFC 4303のESPはpacketごとに処理される。SA optionと配置がサービスを決め、送信変換と受信検証が実行される。その後にもforwarding、遠隔受信、transport、application認可がある。

必要な記録は、特権caller、PF_KEY request/reply、SADとSPDの世代、保護された鍵由来、認証・許可された遠隔交渉、flow match、AH/ESP結果、相手観測、application responseである。共通IDと時刻で結び、欠けたjoinを推測で埋めない。

情報源