[要約] RFC 5997は、RADIUSプロトコルでのステータスサーバーパケットの使用に関するものであり、RADIUSサーバーとクライアント間の通信の状態を報告するために使用されます。目的は、ネットワークのトラブルシューティングを容易にすることです。
Internet Engineering Task Force (IETF) A. DeKok
Request for Comments: 5997 FreeRADIUS
Updates: 2866 August 2010
Category: Informational
ISSN: 2070-1721
Use of Status-Server Packets in the Remote Authentication Dial In User Service (RADIUS) Protocol
リモート認証でのステータスサーバーパケットの使用ユーザーサービス（RADIUS）プロトコルのダイヤル
Abstract
概要
This document describes a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. This extension utilizes the Status-Server (12) Code, which was reserved for experimental use in RFC 2865.
このドキュメントでは、ユーザーサービス（RADIUS）プロトコルのリモート認証ダイヤルへの展開された拡張機能について説明し、クライアントがRADIUSサーバーのステータスを照会できるようにします。この拡張機能は、RFC 2865で実験的に使用するために予約されていたステータスサーバー（12）コードを利用しています。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc5997.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5997で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Applicability ..............................................3
1.2. Terminology ................................................4
1.3. Requirements Language ......................................4
2. Overview ........................................................4
2.1. Why Access-Request is Inappropriate ........................6
2.1.1. Recommendation against Access-Request ...............7
2.2. Why Accounting-Request is Inappropriate ....................7
2.2.1. Recommendation against Accounting-Request ...........7
3. Packet Format ...................................................8
3.1. Single Definition for Status-Server .......................10
4. Implementation Notes ...........................................10
4.1. Client Requirements .......................................11
4.2. Server Requirements .......................................12
4.3. Failover with Status-Server ...............................14
4.4. Proxy Server Handling of Status-Server ....................14
4.5. Limitations of Status-Server ..............................15
4.6. Management Information Base (MIB) Considerations ..........17
4.6.1. Interaction with RADIUS Server MIB Modules .........17
4.6.2. Interaction with RADIUS Client MIB Modules .........17
5. Table of Attributes ............................................18
6. Examples .......................................................19
6.1. Minimal Query to Authentication Port ......................19
6.2. Minimal Query to Accounting Port ..........................20
6.3. Verbose Query and Response ................................21
7. Security Considerations ........................................21
8. References .....................................................23
8.1. Normative References ......................................23
8.2. Informative References ....................................23
Acknowledgments ...................................................24
This document specifies a deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, enabling clients to query the status of a RADIUS server. While the Status-Server (12) Code was defined as experimental in [RFC2865], Section 3, details of the operation and potential uses of the Code were not provided.
このドキュメントは、ユーザーサービス（RADIUS）プロトコルに展開された拡張機能を指定し、クライアントがRADIUSサーバーのステータスを照会できるようにします。ステータスサーバー（12）コードは[RFC2865]、セクション3の実験として定義されていましたが、セクション3では、コードの操作と潜在的な使用の詳細は提供されませんでした。
As with the core RADIUS protocol, the Status-Server extension is stateless, and queries do not otherwise affect the normal operation of a server, nor do they result in any side effects, other than perhaps incrementing an internal packet counter. Most of the implementations of this extension have utilized it alongside implementations of RADIUS as defined in [RFC2865], so that this document focuses solely on the use of this extension with UDP transport.
Core Radiusプロトコルと同様に、ステータスサーバー拡張機能はステートレスであり、クエリはそれ以外の場合はサーバーの通常の動作に影響しません。また、おそらく内部パケットカウンターを増やす以外に、副作用も発生しません。この拡張機能の実装のほとんどは、[RFC2865]で定義されているRADIUSの実装とともにそれを利用しているため、このドキュメントはUDP輸送でのこの拡張機能の使用のみに焦点を当てています。
The rest of this document is laid out as follows. Section 2 contains the problem statement, and explanations as to why some possible solutions can have unwanted side effects. Section 3 defines the Status-Server packet format. Section 4 contains client and server requirements, along with some implementation notes. Section 5 contains a RADIUS table of attributes. The remaining text discusses security considerations not covered elsewhere in the document.
このドキュメントの残りの部分は、次のようにレイアウトされています。セクション2には、問題の声明と、いくつかの可能なソリューションが望ましくない副作用を持つことができる理由についての説明が含まれています。セクション3では、ステータスサーバーパケット形式を定義します。セクション4には、いくつかの実装ノートとともに、クライアントおよびサーバーの要件が含まれています。セクション5には、属性の半径テーブルが含まれています。残りのテキストでは、ドキュメントの他の場所でカバーされていないセキュリティ上の考慮事項について説明します。
This protocol is being recommended for publication as an Informational RFC rather than as a Standards-Track RFC because of problems with deployed implementations. This includes security vulnerabilities. The fixes recommended here are compatible with existing servers that receive Status-Server packets, but impose new security requirements on clients that send Status-Server packets.
このプロトコルは、展開された実装の問題のために、標準トラックRFCとしてではなく、情報RFCとして公開するために推奨されています。これには、セキュリティの脆弱性が含まれます。ここで推奨される修正は、ステータスサーバーパケットを受信するが、ステータスサーバーパケットを送信するクライアントに新しいセキュリティ要件を課す既存のサーバーと互換性があります。
Some existing implementations of this protocol do not support the Message-Authenticator attribute ([RFC3579]). This enables an unauthorized client to spoof Status-Server packets, potentially leading to incorrect Access-Accepts. In order to remedy this problem, this specification requires the use of the Message-Authenticator attribute to provide per-packet authentication and integrity protection.
このプロトコルの既存の実装の一部は、メッセージ-Authenticator属性（[RFC3579]）をサポートしていません。これにより、許可されていないクライアントがステータスサーバーパケットをスプーフィングすることができ、潜在的に誤ったアクセスアクセプトにつながる可能性があります。この問題を改善するために、この仕様では、パケットごとの認証と整合性の保護を提供するために、メッセージ-Authenticator属性を使用する必要があります。
With existing implementations of this protocol, the potential exists for Status-Server requests to be in conflict with Access-Request or Accounting-Request packets using the same Identifier. This specification recommends techniques to avoid this problem.
このプロトコルの既存の実装により、同じ識別子を使用してアクセスリクエストまたは会計リクエストパケットと競合するステータスサーバー要求が存在する可能性があります。この仕様は、この問題を回避するための手法を推奨しています。
These limitations are discussed in more detail below.
これらの制限については、以下で詳しく説明します。
This document uses the following terms:
このドキュメントでは、次の用語を使用しています。
"Network Access Server (NAS)"
「ネットワークアクセスサーバー（NAS）」
The device providing access to the network. Also known as the Authenticator (in IEEE 802.1X terminology) or RADIUS client.
ネットワークへのアクセスを提供するデバイス。認証機（IEEE 802.1x用語）またはRADIUSクライアントとも呼ばれます。
"RADIUS Proxy"
「RADIUSプロキシ」
In order to provide for the routing of RADIUS authentication and accounting requests, a RADIUS proxy can be employed. To the NAS, the RADIUS proxy appears to act as a RADIUS server, and to the RADIUS server, the proxy appears to act as a RADIUS client.
RADIUS認証と会計リクエストのルーティングを提供するために、RADIUSプロキシを使用できます。NASにとって、RADIUSプロキシはRADIUSサーバーとして機能するように見え、RADIUSサーバーには、プロキシはRADIUSクライアントとして機能するように見えます。
"silently discard"
「静かに捨てる」
This means the implementation discards the packet without further processing. The implementation MAY provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
これは、実装がさらに処理せずにパケットを破棄することを意味します。実装は、静かに破棄されたパケットの内容を含むエラーを記録する機能を提供する場合があり、統計カウンターにイベントを記録する必要があります。
In this document, several words are used to signify the requirements of the specification. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
Status-Server packets are sent by a RADIUS client to a RADIUS server in order to test the status of that server. The destination of a Status-Server packet is set to the IP address and port of the server that is being tested. A single Status-Server packet MUST be included within a UDP datagram. A Message-Authenticator attribute MUST be included so as to provide per-packet authentication and integrity protection.
ステータスサーバーパケットは、そのサーバーのステータスをテストするために、RADIUSクライアントによってRADIUSサーバーに送信されます。ステータスサーバーパケットの宛先は、テストされているサーバーのIPアドレスとポートに設定されています。単一のステータスサーバーパケットをUDPデータグラムに含める必要があります。パケットごとの認証と整合性の保護を提供するために、メッセージ-Authenticator属性を含める必要があります。
RADIUS proxies or servers MUST NOT forward Status-Server packets. A RADIUS server or proxy implementing this specification SHOULD respond to a Status-Server packet with an Access-Accept (authentication port) or Accounting-Response (accounting port). An Access-Challenge response is NOT RECOMMENDED. An Access-Reject response MAY be used. The list of attributes that are permitted in Status-Server packets, and in Access-Accept or Accounting-Response packets responding to Status-Server packets, is provided in Section 5. Section 6 provides several examples.
RADIUSプロキシまたはサーバーは、ステータスサーバーパケットを転送してはなりません。この仕様を実装するRADIUSサーバーまたはプロキシは、Access-Accept（認証ポート）または会計応答（アカウンティングポート）を備えたステータスサーバーパケットに応答する必要があります。アクセスチャレンジ応答は推奨されません。アクセス拒否応答を使用できます。ステータスサーバーパケット、およびステータスサーバーパケットに応答するアクセスアクセプトまたは会計応答パケットで許可されている属性のリストは、セクション5に記載されています。セクション6にいくつかの例を示します。
Since a Status-Server packet MUST NOT be forwarded by a RADIUS proxy or server, the client is provided with an indication of the status of that server only, since no RADIUS proxies are on the path between the RADIUS client and server. As servers respond to a Status-Server packet without examining the User-Name attribute, the response to a Status-Server packet cannot be used to infer any information about the reachability of specific realms.
ステータスサーバーパケットはRADIUSプロキシまたはサーバーによって転送されてはならないため、クライアントには、RADIUSクライアントとサーバーの間のパス上にRADIUSプロキシがないため、そのサーバーのステータスのみを示すことができます。サーバーは、ユーザー名属性を調べずにステータスサーバーパケットに応答するため、ステータスサーバーパケットへの応答を使用して、特定の領域の到達可能性に関する情報を推測することはできません。
The "hop-by-hop" functionality of Status-Server packets is useful to RADIUS clients attempting to determine the status of the first element on the path between the client and a server. Since the Status-Server packet is non-forwardable, the lack of a response may only be due to packet loss or the failure of the server at the destination IP address, and not due to faults in downstream links, proxies, or servers. It therefore provides an unambiguous indication of the status of a server.
ステータスサーバーパケットの「ホップバイホップ」機能は、クライアントとサーバーの間のパス上の最初の要素のステータスを決定しようとするRADIUSクライアントに役立ちます。Status-Serverパケットは装飾不能であるため、応答の欠如は、パケットの損失または宛先IPアドレスでのサーバーの障害によるものであり、ダウンストリームリンク、プロキシ、またはサーバーの障害によるものではありません。したがって、サーバーのステータスの明確な兆候を提供します。
This information may be useful in situations in which the RADIUS client does not receive a response to an Access-Request. A client may have multiple proxies configured, with one proxy marked as primary and another marked as secondary. If the client does not receive a response to a request sent to the primary proxy, it can "failover" to the secondary, and send requests to the secondary proxy instead.
この情報は、RADIUSクライアントがアクセスリケストへの応答を受け取らない状況で役立つ場合があります。クライアントは複数のプロキシを構成し、1つのプロキシがプライマリとしてマークされ、別のプロキシがセカンダリとしてマークされている場合があります。クライアントがプライマリプロキシに送信されたリクエストへの応答を受け取らない場合、代わりにセカンダリに「フェイルオーバー」し、代わりにリクエストをセカンダリプロキシに送信できます。
However, it is possible that the lack of a response to requests sent to the primary proxy was due not to a failure within the primary, but to alternative causes such as a failed link along the path to the destination server or the failure of the destination server itself.
ただし、プライマリプロキシに送信されたリクエストへの応答の欠如は、プライマリ内の障害ではなく、宛先サーバーへのパスに沿ったリンクの失敗や宛先の障害などの代替の原因によるものである可能性があります。サーバー自体。
In such a situation, it may be useful for the client to be able to distinguish between failure causes so that it does not trigger failover inappropriately. For example, if the primary proxy is down, then a quick failover to the secondary proxy would be prudent; whereas, if a downstream failure is the cause, then the value of failover to a secondary proxy will depend on whether packets forwarded by the secondary will utilize independent links, intermediaries, or destination servers.
このような状況では、クライアントが失敗の原因を区別できるため、フェイルオーバーが不適切にトリガーされないようにすることが役立つ場合があります。たとえば、プライマリプロキシがダウンしている場合、セカンダリプロキシへのクイックフェールオーバーは慎重になります。一方、下流の障害が原因である場合、セカンダリプロキシへのフェールオーバーの値は、セカンダリによって転送されるパケットが独立したリンク、仲介者、または宛先サーバーを利用するかどうかによって異なります。
The Status-Server packet is not a "Keep-Alive" as discussed in [RFC2865], Section 2.6. "Keep-Alives" are Access-Request packets sent to determine whether a downstream server is responsive. These packets are typically sent only when a server is suspected to be down, and they are no longer sent as soon as the server is available again.
[RFC2865]、セクション2.6で説明したように、ステータスサーバーパケットは「キープアライブ」ではありません。「Keep-Alives」は、ダウンストリームサーバーがレスポンシブかどうかを判断するために送信されるアクセスリクエストパケットです。これらのパケットは通常、サーバーがダウンしていると疑われる場合にのみ送信され、サーバーが再び利用可能になるとすぐに送信されなくなります。
One possible solution to the problem of querying server status is for a NAS to send specially formed Access-Request packets to a RADIUS server's authentication port. The NAS can then look for a response and use this information to determine if the server is active or unresponsive.
サーバーのステータスを照会する問題の可能な解決策の1つは、NASが特別に形成されたアクセスリケストパケットをRADIUSサーバーの認証ポートに送信することです。その後、NASは応答を探し、この情報を使用して、サーバーがアクティブであるか反応していないかを判断できます。
However, the server may see the request as a normal login request for a user and conclude that a real user has logged onto that NAS. The server may then perform actions that are undesirable for a simple status query. The server may alternatively respond with an Access-Challenge, indicating that it believes an extended authentication conversation is necessary.
ただし、サーバーは、リクエストをユーザーの通常のログイン要求として表示し、実際のユーザーがそのNASにログインしていると結論付ける場合があります。サーバーは、単純なステータスクエリに対して望ましくないアクションを実行できます。サーバーは、Access-Challengeで代わりに応答する場合があります。これは、拡張された認証会話が必要であると考えていることを示しています。
Another possibility is that the server responds with an Access-Reject, indicating that the user is not authorized to gain access to the network. As above, the server may also perform local-site actions, such as warning an administrator of failed login attempts. The server may also delay the Access-Reject response, in the traditional manner of rate-limiting failed authentication attempts. This delay in response means that the querying administrator is unsure as to whether or not the server is down, slow to respond, or intentionally delaying its response to the query.
もう1つの可能性は、サーバーがアクセス抵抗で応答し、ユーザーがネットワークへのアクセスを取得する権限を与えられていないことを示していることです。上記のように、サーバーは、失敗したログイン試行の管理者に警告するなど、ローカルサイトのアクションを実行する場合があります。また、サーバーは、従来のレート制限障害認証試行の場合に、アクセス拒否応答を遅らせることもあります。この応答の遅延は、クエリ管理者がサーバーがダウンしているかどうか、応答が遅いか、意図的にクエリへの応答を遅らせるかについて不確実であることを意味します。
In addition, using Access-Request queries may mean that the server may have local users configured whose sole reason for existence is to enable these query requests. Unless the server policy is designed carefully, it may be possible for an attacker to use those credentials to gain unauthorized network access.
さらに、Access-Requestクエリを使用すると、サーバーがローカルユーザーに存在の唯一の理由がこれらのクエリリクエストを有効にすることであることを意味する場合があります。サーバーポリシーが慎重に設計されていない限り、攻撃者がそれらの資格情報を使用して不正なネットワークアクセスを取得することが可能です。
We note that some NAS implementations currently use Access-Request packets as described above, with a fixed (and non-configurable) user name and password. Implementation issues with that equipment mean that if a RADIUS server does not respond to those queries, it may be marked as unresponsive by the NAS. This marking may happen even if the server is actively responding to other Access-Requests from that same NAS. This behavior is confusing to administrators who then need to determine why an active server has been marked as "unresponsive".
一部のNASの実装は、現在、上記のようにアクセスリケストパケットを使用しており、固定（および不適切な）ユーザー名とパスワードを使用していることに注意してください。その機器の実装の問題は、RADIUSサーバーがこれらのクエリに応答しない場合、NASによって反応しないとマークされる可能性があることを意味します。このマーキングは、サーバーが同じNASからの他のアクセス要求に積極的に応答している場合でも発生する可能性があります。この動作は、アクティブサーバーが「反応しない」とマークされた理由を判断する必要がある管理者を混乱させます。
For the reasons outlined above, NAS implementors SHOULD NOT generate Access-Request packets solely to see if a server is alive. Similarly, site administrators SHOULD NOT configure test users whose sole reason for existence is to enable such queries via Access-Request packets.
上記の理由により、NASの実装者は、サーバーが生きているかどうかを確認するためだけにアクセスリケストパケットを生成するべきではありません。同様に、サイト管理者は、存在の唯一の理由であるテストユーザーを設定しては、アクセスリクエストパケットを介してそのようなクエリを有効にすることです。
Note that it still may be useful to configure test users for the purpose of performing end-to-end or in-depth testing of a server policy. While this practice is widespread, we caution administrators to use it with care.
サーバーポリシーのエンドツーエンドまたは詳細なテストを実行する目的で、テストユーザーを構成することは引き続き便利かもしれないことに注意してください。このプラクティスは広まっていますが、管理者に注意を払って使用するよう警告しています。
A similar solution for the problem of querying server status may be for a NAS to send specially formed Accounting-Request packets to a RADIUS server's accounting port. The NAS can then look for a response and use this information to determine if the server is active or unresponsive.
サーバーのステータスを照会する問題に関する同様のソリューションは、NASがRADIUSサーバーの会計ポートに特別に形成されたアカウンティングレクエストパケットを送信することです。その後、NASは応答を探し、この情報を使用して、サーバーがアクティブであるか反応していないかを判断できます。
As seen above with Access-Request, the server may then conclude that a real user has logged onto a NAS, and perform local-site actions that are undesirable for a simple status query.
上記のAccess-Requestを使用して見たように、サーバーは、実際のユーザーがNASにログインし、単純なステータスクエリに対して望ましくないローカルサイトアクションを実行したと結論付ける場合があります。
Another consideration is that some attributes are mandatory to include in an Accounting-Request. This requirement forces the administrator to query an accounting server with fake values for those attributes in a test packet. These fake values increase the work required to perform a simple query, and they may pollute the server's accounting database with incorrect data.
もう1つの考慮事項は、一部の属性がアカウンティングレクエストに含めることを必須であることです。この要件により、管理者は、テストパケット内のこれらの属性の偽の値を持つアカウンティングサーバーを照会する必要があります。これらの偽の値は、簡単なクエリを実行するために必要な作業を増やし、誤ったデータでサーバーの会計データベースを汚染する可能性があります。
For the reasons outlined above, NAS implementors SHOULD NOT generate Accounting-Request packets solely to see if a server is alive. Similarly, site administrators SHOULD NOT configure accounting policies whose sole reason for existence is to enable such queries via Accounting-Request packets.
上記の理由により、NASの実装者は、サーバーが生存しているかどうかを確認するためだけに会計レクエストパケットを生成すべきではありません。同様に、サイト管理者は、存在の唯一の理由が、会計リクエストパケットを介してそのようなクエリを有効にすることである会計ポリシーを構成すべきではありません。
Note that it still may be useful to configure test users for the purpose of performing end-to-end or in-depth testing of a server's policy. While this practice is widespread, we caution administrators to use it with care.
サーバーのポリシーのエンドツーエンドまたは詳細なテストを実行する目的で、テストユーザーを構成することは引き続き便利かもしれないことに注意してください。このプラクティスは広まっていますが、管理者に注意を払って使用するよう警告しています。
Status-Server packets reuse the RADIUS packet format, with the fields and values for those fields as defined in [RFC2865], Section 3. We do not include all of the text or diagrams of that section here, but instead explain the differences required to implement Status-Server.
ステータスサーバーパケットRADIUSパケット形式を再利用し、[RFC2865]で定義されているフィールドのフィールドと値をセクション3で再利用します。ステータスサーバーを実装します。
The Authenticator field of Status-Server packets MUST be generated using the same method as that used for the Request Authenticator field of Access-Request packets, as given below.
ステータスサーバーパケットの認証フィールドは、以下に示すように、アクセスリクエストパケットのリクエスト認証フィールドに使用される方法と同じ方法を使用して生成する必要があります。
The role of the Identifier field is the same for Status-Server as for other packets. However, as Status-Server is taking the role of Access-Request or Accounting-Request packets, there is the potential for Status-Server requests to be in conflict with Access-Request or Accounting-Request packets with the same Identifier. In Section 4.2 below, we describe a method for avoiding these problems. This method MUST be used to avoid conflicts between Status-Server and other packet types.
識別子フィールドの役割は、他のパケットとステータスサーバーで同じです。ただし、Status-Serverがアクセスレクエストまたは会計レクエストパケットの役割を果たしているため、同じ識別子を持つアクセスレクエストまたは会計レクエストパケットと競合するステータスサーバー要求が競合する可能性があります。以下のセクション4.2では、これらの問題を回避する方法について説明します。この方法は、ステータスサーバーと他のパケットタイプの間の競合を回避するために使用する必要があります。
Request Authenticator
Authenticatorをリクエストします
In Status-Server packets, the Authenticator value is a 16-octet random number called the Request Authenticator. The value SHOULD be unpredictable and unique over the lifetime of a secret (the password shared between the client and the RADIUS server), since repetition of a request value in conjunction with the same secret would permit an attacker to reply with a previously intercepted response. Since it is expected that the same secret MAY be used to authenticate with servers in disparate geographic regions, the Request Authenticator field SHOULD exhibit global and temporal uniqueness. See [RFC4086] for suggestions as to how random numbers may be generated.
Status-Serverパケットでは、Authenticator値は、リクエストAuthenticatorと呼ばれる16オクテットの乱数です。値は、秘密の生涯にわたって予測不可能で一意でなければなりません（クライアントとRADIUSサーバーの間で共有されたパスワード）。同じ秘密と併せて要求値を繰り返すと、攻撃者が以前に傍受された応答で返信できるようになります。同じ秘密を使用して、異なる地理的地域のサーバーで認証するために使用される可能性があるため、リクエスト認証機フィールドはグローバルおよび時間的な一意性を示す必要があります。乱数がどのように生成されるかについての提案については、[RFC4086]を参照してください。
The Request Authenticator value in a Status-Server packet SHOULD also be unpredictable, lest an attacker trick a server into responding to a predicted future request, and then use the response to masquerade as that server to a future Status-Server request from a client.
ステータスサーバーパケットのリクエスト認証値も予測不可能である必要があります。攻撃者がサーバーが予測される将来の要求に応答しないようにし、クライアントからの将来のステータスサーバーリクエストにそのサーバーとしてそのサーバーを仮定して応答を使用します。
Similarly, the Response Authenticator field of an Access-Accept packet sent in response to Status-Server queries MUST be generated using the same method as used for calculating the Response Authenticator of the Access-Accept sent in response to an Access-Request, with the Status-Server Request Authenticator taking the place of the Access-Request Request Authenticator.
同様に、ステータスサーバークエリに応じて送信されたアクセスacceptパケットの応答認証フィールドは、アクセスリケストに応じて送信されたアクセスアセプトの応答認証器を計算するために使用されるのと同じ方法を使用して生成する必要があります。Status-Server Request Access-Request Request Authenticatorの代わりにAuthenticatorを使用します。
The Response Authenticator field of an Accounting-Response packet sent in response to Status-Server queries MUST be generated using the same method as used for calculating the Response Authenticator of the Accounting-Response sent in response to an Accounting-Request, with the Status-Server Request Authenticator taking the place of the Accounting-Request Request Authenticator.
ステータスサーバークエリに応答して送信された会計応答パケットの応答認証フィールドは、ステータスとの応答に応じて送信された会計応答の応答認証器を計算するために使用するのと同じ方法を使用して生成する必要があります。Accounting-Request Request Authenticatorの代わりにServer Request Authenticator。
Note that when a server responds to a Status-Server request, it MUST NOT send more than one Response packet.
サーバーがステータスサーバーリクエストに応答した場合、複数の応答パケットを送信してはならないことに注意してください。
Response Authenticator
応答認証器
The value of the Authenticator field in Access-Accept or Accounting-Response packets is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of: the RADIUS packet, beginning with the Code field, including the Identifier, the Length, the Request Authenticator field from the Status-Server packet, and the response Attributes (if any), followed by the shared secret. That is,
Access-AcceptまたはAccounting-Responseパケットの認証装置フィールドの値は、応答Authenticatorと呼ばれ、次のオクテットのストリームに計算された一方向MD5ハッシュが含まれています。識別子、長さ、ステータスサーバーパケットからのリクエスト認証器フィールド、および応答属性（存在する場合）、その後に共有シークレットが続きます。あれは、
ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
where + denotes concatenation.
ここで、連結を意味します。
In addition to the above requirements, all Status-Server packets MUST include a Message-Authenticator attribute. Failure to do so would mean that the packets could be trivially spoofed.
上記の要件に加えて、すべてのステータスサーバーパケットには、メッセージauthenticator属性を含める必要があります。そうしないと、パケットが些細なものになる可能性があることを意味します。
Status-Server packets MAY include NAS-Identifier, and one of NAS-IP-Address or NAS-IPv6-Address. These attributes are not necessary for the operation of Status-Server, but may be useful information to a server that receives those packets.
ステータスサーバーパケットには、NAS-Identifier、およびNAS-IP-AddressまたはNAS-IPV6-Addressの1つが含まれる場合があります。これらの属性は、ステータスサーバーの操作には必要ありませんが、それらのパケットを受信するサーバーにとって有用な情報である可能性があります。
Other attributes SHOULD NOT be included in a Status-Server packet, and MUST be ignored if they are included. User authentication credentials such as User-Name, User-Password, CHAP-Password, EAP-Message MUST NOT appear in a Status-Server packet sent to a RADIUS authentication port. User or NAS accounting attributes such as Acct-Session-Id, Acct-Status-Type, Acct-Input-Octets MUST NOT appear in a Status-Server packet sent to a RADIUS accounting port.
他の属性をステータスサーバーパケットに含めるべきではなく、それらが含まれている場合は無視する必要があります。ユーザー名、ユーザーパスワード、チャップパスワード、EAPメッセージなどのユーザー認証資格情報は、RADIUS認証ポートに送信されたステータスサーバーパケットに表示されてはなりません。ACCT-Session-ID、ACCT-STATUS-TYPE、ACCT-Input-OCTETSなどのユーザーまたはNAS会計属性は、RADIUSアカウンティングポートに送信されたステータスサーバーパケットに表示されてはなりません。
The Access-Accept MAY contain a Reply-Message or Message-Authenticator attribute. It SHOULD NOT contain other attributes. The Accounting-Response packets sent in response to a Status-Server query SHOULD NOT contain any attributes. As the intent is to implement a simple query instead of user authentication or accounting, there is little reason to include other attributes in either the query or the corresponding response.
Access-Acceptには、Reply-MessageまたはMessage-Authenticator属性が含まれている場合があります。他の属性を含めるべきではありません。ステータスサーバークエリに応じて送信された会計応答パケットには、属性を含めるべきではありません。意図は、ユーザー認証や会計の代わりに簡単なクエリを実装することであるため、クエリまたは対応する応答のいずれかに他の属性を含める理由はほとんどありません。
Examples of Status-Server packet flows are given below in Section 6.
ステータスサーバーパケットフローの例を以下に、セクション6に示します。
When sent to a RADIUS accounting port, the contents of the Status-Server packets are calculated as described above. That is, even though the packets are being sent to an accounting port, they are not created using the same method as is used for Accounting-Requests. This difference has a number of benefits.
RADIUSアカウンティングポートに送信されると、ステータスサーバーパケットの内容は上記のように計算されます。つまり、パケットが会計ポートに送信されている場合でも、会計要求に使用されるのと同じ方法を使用して作成されません。この違いには多くの利点があります。
Having a single definition for Status-Server packets is simpler than having different definitions for different destination ports. In addition, if we were to define Status-Server as being similar to Accounting-Request but containing no attributes, then those packets could be trivially forged.
ステータスサーバーパケットの単一の定義を持つことは、異なる宛先ポートの異なる定義を持つよりも簡単です。さらに、ステータスサーバーをアカウンティングレクエストに似ているが属性が含まれていないと定義する場合、それらのパケットは些細なことに断絶される可能性があります。
We therefore define Status-Server consistently, and vary the response packets depending on the port to which the request is sent. When sent to an authentication port, the response to a Status-Server query is an Access-Accept packet. When sent to an accounting port, the response to a Status-Server query is an Accounting-Response packet.
したがって、ステータスサーバーを一貫して定義し、リクエストが送信されるポートに応じて応答パケットを変更します。認証ポートに送信されると、ステータスサーバークエリへの応答はアクセスアセプトパケットです。会計ポートに送信されると、ステータスサーバークエリへの応答は会計応答パケットです。
There are a number of considerations to take into account when implementing support for Status-Server. This section describes implementation details and requirements for RADIUS clients and servers that support Status-Server.
ステータスサーバーのサポートを実装する際には、考慮すべき多くの考慮事項があります。このセクションでは、ステータスサーバーをサポートするRADIUSクライアントとサーバーの実装の詳細と要件について説明します。
The following text applies to the authentication and accounting ports. We use the generic terms below to simplify the discussion:
次のテキストは、認証ポートとアカウンティングポートに適用されます。以下の一般的な用語を使用して、議論を簡素化します。
* Request packet
* リクエストパケット
An Access-Request packet sent to an authentication port or an Accounting-Request packet sent to an accounting port.
認証ポートに送信されたアクセスレクエストパケットまたは会計ポートに送信される会計レクエストパケット。
* Response packet
* 応答パケット
An Access-Accept, Access-Challenge, or Access-Reject packet sent from an authentication port or an Accounting-Response packet sent from an accounting port.
認証ポートから送信されたアクセスアセプト、アクセスチャレンジ、またはアクセス - rejectパケットまたは会計ポートから送信された会計応答パケット。
We also refer to "client" as the originator of the Status-Server packet, and "server" as the receiver of that packet and the originator of the Response packet.
また、「クライアント」をステータスサーバーパケットのオリジネーターと呼び、「サーバー」をそのパケットの受信者および応答パケットのオリジネーターとして呼びます。
Using generic terms to describe the Status-Server conversations is simpler than duplicating the text for authentication and accounting packets.
一般的な用語を使用してステータスサーバーの会話を説明することは、認証と会計パケットのテキストを複製するよりも簡単です。
Clients SHOULD permit administrators to globally enable or disable the generation of Status-Server packets. The default SHOULD be that it is disabled. As it is undesirable to send queries to servers that do not support Status-Server, clients SHOULD also have a per-server configuration indicating whether or not to enable Status-Server for a particular destination. The default SHOULD be that it is disabled.
クライアントは、管理者がグローバルにステータスサーバーパケットの生成を有効または無効にできるようにする必要があります。デフォルトは、それが無効になっていることです。ステータスサーバーをサポートしていないサーバーにクエリを送信することは望ましくないため、クライアントは、特定の宛先のステータスサーバーを有効にするかどうかを示すサーバーあたりの構成も持っている必要があります。デフォルトは、それが無効になっていることです。
The client SHOULD use a watchdog timer, such as is defined in Section 2.2.1 of [RFC5080], to determine when to send Status-Server packets.
クライアントは、[RFC5080]のセクション2.2.1で定義されているようなウォッチドッグタイマーを使用して、ステータスサーバーパケットをいつ送信するかを決定する必要があります。
When Status-Server packets are sent from a client, they MUST NOT be retransmitted. Instead, the Identity field MUST be changed every time a packet is transmitted. The old packet should be discarded, and a new Status-Server packet should be generated and sent, with new Identity and Authenticator fields.
ステータスサーバーパケットがクライアントから送信された場合、それらを再送信してはなりません。代わりに、パケットが送信されるたびにIDフィールドを変更する必要があります。古いパケットを廃棄する必要があり、新しいステータスサーバーパケットを生成して送信して、新しいIDと認証器のフィールドを使用して送信する必要があります。
Clients MUST include the Message-Authenticator attribute in all Status-Server packets. Failure to do so would mean that the packets could be trivially spoofed, leading to potential denial-of-service (DoS) attacks. Other attributes SHOULD NOT appear in a Status-Server packet, except as outlined below in Section 5. As the intent of the packet is a simple status query, there is little reason for any additional attributes to appear in Status-Server packets.
クライアントは、すべてのステータスサーバーパケットにメッセージauthenticator属性を含める必要があります。そうしないと、パケットが些細なものになり、潜在的なサービス拒否（DOS）攻撃につながる可能性があることを意味します。セクション5で以下に概説する場合を除き、他の属性はステータスサーバーパケットに表示されないでください。パケットの意図は単純なステータスクエリであるため、ステータスサーバーパケットに追加の属性が表示される理由はほとんどありません。
The client MAY increment packet counters as a result of sending a Status-Server request or of receiving a Response packet. The client MUST NOT perform any other action that is normally performed when it receives a Response packet, such as permitting a user to have login access to a port.
クライアントは、ステータスサーバーリクエストの送信または応答パケットの受信の結果として、パケットカウンターをインクリメントする場合があります。クライアントは、ユーザーがポートへのログインアクセスを許可するなど、応答パケットを受信したときに通常実行される他のアクションを実行してはなりません。
Clients MAY send Status-Server requests to the RADIUS destination ports from the same source port used to send normal Request packets. Other clients MAY choose to send Status-Server requests from a unique source port that is not used to send Request packets.
クライアントは、通常の要求パケットを送信するために使用される同じソースポートから、ステータスサーバーリクエストをRADIUS宛先ポートに送信できます。他のクライアントは、リクエストパケットの送信に使用されていない一意のソースポートからステータスサーバーリクエストを送信することを選択できます。
The above suggestion for a unique source port for Status-Server packets aids in matching responses to requests. Since the response to a Status-Server packet is an Access-Accept or Accounting-Response packet, those responses are indistinguishable from other packets sent in response to a Request packet. Therefore, the best way to distinguish them from other traffic is to have a unique port.
ステータスサーバーパケットのユニークなソースポートの上記の提案は、リクエストに対する応答を一致させるのに役立ちます。ステータスサーバーパケットへの応答はアクセスacceptまたは会計応答パケットであるため、これらの応答はリクエストパケットに応じて送信された他のパケットと区別できません。したがって、それらを他のトラフィックと区別する最良の方法は、一意のポートを持つことです。
A client MAY send a Status-Server packet from a source port also used to send Request packets. In that case, the Identifier field MUST be unique across all outstanding Request packets for that source port, independent of the value of the RADIUS Code field for those outstanding requests. Once the client has either received a response to the Status-Server packet or determined that the Status-Server packet has timed out, it may reuse that Identifier in another packet.
クライアントは、リクエストパケットの送信にも使用されるソースポートからステータスサーバーパケットを送信する場合があります。その場合、識別子フィールドは、そのソースポートのすべての未解決の要求パケットにわたって一意でなければなりません。これらの未解決の要求のRADIUSコードフィールドの値とは無関係です。クライアントがステータスサーバーパケットへの応答を受け取ったか、ステータスサーバーパケットがタイムアウトしていると判断したら、その識別子が別のパケットで再利用する可能性があります。
Robust implementations SHOULD accept any Response packet as a valid response to a Status-Server packet, subject to the validation requirements defined above for the Response Authenticator. The Code field of the packet matters less than the fact that a valid, signed response has been received.
堅牢な実装は、応答認証器の上記で定義された検証要件を条件として、ステータスサーバーパケットに対する有効な応答として、応答パケットを受け入れる必要があります。パケットのコードフィールドは、有効な署名された応答が受信されたという事実よりも重要です。
That is, prior to accepting the response as valid, the client should check that the Response packet Code field is either Access-Accept (2) or Accounting-Response (5). If the Code does not match any of these values, the packet MUST be silently discarded. The client MUST then validate the Response Authenticator via the algorithm given above in Section 3. If the Response Authenticator is not valid, the packet MUST be silently discarded. If the Response Authenticator is valid, then the packet MUST be deemed to be a valid response from the server.
つまり、応答を有効であると受け入れる前に、クライアントは応答パケットコードフィールドがアクセスaccept（2）またはアカウンティング応答（5）であることを確認する必要があります。コードがこれらの値のいずれかと一致しない場合、パケットは静かに破棄する必要があります。次に、クライアントは、セクション3で上記のアルゴリズムを介して応答認証器を検証する必要があります。応答認証器が有効でない場合、パケットは静かに破棄する必要があります。応答認証器が有効な場合、パケットはサーバーからの有効な応答であるとみなされる必要があります。
If the client instead discarded the response because the packet Code did not match what it expected, then it could erroneously discard valid responses from a server, and mark that server as unresponsive. This behavior would affect the stability of a RADIUS network, as responsive servers would erroneously be marked as unresponsive. We therefore recommend that clients should be liberal in what they accept as responses to Status-Server queries.
代わりに、パケットコードが予想されるものと一致しなかったためにクライアントが応答を破棄した場合、サーバーから有効な応答を誤って破棄し、そのサーバーを反応しないものとしてマークする可能性があります。この動作は、レスポンシブサーバーが反応しないものとして誤ってマークされるため、RADIUSネットワークの安定性に影響します。したがって、クライアントは、ステータスサーバークエリへの応答として受け入れるものにおいて、クライアントがリベラルであることをお勧めします。
Servers SHOULD permit administrators to globally enable or disable the acceptance of Status-Server packets. The default SHOULD be that acceptance is enabled. Servers SHOULD also permit administrators to enable or disable acceptance of Status-Server packets on a per-client basis. The default SHOULD be that acceptance is enabled.
サーバーは、管理者がグローバルにステータスサーバーパケットの受け入れを有効または無効にできるようにする必要があります。デフォルトは、受け入れが有効になることです。また、サーバーは、管理者がクライアントごとにステータスサーバーパケットの受け入れを有効または無効にすることを許可する必要があります。デフォルトは、受け入れが有効になることです。
Status-Server packets originating from clients that are not permitted to send the server Request packets MUST be silently discarded. If a server does not support Status-Server packets, or is configured not to respond to them, then it MUST silently discard the packet.
サーバーリクエストパケットを送信することが許可されていないクライアントから発信されるステータスサーバーパケットは、静かに破棄する必要があります。サーバーがステータスサーバーパケットをサポートしていない場合、またはそれらに応答しないように構成されている場合、パケットを静かに破棄する必要があります。
We note that [RFC2865], Section 3, defines a number of RADIUS Codes, but does not make statements about which Codes are valid for port 1812. In contrast, [RFC2866], Section 3, specifies that only RADIUS Accounting packets are to be sent to port 1813. This specification is compatible with [RFC2865], as it uses a known Code for packets to port 1812. This specification is not compatible with [RFC2866], as it adds a new Code (Status-Server) that is valid for port 1812. However, as the category of [RFC2866] is Informational, this conflict is acceptable.
[RFC2865]、セクション3は、多くの半径コードを定義しているが、ポート1812に有効なコードについてのステートメントを作成しないことに注意してください。ポート1813に送信されました。この仕様は[RFC2865]と互換性があります。これは、ポート1812にパケットの既知のコードを使用します。この仕様は、有効な新しいコード（ステータスサーバー）を追加するため、[RFC2866]と互換性がありません。ただし、[RFC2866]のカテゴリは情報に基づいているため、この紛争は許容されます。
Servers SHOULD silently discard Status-Server packets if they determine that a client is sending too many Status-Server requests in a particular time period. The method used by a server to make this determination is implementation specific and out of scope for this specification.
サーバーは、クライアントが特定の期間にあまりにも多くのステータスサーバーリクエストを送信していると判断した場合、ステータスサーバーパケットを静かに破棄する必要があります。この決定を行うためにサーバーが使用する方法は、実装固有であり、この仕様の範囲外です。
If a server supports Status-Server packets, and is configured to respond to them, and receives a packet from a known client, it MUST validate the Message-Authenticator attribute as defined in [RFC3579], Section 3.2. Packets failing that validation MUST be silently discarded.
サーバーがステータスサーバーパケットをサポートし、それらに応答するように構成され、既知のクライアントからパケットを受信する場合、[RFC3579]で定義されているメッセージ-Authenticator属性を検証する必要があります。セクション3.2。その検証に失敗したパケットは、静かに破棄する必要があります。
Servers SHOULD NOT otherwise discard Status-Server packets if they have recently sent the client a Response packet. The query may have originated from an administrator who does not have access to the Response packet stream or one who is interested in obtaining additional information about the server.
それ以外の場合、サーバーがクライアントに応答パケットを送信した場合、ステータスサーバーパケットを破棄しないでください。クエリは、応答パケットストリームにアクセスできない管理者またはサーバーに関する追加情報の取得に関心のある管理者から発信された可能性があります。
The server MAY prioritize the handling of Status-Server packets over the handling of other requests, subject to the rate limiting described above.
サーバーは、上記のレート制限を条件として、他のリクエストの処理よりもステータスサーバーパケットの処理を優先する場合があります。
The server MAY decide not to respond to a Status-Server, depending on local-site policy. For example, a server that is running but is unable to perform its normal activities MAY silently discard Status-Server packets. This situation can happen, for example, when a server requires access to a database for normal operation, but the connection to that database is down. Or, it may happen when the accepted load on the server is lower than the offered load.
サーバーは、ローカルサイトポリシーに応じて、ステータスサーバーに応答しないことを決定する場合があります。たとえば、実行中ですが、通常のアクティビティを実行できないサーバーは、ステータスサーバーパケットを静かに破棄する場合があります。この状況は、たとえば、サーバーが通常の操作のためにデータベースにアクセスする必要があるが、そのデータベースへの接続がダウンしている場合に発生する可能性があります。または、サーバー上の受け入れられた負荷が提供された負荷よりも低い場合に発生する可能性があります。
Some server implementations require that Access-Request packets be accepted only on "authentication" ports (e.g., 1812/udp), and that Accounting-Request packets be accepted only on "accounting" ports (e.g., 1813/udp). Those implementations SHOULD reply to Status-Server packets sent to an "authentication" port with an Access-Accept packet and SHOULD reply to Status-Server packets sent to an "accounting" port with an Accounting-Response packet.
一部のサーバーの実装では、アクセスリケストパケットは「認証」ポート（例：1812/UDP）でのみ受け入れられ、会計リクエストパケットは「会計」ポート（例：1813/UDP）でのみ受け入れられることが必要です。これらの実装は、Access-Acceptパケットを使用して「認証」ポートに送信されたステータスサーバーパケットに返信し、会計応答パケットを使用して「アカウンティング」ポートに送信されるステータスサーバーパケットに返信する必要があります。
Some server implementations accept both Access-Request and Accounting-Request packets on the same port, and they do not distinguish between "authentication only" ports and "accounting only" ports. Those implementations SHOULD reply to Status-Server packets with an Access-Accept packet.
一部のサーバーの実装は、同じポートにあるアクセスリケストと会計リクエストパケットの両方を受け入れ、「認証のみ」ポートと「アカウンティングのみ」ポートを区別しません。これらの実装は、Access-Acceptパケットを使用してStatus-Serverパケットに返信する必要があります。
The server MAY increment packet counters as a result of receiving a Status-Server packet or sending a Response packet. The server SHOULD NOT perform any other action that is normally performed when it receives a Request packet, other than sending a Response packet.
サーバーは、ステータスサーバーパケットを受信したり、応答パケットを送信したりした結果として、パケットカウンターをインクリメントする場合があります。サーバーは、応答パケットを送信する以外に、リクエストパケットを受信したときに通常実行される他のアクションを実行してはなりません。
A client may wish to "failover" from one proxy to another in the event that it does not receive a response to an Access-Request or Accounting-Request. In order to determine whether the lack of response is due to a problem with the proxy or a downstream server, the client can send periodic Status-Server packets to a proxy after the lack of a response.
クライアントは、アクセスリクエストまたは会計要求への応答を受け取らない場合に、あるプロキシから別のプロキシへの「フェイルオーバー」を希望する場合があります。応答の欠如がプロキシまたはダウンストリームサーバーの問題によるものであるかどうかを判断するために、クライアントは応答がない後に定期的なステータスサーバーパケットをプロキシに送信できます。
These packets will help the client determine if the failure was due to an issue on the path between the client and proxy or the proxy itself, or whether the issue is occurring downstream.
これらのパケットは、クライアントがクライアントとプロキシまたはプロキシ自体の間のパスに関する問題が原因であるかどうか、または問題が下流に発生しているかどうかをクライアントが判断するのに役立ちます。
If no response is received to Status-Server packets, the RADIUS client can initiate failover to another proxy. By continuing to send Status-Server packets to the original proxy, the RADIUS client can determine when it becomes responsive again.
ステータスサーバーパケットへの応答がない場合、RADIUSクライアントは別のプロキシにフェイルオーバーを開始できます。ステータスサーバーパケットを元のプロキシに送信し続けることにより、RADIUSクライアントはいつ再び応答性があるかを判断できます。
Once the server has been deemed responsive, normal RADIUS requests may be sent to it again. This determination should be made separately for each server with which the client has a relationship. The same algorithm SHOULD be used for both authentication and accounting ports. The client MUST treat each destination (IP, port) combination as a unique server for the purposes of this determination.
サーバーがレスポンシブとみなされると、通常の半径要求が再度送信される場合があります。この決定は、クライアントが関係を持っているサーバーごとに個別に行う必要があります。同じアルゴリズムを、認証ポートとアカウンティングポートの両方に使用する必要があります。クライアントは、この決定の目的のために、各宛先（IP、ポート）の組み合わせを一意のサーバーとして扱う必要があります。
Clients SHOULD use a retransmission mechanism similar to that given in Section 2.2.1 of [RFC5080]. If a reliable transport is used for RADIUS, then the watchdog timer algorithm specified in [RFC3539] MUST be used.
クライアントは、[RFC5080]のセクション2.2.1で与えられたものと同様の再送信メカニズムを使用する必要があります。信頼できるトランスポートが半径に使用される場合、[RFC3539]で指定されたウォッチドッグタイマーアルゴリズムを使用する必要があります。
Many RADIUS servers can act as proxy servers, and can forward requests to another RADIUS server. Such servers MUST NOT proxy Status-Server packets. The purpose of Status-Server as specified here is to permit the client to query the responsiveness of a server with which it has a direct relationship. Proxying Status-Server queries would negate any usefulness that may be gained by implementing support for them.
多くのRADIUSサーバーはプロキシサーバーとして機能し、別のRADIUSサーバーにリクエストを転送できます。このようなサーバーは、ステータスサーバーパケットをプロキシであってはなりません。ここで指定されているステータスサーバーの目的は、クライアントが直接的な関係を持つサーバーの応答性を照会できるようにすることです。ステータスサーバークエリのプロキシは、サポートを実装することで得られる可能性のある有用性を無効にします。
Proxy servers MAY be configured to respond to Status-Server queries from clients, and they MAY act as clients sending Status-Server queries to other servers. However, those activities MUST be independent of one another.
プロキシサーバーは、クライアントからのステータスサーバークエリに応答するように構成されている場合があり、他のサーバーにステータスサーバークエリを送信するクライアントとして機能する場合があります。ただし、これらの活動は互いに独立している必要があります。
RADIUS servers are commonly used in an environment where Network Access Identifiers (NAIs) are used as routing identifiers [RFC4282]. In this practice, the User-Name attribute is decorated with realm-routing information, commonly in the format of "user@realm". Since a particular RADIUS server may act as a proxy for more than one realm, we need to explain how the behavior defined above in Section 4.3 affects realm routing.
RADIUSサーバーは、ネットワークアクセス識別子（NAIS）がルーティング識別子として使用される環境で一般的に使用されます[RFC4282]。このプラクティスでは、ユーザー名属性は、一般的に「user@realm」の形式で、レルムルーティング情報で飾られています。特定のRADIUSサーバーは複数の領域のプロキシとして機能する可能性があるため、セクション4.3で上記の動作がレルムルーティングにどのように影響するかを説明する必要があります。
The schematic below demonstrates this scenario.
以下の概略図は、このシナリオを示しています。
/-> RADIUS Proxy P -----> RADIUS Server for Realm A
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server for Realm B
That is, the NAS has relationships with two RADIUS Proxies, P and S. Each RADIUS proxy has relationships with RADIUS servers for both Realm A and Realm B.
つまり、NASには2つのRADIUSプロキシPとSとの関係があります。PとS。各半径プロキシは、領域AとレルムBの両方のRADIUSサーバーとの関係を持っています。
In this scenario, the RADIUS proxies can determine if one or both of the RADIUS servers are dead or unreachable. The NAS can determine if one or both of the RADIUS proxies are dead or unreachable. There is an additional case to consider, however.
このシナリオでは、RADIUSプロキシは、半径サーバーの1つまたは両方が死んでいるか、到達不可能かを判断できます。NASは、半径プロキシの1つまたは両方が死んでいるか、到達不能であるかを判断できます。ただし、考慮すべき追加のケースがあります。
If RADIUS Proxy P cannot reach the RADIUS server for Realm A, but RADIUS Proxy S can reach that RADIUS server, then the NAS cannot discover this information using the Status-Server queries as outlined above. It would therefore be useful for the NAS to know that Realm A is reachable from RADIUS Proxy S, as it can then route all requests for Realm A to that RADIUS proxy. Without this knowledge, the client may route requests to RADIUS Proxy P, where they may be discarded or rejected.
RADIUSプロキシPがRealm AのRADIUSサーバーに到達できないが、RADIUSプロキシSがそのRADIUSサーバーに到達できる場合、NASは上記のようにステータスサーバークエリを使用してこの情報を発見できません。したがって、NASは、Realm AがRealm Aのすべての要求をそのRADIUSプロキシにルーティングできるため、Realm AがRadiusプロキシから到達できることを知ることが有用です。この知識がなければ、クライアントはRadius Proxy Pにリクエストをルーティングでき、そこで廃棄または拒否される場合があります。
To complicate matters, the behavior of RADIUS Proxies P and S in this situation is not well defined. Some implementations simply fail to respond to the request, and other implementations respond with an Access-Reject. If the implementation fails to respond, then the NAS cannot distinguish between the RADIUS proxy being down and the next server along the proxy chain being unreachable.
問題を複雑にするために、この状況における半径プロキシPとSの動作は十分に定義されていません。一部の実装は、単にリクエストに応答できず、他の実装はアクセス拒否で応答します。実装が応答できない場合、NASはRADIUSプロキシがダウンしていることと、プロキシチェーンに沿った次のサーバーが到達不可能であることを区別できません。
In the worst case, failures in routing for Realm A may affect users of Realm B. For example, if RADIUS Proxy P can reach Realm B but not Realm A, and RADIUS Proxy S can reach Realm A but not Realm B, then active paths exist to handle all RADIUS requests. However, depending on the NAS and RADIUS proxy implementation choices, the NAS may not be able to determine to which server requests may be sent in order to maintain network stability.
最悪の場合、領域Aのルーティングの障害は、領域Bのユーザーに影響を与える可能性があります。たとえば、半径プロキシPがレルムbに到達できますが、レルムAではなく、半径プロキシはレルムAではなく領域に到達する可能性があります。すべての半径要求を処理するために存在します。ただし、NASおよびRADIUSプロキシの実装の選択に応じて、NASは、ネットワークの安定性を維持するためにどのサーバー要求を送信できるかを決定できない場合があります。
Unfortunately, this problem cannot be solved by using Status-Server requests. A robust solution would involve either a RADIUS routing table for the NAI realms or a RADIUS "destination unreachable" response to authentication requests. Either solution would not fit into the traditional RADIUS model, and both are therefore outside of the scope of this specification.
残念ながら、この問題は、ステータスサーバーリクエストを使用して解決することはできません。堅牢なソリューションには、NAIレルムの半径ルーティングテーブルまたは認証要求に対する「宛先の到達不可能」応答の半径のいずれかが含まれます。どちらのソリューションも従来の半径モデルには適合しないため、どちらもこの仕様の範囲外です。
The problem is discussed here in order to define how best to use Status-Server in this situation, rather than to define a new solution.
この問題については、新しいソリューションを定義するのではなく、この状況でステータスサーバーを使用する最善の方法を定義するためにここで説明します。
When a server has responded recently to a request from a client, that client MUST mark the server as "responsive". In the above case, a RADIUS proxy may be responding to requests destined for Realm A, but not responding to requests destined for Realm B. The client therefore considers the server to be responsive, as it is receiving responses from the server.
サーバーが最近クライアントからの要求に応答した場合、そのクライアントはサーバーを「応答性」としてマークする必要があります。上記の場合、RADIUSプロキシは、レルムAに任命されたリクエストに応答している可能性がありますが、レルムBに向けられたリクエストに応答しない場合があります。したがって、クライアントはサーバーから応答を受信しているため、サーバーが応答性が高いと考えています。
The client will then continue to send requests to the RADIUS proxy for destination Realm B, even though the RADIUS proxy cannot route the requests to that destination. This failure is a known limitation of RADIUS, and can be partially addressed through the use of failover in the RADIUS proxies.
Radius Proxyがその宛先にリクエストをルーティングできない場合でも、クライアントは宛先レルムBのRADIUSプロキシにリクエストを送信し続けます。この障害は半径の既知の制限であり、半径プロキシでのフェールオーバーの使用により部分的に対処できます。
A more realistic situation than the one outlined above is one in which each RADIUS proxy also has multiple choices of RADIUS servers for a realm, as outlined below.
以下に概説するように、各RADIUSプロキシには、各RADIUSプロキシが領域用のRADIUSサーバーの複数の選択肢もある場合よりも、より現実的な状況です。
/-> RADIUS Proxy P -----> RADIUS Server P
/ \ /
NAS X
\ / \
\-> RADIUS Proxy S -----> RADIUS Server S
In this situation, if all participants implement Status-Server as defined herein, any one link may be broken, and all requests from the NAS will still reach a RADIUS server. If two links are broken at different places (i.e., not both links from the NAS), then all requests from the NAS will still reach a RADIUS server. In many situations where three or more links are broken, requests from the NAS may still reach a RADIUS server.
この状況では、すべての参加者が本明細書で定義されているようにステータスサーバーを実装した場合、1つのリンクが壊れている可能性があり、NASからのすべての要求は依然としてRADIUSサーバーに到達します。2つのリンクが異なる場所で壊れている場合（つまり、NASの両方のリンクではなく）、NASからのすべての要求は依然としてRADIUSサーバーに到達します。3つ以上のリンクが壊れている多くの状況では、NASからのリクエストが依然としてRADIUSサーバーに到達する可能性があります。
It is RECOMMENDED, therefore, that implementations desiring the most benefit from Status-Server also implement server failover. The combination of these two practices will maximize network reliability and stability.
したがって、Status-Serverの最も利益を必要とする実装もサーバーフェールオーバーを実装することをお勧めします。これら2つのプラクティスの組み合わせは、ネットワークの信頼性と安定性を最大化します。
Since Status-Server packets are sent to the defined RADIUS ports, they can affect the [RFC4669] and [RFC4671] RADIUS server MIB modules. [RFC4669] defines a counter named radiusAuthServTotalUnknownTypes that counts "The number of RADIUS packets of unknown type that were received". [RFC4671] defines a similar counter named radiusAccServTotalUnknownTypes. Implementations not supporting Status-Server or implementations that are configured not to respond to Status-Server packets MUST use these counters to track received Status-Server packets.
ステータスサーバーパケットは定義されたRADIUSポートに送信されるため、[RFC4669]および[RFC4671] RADIUSサーバーMIBモジュールに影響を与える可能性があります。[RFC4669]は、「受信された未知のタイプの半径パケットの数」をカウントするRadiusiuthServtotalunkentyTypesという名前のカウンターを定義します。[RFC4671]は、RadiusAccservtotalunkentyTypesという名前の同様のカウンターを定義します。ステータスサーバーをサポートしていない実装またはステータスサーバーパケットに応答しないように構成されている実装は、これらのカウンターを使用して、受信したステータスサーバーパケットを追跡する必要があります。
If, however, Status-Server is supported and the server is configured to respond as described above, then the counters defined in [RFC4669] and [RFC4671] MUST NOT be used to track Status-Server requests or responses to those requests. That is, when a server fully implements Status-Server, the counters defined in [RFC4669] and [RFC4671] MUST be unaffected by the transmission or reception of packets relating to Status-Server.
ただし、ステータスサーバーがサポートされ、サーバーが上記のように応答するように構成されている場合、[RFC4669]および[RFC4671]で定義されているカウンターを使用して、それらのリクエストに対するステータスサーバーの要求または応答を追跡するために使用してはなりません。つまり、サーバーがステータスサーバーを完全に実装する場合、[RFC4669]および[RFC4671]で定義されているカウンターは、ステータスサーバーに関連するパケットの送信または受信の影響を受けない必要があります。
If a server supports Status-Server and the [RFC4669] or [RFC4671] MIB modules, then it SHOULD also support vendor-specific MIB extensions dedicated solely to tracking Status-Server requests and responses. Any definition of the server MIB modules for Status-Server is outside of the scope of this document.
サーバーがステータスサーバーと[RFC4669]または[RFC4671] MIBモジュールをサポートする場合、ステータスサーバーのリクエストと回答の追跡のみに専念するベンダー固有のMIB拡張機能もサポートする必要があります。ステータスサーバーのサーバーMIBモジュールの定義は、このドキュメントの範囲外です。
Clients implementing Status-Server MUST NOT increment [RFC4668] or [RFC4670] counters upon reception of Response packets to Status-Server queries. That is, when a server fully implements Status- Server, the counters defined in [RFC4668] and [RFC4670] MUST be unaffected by the transmission or reception of packets relating to Status-Server.
ステータスサーバーを実装するクライアントは、[RFC4668]または[RFC4670]が、ステータスサーバークエリへの応答パケットの受信時にカウンターをインクリメントしてはなりません。つまり、サーバーがステータスサーバーを完全に実装する場合、[RFC4668]および[RFC4670]で定義されているカウンターは、ステータスサーバーに関連するパケットの送信または受信の影響を受けない必要があります。
If an implementation supports Status-Server and the [RFC4668] or [RFC4670] MIB modules, then it SHOULD also support vendor-specific MIB extensions dedicated solely to tracking Status-Server requests and responses. Any definition of the client MIB modules for Status-Server is outside of the scope of this document.
実装がステータスサーバーと[RFC4668]または[RFC4670] MIBモジュールをサポートする場合、ステータスサーバーのリクエストと回答の追跡のみに専念するベンダー固有のMIB拡張機能もサポートする必要があります。ステータスサーバーのクライアントMIBモジュールの定義は、このドキュメントの範囲外です。
The following table provides a guide to which attributes may be found in Status-Server packets, and in what quantity. Attributes other than the ones listed below SHOULD NOT be found in a Status-Server packet.
次の表は、ステータスサーバーパケットとどの量の属性が見つかるかについてのガイドを示します。以下にリストされている属性以外の属性は、ステータスサーバーパケットに記載されていないべきではありません。
Status- Access- Accounting-Server Accept Response # Attribute
ステータス - アクセス - アカウンティングサーバーは、応答＃属性を受け入れます
0 0 0 1 User-Name
0 0 0 2 User-Password
0 0 0 3 CHAP-Password
0-1 0 0 4 NAS-IP-Address (Note 1)
0 0+ 0 18 Reply-Message
0+ 0+ 0+ 26 Vendor-Specific
0-1 0 0 32 NAS-Identifier (Note 1)
0 0 0 79 EAP-Message
1 0-1 0-1 80 Message-Authenticator
0-1 0 0 95 NAS-IPv6-Address (Note 1)
0 0 0 103-121 Digest-*
Note 1: A Status-Server packet SHOULD contain one of (NAS-IP-Address or NAS-IPv6-Address), or NAS-Identifier, or both NAS-Identifier and one of (NAS-IP-Address or NAS-IPv6-Address).
注1：ステータスサーバーパケットには、NAS-IP-AddressまたはNAS-IPV6-Address）、またはNAS-IDINTIFIERのいずれか、またはNAS-IP-ADDRESSまたはNAS-IPV6-のいずれかを含める必要があります。住所）。
The following table defines the meaning of the above table entries.
次の表は、上記のテーブルエントリの意味を定義しています。
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.
0この属性はパケットに存在してはなりません。この属性の0ゼロ以上のインスタンスがパケットに存在する場合があります。この属性の0-1インスタンスまたは1つのインスタンスがパケットに存在する場合があります。1この属性の1つのインスタンスがパケットに存在する必要があります。
A few examples are presented to illustrate the flow of packets to both the authentication and accounting ports. These examples are not intended to be exhaustive; many others are possible. Hexadecimal dumps of the example packets are given in network byte order, using the shared secret "xyzzy5461".
認証ポートとアカウンティングポートの両方へのパケットの流れを説明するために、いくつかの例が提示されています。これらの例は、網羅的であることを意図したものではありません。他の多くは可能です。サンプルパケットの16進ダンプは、共有秘密の「Xyzzy5461」を使用して、ネットワークバイトの順序で与えられます。
The NAS sends a Status-Server UDP packet with minimal content to a RADIUS server on port 1812.
NASは、ポート1812のRADIUSサーバーに最小限のコンテンツを備えたステータスサーバーUDPパケットを送信します。
The Request Authenticator is a 16-octet random number generated by the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client.
リクエスト認証器は、NASによって生成された16オクセットの乱数です。Message-authenticatorは、リクエストが既知のクライアントからのものであることを認証するために含まれています。
0c da 00 26 8a 54 f4 68 6f b3 94 c5 28 66 e3 02 18 5d 06 23 50 12 5a 66 5e 2e 1e 84 11 f3 e2 43 82 20 97 c8 4f a3
0c DA 00 26 8A 54 F4 68 6F B3 94 C5 28 66 E3 02 18 5D 06 23 50 12 5A 66 5E 2E 1E 84 11 F3 E2 43 82 20 97 C8 4F A3
1 Code = Status-Server (12) 1 ID = 218 2 Length = 38 16 Request Authenticator
1コード= status-server（12）1 id = 218 2 length = 38 16リクエスト認証器
Attributes:
18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
The Response Authenticator is a 16-octet MD5 checksum of the Code (2), ID (218), Length (20), the Request Authenticator from above, and the shared secret.
Response Authenticatorは、コード（2）、ID（218）、長さ（20）の16オクテットのMD5チェックサム、上からのリクエスト認証機、および共有秘密です。
02 da 00 14 ef 0d 55 2a 4b f2 d6 93 ec 2b 6f e8 b5 41 1d 66
02 DA 00 14 EF 0D 55 2A 4B F2 D6 93 EC 2B 6F E8 B5 41 1D 66
1 Code = Access-Accept (2) 1 ID = 218 2 Length = 20 16 Request Authenticator
1 Code = Access-Accept（2）1 Id = 218 2 length = 20 16リクエスト認証器
Attributes: None.
属性：なし。
The NAS sends a Status-Server UDP packet with minimal content to a RADIUS server on port 1813.
NASは、ポート1813のRADIUSサーバーに最小限のコンテンツを備えたステータスサーバーUDPパケットを送信します。
The Request Authenticator is a 16-octet random number generated by the NAS. Message-Authenticator is included in order to authenticate that the request came from a known client.
リクエスト認証器は、NASによって生成された16オクセットの乱数です。Message-authenticatorは、リクエストが既知のクライアントからのものであることを認証するために含まれています。
0c b3 00 26 92 5f 6b 66 dd 5f ed 57 1f cb 1d b7 ad 38 82 60 50 12 e8 d6 ea bd a9 10 87 5c d9 1f da de 26 36 78 58
0C B3 00 26 92 5F 6B 66 DD 5F ED 57 1F CB 1D B7 AD 38 82 60 50 12 E8 D6 EA BD A9 10 87 5C D9 1F DA DE 26 36 78 58
1 Code = Status-Server (12) 1 ID = 179 2 Length = 38 16 Request Authenticator
1コード= status-server（12）1 id = 179 2 length = 38 16リクエスト認証器
Attributes:
18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
The Response Authenticator is a 16-octet MD5 checksum of the Code (5), ID (179), Length (20), the Request Authenticator from above, and the shared secret.
Response Authenticatorは、コード（5）、ID（179）、長さ（20）、上からのリクエスト認証者、および共有秘密の16オクテットのMD5チェックサムです。
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 48 60 66 9c
02 b3 00 14 0f 6f 92 14 5f 10 7e 2f 50 4e 86 0a 48 60 66 9c
1 Code = Accounting-Response (5) 1 ID = 179 2 Length = 20 16 Request Authenticator
1コード= accounting-response（5）1 id = 179 2 length = 20 16リクエスト認証器
Attributes: None.
属性：なし。
The NAS at 192.0.2.16 sends a Status-Server UDP packet to the RADIUS server on port 1812.
192.0.2.16のNASは、ポート1812のRADIUSサーバーにステータスサーバーUDPパケットを送信します。
The Request Authenticator is a 16-octet random number generated by the NAS.
リクエスト認証器は、NASによって生成された16オクセットの乱数です。
0c 47 00 2c bf 58 de 56 ae 40 8a d3 b7 0c 85 13 f9 b0 3f be 04 06 c0 00 02 10 50 12 85 2d 6f ec 61 e7 ed 74 b8 e3 2d ac 2f 2a 5f b2
0C 47 00 2C BF 58 DE 56 AE 40 8A D3 B7 0C 85 13 F9 B0 3F BE 04 06 C0 00 02 10 50 12 85 2D 6F EC 61 E7 ED 74 B8 E3 2D AC 2F 2A 5F B2 B2
1 Code = Status-Server (12) 1 ID = 71 2 Length = 44 16 Request Authenticator
1 Code = status-Server（12）1 id = 71 2 length = 44 16リクエスト認証器
Attributes:
6 NAS-IP-Address (4) = 192.0.2.16
18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2
The Response Authenticator is a 16-octet MD5 checksum of the Code (2), ID (71), Length (52), the Request Authenticator from above, the attributes in this reply, and the shared secret.
Response Authenticatorは、コード（2）、ID（71）、長さ（52）の16オクテットMD5チェックサム、上からのリクエスト認証機、この返信の属性、および共有秘密です。
The Reply-Message is "RADIUS Server up 2 days, 18:40"
返信メッセージは「Radius Server Up 2日、18:40」です
02 47 00 34 46 f4 3e 62 fd 03 54 42 4c bb eb fd 6d 21 4e 06 12 20 52 41 44 49 55 53 20 53 65 72 76 65 72 20 75 70 20 32 20 64 61 79 73 2c 20 31 38 3a 34 30
02 47 00 34 46 F4 3E 62 FD 03 54 42 4C BB EB FD 6D 21 4E 06 12 20 52 41 44 44 44 49 55 53 20 53 65 72 76 65 72 20 75 70 20 32 20 64 61 79 73 2C 20 31 38 3A34 30
1 Code = Access-Accept (2) 1 ID = 71 2 Length = 52 16 Request Authenticator
1 Code = Access-Accept（2）1 Id = 71 2 Length = 52 16 Request Authenticator
Attributes: 32 Reply-Message (18)
属性：32 Reply-Message（18）
This document defines the Status-Server packet as being similar in treatment to the Access-Request packet, and is therefore subject to the same security considerations as described in [RFC2865], Section 8. Status-Server packets also use the Message-Authenticator attribute, and are therefore subject to the same security considerations as [RFC3579], Section 4.
このドキュメントでは、ステータスサーバーパケットがアクセスリケストパケットとの治療が類似していると定義されているため、[RFC2865]、セクション8で説明されているのと同じセキュリティ上の考慮事項があります。、したがって、[RFC3579]、セクション4と同じセキュリティ上の考慮事項の対象となります。
We reiterate that Status-Server packets MUST contain a Message-Authenticator attribute. Early implementations supporting Status-Server did not enforce this requirement, and were vulnerable to the following attacks:
Status-Serverパケットには、メッセージAuthenticator属性が含まれている必要があることを繰り返します。ステータスサーバーをサポートする初期の実装は、この要件を実施せず、次の攻撃に対して脆弱でした。
* Servers not checking the Message-Authenticator attribute could respond to Status-Server packets from an attacker, potentially enabling a reflected DoS attack onto a real client.
* メッセージAuthenticator属性をチェックしないサーバーは、攻撃者からのステータスサーバーパケットに応答し、実際のクライアントに反射したDOS攻撃を可能にする可能性があります。
* Servers not checking the Message-Authenticator attribute could be subject to a race condition, where an attacker could see an Access-Request packet from a valid client and synthesize a Status-Server packet containing the same Request Authenticator. If the attacker won the race against the valid client, the server could respond with an Access-Accept and potentially authorize unwanted service.
* メッセージ-Authenticator属性をチェックしないサーバーは、攻撃者が有効なクライアントからアクセスリクエストパケットを表示し、同じリクエスト認証器を含むステータスサーバーパケットを合成することができるレース条件の対象となる可能性があります。攻撃者が有効なクライアントとのレースに勝った場合、サーバーはアクセスacceptで応答し、不要なサービスを潜在的に許可することができます。
The last attack is similar to a related attack when Access-Request packets contain a CHAP-Password but no Message-Authenticator. We re-iterate the suggestion of [RFC5080], Section 2.2.2, which proposes that all clients send a Message-Authenticator in every Access-Request packet, and that all servers have a configuration setting to require (or not) that a Message-Authenticator attribute be used in every Access-Request packet.
最後の攻撃は、Access-RequestパケットにChap-Passwordが含まれているがメッセージAuthenticatorがない場合の関連攻撃に似ています。[RFC5080]の提案、セクション2.2.2を繰り返します。これは、すべてのクライアントがすべてのアクセスリケストパケットでメッセージauthenticatorを送信し、すべてのサーバーがメッセージを要求する構成設定を持っていることを提案しています。-authenticator属性は、すべてのアクセスリケストパケットで使用されます。
Failure to include a Message-Authenticator attribute in a Status-Server packet means that any RADIUS client or server may be vulnerable to the attacks outlined above. For this reason, implementations of this specification that fail to require use of the Message-Authenticator attribute are NOT RECOMMENDED.
Status-ServerパケットにメッセージAuthenticator属性を含めることができないことは、上記の攻撃に対してradiusクライアントまたはサーバーが脆弱であることを意味します。このため、Message-authenticator属性の使用を必要としないこの仕様の実装は推奨されません。
Where this document differs from [RFC2865] is that it defines a new request/response method in RADIUS: the Status-Server request. As this use is based on previously described and implemented standards, we know of no additional security considerations that arise from the use of Status-Server as defined herein.
このドキュメントが[RFC2865]と異なるのは、RADIUSで新しいリクエスト/応答方法を定義することです：ステータスサーバーリクエスト。この使用は以前に記載および実装された標準に基づいているため、本明細書で定義されているステータスサーバーの使用から生じる追加のセキュリティ上の考慮事項はありません。
Attacks on cryptographic hashes are well known [RFC4270] and getting better with time. RADIUS uses the MD5 hash [RFC1321] for packet authentication and attribute obfuscation. There are ongoing efforts in the IETF to analyze and address these issues for the RADIUS protocol.
暗号化のハッシュに対する攻撃はよく知られており[RFC4270]、時間とともに良くなります。RADIUSは、パケット認証と属性難読化にMD5ハッシュ[RFC1321]を使用します。IETFでは、RADIUSプロトコルのこれらの問題を分析および対処するための継続的な取り組みがあります。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「The MD5 Message-Digest Algorithm」、RFC 1321、1992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B。およびJ. Wood、「認証、認可および会計（AAA）輸送プロファイル」、RFC 3539、2003年6月。
[RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[RFC4086] EastLake 3rd、D.、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The Network Access Identifier", RFC 4282, December 2005.
[RFC4282] Aboba、B.、Beadles、M.、Arkko、J。、およびP. Eronen、「ネットワークアクセス識別子」、RFC 4282、2005年12月。
[RFC5080] Nelson, D. and A. DeKok, "Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes", RFC 5080, December 2007.
[RFC5080] Nelson、D。およびA. Dekok、「一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）実装の問題と提案された修正」、RFC 5080、2007年12月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。
[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.
[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270] Hoffman、P。およびB. Schneier、「インターネットプロトコルにおける暗号化ハッシュへの攻撃」、RFC 4270、2005年11月。
[RFC4668] Nelson, D., "RADIUS Authentication Client MIB for IPv6", RFC 4668, August 2006.
[RFC4668]ネルソン、D。、「IPv6のRADIUS認証クライアントMIB」、RFC 4668、2006年8月。
[RFC4669] Nelson, D., "RADIUS Authentication Server MIB for IPv6", RFC 4669, August 2006.
[RFC4669]ネルソン、D。、「IPv6のRADIUS認証サーバーMIB」、RFC 4669、2006年8月。
[RFC4670] Nelson, D., "RADIUS Accounting Client MIB for IPv6", RFC 4670, August 2006.
[RFC4670]ネルソン、D。、「IPv6のRadiusアカウンティングクライアントMIB」、RFC 4670、2006年8月。
[RFC4671] Nelson, D., "RADIUS Accounting Server MIB for IPv6", RFC 4671, August 2006.
[RFC4671]ネルソン、D。、「IPv6のRadiusアカウンティングサーバーMIB」、RFC 4671、2006年8月。
Acknowledgments
謝辞
Parts of the text in Section 3 defining the Request and Response Authenticators were taken, with minor edits, from [RFC2865], Section 3.
セクション3のテキストの一部は、[RFC2865]、セクション3のマイナーな編集で、リクエストと応答の認証器を定義しました。
The author would like to thank Mike McCauley of Open Systems Consultants for making a Radiator server available for interoperability testing.
著者は、ラジエーターサーバーを相互運用性テストに利用できるようにしてくれたOpen SystemsコンサルタントのMike McCauleyに感謝します。
Ignacio Goyret provided valuable feedback on the history and security of the Status-Server packet.
Ignacio Goyretは、ステータスサーバーパケットの歴史とセキュリティに関する貴重なフィードバックを提供しました。
Author's Address
著者の連絡先
Alan DeKok The FreeRADIUS Server Project http://freeradius.org
Alan Dekok Freeradius Server Project http://freeradius.org
EMail: aland@freeradius.org