[要約] RFC 8559は、RADIUSプロトコルでの動的認証プロキシングに関する仕様です。その目的は、ネットワーク上での認証情報のプロキシングを効率的かつ安全に行うことです。
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 8559 FreeRADIUS
Updates: 5176, 5580 J. Korhonen
Category: Standards Track April 2019
ISSN: 2070-1721
Dynamic Authorization Proxying in the Remote Authentication Dial-In User Service (RADIUS) Protocol
リモート認証ダイヤルインユーザーサービス（RADIUS）プロトコルでの動的承認プロキシ
Abstract
概要
RFC 5176 defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. RFC 5176 also suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This specification updates RFC 5176 to correct that omission for scenarios where networks use realm-based proxying as defined in RFC 7542. This specification also updates RFC 5580 to allow the Operator-Name attribute in CoA-Request and Disconnect-Request packets.
RFC 5176は、RADIUSの許可変更（CoA）および切断メッセージ（DM）の動作を定義しています。 RFC 5176は、これらのメッセージのプロキシが可能であることも示唆していますが、それがどのように行われるかについてのガイダンスは提供していません。この仕様は、RFC 5176を更新して、ネットワークがRFC 7542で定義されているレルムベースのプロキシを使用するシナリオの省略を修正します。この仕様は、RFC 5580も更新して、CoA-RequestおよびDisconnect-RequestパケットのOperator-Name属性を許可します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8559.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8559で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Terminology ................................................4
1.2. Requirements Language ......................................5
2. Problem Statement ...............................................5
2.1. Typical RADIUS Proxying ....................................5
2.2. CoA Processing .............................................6
2.3. Failure of CoA Proxying ....................................6
3. How to Perform CoA Proxying .....................................7
3.1. Changes to Access-Request and Accounting-Request Packets ...8
3.2. Proxying of CoA-Request and Disconnect-Request Packets .....9
3.3. Reception of CoA-Request and Disconnect-Request Packets ...10
3.4. Operator-NAS-Identifier ...................................11
4. Requirements ...................................................14
4.1. Requirements on Home Servers ..............................14
4.2. Requirements on Visited Networks ..........................14
4.3. Requirements on Proxies ...................................14
4.3.1. Security Requirements on Proxies ...................15
4.3.2. Filtering Requirements on Proxies ..................16
5. Functionality ..................................................17
5.1. User Login ................................................17
5.2. CoA Proxying ..............................................17
6. Security Considerations ........................................18
6.1. RADIUS Security and Proxies ...............................18
6.2. Security of the Operator-NAS-Identifier Attribute .........19
7. IANA Considerations ............................................20
8. References .....................................................20
8.1. Normative References ......................................20
8.2. Informative References ....................................21
Authors' Addresses ................................................21
RFC 5176 [RFC5176] defines Change-of-Authorization (CoA) and Disconnect Message (DM) behavior for RADIUS. Section 3.1 of [RFC5176] suggests that proxying these messages is possible, but it does not provide guidance as to how that is done. This omission means that in practice, proxying of CoA packets is impossible.
RFC 5176 [RFC5176]は、RADIUSの許可変更（CoA）および切断メッセージ（DM）の動作を定義しています。 [RFC5176]のセクション3.1は、これらのメッセージのプロキシが可能であることを示唆していますが、それがどのように行われるかについてのガイダンスは提供していません。この省略は、実際にはCoAパケットのプロキシが不可能であることを意味します。
We partially correct that omission here by explaining how proxying of these packets can be done by leveraging an existing RADIUS attribute, Operator-Name (Section 4.1 of [RFC5580]). We then explain how this attribute can be used by proxies to route packets "backwards" through a RADIUS proxy chain from a home network to a visited network. We then introduce a new attribute: Operator-NAS-Identifier. This attribute permits packets to be routed from the RADIUS server at the visited network to the Network Access Server (NAS).
ここでは、既存のRADIUS属性であるOperator-Nameを利用してこれらのパケットのプロキシを実行する方法を説明することで、この省略を部分的に修正しています（[RFC5580]のセクション4.1）。次に、プロキシがこの属性を使用して、RADIUSプロキシチェーンを通じてホームネットワークから訪問先ネットワークにパケットを「逆方向」にルーティングする方法について説明します。次に、新しい属性であるOperator-NAS-Identifierを導入します。この属性は、訪問先ネットワークのRADIUSサーバーからネットワークアクセスサーバー（NAS）へのパケットのルーティングを許可します。
This correction is limited to the use case of realm-based proxying as defined in [RFC7542]. Other forms of proxying are possible but are not discussed here. We note that the recommendations provided in this document apply only to those systems that implement proxying of CoA packets, and then only to those that implement realm-based CoA proxying. This specification neither requires nor suggests changes to any implementation or deployment of any other RADIUS systems.
この修正は、[RFC7542]で定義されているレルムベースのプロキシの使用例に限定されています。他の形式のプロキシも可能ですが、ここでは説明しません。このドキュメントで提供される推奨事項は、CoAパケットのプロキシを実装するシステムにのみ適用され、その後、レルムベースのCoAプロキシを実装するシステムにのみ適用されることに注意してください。この仕様は、他のRADIUSシステムの実装または展開に対する変更を要求も提案もしていません。
We also update the behavior described in [RFC5580] to allow the Operator-Name attribute to be used in CoA-Request and Disconnect-Request packets, as further described in this document.
このドキュメントでさらに説明されているように、[RFC5580]で説明されている動作を更新して、CoA-RequestおよびDisconnect-RequestパケットでOperator-Name属性を使用できるようにします。
This document is a Standards Track document in order to update the behavior described in [RFC5580], as [RFC5580] is also a Standards Track document. This document relies heavily upon and also updates some of the behaviors described in RFC 5176, which is an Informational document; because the applicability statements in Section 1.1 of [RFC5176] do not apply to this document, this document does not change the status of [RFC5176].
このドキュメントは、[RFC5580]も標準トラックドキュメントであるため、[RFC5580]で説明されている動作を更新するための標準トラックドキュメントです。このドキュメントは、情報ドキュメントであるRFC 5176で説明されている動作の一部に大きく依存し、更新されています。 [RFC5176]のセクション1.1の適用性に関する記述はこのドキュメントには適用されないため、このドキュメントは[RFC5176]のステータスを変更しません。
We finally conclude with a discussion of the security implications of this design and show that they do not decrease the security of the network.
最後に、この設計のセキュリティへの影響についての議論を締めくくり、それらがネットワークのセキュリティを低下させないことを示します。
This document frequently uses the following terms:
このドキュメントでは、次の用語を頻繁に使用しています。
CoA
とともに
Change of authorization, e.g., CoA-Request, CoA-ACK, or CoA-NAK, as defined in [RFC5176]. [RFC5176] also defines Disconnect-Request, Disconnect-ACK, and Disconnect-NAK. For simplicity, where we use "CoA" in this document, we mean a generic "CoA-Request or Disconnect-Request" packet. We use "CoA-Request" or "Disconnect-Request" to refer to the specific packet types.
[RFC5176]で定義されているCoA-Request、CoA-ACK、CoA-NAKなどの許可の変更。 [RFC5176]は、Disconnect-Request、Disconnect-ACK、Disconnect-NAKも定義しています。簡単にするために、このドキュメントでは「CoA」を使用していますが、これは一般的な「CoA-RequestまたはDisconnect-Request」パケットを意味します。 「CoA-Request」または「Disconnect-Request」を使用して、特定のパケットタイプを参照します。
Network Access Identifier (NAI)
ねとぉｒｋ あっせっｓ いでんちふぃえｒ （ない）
The user identity submitted by the client during network access authentication. See [RFC7542]. The purpose of the NAI is to identify the user as well as assist in the routing of the authentication request. Please note that the NAI may not necessarily be the same as the user's email address or the user identity submitted in an application-layer authentication.
ネットワークアクセス認証中にクライアントによって送信されたユーザーID。 [RFC7542]を参照してください。 NAIの目的は、ユーザーを識別し、認証要求のルーティングを支援することです。 NAIは、必ずしもユーザーのメールアドレスまたはアプリケーションレイヤー認証で送信されたユーザーIDと同じであるとは限らないことに注意してください。
Network Access Server (NAS)
ネットワークアクセスサーバー（NAS）
The device that clients connect to in order to get access to the network. In Point-to-Point Tunneling Protocol (PPTP) terminology, this is referred to as the PPTP Access Concentrator (PAC), and in Layer 2 Tunneling Protocol (L2TP) terminology, it is referred to as the L2TP Access Concentrator (LAC). In IEEE 802.11, it is referred to as an Access Point.
クライアントがネットワークにアクセスするために接続するデバイス。ポイントツーポイントトンネリングプロトコル（PPTP）の用語では、これはPPTPアクセスコンセントレーター（PAC）と呼ばれ、レイヤー2トンネリングプロトコル（L2TP）の用語では、L2TPアクセスコンセントレーター（LAC）と呼ばれます。 IEEE 802.11では、アクセスポイントと呼ばれます。
Home Network
ホーム・ネットワーク
The network that holds the authentication credentials for a user.
ユーザーの認証資格情報を保持するネットワーク。
Visited Network
訪問したネットワーク
A network other than the home network, where the user attempts to gain network access. The visited network typically has a relationship with the home network, possibly through one or more intermediary proxies.
ユーザーがネットワークアクセスを取得しようとする、ホームネットワーク以外のネットワーク。訪問先ネットワークは通常、おそらく1つ以上の中間プロキシを介して、ホームネットワークと関係があります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
This section describes how RADIUS proxying works, how CoA packets work, and why CoA proxying as discussed in [RFC5176] is insufficient to create a working system.
このセクションでは、RADIUSプロキシの仕組み、CoAパケットの仕組み、および[RFC5176]で説明されているCoAプロキシでは機能するシステムを作成するのに不十分な理由について説明します。
When a RADIUS server proxies an Access-Request packet, it typically does so based on the contents of the User-Name attribute, which contains an NAI [RFC7542]. This specification describes how to use the NAI in order to proxy CoA packets across multiple hops. Other methods of proxying CoA packets are possible but are not discussed here.
RADIUSサーバーがAccess-Requestパケットをプロキシする場合、通常は、NAI [RFC7542]を含むUser-Name属性の内容に基づいてプロキシを行います。この仕様では、CoAパケットを複数のホップにプロキシするためにNAIを使用する方法について説明します。 CoAパケットをプロキシする他の方法も可能ですが、ここでは説明しません。
In order to determine the "next hop" for a packet, the proxying server looks up the "realm" portion of the NAI in a logical Authentication, Authorization, and Accounting (AAA) routing table, as described in Section 3 of [RFC7542]. The entry in that table contains information about the next hop to which the packet is sent. This information can be IP address, shared secret, certificate, etc. The next hop may also be another proxy, or it may be the home server for that realm.
[RFC7542]のセクション3で説明されているように、パケットの「ネクストホップ」を決定するために、プロキシサーバーは論理的な認証、承認、アカウンティング（AAA）ルーティングテーブルでNAIの「レルム」部分を検索します。 。そのテーブルのエントリには、パケットの送信先のネクストホップに関する情報が含まれています。この情報には、IPアドレス、共有シークレット、証明書などがあります。ネクストホップは別のプロキシの場合もあれば、そのレルムのホームサーバーの場合もあります。
If the next hop is a proxy, that proxy will perform the same realm lookup and then proxy the packet as above. At some point, the next hop will be the home server for that realm.
ネクストホップがプロキシの場合、そのプロキシは同じレルムルックアップを実行してから、上記のようにパケットをプロキシします。ある時点で、ネクストホップはそのレルムのホームサーバーになります。
The home server validates the NAI in the User-Name attribute against the list of realms hosted by the home network. If there is no match, then an Access-Reject is returned. All other packets are processed through local site rules, which result in an appropriate response packet being sent. This response packet can be Access-Accept, Access-Challenge, or Access-Reject.
ホームサーバーは、ホームネットワークでホストされているレルムのリストに対して、User-Name属性のNAIを検証します。一致しない場合は、Access-Rejectが返されます。他のすべてのパケットはローカルサイトルールによって処理され、適切な応答パケットが送信されます。この応答パケットは、Access-Accept、Access-Challenge、またはAccess-Rejectです。
The RADIUS client receiving that response packet will match it to an outstanding request. If the client is part of a proxy, the proxy will then send that response packet in turn to the system that originated the Access-Request. This process continues until the response packet arrives at the NAS.
その応答パケットを受信するRADIUSクライアントは、それを未処理の要求と照合します。クライアントがプロキシの一部である場合、プロキシはその応答パケットをAccess-Requestを発信したシステムに順番に送信します。このプロセスは、応答パケットがNASに到着するまで続きます。
The proxies are typically stateful with respect to ongoing request/response packets but are stateless with respect to user sessions. That is, once a response has been sent by the proxy, it can discard all information about the request packet, other than what is needed for detecting retransmissions as per Section 2.2.2 of [RFC5080].
プロキシは通常、進行中の要求/応答パケットに関してはステートフルですが、ユーザーセッションに関してはステートレスです。つまり、プロキシによって応答が送信されると、[RFC5080]のセクション2.2.2に従って再送信を検出するために必要な情報以外の、要求パケットに関するすべての情報を破棄できます。
The same method is used to proxy Accounting-Request packets. Proxying both Access-Request and Accounting-Request packets allows proxies to connect visited networks to home networks for all AAA purposes.
同じ方法を使用して、アカウンティング要求パケットをプロキシします。 Access-RequestパケットとAccounting-Requestパケットの両方をプロキシすることで、プロキシはすべてのAAAの目的で訪問したネットワークをホームネットワークに接続できます。
[RFC5176] describes how CoA clients send packets to CoA servers. We note that a system comprising the CoA client is typically co-located with, or is the same as, the RADIUS server. Similarly, the CoA server is a system that is either co-located with or the same as the RADIUS client.
[RFC5176]では、CoAクライアントがCoAサーバーにパケットを送信する方法について説明しています。 CoAクライアントを構成するシステムは、通常、RADIUSサーバーと同じ場所にあるか、RADIUSサーバーと同じであることに注意してください。同様に、CoAサーバーは、RADIUSクライアントと同じ場所に配置されるか、RADIUSクライアントと同じシステムです。
In the case of packets sent inside of one network, the source and destination of CoA packets are locally determined. There is thus no need for standardization of that process, as networks are free to send CoA packets whenever they want, for whatever reason they want.
1つのネットワーク内で送信されるパケットの場合、CoAパケットの送信元と宛先はローカルで決定されます。したがって、ネットワークは、理由を問わず、必要なときにいつでもCoAパケットを自由に送信できるため、そのプロセスを標準化する必要はありません。
The situation is more complicated when proxies are involved. [RFC5176] suggests that CoA proxying is permitted, but [RFC5176] does not make any suggestions as to how that proxying should be done.
プロキシが関係する場合、状況はさらに複雑になります。 [RFC5176]はCoAプロキシが許可されることを示唆していますが、[RFC5176]はそのプロキシがどのように行われるべきかについては何も示唆していません。
If proxies were to track user sessions, it would be possible for a proxy to match an incoming CoA packet to a user session and then to proxy the CoA packet to the RADIUS client that originated the Access-Request for that session. There are many problems with such a scenario.
プロキシがユーザーセッションを追跡する場合、プロキシが着信CoAパケットをユーザーセッションに一致させ、そのセッションのアクセス要求を発信したRADIUSクライアントにCoAパケットをプロキシする可能性があります。このようなシナリオには多くの問題があります。
The CoA server might not, in fact, be co-located with the RADIUS client, in which case it might not have access to user session information for performing the reverse path forwarding.
実際には、CoAサーバーはRADIUSクライアントと同じ場所に配置されていない場合があります。その場合、リバースパス転送を実行するためのユーザーセッション情報にアクセスできない可能性があります。
The CoA server may be down, but there may be a different CoA server that could successfully process the packet. The CoA client should then fail over to a different CoA server. If the reverse path is restricted to be the same as the forward path, then such failover is not possible.
CoAサーバーがダウンしている可能性がありますが、パケットを正常に処理できる別のCoAサーバーが存在する可能性があります。次に、CoAクライアントは別のCoAサーバーにフェイルオーバーする必要があります。リバースパスがフォワードパスと同じになるように制限されている場合、このようなフェイルオーバーは不可能です。
In a roaming consortium, the proxies may forward traffic for tens of millions of users. Tracking each user session can be expensive and complicated, and doing so does not scale well. For that reason, most proxies do not record user sessions.
ローミングコンソーシアムでは、プロキシが数千万のユーザーのトラフィックを転送する場合があります。各ユーザーセッションの追跡は、費用がかかり、複雑になる可能性があり、そうすることはうまく拡張できません。そのため、ほとんどのプロキシはユーザーセッションを記録しません。
Even if the proxy recorded user sessions, [RFC5176] is silent on the topic of what attributes constitute "session identification attributes". That silence means it is impossible for a proxy to determine if a CoA packet matches a particular user session.
プロキシがユーザーセッションを記録した場合でも、[RFC5176]は、「セッション識別属性」を構成する属性については触れていません。この沈黙は、CoAパケットが特定のユーザーセッションと一致するかどうかをプロキシが判断できないことを意味します。
The result of all of these issues is that CoA proxying is impossible when using the behavior defined in [RFC5176].
これらすべての問題の結果として、[RFC5176]で定義された動作を使用すると、CoAプロキシは不可能になります。
The solution to the above problem is to use realm-based proxying on the reverse path, just as with the forward path. In order for the reverse path proxying to work, the proxy decision must be based on an attribute other than User-Name.
上記の問題の解決策は、フォワードパスと同様に、リバースパスでレルムベースのプロキシを使用することです。リバースパスプロキシが機能するためには、プロキシの決定がUser-Name以外の属性に基づいている必要があります。
The reverse path proxying can be done by using the Operator-Name attribute defined in Section 4.1 of [RFC5580]. We repeat a portion of that definition here for clarity:
リバースパスプロキシは、[RFC5580]のセクション4.1で定義されているOperator-Name属性を使用して実行できます。明確にするために、ここではその定義の一部を繰り返します。
This attribute carries the operator namespace identifier and the operator name. The operator name is combined with the namespace identifier to uniquely identify the owner of an access network.
この属性は、オペレーター名前空間IDおよびオペレーター名を保持します。オペレーター名と名前空間識別子を組み合わせて、アクセスネットワークの所有者を一意に識別します。
...followed a few paragraphs later by a description of the REALM namespace:
...いくつかの段落の後に、REALMネームスペースの説明が続きます。
REALM ('1' (0x31)):
REALM（ '1'（0x31））：
The REALM operator namespace can be used to indicate operator names based on any registered domain name. Such names are required to be unique, and the rights to use a given realm name are obtained coincident with acquiring the rights to use a particular Fully Qualified Domain Name (FQDN). ...
REALMオペレーター名前空間を使用して、登録済みのドメイン名に基づいてオペレーター名を示すことができます。このような名前は一意である必要があり、特定の領域名を使用する権利は、特定の完全修飾ドメイン名（FQDN）を使用する権利の取得と同時に取得されます。 ...
In short, the Operator-Name attribute contains an ASCII "1", followed by the realm of the visited network. For example, for the "example.com" realm, the Operator-Name attribute contains the text "1example.com". This information is precisely what is needed by intermediate nodes in order to perform CoA proxying.
つまり、Operator-Name属性にはASCII "1"が含まれ、その後に訪問先ネットワークのレルムが続きます。たとえば、「example.com」レルムの場合、Operator-Name属性にはテキスト「1example.com」が含まれています。この情報は、CoAプロキシを実行するために中間ノードが必要とするものです。
The remainder of this document describes how CoA proxying can be performed by using the Operator-Name attribute. We describe the following:
このドキュメントの残りの部分では、Operator-Name属性を使用してCoAプロキシを実行する方法について説明します。以下について説明します。
o how the forward path has to change in order to allow reverse path proxying
o リバースパスプロキシを許可するためにフォワードパスを変更する方法
o how reverse path proxying works
o リバースパスプロキシのしくみ
o how visited networks and home networks have to behave in order for CoA proxying to work
o CoAプロキシが機能するために訪問済みネットワークとホームネットワークがどのように動作する必要があるか
We note that as a proxied CoA packet is sent to only one destination, the Operator-Name attribute MUST NOT occur more than once in a packet. If a packet contains more than one Operator-Name, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in Section 2.8 of [RFC6929].
プロキシされたCoAパケットは1つの宛先にのみ送信されるため、Operator-Name属性はパケット内で複数回発生してはならないことに注意してください。 [RFC6929]のセクション2.8で説明されているように、パケットに複数のOperator-Nameが含まれている場合、実装では2番目以降の属性を「無効な属性」として扱う必要があります。
When a visited network proxies an Access-Request or Accounting-Request packet outside of its network, a visited network that wishes to support realm-based CoA proxying SHOULD include an Operator-Name attribute in the packet, as discussed in Section 4.1 of [RFC5580]. The contents of the Operator-Name attribute should be "1", followed by the realm name of the visited network. Where the visited network has more than one realm name, a "canonical" name SHOULD be chosen and used for all packets.
[RFC5580のセクション4.1で説明されているように、訪問済みネットワークがそのネットワーク外のAccess-RequestまたはAccounting-Requestパケットをプロキシする場合、レルムベースのCoAプロキシのサポートを希望する訪問済みネットワークは、パケットにOperator-Name属性を含める必要があります（SHOULD）。 ]。 Operator-Name属性の内容は「1」で、その後に訪問先ネットワークのレルム名が続く必要があります。訪問したネットワークに複数のレルム名がある場合、「正規の」名前を選択して、すべてのパケットに使用する必要があります（SHOULD）。
Visited networks MUST use a consistent value for Operator-Name for any one user session. That is, sending "1example.com" in an Access-Request packet and "1example.org" in an Accounting-Request packet for that same session is forbidden. Such behavior would make it look like a single user session was active simultaneously in two different visited networks, which is impossible.
訪問したネットワークは、1つのユーザーセッションのOperator-Nameに一貫した値を使用する必要があります。つまり、同じセッションのAccess-Requestパケットで「1example.com」を送信し、Accounting-Requestパケットで「1example.org」を送信することは禁止されています。このような動作により、1つのユーザーセッションが2つの異なる訪問先ネットワークで同時にアクティブであるように見えますが、これは不可能です。
Proxies that record user session information SHOULD also record Operator-Name. Proxies that do not record user session information do not need to record Operator-Name.
ユーザーセッション情報を記録するプロキシは、Operator-Nameも記録する必要があります（SHOULD）。ユーザーセッション情報を記録しないプロキシは、Operator-Nameを記録する必要はありません。
Home networks SHOULD record Operator-Name along with any other information that they record about user sessions. Home networks that expect to send CoA packets to visited networks MUST record Operator-Name for each user session that originates from a visited network. Failure to record Operator-Name would mean that the home network would not know where to send any CoA packets.
ホームネットワークは、ユーザーセッションについて記録するその他の情報とともにOperator-Nameを記録する必要があります（SHOULD）。訪問先ネットワークにCoAパケットを送信することを期待するホームネットワークは、訪問先ネットワークから発信された各ユーザーセッションのOperator-Nameを記録する必要があります。 Operator-Nameの記録に失敗すると、ホームネットワークはCoAパケットの送信先を認識できなくなります。
Networks that host both the RADIUS client and RADIUS server do not need to create, record, or track Operator-Name. That is, if the visited network and home network are the same, there is no need to use the Operator-Name attribute.
RADIUSクライアントとRADIUSサーバーの両方をホストするネットワークでは、Operator-Nameを作成、記録、または追跡する必要はありません。つまり、訪問先ネットワークとホームネットワークが同じ場合、Operator-Name属性を使用する必要はありません。
When a home network wishes to send a CoA-Request or Disconnect-Request packet to a visited network, it MUST include an Operator-Name attribute in the CoA packet. The value of the Operator-Name attribute MUST be the value that was recorded earlier for that user session.
ホームネットワークが訪問先ネットワークにCoA-RequestまたはDisconnect-Requestパケットを送信する場合は、CoAパケットにOperator-Name属性を含める必要があります。 Operator-Name属性の値は、そのユーザーセッションで以前に記録された値である必要があります。
The home network MUST look up the realm from the Operator-Name attribute in a logical "realm routing table", as discussed in Section 3 of [RFC7542]. That logical realm table is defined therein as:
[RFC7542]のセクション3で説明されているように、ホームネットワークは論理的な「レルムルーティングテーブル」のOperator-Name属性からレルムを検索する必要があります。その論理レルムテーブルは、次のように定義されています。
... a logical AAA routing table, where the "utf8-realm" portion acts as a key, and the values stored in the table are one or more "next hop" AAA servers.
...論理AAAルーティングテーブル。「utf8-realm」部分がキーとして機能し、テーブルに格納される値は1つ以上の「ネクストホップ」AAAサーバーです。
In order to support proxying of CoA packets, this table is extended to include a mapping between "utf8-realm" and one or more next-hop CoA servers.
CoAパケットのプロキシをサポートするために、このテーブルは "utf8-realm"と1つ以上のネクストホップCoAサーバー間のマッピングを含むように拡張されています。
When proxying CoA-Request and Disconnect-Request packets, the lookups will return data from the "CoA server" field instead of the "AAA server" field.
CoA-RequestおよびDisconnect-Requestパケットをプロキシする場合、ルックアップは「AAAサーバー」フィールドではなく「CoAサーバー」フィールドからデータを返します。
In practice, this process means that CoA proxying works exactly like "normal" RADIUS proxying, except that the proxy decision is made using the realm from the Operator-Name attribute instead of using the realm from the User-Name attribute.
実際には、このプロセスは、CoAプロキシが「通常の」RADIUSプロキシとまったく同じように機能することを意味します。ただし、プロキシの決定は、User-Name属性のレルムを使用するのではなく、Operator-Name属性のレルムを使用して行われます。
Proxies that receive the CoA packet will look up the realm from the Operator-Name attribute in a logical "realm routing table", as with home servers, above. The packet is then sent to the proxy for the realm that was found in that table. This process continues with any subsequent proxies until the packet reaches a public CoA server at the visited network.
CoAパケットを受信するプロキシは、上記のホームサーバーと同様に、論理的な「レルムルーティングテーブル」のOperator-Name属性からレルムを検索します。パケットは、そのテーブルで見つかったレルムのプロキシに送信されます。このプロセスは、パケットが訪問先ネットワークのパブリックCoAサーバーに到達するまで、後続のプロキシで続行されます。
Where the realm is unknown, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
レルムが不明な場合、プロキシは、値502（ "Request Not Routable"）を持つエラー原因属性を含むNAKパケットを返さなければなりません（MUST）。
Proxies that receive a CoA packet MUST NOT use the NAI from the User-Name attribute in order to make proxying decisions. Doing so would result in the CoA packet being forwarded to the home network, while the user's session is in the visited network.
CoAパケットを受信するプロキシは、プロキシ決定を行うために、User-Name属性からのNAIを使用してはなりません（MUST NOT）。これを行うと、ユーザーのセッションが訪問先ネットワークにある間、CoAパケットがホームネットワークに転送されます。
We also update Section 5 of [RFC5580] to permit CoA-Request and Disconnect-Request packets to contain zero or one instance of the Operator-Name attribute.
また、[RFC5580]のセクション5を更新して、CoA-RequestおよびDisconnect-Requestパケットに、Operator-Name属性のインスタンスが0または1つ含まれることを許可します。
After some proxying, the CoA packet will be received by the CoA server in the visited network. That CoA server MUST validate the NAI in the Operator-Name attribute against the list of realms hosted by the visited network. If the realm is not found, then the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
プロキシを行った後、訪問先ネットワークのCoAサーバーがCoAパケットを受信します。そのCoAサーバーは、訪問したネットワークによってホストされているレルムのリストに対してOperator-Name属性のNAIを検証する必要があります。レルムが見つからない場合、CoAサーバーは値502（ "Request Not Routable"）のエラー原因属性を含むNAKパケットを返さなければなりません（MUST）。
Some home networks will not have permission to send CoA packets to the visited network. The CoA server SHOULD therefore also validate the NAI contained in the User-Name attribute. If the home network is not permitted to send CoA packets to this visited network, then the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
一部のホームネットワークには、訪問先ネットワークにCoAパケットを送信する権限がありません。したがって、CoAサーバーは、User-Name属性に含まれるNAIも検証する必要があります（SHOULD）。ホームネットワークがこの訪問先ネットワークへのCoAパケットの送信を許可されていない場合、CoAサーバーは値502（ "Request Not Routable"）のエラー原因属性を含むNAKパケットを返さなければなりません（MUST）。
These checks make it more difficult for a malicious home network to scan roaming networks in order to determine which visited network hosts which realm. That information should be known to all parties in advance and exchanged via methods outside the scope of this specification. Those methods will typically be in the form of contractual relationships between parties or membership in a roaming consortium.
これらのチェックにより、悪意のあるホームネットワークがローミングネットワークをスキャンして、どの訪問先ネットワークホストがどのレルムをホストしているかを判断することがより困難になります。その情報は、事前にすべての関係者に知らされ、この仕様の範囲外の方法で交換されるべきです。これらの方法は、通常、当事者間の契約関係またはローミングコンソーシアムのメンバーシップの形式になります。
The CoA server in the visited network will also ensure that the Operator-NAS-Identifier attribute is known, as described below. If the attribute matches a known NAS, then the packet will be sent to that NAS. Otherwise, the CoA server MUST return a NAK packet that contains an Error-Cause Attribute having value 403 ("NAS Identification Mismatch").
訪問先ネットワークのCoAサーバーは、以下で説明するように、Operator-NAS-Identifier属性が確実に認識されるようにします。属性が既知のNASと一致する場合、パケットはそのNASに送信されます。それ以外の場合、CoAサーバーは、値403（「NAS識別ミスマッチ」）のエラー原因属性を含むNAKパケットを返さなければなりません（MUST）。
All other received packets are processed as per local site rules and will result in an appropriate response packet being sent. This process mirrors the method used to process Access-Request and Accounting-Request packets (described above).
他のすべての受信パケットはローカルサイトのルールに従って処理され、適切な応答パケットが送信されます。このプロセスは、Access-RequestおよびAccounting-Requestパケット（上記）の処理に使用される方法を反映しています。
Processing done by the visited network will normally include sending the CoA packet to the NAS, having the NAS process it, and then returning any response packets back up the proxy chain to the home server.
訪問先ネットワークで行われる処理には、通常、CoAパケットをNASに送信し、NASに処理させてから、応答パケットをプロキシチェーンに戻し、ホームサーバーに戻します。
The only missing piece here is the procedure by which the visited network gets the packet from its public CoA server to the NAS. The visited network could use NAS-Identifier, NAS-IP-Address, or NAS-IPv6-Address, but these attributes may have been edited by an intermediate proxy or the attributes may be missing entirely.
ここで唯一欠けているのは、訪問したネットワークがそのパブリックCoAサーバーからNASにパケットを取得する手順です。訪問先のネットワークはNAS-Identifier、NAS-IP-Address、またはNAS-IPv6-Addressを使用できますが、これらの属性は中間プロキシによって編集されたか、属性が完全に欠落している可能性があります。
These attributes may be incorrect because proxies forwarding Access-Request packets often rewrite them for internal policy reasons. These attributes may be missing, because the visited network may not want all upstream proxies and home servers to have detailed information about the internals of its private network and may remove them itself.
Access-Requestパケットを転送するプロキシは、内部ポリシーの理由でそれらを頻繁に書き換えるため、これらの属性は正しくない場合があります。訪問先のネットワークがすべてのアップストリームプロキシとホームサーバーにプライベートネットワークの内部に関する詳細情報を持たせたくない場合があり、それらを削除する場合があるため、これらの属性が欠落している可能性があります。
We therefore need a way to identify a NAS in the visited network via a method that affords privacy and does not use any existing attributes. Our solution is to define an Operator-NAS-Identifier attribute, which identifies an individual NAS in the visited network.
したがって、プライバシーを提供し、既存の属性を使用しない方法で、訪問先ネットワークのNASを識別する方法が必要です。私たちのソリューションは、訪問したネットワーク内の個々のNASを識別するOperator-NAS-Identifier属性を定義することです。
The Operator-NAS-Identifier attribute is an opaque token that identifies an individual NAS in a visited network. It MAY appear in the following packets: Access-Request, Accounting-Request, CoA-Request, or Disconnect-Request. Operator-NAS-Identifier MUST NOT appear in any other packets.
Operator-NAS-Identifier属性は、訪問したネットワーク内の個々のNASを識別する不透明なトークンです。次のパケットに表示される場合があります：Access-Request、Accounting-Request、CoA-Request、またはDisconnect-Request。 Operator-NAS-Identifierは、他のパケットに現れてはいけません。
Operator-NAS-Identifier MAY occur in a packet if the packet also contains an Operator-Name attribute. Operator-NAS-Identifier MUST NOT appear in a packet if there is no Operator-Name in the packet. As each proxied CoA packet is sent to only one NAS, the Operator-NAS-Identifier attribute MUST NOT occur more than once in a packet. If a packet contains more than one Operator-NAS-Identifier, implementations MUST treat the second and subsequent attributes as "invalid attributes", as discussed in Section 2.8 of [RFC6929].
Operator-NAS-Identifierは、パケットにOperator-Name属性も含まれている場合、パケット内で発生する場合があります。パケットにOperator-Nameがない場合、Operator-NAS-Identifierはパケットに現れてはなりません（MUST NOT）。プロキシされた各CoAパケットは1つのNASにのみ送信されるため、Operator-NAS-Identifier属性はパケット内で複数回発生してはなりません。 [RFC6929]のセクション2.8で説明されているように、パケットに複数のOperator-NAS-Identifierが含まれている場合、実装では2番目以降の属性を「無効な属性」として扱う必要があります。
An Operator-NAS-Identifier attribute SHOULD be added to an Access-Request or Accounting-Request packet by a visited network, before proxying a packet to an external RADIUS server. When the Operator-NAS-Identifier attribute is added to a packet, the following attributes SHOULD be deleted from the packet: NAS-IP-Address, NAS-IPv6-Address, and NAS-Identifier. If these attributes are deleted, the proxy MUST then add a new NAS-Identifier attribute, in order to satisfy the requirements of Section 4.1 of [RFC2865] and Section 4.1 of [RFC2866]. The contents of the new NAS-Identifier attribute SHOULD be the realm name of the visited network.
Operator-NAS-Identifier属性は、外部RADIUSサーバーにパケットをプロキシする前に、アクセスしたネットワークによってAccess-RequestまたはAccounting-Requestパケットに追加する必要があります（SHOULD）。 Operator-NAS-Identifier属性がパケットに追加されると、NAS-IP-Address、NAS-IPv6-Address、およびNAS-Identifierの属性をパケットから削除する必要があります（SHOULD）。これらの属性が削除された場合、プロキシは、[RFC2865]のセクション4.1および[RFC2866]のセクション4.1の要件を満たすために、新しいNAS-Identifier属性を追加する必要があります。新しいNAS-Identifier属性の内容は、訪問先ネットワークのレルム名である必要があります（SHOULD）。
When a server receives a packet that already contains an Operator-NAS-Identifier attribute, no such editing is performed.
サーバーがOperator-NAS-Identifier属性をすでに含むパケットを受信すると、そのような編集は実行されません。
The Operator-NAS-Identifier attribute MUST NOT be added to any packet by any other proxy or server in the network. Only the visited network (i.e., the operator) can name a NAS that is inside of the visited network.
Operator-NAS-Identifier属性は、ネットワーク内の他のプロキシまたはサーバーによってパケットに追加してはなりません（MUST NOT）。訪問されたネットワーク（つまり、オペレーター）のみが、訪問されたネットワーク内にあるNASに名前を付けることができます。
The result of these requirements is that for everyone outside of the visited network there is only one NAS: the visited network itself. Also, the visited network is able to identify its own NASes to its own satisfaction.
これらの要件の結果として、訪問先ネットワークの外部にいるすべての人に対して、NASは1つしかありません。訪問先ネットワーク自体です。また、訪問したネットワークは、自分のNASを自分の満足感まで識別することができます。
This usage of the Operator-NAS-Identifier attribute parallels the Operator-Name attribute as defined in Section 4.1 of [RFC5580].
Operator-NAS-Identifier属性のこの使用法は、[RFC5580]のセクション4.1で定義されているOperator-Name属性に対応しています。
The Operator-NAS-Identifier attribute is defined as follows.
Operator-NAS-Identifier属性は次のように定義されます。
Description
説明
An opaque token describing the NAS a user has logged into.
ユーザーがログインしたNASを説明する不透明なトークン。
Type
タイプ
241.8 (assigned by IANA from the "short extended space" [RFC6929] of the "RADIUS Attribute Types" registry).
241.8（「RADIUS Attribute Types」レジストリの「short extended space」[RFC6929]からIANAによって割り当てられます）。
Length
長さ
4 to 35.
４ と ３５。
Implementations supporting this attribute MUST be able to handle between one (1) and thirty-two (32) octets of data. Implementations creating an Operator-NAS-Identifier attribute MUST NOT create attributes with more than sixty-four (64) octets of data. A 32-octet string should be more than sufficient for future uses.
この属性をサポートする実装は、1オクテットと32オクテットの間のデータを処理できなければなりません（MUST）。 Operator-NAS-Identifier属性を作成する実装は、64オクテットを超えるデータを持つ属性を作成してはなりません。 32オクテットの文字列は、将来の使用には十分以上のはずです。
Data Type
データ・タイプ
The data type of this field is "string". See Section 3.5 of [RFC8044] for a definition.
このフィールドのデータ型は「文字列」です。定義については、[RFC8044]のセクション3.5を参照してください。
Value
値
This attribute contains an opaque token that can only be interpreted by the visited network.
この属性には、訪問したネットワークでのみ解釈できる不透明なトークンが含まれています。
This token MUST allow the visited network to direct the packet to the NAS for the user's session. In practice, this requirement means that the visited network has two practical methods for creating the value.
このトークンは、訪問したネットワークがユーザーのセッションのためにパケットをNASに送信できるようにする必要があります。実際には、この要件は、訪問先のネットワークに値を作成するための2つの実用的な方法があることを意味します。
The first method is to create an opaque token per NAS and then to store that information in a database. The database can be configured to allow querying by NAS IP address in order to find the correct Operator-NAS-Identifier. The database can also be configured to allow querying by Operator-NAS-Identifier in order to find the correct NAS IP address.
最初の方法は、NASごとに不透明なトークンを作成し、その情報をデータベースに格納することです。正しいOperator-NAS-Identifierを見つけるために、NAS IPアドレスによるクエリを許可するようにデータベースを構成できます。正しいNAS IPアドレスを見つけるために、Operator-NAS-Identifierによるクエリを許可するようにデータベースを構成することもできます。
The second method is to obfuscate the NAS IP address using information known locally by the visited network -- for example, by XORing it with a locally known secret key. The output of that obfuscation operation is data that can be used as the value of Operator-NAS-Identifier. On reception of a CoA packet, the locally known information can be used to unobfuscate the value of Operator-NAS-Identifier, in order to determine the actual NAS IP address.
2番目の方法は、訪問先ネットワークでローカルに既知の情報を使用して、NAS IPアドレスを難読化することです。たとえば、ローカルで既知の秘密鍵でXORを実行します。その難読化操作の出力は、Operator-NAS-Identifierの値として使用できるデータです。 CoAパケットの受信時に、ローカルで既知の情報を使用して、Operator-NAS-Identifierの値を難読化せずに、実際のNAS IPアドレスを判別できます。
Note that there is no requirement that the value of Operator-NAS-Identifier be checked for integrity. Modification of the value can only result in the erroneous transaction being rejected.
Operator-NAS-Identifierの値の整合性をチェックする必要はないことに注意してください。値を変更しても、誤ったトランザクションが拒否されるだけです。
We note that the Access-Request and Accounting-Request packets often contain the Media Access Control (MAC) address of the NAS. There is therefore no requirement that Operator-NAS-Identifier obfuscate or hide in any way the total number of NASes in a visited network. That information is already public knowledge.
Access-RequestおよびAccounting-Requestパケットには、NASのメディアアクセスコントロール（MAC）アドレスが含まれていることがよくあります。したがって、Operator-NAS-Identifierが、訪問したネットワーク内のNASの総数を何らかの方法で難読化または非表示にする必要はありません。その情報はすでに公開されています。
The Operator-NAS-Identifier attribute MUST be stored by a home server along with any user session identification attributes. When sending a CoA packet for a user session, the home server MUST include verbatim any Operator-NAS-Identifier it has recorded for that session.
Operator-NAS-Identifier属性は、ユーザーセッション識別属性とともにホームサーバーに格納する必要があります。ユーザーセッションのCoAパケットを送信する場合、ホームサーバーは、そのセッション用に記録したすべてのOperator-NAS-Identifierをそのまま含める必要があります。
A home server MUST NOT send CoA packets for users of other networks. The next few sections describe how other participants in the RADIUS ecosystem can help enforce this requirement.
ホームサーバーは、他のネットワークのユーザーにCoAパケットを送信してはなりません（MUST NOT）。次のいくつかのセクションでは、RADIUSエコシステムの他の参加者がこの要件の適用をどのように支援できるかについて説明します。
A visited network that receives a CoA packet that will be proxied to a NAS MUST perform all of the operations required for proxies; see Section 4.3.2. We specify this requirement because we assume that the visited network has a proxy between the NAS and any external (i.e., third-party) proxy. Situations where a NAS sends packets directly to a third-party RADIUS server are outside the scope of this specification.
NASにプロキシされるCoAパケットを受信する訪問先ネットワークは、プロキシに必要なすべての操作を実行する必要があります。セクション4.3.2を参照してください。訪問先ネットワークにはNASと外部（つまり、サードパーティ）プロキシの間にプロキシがあると想定しているため、この要件を指定します。 NASがサードパーティのRADIUSサーバーに直接パケットを送信する状況は、この仕様の範囲外です。
The visited network uses the contents of the Operator-NAS-Identifier attribute to determine which NAS will receive the packet.
訪問したネットワークは、Operator-NAS-Identifier属性の内容を使用して、どのNASがパケットを受信するかを決定します。
The visited network MUST remove the Operator-Name and Operator-NAS-Identifier attributes from a given CoA packet prior to sending that packet to the final CoA server (i.e., NAS). This step is necessary due to the limits specified in Section 2.3 of [RFC5176].
訪問したネットワークは、最終的なCoAサーバー（つまり、NAS）にパケットを送信する前に、所定のCoAパケットからOperator-NameおよびOperator-NAS-Identifier属性を削除する必要があります。 [RFC5176]のセクション2.3で指定されている制限のため、この手順が必要です。
The visited network MUST also ensure that the CoA packet sent to the NAS contains one of the following attributes: NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier. This step is the inverse of the removal suggested above in Section 3.4.
訪問先のネットワークは、NASに送信されるCoAパケットに、NAS-IP-Address、NAS-IPv6-Address、またはNAS-Identifierのいずれかの属性が含まれていることも確認する必要があります。このステップは、上記のセクション3.4で提案された削除の逆です。
In general, the NAS should only receive attributes that identify or modify a user's session. It is not appropriate to send to a NAS attributes that are used only for inter-proxy signaling.
一般に、NASはユーザーのセッションを識別または変更する属性のみを受信する必要があります。プロキシ間シグナリングにのみ使用される属性をNASに送信することは適切ではありません。
There are a number of requirements on both CoA proxies and RADIUS proxies. For the purpose of this section, we assume that each RADIUS proxy shares a common administration with a corresponding CoA proxy and that the two systems can communicate electronically. There is no requirement that these systems be co-located.
CoAプロキシとRADIUSプロキシの両方にいくつかの要件があります。このセクションでは、各RADIUSプロキシが対応するCoAプロキシと共通の管理を共有し、2つのシステムが電子的に通信できることを前提としています。これらのシステムを同じ場所に配置する必要はありません。
Section 6.1 of [RFC5176] has some security requirements on proxies that handle CoA-Request and Disconnect-Request packets:
[RFC5176]のセクション6.1には、CoA-RequestおよびDisconnect-Requestパケットを処理するプロキシに関するいくつかのセキュリティ要件があります。
... a proxy MAY perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized Dynamic Authorization Client.
...プロキシは、「リバースパス転送」（RPF）チェックを実行して、Disconnect-RequestまたはCoA-Requestが承認された動的認証クライアントから発信されていることを確認できます（MAY）。
We strengthen that requirement by saying that a proxy MUST perform a reverse path forwarding check to verify that a CoA packet originates from an authorized Dynamic Authorization Client. Without this check, a proxy may forward packets from misconfigured or malicious parties and thus contribute to the problem instead of preventing it. Where the check fails, the proxy MUST return a NAK packet that contains an Error-Cause Attribute having value 502 ("Request Not Routable").
プロキシがリバースパス転送チェックを実行して、CoAパケットが許可された動的認証クライアントから発信されていることを確認する必要があることを明言することで、この要件を強化します。このチェックがないと、プロキシは、設定が間違っているか悪意のあるパーティからのパケットを転送し、問題を防ぐのではなく、問題の原因となる場合があります。チェックが失敗した場合、プロキシは値502（ "Request Not Routable"）を持つエラー原因属性を含むNAKパケットを返さなければなりません（MUST）。
Proxies that record user session information SHOULD verify the contents of a received CoA packet against the recorded data for that user session. If the proxy determines that the information in the packet does not match the recorded user session, it SHOULD return a NAK packet that contains an Error-Cause Attribute having value 503 ("Session Context Not Found"). These checks cannot be mandated due to the fact that [RFC5176] offers no advice on which attributes are used to identify a user's session.
ユーザーセッション情報を記録するプロキシは、受信したCoAパケットの内容を、そのユーザーセッションの記録されたデータと照合して検証する必要があります（SHOULD）。パケットの情報が記録されたユーザーセッションと一致しないとプロキシが判断した場合、プロキシは値503（「セッションコンテキストが見つかりません」）のエラー原因属性を含むNAKパケットを返す必要があります（SHOULD）。これらのチェックは、[RFC5176]がユーザーのセッションを識別するためにどの属性が使用されるかについてのアドバイスを提供しないという事実のために義務付けられません。
Because a RADIUS proxy will see Access-Request and Accounting-Request packets, we recognize that it will have sufficient information to forge CoA packets. The RADIUS proxy will thus have the ability to subsequently disconnect any user who was authenticated through itself.
RADIUSプロキシはAccess-RequestパケットとAccounting-Requestパケットを参照するため、CoAパケットを偽造するのに十分な情報があることを認識しています。したがって、RADIUSプロキシは、その後、自身を介して認証されたユーザーを切断することができます。
We suggest that the real-world effect of this security problem is minimal. RADIUS proxies can already return Access-Accept or Access-Reject for Access-Request packets and can change authorization attributes contained in an Access-Accept. Allowing a proxy to change (or disconnect) a user session post-authentication is not substantially different from changing (or refusing to connect) a user session during the initial process of authentication.
このセキュリティ問題の実際の影響は最小限であることをお勧めします。 RADIUSプロキシは、Access-Requestパケットに対してAccess-AcceptまたはAccess-Rejectをすでに返し、Access-Acceptに含まれる認証属性を変更できます。認証後のユーザーセッションの変更（または切断）をプロキシに許可することは、認証の初期プロセス中にユーザーセッションを変更（または接続を拒否）することと実質的に変わりません。
The biggest problem is that there are no provisions in RADIUS for "end-to-end" security. That is, the visited network and home network cannot communicate privately in the presence of proxies. This limitation originates from the design of RADIUS for Access-Request and Accounting-Request packets. That limitation is then carried over to CoA-Request and Disconnect-Request packets.
最大の問題は、RADIUSに「エンドツーエンド」のセキュリティに関する規定がないことです。つまり、訪問先ネットワークとホームネットワークは、プロキシの存在下では非公開で通信できません。この制限は、Access-RequestおよびAccounting-RequestパケットのRADIUSの設計に起因します。その後、その制限はCoA-RequestおよびDisconnect-Requestパケットに引き継がれます。
We therefore cannot prevent proxies or home servers from forging CoA packets. We can only create scenarios where that forgery is hard to perform, is likely to be detected, and/or has no effect.
したがって、プロキシやホームサーバーがCoAパケットを偽造するのを防ぐことはできません。私たちは、その偽造が実行するのが難しい、検出される可能性が高い、および/または効果がないシナリオのみを作成できます。
Section 2.3 of [RFC5176] makes the following requirement for CoA servers:
[RFC5176]のセクション2.3では、CoAサーバーに次の要件を課しています。
In CoA-Request and Disconnect-Request packets, all attributes MUST be treated as mandatory.
CoA-RequestおよびDisconnect-Requestパケットでは、すべての属性を必須として扱う必要があります。
This requirement is too stringent for a CoA proxy. Only the final CoA server (i.e., NAS) can decide which attributes are mandatory and which are not.
この要件は、CoAプロキシには厳しすぎます。最終的なCoAサーバー（つまり、NAS）のみが必須属性と必須属性を決定できます。
Instead, in the case of a CoA proxy, we say that all attributes MUST NOT be treated as mandatory. Proxies implementing this specification MUST perform proxying based on Operator-Name. Other schemes are possible but are not discussed here. Proxies SHOULD forward all packets either "as is" or with minimal changes.
代わりに、CoAプロキシの場合、すべての属性を必須として扱うことはできません。この仕様を実装するプロキシは、Operator-Nameに基づいてプロキシを実行する必要があります。他のスキームも可能ですが、ここでは説明しません。プロキシは、すべてのパケットを「そのまま」または最小限の変更で転送する必要があります（SHOULD）。
We note that some NAS implementations currently treat signaling attributes as mandatory. For example, some NAS implementations will NAK any CoA packet that contains a Proxy-State attribute. While this behavior is based on a straightforward reading of the above text, it causes problems in practice.
現在、一部のNAS実装では、シグナリング属性を必須として扱います。たとえば、一部のNAS実装は、Proxy-State属性を含むCoAパケットをNAKにします。この動作は上記のテキストを直接読んだことに基づいていますが、実際には問題が発生します。
We update Section 2.3 of [RFC5176] as follows: in CoA-Request and Disconnect-Request packets, the NAS MUST NOT treat as mandatory any attribute that is known to not affect the user's session -- for example, the Proxy-State attribute. Proxy-State is an attribute used for proxy-to-proxy signaling. It cannot affect the user's session, and therefore Proxy-State (and similar attributes) MUST be ignored by the NAS.
[RFC5176]のセクション2.3を次のように更新します。CoA-RequestパケットとDisconnect-Requestパケットでは、NASは、ユーザーのセッションに影響を与えないことがわかっている属性（Proxy-State属性など）を必須として扱わないでください。 Proxy-Stateは、プロキシからプロキシへのシグナリングに使用される属性です。ユーザーのセッションに影響を与えることはできないため、NASはProxy-State（および同様の属性）を無視する必要があります。
When Operator-Name and/or Operator-NAS-Identifier are received by a proxy, the proxy MUST pass those attributes through unchanged. This requirement applies to all proxies, including proxies that forward any or all of Access-Request, Accounting-Request, CoA-Request, and Disconnect-Request packets.
Operator-NameやOperator-NAS-Identifierがプロキシによって受信された場合、プロキシはそれらの属性を変更せずに渡す必要があります。この要件は、Access-Request、Accounting-Request、CoA-Request、Disconnect-Requestパケットのいずれかまたはすべてを転送するプロキシを含む、すべてのプロキシに適用されます。
All attributes added by a RADIUS proxy when sending packets from the visited network to the home network MUST be removed by the corresponding CoA proxy from packets traversing the reverse path. That is, any editing of attributes that is done on the "forward" path MUST be undone on the "reverse" path.
訪問先ネットワークからホームネットワークにパケットを送信するときにRADIUSプロキシによって追加されるすべての属性は、対応するCoAプロキシによって、逆パスを通過するパケットから削除する必要があります。つまり、「順方向」パスで行われた属性の編集は、「逆方向」パスで元に戻す必要があります。
The result is that a NAS will only ever receive CoA packets that either contain (1) attributes sent by the NAS to its local RADIUS server or (2) attributes that are sent by the home server in order to perform a change of authorization.
その結果、NASは、（1）NASからローカルRADIUSサーバーに送信された属性、または（2）許可の変更を実行するためにホームサーバーから送信された属性を含むCoAパケットのみを受信します。
Finally, we extend the above requirement not only to Operator-Name and Operator-NAS-Identifier but also to any future attributes that are added for proxy-to-proxy signaling.
最後に、上記の要件をOperator-NameおよびOperator-NAS-Identifierだけでなく、プロキシからプロキシへのシグナリングに追加される将来の属性にも拡張します。
This section describes how the two attributes work together to permit CoA proxying.
このセクションでは、CoAプロキシを許可するために2つの属性がどのように連携するかについて説明します。
In this scenario, we follow a roaming user who is attempting to log in to a visited network. The login attempt is done via a NAS in the visited network. That NAS will send an Access-Request packet to the visited RADIUS server. The visited RADIUS server will see that the user is roaming and will add an Operator-Name attribute, with value "1" followed by its own realm name, e.g., "1example.com". The visited RADIUS server MAY also add an Operator-NAS-Identifier attribute. The NAS identification attributes are also edited, as required by Section 3.4, above.
このシナリオでは、アクセスしたネットワークにログインしようとしているローミングユーザーを追跡します。ログインの試行は、アクセスしたネットワークのNASを介して行われます。そのNASは、アクセスしたRADIUSサーバーにAccess-Requestパケットを送信します。訪問したRADIUSサーバーは、ユーザーがローミングしていることを確認し、値「1」の後に独自のレルム名が続く「1example.com」などのOperator-Name属性を追加します。訪問したRADIUSサーバーは、Operator-NAS-Identifier属性も追加する場合があります。上記のセクション3.4で要求されているように、NAS識別属性も編集されます。
The visited server will then proxy the authentication request to an upstream server. That server may be the home server, or it may be a proxy. In the case of a proxy, the proxy will forward the packet until the packet reaches the home server.
アクセスしたサーバーは、認証要求を上流のサーバーにプロキシします。そのサーバーは、ホームサーバーでも、プロキシでもかまいません。プロキシの場合、パケットはホームサーバーに到達するまでプロキシがパケットを転送します。
The home server will record the Operator-Name and Operator-NAS-Identifier attributes, along with other information about the user's session, if those attributes are present in a packet.
これらの属性がパケットに存在する場合、ホームサーバーは、Operator-NameおよびOperator-NAS-Identifier属性と、ユーザーのセッションに関するその他の情報を記録します。
At some later point in time, the home server determines that (1) a user session should have its authorization changed or (2) the user should be disconnected. The home server looks up the Operator-Name and Operator-NAS-Identifier attributes, along with other user session identifiers as described in [RFC5176]. The home server then looks up the realm from the Operator-Name attribute in the logical AAA routing table, in order to find the next-hop CoA server for that realm (which may be a proxy). The CoA-Request is then sent to that CoA server.
後で、ホームサーバーは、（1）ユーザーセッションの認証を変更するか、（2）ユーザーを切断する必要があると判断します。 [RFC5176]で説明されているように、ホームサーバーは、Operator-Name属性とOperator-NAS-Identifier属性、および他のユーザーセッション識別子を検索します。次に、ホームサーバーは論理AAAルーティングテーブルのOperator-Name属性からレルムを検索して、そのレルム（プロキシの場合がある）のネクストホップCoAサーバーを見つけます。次に、CoA要求がそのCoAサーバーに送信されます。
The CoA server receives the request and, if it is a proxy, performs a lookup similar to the lookup done by the home server. The packet is then proxied repeatedly until it reaches the visited network.
CoAサーバーは要求を受信し、それがプロキシの場合は、ホームサーバーによって実行されるルックアップと同様のルックアップを実行します。次に、パケットは訪問先ネットワークに到達するまで繰り返しプロキシされます。
If the proxy cannot find a destination for the request or if no Operator-Name attribute exists in the request, the proxy will return a CoA-NAK with Error-Cause 502 ("Request Not Routable").
プロキシが要求の宛先を見つけられない場合、または要求にOperator-Name属性が存在しない場合、プロキシはCoA-NAKをエラー原因502（ "Request Not Routable"）で返します。
The visited network will receive the CoA-Request packet and will use the Operator-NAS-Identifier attribute (if available) to determine which local CoA server (i.e., NAS) the packet should be sent to. If there is no Operator-NAS-Identifier attribute, the visited network may use other means to locate the NAS, such as consulting a local database that tracks user sessions.
訪問先ネットワークはCoA要求パケットを受信し、Operator-NAS-Identifier属性（使用可能な場合）を使用して、パケットの送信先となるローカルCoAサーバー（つまり、NAS）を決定します。 Operator-NAS-Identifier属性がない場合、訪問先ネットワークは、ユーザーセッションを追跡するローカルデータベースを調べるなど、他の手段を使用してNASを見つけることができます。
The Operator-Name and Operator-NAS-Identifier attributes are then removed from the packet; one of NAS-IP-Address, NAS-IPv6-Address, or NAS-Identifier is added to the packet; and the packet is then sent to the CoA server.
次に、Operator-NameおよびOperator-NAS-Identifier属性がパケットから削除されます。 NAS-IP-Address、NAS-IPv6-Address、またはNAS-Identifierのいずれかがパケットに追加されます。その後、パケットはCoAサーバーに送信されます。
If no CoA server can be found, the visited network returns a CoA-NAK with Error-Cause 403 ("NAS Identification Mismatch").
CoAサーバーが見つからない場合、訪問したネットワークはエラー原因403（「NAS識別ミスマッチ」）でCoA-NAKを返します。
Any response from the CoA server (NAS) is returned to the home network via the normal method of returning responses to requests.
CoAサーバー（NAS）からの応答はすべて、要求に応答を返す通常の方法でホームネットワークに返されます。
This specification incorporates by reference Section 11 of [RFC6929]. In short, RADIUS has many known issues; those issues are discussed in detail in [RFC6929] and do not need to be repeated here.
この仕様は、[RFC6929]のセクション11を参照として組み込んでいます。つまり、RADIUSには多くの既知の問題があります。これらの問題は[RFC6929]で詳細に説明されており、ここで繰り返す必要はありません。
This specification adds one new attribute and defines new behavior for RADIUS proxying. As this behavior mirrors existing RADIUS proxying, we do not believe that it introduces any new security issues. We note, however, that RADIUS proxying has many inherent security issues.
この仕様では、1つの新しい属性が追加され、RADIUSプロキシの新しい動作が定義されています。この動作は既存のRADIUSプロキシを反映しているため、新しいセキュリティ問題が発生するとは考えていません。ただし、RADIUSプロキシには多くの固有のセキュリティ問題があることに注意してください。
The requirement that packets be signed with a shared secret means that a CoA packet can only be received from a trusted party or, transitively, received from a third party via a trusted party. This security provision of the base RADIUS protocol makes it impossible for untrusted parties to affect the user's session.
共有秘密でパケットに署名する必要があるということは、CoAパケットは信頼できる当事者からのみ、または推移的には信頼できる当事者を介して第三者から受信できることを意味します。この基本RADIUSプロトコルのセキュリティ対策により、信頼できない当事者がユーザーのセッションに影響を与えることができなくなります。
When RADIUS proxying is performed, all packets are signed on a hop-by-hop basis. Any intermediate proxy can therefore forge packets, replay packets, or modify the contents of any packet. Any system receiving correctly signed packets must accept them at face value and is unable to detect any forgery, replay, or modifications. As a result, the secure operation of such a system depends largely on trust instead of on technical means.
RADIUSプロキシが実行されると、すべてのパケットがホップバイホップで署名されます。したがって、中間プロキシは、パケットの偽造、パケットの再生、またはパケットの内容の変更を行うことができます。正しく署名されたパケットを受信するシステムは、額面どおりにそれらを受け入れる必要があり、偽造、リプレイ、または変更を検出できません。その結果、そのようなシステムの安全な運用は、技術的手段ではなく信頼に大きく依存します。
CoA packet proxying has all of the same issues as those noted above. We note that the proxies that see and can modify CoA packets are generally the same proxies that can see or modify Access-Request and Accounting-Request packets. As such, there are few additional security implications in allowing CoA proxying.
CoAパケットプロキシには、上記と同じ問題がすべてあります。 CoAパケットを表示および変更できるプロキシは、一般に、Access-RequestおよびAccounting-Requestパケットを表示または変更できるプロキシと同じであることに注意してください。そのため、CoAプロキシを許可することによる追加のセキュリティへの影響はほとんどありません。
The main security implication that remains is that home networks now have the ability to disconnect or change the authorization of users in a visited network. As this capability is only enabled when mutual agreement is in place, and only for those parties who can already control user sessions, there are no new security issues with this specification.
残っている主なセキュリティ上の影響は、ホームネットワークが、アクセスしたネットワーク内のユーザーの認証を切断または変更できるようになったことです。この機能は、相互の合意が確立されている場合にのみ有効であり、すでにユーザーセッションを制御できる当事者に対してのみ有効であるため、この仕様に新しいセキュリティの問題はありません。
Nothing in this specification depends on the security of the Operator-NAS-Identifier attribute. The entire process would work exactly the same if the Operator-NAS-Identifier attribute simply contained the NAS IP address that is hosting the user's session. The only real downside in that situation would be that external parties would see some additional private information about the visited network. They would still, however, be unable to leverage that information to do anything malicious.
この仕様は、Operator-NAS-Identifier属性のセキュリティに依存しません。 Operator-NAS-Identifier属性にユーザーのセッションをホストしているNAS IPアドレスが含まれている場合、プロセス全体はまったく同じように機能します。その状況での唯一の本当の欠点は、外部の当事者が訪問したネットワークに関する追加のプライベート情報を見るということです。ただし、その情報を悪用して悪意のある行為を行うことはできません。
The main reason to use an opaque token for the Operator-NAS-Identifier attribute is that there is no compelling reason to make the information public. We therefore recommend that the value be simply an opaque token. We also state that there is no requirement for integrity protection or replay detection of this attribute. The rest of the RADIUS protocol ensures that modification or replay of the Operator-NAS-Identifier attribute will either have no effect or have the same effect as if the value had not been modified.
Operator-NAS-Identifier属性に不透明なトークンを使用する主な理由は、情報を公開する説得力のある理由がないためです。したがって、値は単に不透明なトークンにすることをお勧めします。また、この属性の整合性保護やリプレイ検出の要件はないと述べています。 RADIUSプロトコルの残りの部分は、Operator-NAS-Identifier属性の変更または再生が効果がないか、値が変更されていない場合と同じ効果があることを保証します。
Trusted parties can modify a user's session on the NAS only when they have sufficient information to identify that session. In practice, this limitation means that those parties already have access to the user's session information. In other words, those parties are the proxies who are already forwarding Access-Request and Accounting-Request packets.
信頼できる当事者は、そのセッションを識別するのに十分な情報を持っている場合にのみ、NAS上のユーザーのセッションを変更できます。実際には、この制限は、それらの当事者がすでにユーザーのセッション情報にアクセスできることを意味します。つまり、これらのパーティは、Access-RequestおよびAccounting-Requestパケットをすでに転送しているプロキシです。
Since those parties already have the ability to see and modify all of the information about a user's session, there is no additional security issue with allowing them to see and modify CoA packets.
それらの当事者はすでにユーザーのセッションに関するすべての情報を表示および変更する機能を持っているため、CoAパケットを表示および変更することを許可することによる追加のセキュリティ問題はありません。
In short, any security issues with the contents of Operator-NAS-Identifier are largely limited by the security of the underlying RADIUS protocol. This limitation means that it does not matter how the values of Operator-NAS-Identifier are created, stored, or used.
つまり、Operator-NAS-Identifierの内容に関するセキュリティの問題は、基になるRADIUSプロトコルのセキュリティによって大きく制限されます。この制限は、Operator-NAS-Identifierの値がどのように作成、保存、または使用されるかは問題ではないことを意味します。
Per Section 3.4 of this document, IANA has allocated one new RADIUS attribute (the Operator-NAS-Identifier attribute) from the "short extended space" of the "RADIUS Attribute Types" registry as follows:
このドキュメントのセクション3.4に従って、IANAは次のように「RADIUS Attribute Types」レジストリの「short extended space」から1つの新しいRADIUS属性（Operator-NAS-Identifier属性）を割り当てました。
Value: 241.8 Description: Operator-NAS-Identifier Data Type: string Reference: RFC 8559
値：241.8説明：Operator-NAS-Identifierデータタイプ：文字列参照：RFC 8559
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, DOI 10.17487/RFC2865, June 2000, <https://www.rfc-editor.org/info/rfc2865>.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「Remote Authentication Dial In User Service（RADIUS）」、RFC 2865、DOI 10.17487 / RFC2865、2000年6月、<https：/ /www.rfc-editor.org/info/rfc2865>。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, DOI 10.17487/RFC5080, December 2007, <https://www.rfc-editor.org/info/rfc5080>.
[RFC5080] Nelson、D。およびA. DeKok、「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）の実装の問題と推奨される修正」、RFC 5080、DOI 10.17487 / RFC5080、2007年12月、<https：//www.rfc- editor.org/info/rfc5080>。
[RFC5176] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 5176, DOI 10.17487/RFC5176, January 2008, <https://www.rfc-editor.org/info/rfc5176>.
[RFC5176] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、and B. Aboba、 "Dynamic Authorization Extensions to Remote Authentication Dial In User Service（RADIUS）"、RFC 5176、DOI 10.17487 / RFC5176、2008年1月、<https://www.rfc-editor.org/info/rfc5176>。
[RFC5580] Tschofenig, H., Ed., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, DOI 10.17487/RFC5580, August 2009, <https://www.rfc-editor.org/info/rfc5580>.
[RFC5580] Tschofenig、H.、Ed。、Adrangi、F.、Jones、M.、Lior、A。、およびB. Aboba、「RADIUSおよびDiameterでのロケーションオブジェクトのキャリング」、RFC 5580、DOI 10.17487 / RFC5580、8月2009、<https://www.rfc-editor.org/info/rfc5580>。
[RFC6929] DeKok, A. and A. Lior, "Remote Authentication Dial In User Service (RADIUS) Protocol Extensions", RFC 6929, DOI 10.17487/RFC6929, April 2013, <https://www.rfc-editor.org/info/rfc6929>.
[RFC6929] DeKok、A。およびA. Lior、「Remote Authentication Dial In User Service（RADIUS）Protocol Extensions」、RFC 6929、DOI 10.17487 / RFC6929、2013年4月、<https://www.rfc-editor.org/ info / rfc6929>。
[RFC7542] DeKok, A., "The Network Access Identifier", RFC 7542, DOI 10.17487/RFC7542, May 2015, <https://www.rfc-editor.org/info/rfc7542>.
[RFC7542] DeKok、A。、「The Network Access Identifier」、RFC 7542、DOI 10.17487 / RFC7542、2015年5月、<https://www.rfc-editor.org/info/rfc7542>。
[RFC8044] DeKok, A., "Data Types in RADIUS", RFC 8044, DOI 10.17487/RFC8044, January 2017, <https://www.rfc-editor.org/info/rfc8044>.
[RFC8044] DeKok、A。、「RADIUSのデータタイプ」、RFC 8044、DOI 10.17487 / RFC8044、2017年1月、<https://www.rfc-editor.org/info/rfc8044>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, DOI 10.17487/RFC2866, June 2000, <https://www.rfc-editor.org/info/rfc2866>.
[RFC2866] Rigney、C。、「RADIUS Accounting」、RFC 2866、DOI 10.17487 / RFC2866、2000年6月、<https://www.rfc-editor.org/info/rfc2866>。
Authors' Addresses
著者のアドレス
Alan DeKok The FreeRADIUS Server Project
Alan DeKok FreeRADIUSサーバープロジェクト
Email: aland@freeradius.org
Jouni Korhonen
ジョーニ・コルホネン
Email: jouni.nospam@gmail.com