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
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によって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 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.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報が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.
著作権（C）2010 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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トラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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.
この材料の一部がIETFトラストにこのような材料の変更を許可する権利を与えられていない可能性がありますにこの文書は、2008年、IETFドキュメントまたは11月10日以前に発行または公開さIETF貢献から著作権を支配する者（複数可）材料を含んでいてもよいですIETF標準化プロセスの外。そのような材料の著作権を管理者（単数または複数）から適切なライセンスを取得することなく、この文書は、IETF標準化過程の外側修正されないかもしれません、そして、それの派生物は、IETF標準化過程の外側に作成されない場合があり、それをフォーマットする以外出版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での実験のように定義されたが、操作及びコードの潜在的な使用の詳細は提供されませんでした。
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.
コアRADIUSプロトコルと同様に、ステータス・サーバーの拡張子はステートレスで、クエリはそれ以外の場合は、サーバーの正常な動作には影響しません、また、彼らはおそらく内部のパケットカウンタをインクリメントする以外、任意の副作用をもたらします。この拡張機能の実装のほとんどは、この文書はUDPトランスポートでこの拡張の使用のみに焦点を当てるように、[RFC2865]で定義されているRADIUSの実装と一緒にそれを利用してきました。
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節では、属性のRADIUSテーブルが含まれています。残りのテキストは、文書内の他の場所でカバーされていないセキュリティ上の考慮事項について説明します。
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.
このプロトコルのいくつかの既存の実装はMessage-Authenticatorアトリビュートをサポートしていません（[RFC3579]）。これは、潜在的に間違って受け入れてアクセスにつながる、なりすましステータス・サーバーのパケットに不正なクライアントを可能にします。この問題を解決するために、この仕様は、パケットごとの認証と完全性保護を提供するために、Message-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].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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データグラム内に含まれなければなりません。パケットごとの認証と完全性保護を提供するようにMessage-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サーバまたはプロキシは、接続許可（認証ポート）またはアカウンティング - 応答（アカウンティングポート）とステータス・サーバーのパケットに応答する必要があります。アクセスチャレンジ応答が推奨されていません。アクセス拒否応答を使用することができます。ステータス・サーバーのパケットに許可された属性、およびアクセス - 受け入れやステータス・サーバーのパケットに応答アカウンティング応答パケットのリストは、第6節は、いくつかの例を提供して第5節で提供されています。
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クライアントとサーバ間のパス上にないため、クライアントは、そのサーバーのみの状態の表示を備えています。サーバーは、User-Name属性を調べずにステータス・サーバーのパケットに応答として、ステータス・サーバーのパケットに対する応答は、特定のレルムの到達可能性に関する情報を推測するために使用することはできません。
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クライアントに便利です。ステータス・サーバーのパケットが非転送可能であるので、応答の欠如は、パケット損失または宛先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節ではありません。 「キープアライブは、」ダウンストリームサーバーが応答するかどうかを判断するために送られたアクセス要求パケットです。これらのパケットは、通常、サーバーがダウンしていることが疑われる場合にのみ、送信されていない、と彼らはもはや、すぐにサーバーが再び利用可能であるとして送信されます。
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.
NASは、RADIUSサーバの認証ポートに特別に形成されたAccess-Requestパケットを送信するためのサーバのステータスを照会する問題に対する1つの可能なソリューションです。 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にログオンしていることを結論付けることができます。その後、サーバーは、単純なステータスクエリーのために望ましくないアクションを実行することができます。サーバは、代わりにそれが拡張認証対話が必要であると考えていることを示す、アクセスチャレンジで応答することができます。
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.
別の可能性は、サーバは、ユーザがネットワークにアクセスを許可されていないことを示し、拒否のアクセスに応答することです。上記のように、サーバはまた、失敗したログイン試行の管理者に警告するなど、ローカルサイトのアクションを実行することができます。サーバはまた、律速失敗した認証試行の伝統的な方法で、アクセス拒否応答を遅延させることができます。応答におけるこの遅延は、サーバーがダウンしているか否かの照会管理者が応答し、または意図的に、クエリへの応答を遅らせるために、遅い不確かであることを意味しています。
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.
また、アクセス要求のクエリを使用すると、サーバは、ローカルユーザーがその唯一の理由の存在のためにこれらのクエリ要求を有効にすることです設定されていることを意味するかもしれません。サーバーポリシーを慎重に設計されていない限り、攻撃者が不正なネットワークアクセスを得るために、これらの資格情報を使用することが可能です。
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の実装は、現在のAccess-Requestパケットを使用することに注意してください。その機器と実装の問題は、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の実装は、サーバーが生きているかどうかを確認するためだけのAccess-Requestパケットを生成するべきではありません。同様に、サイトの管理者は、その唯一の理由の存在のためのAccess-Requestパケットを経由してこのようなクエリを有効にすることですテストユーザーを設定しないでください。
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.
アクセス要求して上で見られるように、サーバーは、実際のユーザーが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.
ステータス - サーバのパケットは、[RFC2865]で定義され、第3項は、我々がここでそのセクションのテキストや図の全てを含んでいないとして、これらのフィールドのフィールドと値で、RADIUSパケットのフォーマットを再利用し、代わりに必要な違いを説明しますステータス・サーバーを実装します。
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.
識別子フィールドの役割は、他のパケットのためとして、ステータス・サーバーでも同じです。ステータス・サーバーがアクセス要求またはアカウンティング要求パケットの役割を取っているようしかし、同じ識別子を持つアクセス要求またはアカウンティング要求パケットと競合しているとステータス-Serverリクエストする可能性があります。以下の4.2節では、我々はこれらの問題を回避する方法について説明します。この方法では、ステータス・サーバーおよび他のパケットタイプ間の競合を回避するために使用しなければなりません。
Request 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.
ステータス・サーバーのパケットでは、認証値は、要求認証と呼ばれる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.
アクセス - 受け入れアクセス - 受け入れで、アクセス要求に応答して送信された応答のオーセンティケータを計算するために使用されるステータス・サーバークエリに応答して送信されたパケットは、同じ方法を使用して生成されなければならないのも同様に、応答認証フィールドアクセス要求の要求認証の行わステータス・サーバー要求認証。
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.
アカウンティング要求に応答して送信されるアカウンティングレスポンスのレスポンス認証を計算するために使用されるステータス・サーバークエリに応答して送信されるアカウンティング応答パケットの応答認証フィールドはステータス - で、同じ方法を使用して生成されなければなりませんアカウンティング要求の要求認証に代わるサーバー要求認証。
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,
含め、Codeフィールドで始まる、RADIUSパケット：アクセス-受け入れるか、アカウンティング応答パケットにおける認証フィールドの値は、レスポンス認証と呼ばれる、とから成る八重奏のストリームに関して計算一方向MD5ハッシュが含まれています識別子、長さ、ステータス・サーバーのパケットからの要求認証フィールド、および応答の属性（もしあれば）、共有秘密が続きます。あれは、
ResponseAuth = MD5(Code+ID+Length+RequestAuth+Attributes+Secret)
ResponseAuth = MD5（コード+ ID +長さ+ RequestAuth +は+シークレット属性）
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.
上記の要件に加えて、すべてのステータス・サーバーのパケットは、Message-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-ID、およびNAS-IP-アドレスの1またはNAS-IPv6にアドレスを含んでいてもよいです。これらの属性は、ステータス・サーバーの動作に必要ではないですが、それらのパケットを受信するサーバーに役立つ情報であってもよいです。
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.
他の属性は、ステータス・サーバーのパケットに含めるべきではない、と彼らは含まれている場合は無視しなければなりません。こうしたユーザー名、ユーザーパスワード、CHAP-パスワードなどのユーザ認証証明書は、EAP-のメッセージは、RADIUS認証ポートに送信されたステータス・サーバーのパケットに現れてはいけません。ユーザーまたはNAS会計は、このようなアカウンティング・セッションId、ACCT-ステータス・タイプ、ACCT-入力オクテットは、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.
アクセス - 受け入れ返信メッセージまたはMessage-Authenticatorアトリビュートを含むかもしれません。これは、他の属性を含めることはできません。ステータス-Serverのクエリに応答して送信されるアカウンティング応答パケットは、任意の属性を含めることはできません。意図はなく、ユーザー認証やアカウンティングの単純なクエリを実行することであるとして、クエリまたは対応する応答のいずれかで他の属性を含めるする理由はほとんどありません。
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.
したがって、我々は一貫してステータス・サーバーを定義し、要求が送信されているポートに応じて、応答パケットを変えます。認証ポートに送信された場合は、ステータス-Serverのクエリに対する応答は、接続許可パケットです。アカウンティングポートに送信された場合は、ステータス-Serverのクエリに対する応答は、アカウンティング応答パケットです。
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
* Requestパケット
An Access-Request packet sent to an authentication port or an Accounting-Request packet sent to an accounting port.
認証ポートまたはアカウンティングポートに送信されたアカウンティング要求パケットに送信されたAccess-Requestパケット。
* Response packet
* Responseパケット
An Access-Accept, Access-Challenge, or Access-Reject packet sent from an authentication port or an Accounting-Response packet sent from an accounting port.
アクセス - 受け入れ、アクセスチャレンジ、または認証ポートまたはアカウンティングポートから送信された会計-Responseパケットから送信されたアクセス拒否パケット。
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.
ステータス・サーバーのパケットがクライアントから送信されたとき、彼らは再送信してはなりません。代わりに、アイデンティティフィールドは、パケットが送信されるたびに変更する必要があります。古いパケットが破棄されなければならない、と新しいステータス・サーバーのパケットが生成され、送信され、新しいアイデンティティと認証フィールドを持つべきです。
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.
クライアントは、すべてのステータス・サーバーのパケットでMessage-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宛先ポートにステータス-Serverリクエストを送信することができます。他のクライアントは要求パケットを送信するために使用されていない独自のソースポートからステータス-Serverリクエストを送信するために選ぶかもしれません。
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.
要求への応答を合わせるのStatus-Serverのパケット補助のためのユニークな送信元ポートの上記の提案。ステータス・サーバーのパケットに対する応答がアクセス-受け入れるか、アカウンティング応答パケットであるので、それらの応答が要求パケットに応答して送信される他のパケットと区別できません。そのため、他のトラフィックと区別するための最良の方法は、固有のポートを持つことです。
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 Codeフィールドの値とは無関係に、その送信元ポートのすべての未処理の要求パケットで一意である必要があります。クライアントがステータス・サーバーのパケットへの応答を受け取ったか、ステータス・サーバーのパケットがタイムアウトしたと判断したのいずれかと、それは別のパケットでその識別子を再利用することができます。
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.
これは、有効なものとして応答を受け入れる前にある、クライアントが応答パケットコードフィールドはどちらかであるアクセス-受け入れ（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.
サーバーRequestパケットを送信することが許可されていないクライアントから発信ステータス・サーバーのパケットが静かに捨てなければなりません。サーバはステータス・サーバーのパケットをサポートしていない、またはそれらに反応しないように構成されている場合は、それは静かにパケットを捨てなければなりません。
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は、RADIUSコードの数を定義しますが、コードは対照的に、ポート1812に対して有効であるかについての声明、[RFC2866]、セクション3、唯一のRADIUSアカウンティングパケットがすることを指定をしないことに注意してくださいポート1813に送信され、それがポート1812にパケットのために知られているコードを使用していますので、この仕様は、それが有効である新しいコード（ステータス-Server）を追加し、この仕様は、[RFC2866]との互換性がありません、[RFC2865]と互換性があります[RFC2866]のカテゴリが通知され、ポート1812しかしながら、この競合は許容可能です。
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.
彼らは、クライアントが特定の期間にあまりにも多くのステータス-Serverリクエストを送信していると判断した場合、サーバーが黙っステータス・サーバーのパケットを破棄すべきです。この決定を行うためにサーバによって使用される方法は、実装固有のこの仕様の範囲外です。
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]で定義されるように、それは、セクション3.2をMessage-Authenticatorアトリビュートを検証する必要があります。その検証に失敗したパケットは黙って捨てなければなりません。
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）に受け入れられます。これらの実装は、接続許可パケットで「認証」のポートに送信されたステータス・サーバーのパケットに応答すべき会計-Responseパケットで「会計」のポートに送信されたステータス・サーバーのパケットに返信すべきです。
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.
一部のサーバーの実装は、同じポートにアクセス要求およびアカウンティング要求パケットの両方を受け入れ、彼らは「認証のみ」のポートとポートを「唯一の会計」を区別しません。これらの実装は、接続許可パケットでステータス・サーバーのパケットに返信すべきです。
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.
サーバーは、ステータス・サーバーのパケットを受信したか、応答パケットを送信した結果として、パケットカウンタをインクリメントするかもしれません。サーバは、応答パケットを送信するよりも、他のRequestパケットを受信したときに正常に行われている他のアクションを実行しないでください。
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.
サーバが応答とみなされた後、通常のRADIUS要求が再びそれに送信することができます。この決定は、クライアントが関係を有するサーバごとに個別になされるべきです。同じアルゴリズムは、認証とアカウンティングポートの両方に使用されるべきです。クライアントは、この決意の目的のためにユニークなサーバとして各目的地（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で与えられたものと同様の再送信機構を使用すべきです。信頼性の高いトランスポートがRADIUSに使用されている場合は、[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サーバは、一般に、ネットワークアクセス識別子（のNAI）をルーティング識別子[RFC4282]として使用される環境で使用されます。この練習では、User-Name属性は、一般に、「ユーザー@レルム」の形式で、レルムルーティング情報で飾られています。特定の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は、各RADIUSプロキシはレルムAと領域Bの両方のためのRADIUSサーバとの関係を有している2台のRADIUSプロキシ、P及びSとの関係を有しています
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サーバーのいずれかまたは両方が死んでいるか到達できない場合は、このシナリオでは、RADIUSプロキシを決定することができます。 RADIUSプロキシの1つまたは両方が死んでいるか到達不能である場合にNASを決定することができます。しかし、考慮すべき追加的なケースがあります。
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は、レルムAのためのRADIUSサーバに到達することはできませんが、RADIUSプロキシSは、そのRADIUSサーバに達することができるならば、NASは、上記で概説したようにステータス・サーバーのクエリを使用してこの情報を発見することはできません。それはRADIUSプロキシへのルートレルムAのためのすべての要求を、その後できる限りNASは、Aは、RADIUSプロキシSから到達可能であることレルムを知ることは有用だろう。この知識がないと、クライアントは、RADIUSプロキシ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
問題を複雑にし、このような状況ではRADIUSプロキシPとSの動作は明確に定義されていません。一部の実装では、単に要求に応答しないと、他の実装がで応答します
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.
アクセス拒否。実装が応答に失敗した場合、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.
RADIUSプロキシPはレルムBなくレルムAに到達することができ、およびRADIUSプロキシSはレルムAなくレルムB、アクティブパスに達することができれば、最悪の場合には、レルムAのルーティングの失敗は、例えばレルムBのユーザーに影響を与える可能性すべてのRADIUS要求を処理するために存在します。しかし、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レルムのためのRADIUSルーティングテーブルやRADIUS認証要求を「宛先到達不能」応答のいずれかを伴うだろう。どちらのソリューションは、従来のRADIUSモデルに適合しないだろう、との両方がこの仕様の範囲の外にそれゆえです。
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.
問題は、最高の新しいソリューションを定義するのではなく、このような状況でステータス-Serverを使用する方法を定義するために、ここで説明されています。
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プロキシはその目的地へのルートリクエストをすることはできませんが、先のレルムB用のRADIUSプロキシに要求を送信し続けます。この障害は、RADIUSの既知の制限であり、部分的に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 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.
本明細書で定義されるすべての参加者がステータス・サーバーを実装する場合は、このような状況では、いずれかのリンクが破損する可能性があり、NASからのすべての要求は、まだRADIUSサーバに到達します。二つのリンクが別の場所で壊れている場合（つまり、いないNASからの両方のリンク）は、その後、NASからのすべての要求は、まだRADIUSサーバに到達します。三件の以上のリンクが壊れている多くの状況では、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.
ステータス・サーバーから最大の利益を望む実装は、サーバのフェイルオーバーを実装すること、そのため、推奨されます。これらの二つの実践の組み合わせは、ネットワークの信頼性と安定性を最大化します。
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]「は受信された未知のタイプのRADIUSパケットの数」をカウントするカウンタと命名radiusAuthServTotalUnknownTypesを定義します。 [RFC4671]はradiusAccServTotalUnknownTypes名前同様のカウンタを規定します。実装は、ステータス・サーバーまたは受信ステータス・サーバーのパケットを追跡するために、これらのカウンタを使用しなければならない状況、サーバーのパケットに応答しないように構成されている実装をサポートしていません。
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-
ステータス・サーバーを実装するクライアントは、ステータス・サーバーのクエリに対する応答パケットの受信時に、[RFC4668]か[RFC4670]カウンタをインクリメントしてはなりません。サーバーが完全にステータス - を実装した場合には、あります
Server, the counters defined in [RFC4668] and [RFC4670] MUST be unaffected by the transmission or reception of packets relating to Status-Server.
サーバ、[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.
次の表は、ステータス・サーバー・パケット中に見出すことができる属性にガイドを提供し、どのような量です。下記に記載されたもの以外の属性は、ステータス・サーバーのパケットに記載されていない（SHOULD NOT）。
Status- Access- Accounting-Server Accept Response # Attribute
ステータス - Access-アカウンティングサーバレスポンス＃属性を受け入れます
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-*
0 0 0 1ユーザ名0 0 0 2ユーザパスワード0 0 3 CHAP-パスワード0-1 0 0 4 NAS-IPアドレス（注1）0 0 + 0 18返信メッセージ0+ 0+ 0+ 26ベンダー固有0-1 0 0 32 NAS-識別子0 0 79 EAP-メッセージ（注1）1 0-1 0-1 80メッセージ認証0-1 0 0 95 NAS-のIPv6アドレス（注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-アドレスまたはNAS-IPv6の-アドレス）、またはNAS識別子、またはその両方NAS-識別子と（NAS-IP-Address]またはNAS-IPv6-の1住所）。
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".
いくつかの例は、両方の認証とアカウンティングポートへのパケットの流れを説明するために提示されています。これらの例は網羅するものではありません。多くの他のものが可能です。例えば、パケットの進ダンプが共有秘密「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オクテット乱数です。メッセージ認証は、要求が既知のクライアントから来たことを認証するために含まれています。
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
0 5 28 YYレイク02 18 5E 06 23 50 12 SHF FCHのKBのyach 26 8 54 68 00 5A YY 5F 1F 2F 84 11 FZ E2 43 82 20 97 C8の4f A3
1 Code = Status-Server (12) 1 ID = 218 2 Length = 38 16 Request Authenticator
1コード=ステータス・サーバ（12）1、ID = 218 2長さ= 38 16リクエスト認証
Attributes: 18 Message-Authenticator (80) = 5a665e2e1e8411f3e243822097c84fa3
属性：18メッセージオーセンティケータ（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.
レスポンス認証は、コードの16オクテットMD5チェックサムであり、（2）、ID（218）、長さ（20）は、上記の要求の認証、および共有シークレット。
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つのコード=アクセス - 受け入れ（2）1つのID = 218 2長さ= 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オクテット乱数です。メッセージ認証は、要求が既知のクライアントから来たことを認証するために含まれています。
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
0キロバイト00 26 92 5F IIIb族YY電子部5fユニット38 82 60 50 12 E8メチルプロパFA BPアヤ10 87 5 D9 1Fダ・デ・26 36 78 58 AE COMMON 1E 57 1UのCB
1 Code = Status-Server (12) 1 ID = 179 2 Length = 38 16 Request Authenticator
1コード=ステータス・サーバ（12）1、ID = 179 2長さ= 38 16リクエスト認証
Attributes: 18 Message-Authenticator (80) = e8d6eabda910875cd91fdade26367858
属性：18メッセージオーセンティケータ（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.
レスポンス認証は、上記のコード（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 BZ 00 14 0F SV 92 14 5F 10あろう2F 50 NPP YY 86 0A 48 60すなわち
1 Code = Accounting-Response (5) 1 ID = 179 2 Length = 20 16 Request Authenticator
1コード=アカウンティング - 応答（5）1、ID = 179 2長さ= 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
EC 61 E7 6F 0C 47 00 2C BF 58ド56 AE 40 8A D3 B7 0C 85 13 F9 B0 3F 04 06 C0 00 02 10 50 12 85である2dは74 B8のE3 2D交流2F 2aは5F B2とを編
1 Code = Status-Server (12) 1 ID = 71 2 Length = 44 16 Request Authenticator
1つのコード=ステータス・サーバ（12）1、ID = 71 2の長さ= 44 16リクエスト認証
Attributes: 6 NAS-IP-Address (4) = 192.0.2.16 18 Message-Authenticator (80) = 852d6fec61e7ed74b8e32dac2f2a5fb2
属性：6 NAS-IPアドレス（4）= 192.0.2.16 18メッセージオーセンティケータ（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.
レスポンス認証は、コード（2）、ID（71）、長さ（52）の16オクテットMD5チェックサム、上記からの要求認証、この応答の属性、および共有秘密です。
The Reply-Message is "RADIUS Server up 2 days, 18:40"
返信メッセージは、「アップ2日間、午前18時40分RADIUSサーバ」であります
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が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はfdが34 30
1 Code = Access-Accept (2) 1 ID = 71 2 Length = 52 16 Request Authenticator
1つのコード=アクセス - 受け入れ（2）1つのID = 71 2の長さ= 52 16リクエスト認証
Attributes: 32 Reply-Message (18)
属性：32返信メッセージ（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:
私たちは、ステータス・サーバーのパケットはMessage-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.
*サーバはMessage-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.
* Message-Authenticatorアトリビュートをチェックしていないサーバは、攻撃者が有効なクライアントからのアクセス要求パケットを参照し、同じ要求認証を含むステータス・サーバーのパケットを合成することができ、レースコンディション、を受ける可能性があります。攻撃者が有効なクライアントとの戦いに勝った場合、サーバーは、アクセス・受け入れで応答し、潜在的に不要なサービスを許可することができます。
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.
アクセス要求パケットはCHAP-パスワードが、ノーメッセージ認証が含まれている場合、最後の攻撃は、関連する攻撃に似ています。我々は、すべてのクライアントは、すべてのAccess-Requestパケットにメッセージ認証を送信し、すべてのサーバーが構成設定を持っていることを要求（またはしない）メッセージがそのためにすることを提案している[RFC5080]、セクション2.2.2、の提案を、反復再-Authenticator属性は、すべてのAccess-Requestパケットで使用されます。
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.
ステータス・サーバーのパケットにMessage-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]を使用し、難読化属性。 RADIUSプロトコルのために、これらの問題を分析し、対処するためのIETFでの継続的な努力があります。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321]のRivest、R.、 "MD5メッセージダイジェストアルゴリズム"、RFC 1321、1992年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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.、ウィレンス、S.、ルーベン、A.、およびW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC3539] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[RFC3539] Aboba、B.、およびJ.ウッド、 "認証、認可およびアカウンティング（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]イーストレーク3、D.、シラー、J.、およびS.クロッカー、 "セキュリティのためのランダム要件"、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]ネルソン、D.とA. DeKok、RFC 5080、2007年12月 "ユーザーサービス（RADIUS）の実装の問題と推奨修正に共通のリモート認証ダイヤル"。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、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.カルフーン、 "RADIUS（ユーザサービスにおけるリモート認証ダイヤル）拡張認証プロトコル（EAP）のサポート"、RFC 3579、2003年9月。
[RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic Hashes in Internet Protocols", RFC 4270, November 2005.
[RFC4270]ホフマン、P.とB.シュナイアー、 "インターネットプロトコルで暗号化ハッシュに対する攻撃"、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.
著者は相互運用性テスト用ラジエーターサーバを利用可能にするためにオープンシステムコンサルタントのマイク・マッコーリーに感謝したいと思います。
Ignacio Goyret provided valuable feedback on the history and security of the Status-Server packet.
イグナシオGoyretは、ステータス・サーバーパケットの歴史やセキュリティ上の貴重なフィードバックを提供します。
Author's Address
著者のアドレス
Alan DeKok The FreeRADIUS Server Project http://freeradius.org
アランDeKok FreeRADIUSサーバプロジェクトhttp://freeradius.org
EMail: aland@freeradius.org
メールアドレス：aland@freeradius.org