要約

  • Proxy-State は接続許可の証明ではない。中継者が付加した私的な状態を、許可・拒否・追加のチャレンジのいずれの応答でも返すための属性である。
  • 各代理サーバーは他者の値と同種属性の順序を保ち、自分が付けた値だけを戻りの応答から取り除く。値の内部形式まで共通化する必要はない。
  • この限定的な約束は、中継者を経路全体の信頼できる証人にはしない。ローカルなポリシー、隣接区間の保護、端点間の保証は区別して読む必要がある。

「いいえ」という回答も帰り道を必要とする

利用者の接続要求に対し、認証先が Access-Reject を返す。サービスは始まらない。それでも、転送時に付けられた Proxy-State が不要になるわけではない。応答を受け取る代理サーバーには、自分の処理を終え、さらに手前の相手へ結果を渡す仕事が残っている。

2000 年 6 月の RFC 2865 は、この属性を Access-Accept だけの付属品にしなかった。Access-Reject と Access-Challenge にも、受け取った値を変更せず返す。接続が成立したかどうかと、中継の往復が正しく完了したかどうかは、別の問題だったのである。

この区別を外すと、成功時だけ動く実装を正しいと思い込んでしまう。許可の応答を通せたからといって、拒否や追加認証の応答でも必要な情報が戻るとは限らない。逆に、私的な状態が正しく戻ったことをもって、利用者が認証されたと判断することもできない。

ここで扱うのは、特定の障害を再現した話ではない。仕様が初めから分けていた二つの責任を読み解くための場面である。拒否にも返却が必要だという一見細かな決まりが、属性の意味を過大に読まない手掛かりになる。

中継者は二つの顔を持つ

典型的な構成では、ネットワークアクセスサーバーが RADIUS のクライアントとなる。利用者本人の端末を、そのまま RADIUS クライアントと呼んでいるわけではない。アクセス装置から依頼を受けたサーバーは、設定された認証領域などに従って別のサーバーへ転送できる。

転送する側は、手前の相手にはサーバーとして振る舞い、先の相手にはクライアントとして振る舞う。同じ装置でも、ある領域の要求は中継し、別の領域の要求は自分で処理することがある。さらに先にも代理サーバーがあれば、処理は連鎖する。

1999 年 6 月の情報提供文書 RFC 2607 は、こうした構成をローミングの文脈で説明した。接続先のネットワークと、利用者の認証を判断する組織が異なっても、要求を渡せるようにする仕組みである。鍵の管理関係を減らす利点に加え、能力の調整、ポリシーの適用、会計情報の中継も論じている。

ただし同文書は、当時の方式の安全上の前提を広いインターネットへ持ち出すことにも警告した。ある管理領域内で信頼できる中継者が、組織をまたいでも同じように信頼できるとは限らない。便利な代理構成の説明を、そのまま安全性の認定と受け取ってはいけない。

追加するのは一つ、取るのも自分の一つ

Proxy-State は 2000 年に突然登場した属性ではない。1997 年 4 月の RFC 2138 にも定義がある。RFC 2865 は転送手順を詳しくし、各代理が何をしてよいかをより明確にした。

代理は、自分の Proxy-State を一つ加えてよい。ただし一度に複数は加えず、既にある同属性の後ろへ置く。それ以前の代理が加えた値は変更しない。同じ型の属性の順序も変えない。応答が帰ってきたら、自分が追加していた場合に限り、最後の Proxy-State を取り除いて手前へ返す。

複数の代理を通った例では、後から加えた代理が先に自分の値を回収することになる。先行する代理の値を解読する必要はない。順序を守ることが、それぞれの取り分を区別する助けになる。

もっとも、ここで「最後」とは Proxy-State 同士の相対的な位置である。別の種類の属性まで含めたパケットの最終位置ではない。RFC 2865 は異なる型の並び順への依存を認めず、同じ型の属性が連続していなければならない、ともしていない。二つの Proxy-State の間に別の属性が入っていても、それだけでは不正ではない。

後入れ先出しの比喩は分かりやすいが、パケット末尾に連続した領域を必ず作るという意味に広げると誤る。共同で守るべきものは帰属と相対順序であり、各実装の好む物理的な並べ方ではなかった。

届けずに預かるという選択

