要約

  • RFC 9813では、TLS-PSKのPSK Identityが送信元IPアドレスに代わってRADIUSクライアント関係の候補を選ぶ。ただし値は平文で認証前に届くため、台帳の一致は認証ではない。
  • 運用証跡は、広域の送信元許可、入力検証、顧客台帳の世代、関係ごとの範囲、PSK保有証明、RADIUS完全性、ローカルポリシー、再開状態、実際のサービス提供を別々に残す必要がある。

従来のRADIUS顧客台帳は送信元アドレスを主キーにしていた。パケットが来ると、そのアドレスで行を選び、共有シークレットを取得し、RADIUSメッセージを確認する。行には接続元だけでなく、装置の種別や許される要求などのローカル規則も結び付いていた。

NATでは複数の顧客が同じ外部アドレスになる。モバイル回線や再番号付けでは一つの顧客が複数アドレスを移動する。範囲を広げても到達性しか戻らず、関係の精度は戻らない。想定アドレスごとの複製は、いずれ現実と食い違う。

2025年7月にBCP 243として公開されたRFC 9813は、RADIUS over TLS/DTLSでTLS-PSKを運用する際の欠けていた規則を示した。PSK Identityが送信元IPに代わってクライアント識別子になる。しかし置き換わるのは検索キーであり、ネットワーク位置、暗号学的証明、RADIUSの権限、NASの実行まで一つになるわけではない。

検索に成功しても、相手はまだ証明されていない

サーバーはどのPSKを試すか知るために、PSK Identityを先に受け取る。この値は平文で、到達できる相手なら偽造できる。組織名や拠点名を入れれば所属情報も漏れる。不透明な識別子やNetwork Access Identifier形式は露出を抑えられるが、選択子を秘密にはしない。

台帳の一行が見つかったという事実は、受信文字列に一致する管理状態があるというだけだ。送信者がPSKを持つこと、許可範囲から来たこと、そのRADIUS要求を送れることは別の判定である。「既知のIdentity」を「認証済み顧客」と表示すれば、IPアドレスに置いていた過剰な信頼を新しい列へ移しただけになる。

入力は検索基盤に触れる前に止める

RFC 9813はIdentityを敵対的入力として扱う。無効なUTF-8、NUL、SQL・LDAP・REST・シェルで意味を持つ文字を含み、TLS上限の65,535オクテットに達することもある。連結したクエリへそのまま渡せば、プロトコルの選択子が注入面になる。

長さを制限し、静的Identityか再開チケットかの名前空間を分類し、表現を検証し、版管理された正規化を行い、実際の照会方式に合わせてエスケープする。失敗時はTLS接続を閉じる。大文字小文字やUnicode処理の更新によって別の二行が暗黙に統合されてはならない。

証跡には生入力の限定ハッシュ、検証理由、正規化後の検索値、規則版、選択行IDを残す。攻撃者が制御する長文をすべてのログへ複製する必要はない。拒否コード、パーサー世代、観測範囲、ハッシュで調査は可能になる。

一行は装置名ではなく二者関係である

論理TLS-PSK台帳は、許可ネットワーク範囲、Identity、PSK、別のTLS資格情報、クライアント証明書要件を束ねられる。TLS確立後もRADIUS側の顧客ポリシーは残る。したがって管理単位は装置の普遍的Identityではなく、特定クライアントと特定サーバーの関係である。

同じ装置でも主系と待機系では別の関係を持てる。RFC 9813は、可能な各関係に固有のPSKとIdentityを設定できる実装を求める。運用者が再利用を選ぶ自由はあるが、二十顧客で一つのPSKを共有すれば、二十者すべてが同じ証明を作れる。漏えい時の取消しも全体作業になる。対称鍵では顧客側の漏えいからサーバー偽装も起こり得るため、無関係な組織間の利用は不向きである。

共通層は隔離能力を要求し、ローテーション間隔や保守窓は現場が決める。この境界はMinimum Initial Specificationの考え方と一致する。

IPアドレスは名前から独立した制約へ戻る

サーバーはIdentityを見る前に、広域の許可範囲外から来た接続を拒否する。行を選んだ後、その関係に許された送信元範囲も確認する。前者はリスナーの露出を抑え、後者は選択された関係が現在地から現れてよいかを問う。

この二段階の内側で、一つのNATアドレスに複数Identity、一つのIdentityに複数アドレスを認められる。範囲の成功は観測した位置を示し、PSKの成功は対称資格情報の保有を示す。物理装置や人間のIdentityまで証明するものではない。

TLS PSKとRADIUS共有シークレットは別会計である

TLS PSKはチャネルの関係を認証し、RADIUS共有シークレットは内側のプロトコル処理に使われる。RFC 9813は同じ値の再利用を禁止し、実装に拒否を求める。同じPSKをTLS 1.3と旧版で共用することも避ける。RFC 9258は、版、KDF、文脈に結び付けて外部PSKを導入する仕組みを定める。

一つの「サイト秘密」欄しかない画面は境界を消す。役割と非秘密の世代を別表示し、秘密そのものを記録せず等値を防ぎ、どの関係がどの世代へ依存するか列挙できなければならない。TLSの成功はRADIUSメッセージ検査や認可を代行しない。

鍵の更新はIdentityの世代交代でもある

IdentityでPSKを探す以上、PSK更新時はIdentityも変える。同じ名前の下で鍵だけを交換すると、古い顧客、配布失敗、既知名への攻撃を区別できない。計画的な更新は新しい関係世代を作り、初回成功、併存期限、旧Identityの最終成功を記録し、最後に旧名を無効化する。配布完了ではなく旧権限の廃止が完了点である。

最終観測時刻は休眠顧客の管理に役立つが、沈黙は廃止、故障、季節運用、盗難のいずれでもあり得る。自動無効化には責任者、閾値、例外、復旧経路が要る。

再開用Identityは別の名前空間に置く

TLS 1.3のセッション再開もPSKとIdentityを使うが、TLS機構が作るチケットであり、静的な顧客名ではない。RFC 9813はこの用途で再開を推奨しない。必要な移行環境では、静的文字列と不透明チケットを別表にし、未知値を拒否し、衝突で片方がもう片方として受理されないようにする。

再開しても認可は永久化しない。初回完全ハンドシェイクのIdentityとポリシー文脈を安全に回収し、送信元などが変われば再評価する。回収できなければ完全ハンドシェイクへ戻る。チケットとキャッシュの上限は七日である。

「既知の顧客」より判定列が重要である

受理した接続から、広域範囲、入力検証、正規化規則、顧客台帳の正確な世代、関係別範囲、TLS版とKDF、PSK証明、再開キャッシュ、RADIUS検査、ローカル認可、NAS動作、観測サービスを再構成できるべきだ。一つが成功しても次は失敗し得る。

Running-Code Primacyが問うのは、仕様上の予定ではなく実行中のパーサーと検索器が選んだ事実である。On Reality Layersに従えば、一つの一致表示を暗号、政策、実行結果の代理にはできない。

RFC 9813はIPアドレスの王座をPSK Identityへ移したのではない。場所、選択、証明、権限、結果を分離した。その分離を台帳とログでも保てるかが、導入の成否を決める。

情報源