要約

  • RADIUSのIdentifierは1オクテットしかなく、待機中の要求を探す手掛かりにすぎない。クライアントは、その要求固有の16オクテットのRequest Authenticatorと当該ホップの共有秘密を使い、Response Authenticatorも検証する。
  • 同じサーバーへの内容不変の再送では、Identifier、Request Authenticator、送信元ポートを維持する。サーバーは重複要求を再処理せず、保存済みの応答を返す。属性を変えた場合は新しい要求になる。

256個の値に永続性を求めなかった

RADIUSパケットは、Code、8ビットのIdentifier、Length、16オクテットのAuthenticator、Attributesという小さなヘッダーで始まる。接続要求が並行し、UDPの損失により再送が起こり、代替サーバーも使われる環境で、256個の値はすぐ一巡する。

1997年1月のRFC 2058は最初のRADIUS RFCだった。同年4月のRFC 2138を経て、2000年のRFC 2865が古典的RADIUSの中核を定めた。いずれもIdentifierを世界共通の取引番号にはしていない。「要求と応答の対応付けを助ける」値である。

RFC 5080は、この限定を実装規則として明確にした。同一の送信元IPアドレスとUDPポートでは、有効な応答を受けるか要求がタイムアウトするまでIdentifierを再利用してはならない。値の選択にはLRU方式が推奨される。

したがって37は、装置の生涯にわたる37番ではない。特定の端点で今まさに待機している37である。待機が終われば、番号は別の要求に使える。小さな名前を安全にしたのは大きさではなく、寿命の短さだった。

16オクテットが「どの質問か」を残した

Access-RequestのAuthenticator欄には、16オクテットのRequest Authenticatorが入る。新しいIdentifierを使うたびに変更し、共有秘密の有効期間を通じて予測困難かつ一意であることが望まれる。

同じ秘密の下で値を繰り返せば、盗聴された古い応答が再び利用可能になり得る。将来の値が予測できれば、攻撃者が正規要求より先に偽応答の材料を用意できる。この値は単なる長い連番ではなく、要求と応答を結び付ける安全材料でもあった。

Access-Accept、Access-Reject、Access-Challengeは、要求のIdentifierをコピーする。一方、Response Authenticatorは、応答側のCode、Identifier、Length、Attributesに、元のRequest Authenticatorと共有秘密を加えて算出される。

クライアントはIdentifierで待機中の候補を探し、その候補が持つRequest Authenticatorで応答を検証する。前回の37に対する遅延応答は、新しい37のRequest Authenticatorとは一致しないため破棄される。

短い番号は検索範囲を狭める。16オクテットは応答を具体的な質問に結ぶ。共有秘密は隣接ホップを認証し、待機表は有効な時間を定める。意味は一つの欄ではなく、この組合せに宿る。

再送は同じ要求のままでなければならない

古典的RADIUSがUDPを使った理由は、アクセス判断の時間感覚にある。利用者は数秒なら待てても、数分後に古いデータが確実に届くことには価値がない。クライアントはトランスポートより上で要求を保存し、自ら再送タイマーを管理し、必要なら別サーバーも試す。

ここで「同じ判断の再配達」と「内容を変えた新しい判断」を区別しなければならない。同じサーバーに同じAttributesを送る再送では、Identifier、Request Authenticator、送信元ポートを保持する。二つ目のデータグラムでも、論理的には一つの試行である。

Attributesを一つでも変えたら、IdentifierとRequest Authenticatorを新しくする。Event-Timestampの追加、パスワード応答の変更、希望サービスの変更は、古い要求の更新ではない。同じ利用者に関する要求であっても、サーバーに尋ねる内容が変わったからだ。

この機械的な境界が、実装者の曖昧な「同じつもり」からプロトコルを守った。

重複した判断ではなく、同じ応答を再配達した

RFC 5080は、サーバーにAccess-Requestの重複検出と応答キャッシュを要求する。すでにAccess-Accept、Access-Reject、Access-Challengeを返していれば、同じ要求を再処理せず、元の応答をもう一度送る。最初の要求が処理中なら、重複パケットは黙って捨てる。

これはCPU節約だけではない。認証処理は、ログイン回数の記録、ワンタイム値の消費、バックエンドへの書込み、外部ディレクトリ照会を伴う場合がある。応答損失から生じた二つのパケットが、二つの業務効果を生んではならない。

キャッシュの照合には、送信元アドレス、送信元ポート、Identifier、受信ソケット、Request Authenticatorが用いられる。保持期間は通常5秒から30秒である。最初の四要素が同じでもRequest Authenticatorが異なれば、古いキャッシュ項目は無効になる。見かけの番号一致が新しい試行を飲み込まないようにするためだ。

キャッシュされた結論が恒久的権限を得るわけではない。再送が合理的に到着し得る短い時間だけ、失われた可能性のある応答を補う。

内容を変えた瞬間、古い応答は現在形でなくなる

