要約

  • radius/1.1がALPNで選ばれたTLSまたはDTLS接続では、RADIUSの共有シークレットとMD5依存のパケット認証・属性難読化が使われなくなる。一方、RADIUS/UDPとRADIUS/TCPは変更されない。
  • 「対応済み」は移行完了を意味しない。各ホップについて、実装、提示、選択、強制、旧方式停止の順に観測できなければならない。

間違いを消さずに修正する

RFC 9765の導入部は、技術文書としては率直だ。RADEXTがRADIUSをTLSやDTLSで運ぶ方式を設計した際、パケット内の共有シークレットとMD5処理を残した。TLSは従来RADIUSを包む外側の層と考えられ、エンコードや検証の仕組みを大きく変えずに導入できたからだ。DeKokは、その判断が振り返ればおそらく誤りであり、自分も決定に関わったと記す。

当時の互換性には意味があった。稼働中のクライアントとサーバーを同時に作り替えなくても、保護された通信路を追加できた。しかし後には、TLSがすでに担う仕事の上に、MD5を用いる古い保護が重なって残った。既知の弱点を持つダイジェストを認めない環境では、その重複自体が検証の障害になる。

IETFの人物情報によれば、DeKokは1997年にRADIUSに触れ、1999年にFreeRADIUSを始めた。FreeRADIUSは、AAAのポリシーサーバーと関連ライブラリーを実運用に届けるプロジェクトである。長い実装経験は、仕様の簡潔さと停止できない認証基盤の間を見せる。ただしRFC 9765は個人の命令ではない。IETFの公開審査と合意を経たExperimental文書であり、実装と評価の対象として公開されたものだ。

TLSが引き受けるもの

RFC 2865のRADIUSでは、クライアントとサーバーが共有する秘密が交換の認証に関わり、User-Passwordなどの値はMD5に基づく方法で隠される。RFC 6614とRFC 7360はTLS、DTLSの輸送を加えたが、従来型RADIUS/TLSはそのパケット処理を残した。

RADIUS/1.1では、TLSハンドシェイク中のALPNが境界線になる。RFC 7301に従い、クライアントがアプリケーションプロトコル名を提示し、サーバーが双方に共通する名前を選ぶ。radius/1.1が選択され、TLS 1.3以降が使われる場合にだけ新しいプロファイルへ入る。

その接続ではRADIUS共有シークレットを使わない。Request AuthenticatorとResponse Authenticatorの領域は要求と応答を対応づける不透明なTokenへ変わり、Identifierは従来の役割を失う。Message-Authenticatorは送信せず、MD5で難読化していた属性は通常の形式でTLS内を通る。機密性と完全性はTLSが担うからである。

つまり、信頼は削除されたのではなく配置換えされた。証明書やその他の方法で正しい相手を認証し、その相手に要求を送る権限があるかを判断し、鍵とTLSライブラリーを維持する責任が前面に出る。ALPNの選択結果も監査できなければならない。

形を残すからこそ、状態を区別する

RADIUS/1.1は全面的な再設計ではない。ヘッダーの大きさ、CodeとLengthの意味、MD5難読化を使わない属性の形式、既存のTLS・DTLSポートは保たれる。仕様が「トランスポートプロファイル」と呼ぶ理由である。

一方、同じ形に見えても1.0と1.1の解釈は互換ではない。片側が古いAuthenticatorとして読み、反対側がTokenとして扱えば、要求または応答は検証に失敗する。誤ったデータを受理しにくい設計ではあるが、現場では認証不能として現れる。安全な失敗にも、原因を識別するログと回復手順が要る。

さらに、RADIUSが運ぶ認証方式すべてが新しくなるわけではない。CHAPやMS-CHAPの属性は不透明なデータとして残り得る。1.1が外すMD5は、このホップのRADIUSパケットを認証・難読化する用途であり、背後の認証方式や資格情報まで一括で更新するものではない。

1ホップ先の状態は見えない

ローミングやプロキシーでは、RADIUS要求が複数のクライアント―サーバー接続を通る。最初の接続が1.1でも、次は従来型RADIUS/TLS、UDP、あるいは別の許可された輸送かもしれない。1.1の効力は選択した二者の接続だけに及ぶ。入口の測定値をエンドツーエンドの証明に使ってはならない。

RFC 9765は、1.1のALPN信号がなければ1.1として動作してはならないとする。両方に対応する実装の初期設定は、radius/1.0とradius/1.1をともに許す考え方だ。管理者は両端を確認し、実際の選択を観測した後に1.1を必須にし、接続を監視する。問題があれば原因を直す間だけ両対応へ戻せる。

この段階移行は停止を避けるが、「いつまでも両対応」という別の固定化を生む。製品に機能があること、クライアントが名前を提示すること、接続で選ばれること、ポリシーで必須になること、旧経路が閉じることは別々の状態だ。

移行状態 確認する事実
実装済み 両端とTLSライブラリーが要件を満たす。
提示済み ClientHelloに対象ALPN名が現れる。
選択済み 本番接続の結果がradius/1.1である。
必須化 1.0しか話せない相手をポリシーが拒否する。
旧方式停止 対象ホップに歴史的プロファイルや未保護輸送が残らない。

この表をホップごとに埋めて初めて、移行という言葉に運用上の意味が生まれる。

DeKokが示したのは支配ではなく訂正の作法

InkBridgeはDeKokをFreeRADIUSの創設者・リーダーとして紹介する。しかしRADIUSにはそれ以前の著者がいて、IETFが審査し、TLSライブラリーと各製品が実装し、運用者が接続方針を決める。プロキシーの次のホップは別組織が握ることさえある。DeKok一人が全体を移行させることはできない。

重要なのは、過去の妥協を認め、使えるパケット構造は残し、重複する保護だけを既存の安全な層へ移し、結果を接続単位で観測可能にしたことだ。Experimentalという位置づけは、まだ評価が続くことも示す。仕様、稼働コード、選択された接続状態の三つが揃ったとき、初めてこの訂正はインフラの現実になる。

出典