2.3 Proxy (プロキシ)

2.3. Proxy (プロキシ)

プロキシ RADIUS では, 1 つの RADIUS サーバーが RADIUS クライアント (NAS など) から認証 (またはアカウンティング) 要求を受信し, 要求をリモート RADIUS サーバーに転送し, リモートサーバーから応答を受信し, その応答をクライアントに送信します。場合によってはローカル管理ポリシーを反映するための変更を加えます。プロキシ RADIUS の一般的な用途はローミングです。ローミングは, 2 つ以上の管理エンティティが互いのユーザーがサービスのためにいずれかのエンティティのネットワークにダイヤルインすることを許可します。

NAS は RADIUS access-request を "転送サーバー (forwarding server)" に送信し, 転送サーバーはそれを "リモートサーバー (remote server)" に転送します。リモートサーバーは応答 (Access-Accept, Access-Reject, または Access-Challenge) を転送サーバーに送り返し, 転送サーバーはそれを NAS に送り返します。User-Name 属性には, RADIUS プロキシ操作用の Network Access Identifier [8] を含めることができます (MAY)。転送された要求を受信するサーバーの選択は, 認証 "レルム (realm)" に基づくべきです (SHOULD)。認証レルムは, Network Access Identifier のレルム部分 ("名前付きレルム (named realm)") である場合があります (MAY)。あるいは, 転送された要求を受信するサーバーの選択は, Called-Station-Id ("番号付きレルム (numbered realm)") など, 転送サーバーが使用するように設定されている他の基準に基づく場合があります (MAY)。

RADIUS サーバーは, 転送サーバーとリモートサーバーの両方として機能でき, 一部のレルムの転送サーバーとして, 他のレルムのリモートサーバーとして機能します。1 つの転送サーバーは, 任意の数のリモートサーバーのフォワーダーとして機能できます。リモートサーバーは, 任意の数のサーバーから転送を受けることができ, 任意の数のレルムの認証を提供できます。1 つの転送サーバーは別の転送サーバーに転送して, プロキシのチェーンを作成できますが, ループの導入を避けるように注意する必要があります。

次のシナリオは, NAS と転送および リモート RADIUS サーバー間のプロキシ RADIUS 通信を示しています:

1. NAS は access-request を転送サーバーに送信します。

2. 転送サーバーは access-request をリモートサーバーに転送します。

3. リモートサーバーは access-accept, access-reject, または access-challenge を転送サーバーに送り返します。この例では, access-accept が送信されます。

4. 転送サーバーは access-accept を NAS に送信します。

転送サーバーは, パケットに既に含まれている Proxy-State 属性を不透明なデータとして扱わなければなりません (MUST)。その動作は, 前のサーバーによって追加された Proxy-State 属性の内容に依存してはなりません (MUST NOT)。

クライアントから受信した要求に Proxy-State 属性がある場合, 転送サーバーはクライアントへの応答にそれらの Proxy-State 属性を含めなければなりません (MUST)。転送サーバーは, 要求を転送するときに access-request に Proxy-State 属性を含めることができ (MAY), 転送された要求でそれらを省略することもできます (MAY)。転送サーバーが転送された access-request で Proxy-State 属性を省略する場合, クライアントに送信する前にそれらを応答に添付しなければなりません (MUST)。

次に, 各ステップをより詳細に検討します。

1. NAS は access-request を転送サーバーに送信します。転送サーバーは, 存在する場合, NAS のために知っている共有秘密を使用して User-Password を復号化します。CHAP-Password 属性がパケットに存在し, CHAP-Challenge 属性が存在しない場合, 転送サーバーは Request-Authenticator を変更せずに残すか, それを CHAP-Challenge 属性にコピーしなければなりません (MUST)。

2. 転送サーバーは, パケットに 1 つの Proxy-State 属性を追加できます (MAY)。(複数追加してはなりません (MUST NOT)。) Proxy-State を追加する場合, Proxy-State はパケット内の他の Proxy-States の後に出現しなければなりません (MUST)。転送サーバーは, パケットに含まれていた他の Proxy-States を変更してはなりません (MUST NOT) (転送しないことを選択できますが, その内容を変更してはなりません (MUST NOT))。転送サーバーは, Proxy-State を含む同じタイプの属性の順序を変更してはなりません (MUST NOT)。

3. 転送サーバーは, 存在する場合, リモートサーバーと共有する秘密を使用して User-Password を暗号化し, 必要に応じて Identifier を設定し, access-request をリモートサーバーに転送します。

4. リモートサーバー (最終目的地の場合) は, User-Password, CHAP-Password, または将来の拡張が指示する可能性のあるような方法を使用してユーザーを検証し, access-accept, access-reject, または access-challenge を転送サーバーに返します。この例では, access-accept が送信されます。リモートサーバーは, access-request からすべての Proxy-State 属性 (および Proxy-State 属性のみ) を順番に変更せずに応答パケットにコピーしなければなりません (MUST)。

5. 転送サーバーは, リモートサーバーと共有する秘密を使用して Response Authenticator を検証し, 検証に失敗した場合はパケットを黙って破棄します。パケットが検証に合格した場合, 転送サーバーは最後の Proxy-State を削除し (添付した場合), NAS と共有する秘密を使用して Response Authenticator に署名し, Identifier を NAS による元の要求のものと一致するように復元し, access-accept を NAS に送信します。

転送サーバーは, ローカルポリシーを強制するために属性を変更する必要がある場合があります (MAY)。そのようなポリシーはこの文書の範囲外ですが, 次の制限があります。転送サーバーは, パケットに存在する既存の Proxy-State, State, または Class 属性を変更してはなりません (MUST NOT)。

転送サーバーの実装者は, Service-Type に対してどの値を受け入れるかを慎重に検討する必要があります。プロキシされた Access-Accept で NAS-Prompt または Administrative の Service-Types を渡すことの影響について慎重に検討する必要があり, 実装者はそれらまたは他のサービスタイプ, または他の属性をブロックするメカニズムを提供することを望む場合があります。そのようなメカニズムはこの文書の範囲外です。