要約

  • RFC 9644はSSHアルゴリズムの能力と優先順位付き方針をYANGで表現するが、個々のセッションの交渉結果までは記録しない。
  • 説明責任を果たすには、レジストリとモジュールの版、実装能力、承認済み設定、双方のSSH_MSG_KEXINIT、方向別の選択、ホスト鍵検証、NEWKEYS、認証、アプリケーション結果を関連付ける必要がある。
  • ここで示す記録は運用設計でありRFCの規定ではない。観測できない区間があれば、結論の範囲を狭めなければならない。

承認票が止まる地点

変更担当者は、設定が受理されたことを証明できる。資産管理担当者は、新しいアルゴリズムを装置がサポートしていると示せる。セキュリティ担当者は、許可リストの承認履歴を出せる。しかし、これらを並べても、相手側の提示内容やセッションの選択結果は現れない。

RFC 9644が定義するietf-ssh-common、ietf-ssh-client、ietf-ssh-serverは、SSHクライアントとサーバーの一般的な設定を再利用可能なgroupingとして表現する。また、IANAのSSHレジストリから四つのアルゴリズム列挙モジュールを生成する仕組みを示す。目的は実装間の共通表現であり、セッション監査ログの標準化ではない。

証拠を混同しないためには、登録、能力、許可、選択を分ける必要がある。登録は名前が公共の名前空間にあること、能力は実装が使用可能だと表明すること、許可は組織が順序付きで認めたこと、選択は二者の交換で生じた出来事である。さらに選択だけでは、相手の身元や利用者認証、業務処理の成功は証明されない。

IANAの登録と組織の判断

生成モジュールは元のIANAレジストリの変更を反映し、新しいrevisionを加える。未割当てや予約済みの値は列挙に含めず、状態を機械可読な形に投影する。管理システムと装置が同じ名前を解釈するうえで、この対応関係は重要である。

ただし、登録は推奨ではない。レジストリには歴史や状態の異なる識別子が共存する。RFC 9142が示すように、鍵交換方式の要求水準も時間とともに更新される。したがって、監査記録には、参照したレジストリと生成モジュールのrevisionに加え、その時点で組織が何を許可・禁止したかを別々に残す必要がある。

ここでrevisionやハッシュを省くと、後日の監査が現在の語彙を過去へ投影してしまう。featureやdeviationが公開スキーマを変える場合、それらも同じ証拠単位に含めるべきだ。

「対応」は「使用」ではない

任意のalgorithm-discovery featureが有効なら、supported-algorithmsはconfig falseの運用データとして実装能力を示す。移行計画では、どの装置が候補方式を扱えるかを把握できるため有用である。

しかし、対応している方式が方針で許可されているとは限らない。許可されていても相手が提示しないことがあり、双方が提示しても優先順位によって選ばれないことがある。能力のスナップショットにはソフトウェア版と観測時刻が必要だ。更新やビルド条件で内容が変わるからである。

設定リストが存在しない、または要素がない場合も注意が要る。RFC 9644では許容集合が実装依存となる。空欄を製品横断の安全な既定値として表示してはならない。有効な挙動を確認できなければ、結論は「不明」である。

二つの提示と、方向別の結果

transport-params-groupingには、鍵交換、ホスト鍵、暗号、MACの順序付きリストがある。順序は優先度そのものであり、監査用に並べ替えてはいけない。設定revision、承認者、受理した装置とともに、完全な順序を残す必要がある。

RFC 4253では、両者がSSH_MSG_KEXINITで名前リストを提示する。鍵交換方式とホスト鍵方式は、サーバーも提示し必要条件を満たす候補のうち、クライアントの優先順位に基づいて決まる。暗号とMACは、クライアントからサーバー、サーバーからクライアントの各方向で独立に選ばれる。

従って、「承認済み暗号」という一項目では情報が足りない。双方の提示と方向別の選択を保存しなければならない。共通候補がなければ接続は切断される。設定が正常に反映されたという記録は、相手との互換性を保証しない。