さらに重要なのは、受け取った Proxy-State をすべて遠方まで転送しなくてもよい点である。RFC 2865 は、代理が既存の値を次の要求から省くことを認める。その場合、応答を元のクライアントへ返す前に、預かった値を付け直さなければならない。

つまり、代理には運び方の選択肢がある。他者の値をそのまま先へ運ばせてもよいし、自分のところで保持して戻りに復元してもよい。内部の責任の置き方は変わるが、手前の相手が受け取るべきものは変わらない。

この例外は Proxy-State を経路記録と考えることの危うさを示す。ある値が戻ったからといって、認証先までその値が届いた証拠にはならない。逆に、次の区間で見えないからといって、必ず消失したとも言えない。過去の全経路を証言する属性ではなく、特定の境界で返却を成立させる属性なのである。

私的な意味と共通の取り扱い

値の具体的な形式や用途は、サイトやアプリケーションに委ねられている。他の代理が加えた値は、不透明なオクテット列として扱う。その私的な中身が、自分のプロトコル動作を左右してはならない。

これは「何が入っているか分からないので適当に扱う」という意味ではない。長さと型を正しく読み、内容を保全し、必要な順序で返すという厳しい仕事は残る。二進の文字列に含まれるゼロのオクテットを文字列終端と誤解すれば、値を途中で切ってしまう。人間向けの文字列とみなして空白を整える処理も、別の実装の情報を壊し得る。

不透明という言葉は、暗号化済みという意味でもない。他者の値を解釈しないという実装上の境界と、通信内容を第三者から秘匿する性質は異なる。属性の意味を共有しないだけで、秘密が守られるわけではない。

IANA の RADIUS 登録簿 は State、Class、Proxy-State をそれぞれ 24、25、33 番として識別できるようにしている。こうした番号の共通化は必要だが、その役割は限定される。登録簿を見ても、ある代理の私的な値の意味や、今回の要求が正しく処理されたかどうかは分からない。

同じ「状態」でも寿命は異なる

State は、サーバーが認証の続きを識別するために Access-Challenge から後続の Access-Request へ持ち回らせる場合がある。Class は Access-Accept から会計要求へ渡す情報として使える。これに対し Proxy-State は、中継した代理自身が戻りで回収する。

2007 年 12 月の RFC 5080 は、新規または再開された認証に以前の State を持ち込んではならないことを明確にした。同じ利用者、同じポートでも、新たな会話かもしれない。属性の用途を見ずに全部を一つの永続的な利用者識別子として扱うと、この境界が失われる。

会計にも固有の確認がある。情報提供文書 RFC 2866 の Accounting-Response は、要求を受け取り、記録できたことを前提とする。単にパケットが届いただけの通知ではない。一方で、代理がどこで保存と転送の責任を引き受けるかによって、ある一つの応答から分かる範囲は変わる。すべての組織が同じ記録を持ったという証拠へ拡大してはならない。

隣の相手を確かめても、全員を確かめたことにはならない

元の RADIUS の代理手順では、先のサーバーから来た応答を、その相手との共有秘密に基づいて検証する。検証に失敗すれば破棄する。成功した応答について自分の Proxy-State を除き、元の要求に対応する Identifier を戻し、手前の相手用に応答の認証値を計算し直す。

応答全体が、不変の認証済み封筒として最初から最後まで渡るわけではない。また代理には、一部の属性をローカルなポリシーに合わせて変える余地がある。ただし既存の Proxy-State、State、Class は変更してはならない。全項目が不変なのでも、すべての変更が攻撃なのでもない。

2012 年 5 月の実験的仕様 RFC 6614 は TLS による区間の保護を扱ったが、代理によるメッセージ処理は残した。2025 年 4 月の実験的仕様 RFC 9765 は RADIUS/1.1 を定め、該当する TLS・DTLS 接続から従来の MD5 や共有秘密による仕組みを取り除いた。古い認証方式の説明は歴史であり、現在の導入推奨ではない。

代理の前後では独立して伝送方式を選べる。一つの接続を新しく保護したことは、その先の全区間の保護や、全組織のポリシーの一致を意味しない。仕様書があることと、各装置が実際に採用したことも別である。

接続を断る応答にも私的な状態を返すという約束は、狭い。しかし、その狭さが有用だった。必要なものを返す義務を、認証結果や他者の内部設計への支配と混ぜない。共有仕様は、全員に同じ内面を持たせなくても、共同作業の境界を明確にできたのである。