最初の要求をサーバーが処理している間に、クライアントがAttributesを変えて新しい要求を出すことがある。古いサーバーから後で届く応答は、旧Request Authenticatorに対しては正しく検証できる。それでも現在の要求への答えではない。

クライアントが処理するのは、まだ待機中の要求に対する最初の有効応答である。要求を閉じた後の応答は未要求パケットとして破棄する。暗号学的な妥当性だけでは、失われた時間的資格を取り戻せない。

Access-Challengeは、この違いを複数ラウンドで示す。サーバーはStateを返し、追加の利用者応答を求められる。NASはStateを引き継ぎつつ、新しいIdentifierとRequest Authenticatorを持つAccess-Requestを送る。Stateは会話を継続させるが、各ラウンドを同一トランザクションにはしない。

代替サーバー同士でポリシーやデータがずれていれば、異なる結論が返る可能性は残る。最初の有効応答を採用する規則は到着順を整理するだけで、運用者の同期責任を消さない。

Acceptでも実行能力は作れない

Access-Acceptという名前は強い。しかしRFC 2865は、NASが応答で指定されたサービスを提供できない場合、それをAccess-Rejectとして扱うよう求める。

応答が真正でも、存在しないVLAN、未対応のプロトコル、利用不能なポートを生成することはできない。Response Authenticatorが示すのは、共有秘密を持つ隣接システムが、待機中の特定要求にこの内容で答えたという範囲である。

利用者本人の認証は、PAP、CHAP、EAPなどAttributesが運ぶ方式とサーバーポリシーに依存する。パケットのホップ認証を、人の身元、正しい認可、サービス提供済みの証明へ拡張してはならない。

プロキシでは証明がホップごとに作り直された

転送プロキシは、下流サーバーからの応答を下流側の秘密で検証し、自分が追加した最後のProxy-Stateを外す。次に上流クライアントが待つIdentifierへ戻し、上流側の共有秘密でResponse Authenticatorを計算し直す。

NASが受け取るのは、ホームサーバーからのエンドツーエンド署名ではない。直接のRADIUSピアが作ったホップ単位の証明である。Proxy-Stateは応答を経路に沿って戻すための不透明情報であり、アクセス権そのものではない。

長期ログに「ID=37、Accept」だけを残しても意味は復元できない。ホップ、クライアントのアドレスとポート、受信ソケット、待機時間、Request Authenticatorの保護された指紋、要求形状、重複キャッシュ動作、プロキシ経路、NASが実行した効果が必要になる。一方、共有秘密や認証情報を平文で記録してはならない。

再送の同期が障害を増幅した

RFC 5080は、1秒以下の固定間隔で、輻輳バックオフを持たないクライアントを問題として挙げる。停電復旧で数千台のNASが同時に起動すれば、同時に要求し、同時にタイムアウトし、同時に再送する。信頼性機構が認証サービスを圧迫する。

推奨アルゴリズムは、初期待ち時間、指数的な増加、ジッター、最大間隔、最大回数、最大継続時間を組み合わせる。ジッターの乱数は同期を崩すためであり、暗号学的強度を必要としない。Request Authenticatorの予測困難性は攻撃耐性のためで、同じ低品質生成器を流用してよい理由にはならない。

過負荷時には、有効なStateを持つ後続ラウンドを優先し、始まった会話を完了させることもできる。プロキシが新規要求よりホームサーバーの応答を先に扱うこともある。これは負荷を減らす順序付けであり、利用者の権利順位ではない。

TLSは後に信頼の置き場所を変えた

2012年のRFC 6614はRADIUSをTLS/TCPで運んだが、歴史的なMD5処理を残し、その計算に固定秘密radsecを使った。接続はTLSで守られても、古いパケット機構は内側で続いた。

2025年のRFC 9765は、TLS 1.3以降でALPNにより明示的にRADIUS/1.1を合意したホップだけ、共有秘密とMD5パケット機構を外した。Authenticatorの16オクテットは不透明なTokenとなり、Identifierの対応付け機能も引き継ぐ。

この移行史は、既存のBTW記事との境界である。RADIUS/1.1は通常のRADIUS/UDPを変更せず、プロキシ鎖の他ホップを自動更新もしない。本稿にとって重要なのは、トランスポートが真正性を担っても、どの要求への応答かを示す十分な相関値は残る、という一点である。

歴史的機構を現代のMD5推奨にしない

古典的Response Authenticatorは当時の設計であり、MD5を現代に推奨する根拠ではない。ポリシーの妥当性、会計記録の確定、すべてのプロキシの誠実性、実トラフィックの提供を証明しない。RFCが示すのは規定された意味と改訂であり、製品準拠や現在の普及率ではない。

長く残る教訓は、短い名前の条件である。範囲、寿命、補助証拠が一緒なら、8ビットでも局所的な調整に使える。監査表が番号だけを保存し、その番号を成立させた稼働中の文脈を捨てたとき、初めて危険な永久名になる。