ホスト鍵方式とホストの身元

選択されたホスト鍵アルゴリズムは暗号手順を表す。実際に提示された鍵や、その鍵をクライアントが信頼した根拠とは別である。RFC 8332では、同じRSA公開鍵形式がrsa-sha2-256とrsa-sha2-512の異なる署名手順に使われ得る。鍵形式だけからセッションのアルゴリズムを断定できない。

RFC 9644も、クライアント識別情報とサーバー認証パラメータを分離し、keystoreやtruststoreへの参照を扱う。この構造に沿えば、交渉された方式、提示鍵の指紋、検証規則と結果、クライアント認証、アプリケーション権限を別々に記録できる。

観測点の限界も残す必要がある。ネットワーク上の記録から交渉を確認できても、クライアント内部の信頼判断が見えない場合がある。そのとき証明できるのは方式の選択までであり、ホスト身元の承認ではない。

NEWKEYSは中間地点

SSH_MSG_NEWKEYSは、新しく計算された鍵とアルゴリズムが有効になる境界である。互換なKEXINITが存在しても、そこへ到達した証拠にはならない。一方、NEWKEYSに到達しても、RFC 4252の利用者認証やアプリケーション処理の成功はまだ先にある。

そこで、運用上の最小記録を次の連鎖として設計できる。

  • IANAレジストリのスナップショットと生成YANGモジュールのrevisionまたはハッシュ
  • 実装、ソフトウェア版、feature、deviation
  • 時刻付きの対応アルゴリズム観測
  • 承認済みの正確な順序付きリスト、設定revision、承認者
  • 双方のKEXINITの保護された取得記録またはハッシュ
  • 鍵交換、ホスト鍵、暗号、MACの方向別選択
  • 提示されたホスト鍵の指紋、検証根拠、結果
  • NEWKEYS完了の証拠
  • 秘密情報を含まない利用者認証方式と結果
  • アプリケーション操作、受入れ条件、結果
  • 観測不能区間と、最終表現を承認した責任者

これはRFC 9644が定める統一形式ではない。設定、プロトコル、サービスの境界に残る説明責任を接続するための運用案である。

証明できる文だけを書く

Heng Luのminimum initial specificationを適用すると、最初に決めるべきなのは大規模な監視基盤ではなく、最低限証明したい文である。「SSHは安全だ」では広すぎる。対象操作と時間帯を特定し、承認済み方針、観測された選択、検証済みの相手、期待した結果を関連付けられる、という範囲なら検証可能になる。

running-code primacyは、不一致時の優先順位を与える。レジストリとモデルは記号の秩序をつくるが、実際の交換が出来事を決める。差異があれば、セッションについての記述は観測に従い、差異自体を調査対象とする。

設定しかなければ「方針が受理された」とだけ言える。交渉とNEWKEYSがあっても信頼判断がなければ、方式の有効化までは言えても相手の身元は言えない。身元まで確認してもアプリケーション結果がなければ、サービス提供の完了は未証明である。

出典

  1. Minimum initial specification
  2. Reality layers and symbolic power
  3. Running-code primacy
  4. RFC 9644 Datatracker
  5. RFC 9644情報ページ
  6. RFC 9644 HTML版
  7. RFC 9644テキスト版
  8. RFC 9644 XML版
  9. RFC 9644インライン正誤表
  10. IANA SSHプロトコルパラメータ
  11. IANA YANGパラメータ
  12. RFC 4250：SSH割当て番号
  13. RFC 4252：SSH認証プロトコル
  14. RFC 4253：SSHトランスポート層
  15. RFC 6187：SSHでのX.509v3証明書
  16. RFC 8332：RSA鍵とSHA-2署名
  17. RFC 9142：SSH鍵交換方式の更新
  18. RFC 7950：YANG 1.1
  19. RFC 8341：ネットワーク設定アクセス制御
  20. RFC 8342：管理データストア構成