RFC 5080 - Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes 日本語訳

URL : https://tools.ietf.org/html/rfc5080
タイトル : RFC 5080 - ユーザーサービス（RADIUS）の実装の問題と推奨修正に共通のリモート認証ダイヤル
翻訳編集 : 自動生成

Network Working Group                                          D. Nelson
Request for Comments: 5080                          Elbrys Networks, Inc
Updates: 2865, 2866, 2869, 3579                                 A. DeKok
Category: Standards Track                                     FreeRADIUS
                                                           December 2007

       Common Remote Authentication Dial In User Service (RADIUS)
               Implementation Issues and Suggested Fixes

Status of This Memo

このメモのステータス

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

Abstract

抽象

This document describes common issues seen in Remote Authentication Dial In User Service (RADIUS) implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.

このドキュメントでは、ユーザーサービス（RADIUS）の実装ではリモート認証ダイヤルで見られる一般的な問題について説明し、いくつかの修正を示唆しています。該当する場合には、前回のRADIUS仕様で曖昧とエラーが明確にされています。

Table of Contents

   1. Introduction ....................................................2
      1.1. Terminology ................................................3
      1.2. Requirements Language ......................................3
   2. Issues ..........................................................3
      2.1. Session Definition .........................................3
           2.1.1. State Attribute .....................................3
           2.1.2. Request-ID Supplementation ..........................6
      2.2. Overload Conditions ........................................7
           2.2.1. Retransmission Behavior .............................7
           2.2.2. Duplicate Detection and Orderly Delivery ...........10
           2.2.3. Server Response to Overload ........................11
      2.3. Accounting Issues .........................................12
           2.3.1. Attributes Allowed in an Interim Update ............12
           2.3.2. Acct-Session-Id and Acct-Multi-Session-Id ..........12
           2.3.3. Request Authenticator ..............................13
           2.3.4. Interim-Accounting-Interval ........................13
           2.3.5. Counter Values in the RADIUS Management
                  Information Base (MIB) .............................14
      2.4. Multiple Filter-ID Attributes .............................15
      2.5. Mandatory and Optional Attributes .........................16
      2.6. Interpretation of Access-Reject ...........................18
           2.6.1. Improper Use of Access-Reject ......................18
           2.6.2. Service Request Denial .............................19
      2.7. Addressing ................................................20
           2.7.1. Link-Local Addresses ...............................20
           2.7.2. Multiple Addresses .................................20
      2.8. Idle-Timeout ..............................................21
      2.9. Unknown Identity ..........................................21
      2.10. Responses After Retransmissions ..........................22
      2.11. Framed-IPv6-Prefix .......................................23
   3. Security Considerations ........................................24
   4. References .....................................................25
      4.1. Normative References ......................................25
      4.2. Informative References ....................................25

1. Introduction

1. はじめに

The last few years have seen an increase in the deployment of RADIUS clients and servers. This document describes common issues seen in RADIUS implementations and suggests some fixes. Where applicable, ambiguities and errors in previous RADIUS specifications are clarified.

ここ数年は、RADIUSクライアントとサーバーの展開の増加を見てきました。このドキュメントでは、RADIUSの実装で見られる一般的な問題について説明し、いくつかの修正を示唆しています。該当する場合には、前回のRADIUS仕様で曖昧とエラーが明確にされています。

1.1. Terminology

1.1. 用語

This document uses the following terms:

このドキュメントでは、次の用語を使用しています：

Network Access Server (NAS) The device providing access to the network. Also known as the Authenticator in IEEE 802.1X or Extensible Authentication Protocol (EAP) terminology, or RADIUS client.

ネットワークアクセスサーバー（NAS）ネットワークへのアクセスを提供するデバイス。また、IEEE 802.1Xまたは拡張認証プロトコル（EAP）の用語、またはRADIUSクライアントで認証サーバとして知られています。

service The NAS provides a service to the user, such as network access via 802.11 or Point to Point Protocol (PPP).

サービスNASは、ポイント・プロトコル（PPP）に802.11またはポイントを介して、ネットワークアクセスなど、ユーザにサービスを提供します。

session Each service provided by the NAS to a peer constitutes a session, with the beginning of the session defined as the point where service is first provided, and the end of the session is defined as the point where service is ended. A peer may have multiple sessions in parallel or series if the NAS supports that, with each session generating a separate start and stop accounting record.

セッションは、ピアにNASによって提供される各サービスは、サービスが最初に提供される点として定義されるセッションの開始で、セッションを構成し、セッションの終了は、サービスが終了した時点として定義されます。ピアは、NASがサポートしている場合、別個のスタートを生成する各セッションに、並列または直列に複数のセッションを有しており、レコードアカウンティング停止してもよいです。

silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.

黙ってこれは実装がさらに処理せずにパケットを破棄する意味捨てます。実装は静かに廃棄されたパケットの内容を含め、エラーをログに記録する機能を提供すべきである、と統計カウンターにイベントを記録する必要があります。

1.2. Requirements Language

1.2. 要件言語

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]に記載されているように解釈されます。

2. Issues

2.問題

2.1. Session Definition

2.1. セッション定義

2.1.1. State Attribute

2.1.1. 状態属性

Regarding the State attribute, [RFC2865] Section 5.24 states:

、[RFC2865]セクション5.24状態は、State属性について：

This Attribute is available to be sent by the server to the client in an Access-Challenge and MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any.

この属性は、アクセスチャレンジでクライアントにサーバによって送信することが可能ですし、もしあれば、その挑戦への新しいアクセス要求の応答でクライアントからサーバにそのまま送らなければなりません。

This Attribute is available to be sent by the server to the client in an Access-Accept that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the NAS performs the Termination-Action by sending a new Access-Request upon termination of the current session, it MUST include the State attribute unchanged in that Access-Request.

この属性は、接続許可もRADIUSリクエストの値と属性終了アクションが含まれていることで、クライアントにサーバによって送信することが可能です。 NASは、現在のセッションの終了時に、新たなアクセス要求を送信することにより終了アクションを実行する場合、それは国家がそのアクセス要求に変わらない属性を含まなければなりません。

Some RADIUS client implementations do not properly use the State attribute in order to distinguish a restarted EAP authentication process from the continuation of an ongoing process (by the same user on the same NAS and port). Where an EAP-Message attribute is included in an Access-Challenge or Access-Accept attribute, RADIUS servers SHOULD also include a State attribute. See Section 2.1.2 on Request ID supplementation for additional benefits to using the State attribute in this fashion.

一部のRADIUSクライアントの実装が適切に（同じNASとポート上の同じユーザによって）進行中のプロセスの続きから再開さEAP認証プロセスを区別するためにState属性を使用しないでください。 EAP-Messageアトリビュートはアクセスチャレンジまたはアクセス - 受け入れ属性に含まれている場合、RADIUSサーバは、状態属性を含めるべきです。このようにState属性を使用して追加の利益のためのリクエストIDの補充のセクション2.1.2を参照してください。

As defined in [RFC2865] Table 5.44, Access-Request packets may contain a State attribute. The table does not qualify this statement, while the text in Section 5.24 (quoted above) adds other requirements not specified in that table.

[RFC2865]表5.44に定義されているように、アクセス要求パケットは、状態属性を含むことができます。セクション5.24（上記引用された）のテキストは、そのテーブルに指定されていない他の要件を追加しながら、表には、この文を修飾しません。

We extend the requirements of [RFC2865] to say that Access-Requests that are part of an ongoing Access-Request / Access-Challenge authentication process SHOULD contain a State attribute. It is the responsibility of the server, to send a State attribute in an Access-Challenge packet, if that server needs a State attribute in a subsequent Access-Request to tie multiple Access-Requests together into one authentication session. As defined in [RFC2865] Section 5.24, the State MUST be sent unmodified from the client to the server in the new Access-Request reply to that challenge, if any.

我々は州属性を含むべきで継続的なアクセス要求/アクセスチャレンジ認証プロセスの一部であるアクセス・リクエストを言うために、[RFC2865]の要件を拡張します。これは、そのサーバがともに1つの認証セッションに複数のアクセス・リクエストを結びつけるために、後続のアクセス要求にState属性を必要とする場合、アクセスチャレンジパケットにState属性を送信するために、サーバーの責任です。 [RFC2865]のセクション5.24で定義されているように、もしあれば、国は、その挑戦への新しいアクセス要求の応答でクライアントからサーバにそのまま送らなければなりません。

While most server implementations require the presence of a State attribute in an Access-Challenge packet, some challenge-response systems can distinguish the initial request from the response to the challenge without using a State attribute to track an authentication session. The Access-Challenge and subsequent Access-Request packets for those systems do not need to contain a State attribute.

ほとんどのサーバ実装はアクセスチャレンジパケット内のState属性の存在を必要としますが、いくつかのチャレンジ・レスポンス・システムは、認証セッションを追跡するために、State属性を使用せずにチャレンジに対する応答から最初の要求を区別することができます。それらのシステムのためのアクセスチャレンジとその後のAccess-Requestパケットは州属性を含む必要はありません。

Other authentication mechanisms need to tie a sequence of Access-Request / Access-Challenge packets together into one ongoing authentication session. Servers implementing those authentication mechanisms SHOULD include a State attribute in Access-Challenge packets.

他の認証メカニズムは、一つの継続的な認証セッション中に一緒にアクセス要求/アクセスチャレンジパケットのシーケンスを結ぶ必要があります。これらの認証メカニズムを実装するサーバーはアクセスチャレンジパケットにおける国家の属性を含めるべきです。

In general, if the authentication process involves one or more Access-Request / Access-Challenge sequences, the State attribute SHOULD be sent by the server in the Access-Challenge packets. Using the State attribute to create a multi-packet session is the simplest method available in RADIUS today. While other methods of creating multi-packet sessions are possible (e.g., [RFC3579] Section 2.6.1), those methods are NOT RECOMMENDED.

認証プロセスは、1つまたは複数のアクセス要求/アクセスチャレンジシーケンスを含む場合、一般的には、State属性はアクセスチャレンジパケットでサーバーによって送信されるべきです。マルチパケットセッションを作成するために、State属性を使用すると、今日RADIUSで利用可能な最も簡単な方法です。マルチパケット・セッションを作成する他の方法（例えば、[RFC3579]セクション2.6.1）が可能であるが、これらの方法は推奨されません。

The only permissible values for a State attribute are values provided in an Access-Accept, Access-Challenge, CoA-Request or Disconnect-Request packet. A RADIUS client MUST use only those values for the State attribute that it has previously received from a server. An Access-Request sent as a result of a new or restarted authentication run MUST NOT include the State attribute, even if a State attribute has previously been received in an Access-Challenge for the same user and port.

State属性のための唯一の許容値は、接続許可、アクセスチャレンジ、アシルCoA-要求または切断し、要求パケットに提供される値です。 RADIUSクライアントは、国家のためにのみ、これらの値は、それ以前に、サーバから受信した属性を使用しなければなりません。新規または再起動し、認証の実行の結果として送信アクセス要求は、State属性は、以前に同じユーザーおよびポートのアクセスチャレンジで受信された場合でも、州属性を含んではいけません。

Access-Request packets that contain a Service-Type attribute with the value Authorize Only (17) MUST contain a State attribute. Access-Request packets that contain a Service-Type attribute with value Call Check (10) SHOULD NOT contain a State attribute. Any other Access-Request packet that performs authorization checks MUST contain a State attribute. This last requirement often means that an Access-Accept needs to contain a State attribute, which can then be used in a later Access-Request that performs authorization checks.

のみ（17）を認可した値でservice-type属性が含まれていたAccess-Requestパケット州属性を含まなければなりません。値コールチェック（10）とのservice-type属性が含まれているアクセス要求パケットは州属性を含めることはできません。認証チェックを実行する任意の他のAccess-Requestパケットは州属性を含まなければなりません。この最後の要件は、多くの場合、アクセス-受け入れニーズが、その後の権限チェックを実行し、後でアクセス要求で使用可能な状態属性を、含まれていることを意味します。

The standard use case for Call Check is pre-screening authentication based solely on the end-point identifier information, such as phone number or Media Access Control (MAC) address in Calling-Station-ID and optionally Called-Station-ID. In this use case, the NAS has no way to obtain a State attribute suitable for inclusion in an Access-Request. Other, non-standard, uses of Call Check may require or permit the use of a State attribute, but are beyond the scope of this document.

コールを確認するための標準的なユースケースは、呼び出し-駅-IDに、このような電話番号またはメディアアクセス制御（MAC）アドレスなどのエンドポイント識別子情報、のみに基づいて事前審査認証と、必要に応じて呼び出され-駅-IDです。このユースケースでは、NASは、国家がアクセス要求に含めるために適切な属性を取得する方法がありません。その他、非標準は、State属性の使用を必要とするか、または許可することができるコールチェックの使用していますが、このドキュメントの範囲を超えています。

In an Access-Request with a Service-Type Attribute with value Call Check, it is NOT RECOMMENDED for the User-Name and User-Password attributes to contain the same values (e.g., a MAC address). Implementing MAC address checking without using a Service-Type of Call Check is NOT RECOMMENDED. This practice gives an attacker both the clear-text and cipher-text of the User-Password field, which permits many attacks on the security of the RADIUS protocol. For example, if the Request Authenticator does not satisfy the [RFC2865] requirements on global and temporal uniqueness, the practice described above may lead to the compromise of the User-Password attribute in other Access-Requests for unrelated users. Access to the cipher-text enables offline dictionary attacks, potentially exposing the shared secret and compromising the entire RADIUS protocol.

値コールチェックとservice-type属性とアクセス要求では、ユーザー名のために推奨されており、ユーザーのパスワードは同じ値（例えば、MACアドレス）を含むように属性をされていません。コールチェックのサービスタイプを使用せずにチェックの実装MACアドレスが推奨されていません。このような行為は、攻撃者にクリアテキストおよびRADIUSプロトコルのセキュリティ上の多くの攻撃を許可するユーザーパスワード]フィールドの暗号文の両方を提供します。要求認証は、グローバル・時間的一意の[RFC2865]の要件を満たしていない場合たとえば、上記の練習は関係のないユーザーのための他のアクセス・リクエストのUser-Password属性の妥協につながる可能性があります。暗号文へのアクセスは、潜在的に共有秘密を暴露し、全体のRADIUSプロトコルを損なう、オフライン辞書攻撃を可能にします。

Any Access-Request packet that performs authorization checks, including Call Check, SHOULD contain a Message-Authenticator attribute. Any response to an Access-Request performing an authorization check MUST NOT contain confidential information about any user (such as Tunnel-Password), unless that Access-Request contains a State attribute. The use of State here permits the authorization check to be tied to an earlier user authentication. In that case, the server MAY respond to the NAS with confidential information about that user. The server MUST NOT respond to that authorization check with confidential information about any other user.

コールチェックを含む認証チェックを実行する任意のAccess-Requestパケットは、Message-Authenticatorアトリビュートを含むべきです。そのアクセス要求がState属性が含まれていない限り、認証チェックを実行するアクセス要求に対する応答は、（例えばトンネルパスワードなど）、任意のユーザーに関する機密情報を含んではなりません。国家の使用は、ここでは、以前のユーザー認証に拘束されることを承認チェックが可能になります。その場合、サーバは、そのユーザに関する機密情報をNASに応答することができます。サーバーは、他のユーザに関する機密情報とその認可チェックに応じてはいけません。

For an Access-Request packet performing an authorization check that does not contain a State attribute, the server MUST respond with an Access-Reject.

州属性が含まれていません承認チェックを実行するアクセス要求パケットの場合、サーバーはアクセス拒否で応じなければなりません。

2.1.2. Request-ID Supplementation

2.1.2. リクエスト-IDサプリメント

[RFC3579] Section 2.6.1 states:

[RFC3579]セクション2.6.1の状態：

In EAP, each session has its own unique Identifier space. RADIUS server implementations MUST be able to distinguish between EAP packets with the same Identifier existing within distinct sessions, originating on the same NAS. For this purpose, sessions can be distinguished based on NAS and session identification attributes. NAS identification attributes include NAS-Identifier, NAS-IPv6-Address and NAS-IPv4-Address. Session identification attributes include User-Name, NAS-Port, NAS-Port-Type, NAS-Port-Id, Called-Station-Id, Calling-Station-Id and Originating-Line-Info.

EAPでは、各セッションは、独自のユニークな識別子スペースがあります。 RADIUSサーバの実装は、同じNAS上の同じ個別のセッション内に存在する識別子、発信元とEAPパケットを区別できなければなりません。この目的のために、セッションは、NASとセッション識別属性に基づいて区別することができます。 NAS識別属性は、NAS-識別子、NAS-のIPv6アドレスとNAS-のIPv4アドレスを含みます。セッション識別属性は、ユーザー名、NASポート、NASポート型、NAS-ポートID、呼び出され-駅-ID、呼び出し-駅-IDと発信ライン情報が含まれます。

There are issues with the suggested algorithm. Since proxies may modify Access-Request attributes such as NAS-IP-Address, depending on any attribute under control of the NAS to distinguish request identifiers can result in deployment problems.

提案されたアルゴリズムに問題があります。アクセス要求は、NAS-IP-アドレスなどの属性プロキシが修正することができますので、リクエスト識別子を区別するためにNASの制御下で、任意の属性に応じて、展開の問題が発生することができます。

The FreeRADIUS implementation does not track EAP identifiers by NAS-IP-Address or other non-EAP attributes sent by the NAS. Instead, it uses the EAP identifier, source Internet Protocol (IP) address, and the State attribute as a "key" to uniquely identify each EAP session. Since the State attribute is under the control of the RADIUS server, the uniqueness of each session is controlled by the server, not the NAS. The algorithm used in FreeRADIUS is as follows:

FreeRADIUSの実装は、NAS-IP-アドレスまたはNASによって送られた他の非EAP属性によってEAP識別子を追跡することはありません。代わりに、それが一意に各EAPセッションを識別するための「鍵」としてEAP識別子、ソースインターネットプロトコル（IP）アドレス、およびState属性を使用しています。州属性がRADIUSサーバの制御下にあるので、各セッションの一意性は、サーバではなく、NASによって制御されます。次のようにFreeRADIUSのに使用されるアルゴリズムは次のとおりです。

if (EAP start, or EAP identity) { allocate unique State Attribute insert session into "active session" table with key=(EAP identifier, State, source IP) } else { look up active session in table, with above key }

IF（EAP開始、またはEAPアイデンティティ）{上記キーと、テーブル内のアクティブなセッションをルックアップ}他{キー=（EAP識別子、状態、ソースIP）を用いて、「アクティブ・セッション」テーブルにセッションを挿入する属性一意状態を割り当てます}

This algorithm appears to work well in a variety of situations, including situations where home servers receive messages via intermediate RADIUS proxies.

このアルゴリズムは、ホームサーバーは、中間RADIUSプロキシを経由してメッセージを受信状況など、さまざまな状況でうまく動作するように表示されます。

Implementations that do not use this algorithm are often restricted to having an EAP Identifier space per NAS, or perhaps one that is global to the implementation. These restrictions are unnecessary when the above algorithm is used, which gives each session a unique EAP Identifier space. The above algorithm SHOULD be used to track EAP sessions in preference to any other method.

このアルゴリズムを使用していない実装は、多くの場合、NASあたりEAP識別子空間を有する、または多分実装に対してグローバルなものに制限されています。上記のアルゴリズムを使用する場合、これらの制限は、各セッションに固有のEAP識別子空間を与える、不要です。上記のアルゴリズムは、任意の他の方法に優先してEAPセッションを追跡するために使用されるべきです。

2.2. Overload Conditions

2.2. 過負荷状態

2.2.1. Retransmission Behavior

2.2.1. 再送挙動

[RFC2865] Section 2.4 describes the retransmission requirements for RADIUS clients:

[RFC2865]セクション2.4は、RADIUSクライアントの再送信の要件について説明します。

At one extreme, RADIUS does not require a "responsive" detection of lost data. The user is willing to wait several seconds for the authentication to complete. The generally aggressive Transmission Control Protocol (TCP) retransmission (based on average round trip time) is not required, nor is the acknowledgment overhead of TCP.

一方の極端では、RADIUSは、失われたデータの「応答」の検出を必要としません。ユーザーが完了するまでに、認証のために数秒待って喜んでいます。（平均ラウンドトリップ時間に基づいて）一般的に、積極的な伝送制御プロトコル（TCP）再送信が必要、またTCPの確認応答のオーバーヘッドであるされていません。

At the other extreme, the user is not willing to wait several minutes for authentication. Therefore the reliable delivery of TCP data two minutes later is not useful. The faster use of an alternate server allows the user to gain access before giving up.

他の極端では、ユーザーは認証のために、数分待つことを望んでいません。したがって、TCPデータの信頼性の高い配信は、2分後には有用ではありません。代替サーバの速い使用は、ユーザがあきらめる前に、アクセス権を取得することができます。

Some existing RADIUS clients implement excessively aggressive retransmission behavior, utilizing default retransmission timeouts of one second or less without support for congestive backoff. When deployed at a large scale, these implementations are susceptible to congestive collapse. For example, as the result of a power failure, a network with 3,000 NAS devices with a fixed retransmission timer of one second will continuously generate 3,000 RADIUS Access-Requests per second. This is sufficient to overwhelm most RADIUS servers.

いくつかの既存のRADIUSクライアントは、うっ血性バックオフのサポートなしで1秒以下のデフォルトの再送信タイムアウトを利用して、過度に攻撃的な再送動作を実装します。大規模に展開する場合、これらの実装は、うっ血性崩壊の影響を受けやすいです。例えば、電源障害の結果として、一つの第二の固定再送タイマーと3,000 NASデバイスとネットワークが連続的に、毎秒3,000 RADIUSアクセス - 要求を生成します。これは、ほとんどのRADIUSサーバを圧倒するのに十分です。

2.2.2. Duplicate Detection and Orderly Delivery

2.2.2. 重複検出と秩序配達

When packets are retransmitted by a client, the server may receive duplicate requests. The limitations of the transport protocol used by RADIUS, the User Datagram Protocol (UDP), means that the Access-Request packets may be received, and potentially processed, in an order different from the order in which the packets were sent. However, the discussion of the Identifier field in Section 3 of [RFC2865] says:

パケットがクライアントによって再送信されると、サーバーは、重複した要求を受信することができます。 RADIUSによって使用されるトランスポートプロトコル、ユーザデータグラムプロトコル（UDP）の制限は、パケットが送信された順序とは異なる順序で、アクセス要求パケットが受信され、潜在的に処理されてもよいことを意味します。ただし、[RFC2865]のセクション3の識別子フィールドの議論は言います：

The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time.

それは時間の短いスパン内の同じクライアントの送信元IPアドレスと送信元UDPポートと識別子を持っている場合、RADIUSサーバは、重複要求を検出することができます。

Also, Section 7 of [RFC4669] defines a radiusAuthServDupAccessRequests object as:

また、[RFC4669]のセクション7はradiusAuthServDupAccessRequestsとしてオブジェクトを定義します。

The number of duplicate Access-Request packets received.

重複したアクセス要求パケットの受信数。

This text has a number of implications. First, without duplicate detection, a RADIUS server may process an authentication request twice, leading to an erroneous conclusion that a user has logged in twice. That behavior is undesirable, so duplicate detection is desirable. Second, the server may track not only the duplicate request, but also the replies to those requests. This behavior permits the server to send duplicate replies in response to duplicate requests, increasing network stability.

このテキストは意味合いの数を持っています。まず、重複検出せずに、RADIUSサーバは、ユーザが二回ログインした誤った結論に導く、二回の認証要求を処理することができます。その振る舞いは望ましくないので、重複検出が望ましいです。第二に、サーバは重複要求するだけでなく、これらの要求への応答だけでなく、を追跡することができます。この動作は、ネットワークの安定性を高め、要求を複製するために応答して、重複応答を送信するサーバーを許可します。

Since Access-Request packets may also be sent by the client in response to an Access-Challenge from the server, those packets form a logically ordered stream, and, therefore have additional ordering requirements over Access-Request packets for different sessions. Implementing duplicate detection results in new packets being processed only once, ensuring order.

アクセス要求パケットは、サーバからのアクセスチャレンジに応じて、クライアントから送信されたことがあるので、これらのパケットは、論理的に注文した流れを形成し、したがって、異なるセッションのためのAccess-Requestパケットを超える追加の発注要件があります。、一度だけ処理されている新たなパケット内の重複検出結果の実装順序を保証します。

RADIUS servers MUST therefore implement duplicate detection for Access-Request packets, as described in Section 3 of [RFC2865]. Implementations MUST also cache the Responses (Access-Accept, Access-Challenge, or Access-Reject) that they send in response to Access-Request packets. If a server receives a valid duplicate Access-Request for which it has already sent a Response, it MUST resend its original Response without reprocessing the request. The server MUST silently discard any duplicate Access-Requests for which a Response has not yet been sent.

[RFC2865]のセクション3に記載されているようにRADIUSサーバは、従って、アクセス要求パケットの重複検出を実装しなければなりません。また、実装は、彼らがアクセス要求パケットに応じて送信すること（、アクセス-受け入れアクセスチャレンジ、またはアクセス拒否）応答をキャッシュしなければなりません。サーバがすでにレスポンスを送信しているため、有効な重複したアクセス要求を受信した場合、その要求を再処理せずに、元のレスポンスを送信しなおさなければなりません。サーバは黙って応答がまだ送信されていない任意の重複したアクセス・リクエストを捨てなければなりません。

Each cache entry SHOULD be purged after a period of time. This time SHOULD be no less than 5 seconds, and no more than 30 seconds. After about 30 seconds, most RADIUS clients and end users will have given up on the authentication request. Therefore, there is little value in having a larger cache timeout.

各キャッシュエントリは、一定期間後にパージされるべきです。この時間はありません5秒未満、およびより多くない30秒であるべきです。約30秒後、ほとんどのRADIUSクライアントとエンドユーザーは、認証要求をあきらめています。そのため、より大きなキャッシュのタイムアウトを持つにはほとんど価値があります。

Cache entries MUST also be purged if the server receives a valid Access-Request packet that matches a cached Access-Request packet in source address, source port, RADIUS Identifier, and receiving socket, but where the Request Authenticator field is different from the one in the cached packet. If the request contains a Message-Authenticator attribute, the request MUST be processed as described in [RFC3580] Section 3.2. Packets with invalid Message-Authenticators MUST NOT affect the cache in any way.

サーバーは、送信元アドレス、送信元ポート、RADIUS識別子、およびソケットの受信にキャッシュされたAccess-Requestパケットに一致する有効なアクセス要求パケットを受信した場合、キャッシュエントリもパージする必要がありますが、要求認証フィールドは、1つの異なる場所キャッシュされたパケット。要求はメッセージ認証属性が含まれている場合は、[RFC3580]セクション3.2で説明したように、要求が処理されなければなりません。無効なメッセージオーセンティケータを持つパケットは、どのような方法でキャッシュに影響してはいけません。

However, Access-Request packets not containing a Message-Authenticator attribute always affect the cache, even though they may be trivially forged. To avoid this issue, server implementations may be configured to require the presence of a Message-Authenticator attribute in Access-Request packets. Requests not containing a Message-Authenticator attribute MAY then be silently discarded.

ただし、Message-Authenticatorアトリビュートを含まないアクセス要求パケットは、常に彼らは自明偽造することができるにもかかわらず、キャッシュに影響を与えます。この問題を回避するには、サーバの実装は、Access-RequestパケットでMessage-Authenticatorアトリビュートの存在を必要とするように構成することができます。 Message-Authenticatorアトリビュートを含まない要求は、その後黙って破棄されることがあります。

Client implementations SHOULD include a Message-Authenticator attribute in every Access-Request to further help mitigate this issue.

クライアントの実装では、この問題をさらに軽減するために、すべてのアクセス要求でMessage-Authenticatorアトリビュートを含むべきです。

When sending requests, RADIUS clients MUST NOT reuse Identifiers for a source IP address and source UDP port until either a valid response has been received, or the request has timed out. Clients SHOULD allocate Identifiers via a least-recently-used (LRU) method for a particular source IP address and source UDP port.

リクエストを送信するときのいずれかの有効な応答が受信された、または要求がタイムアウトするまで、RADIUSクライアントが送信元IPアドレスと送信元UDPポートの識別子を再利用してはいけません。クライアントは、特定の送信元IPアドレスと送信元UDPポートの最低使用頻度（LRU）メソッドを介して識別子を割り当てるべきです。

RADIUS clients do not have to perform duplicate detection. When a client sends a request, it processes the first response that has a valid Response Authenticator as defined in [RFC2865] Section 3. Any later responses MUST be silently discarded, as they do not match a pending request. That is, later responses are treated exactly the same as unsolicited responses, and are silently discarded.

RADIUSクライアントは、重複検出を実行する必要はありません。クライアントが要求を送信すると、それは彼らが保留中の要求と一致しないと、それ以降の応答は黙って、捨てなければなりません[RFC2865]セクション3で定義されている有効なレスポンス認証を持っている最初の応答を処理します。これは、後に応答が正確に迷惑応答と同じように扱われている、と静かに破棄されます。

2.2.3. Server Response to Overload

2.2.3. 過負荷に対するサーバの応答

Some RADIUS server implementations are not robust in response to overload, dropping packets with even probability across multiple sessions. In an overload situation, this results in a high failure rate for multi-round authentication protocols such as EAP [RFC3579]. Typically, users will continually retry in an attempt to gain access, increasing the load even further.

一部のRADIUSサーバの実装は、複数のセッション間で均等確率でパケットをドロップし、過負荷に応じて、堅牢ではありません。過負荷状況においては、これは、EAP [RFC3579]のようなマルチラウンド認証プロトコルの高い故障率をもたらします。一般的に、ユーザーが継続的にさらに負荷が増加、アクセスを得るための試みに再試行されます。

A more sensible approach is for a RADIUS server to preferentially accept RADIUS Access-Request packets containing a valid State attribute, so that multi-round authentication conversations, once begun, will be more likely to succeed. Similarly, a server that is proxying requests should preferentially process Access-Accept, Access-Challenge, or Access-Reject packets from home servers before processing new requests from a NAS.

マルチラウンド認証会話、一度始まっは、成功する可能性が高くなるように、より賢明なアプローチは、優先的に有効な状態属性を含むRADIUSアクセス要求パケットを受け入れるようにRADIUSサーバ用です。同様に、リクエストをプロキシされたサーバは、優先的にアクセス-受け入れ、アクセスチャレンジを処理しなければならない、またはNASから新しい要求を処理する前に、ホームサーバーからのパケットをアクセス拒否します。

These methods will allow some users to gain access to the network, reducing the load created by ongoing access attempts.

これらのメソッドは、一部のユーザーが継続的なアクセスの試みによって作成された負荷を軽減、ネットワークへのアクセスを得ることができます。

2.3. Accounting Issues

2.3. 会計問題

2.3.1. Attributes Allowed in an Interim Update

2.3.1. 中間更新プログラムで許可された属性

[RFC2866] indicates that Acct-Input-Octets, Acct-Output-Octets, Acct-Session-Time, Acct-Input-Packets, Acct-Output-Packets and Acct-Terminate-Cause attributes "can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop".

[RFC2866]はそのアカウンティング・インプット・オクテット、ACCT-出力-オクテット、アカウンティング・セッション時間、アカウンティング・インプット・パケット、アカウンティング・出力・パケットを示しているとのAcct-終了 - 原因は「唯一のアカウンティング要求に存在することができる属性アカウンティング・ステータス-TypeがStopに設定されたレコード」。

However [RFC2869] Section 2.1 states:

しかし、[RFC2869]セクション2.1の状態：

It is envisioned that an Interim Accounting record (with Acct-Status-Type = Interim-Update (3)) would contain all of the attributes normally found in an Accounting Stop message with the exception of the Acct-Term-Cause attribute.

（ACCT-ステータス・タイプ=暫定-アップデート（3）との）中間会計記録は、通常のAcct-ターム - 原因属性を除いて、アカウンティング停止メッセージで見つかったすべての属性を含んであろうと想定されます。

Although [RFC2869] does not indicate that it updates [RFC2866], this is an oversight, and the above attributes are allowable in an Interim Accounting record.

[RFC2869]は、それは[RFC2866]を更新していることを示すものではありませんが、これは監督であり、上記の属性は、中間アカウンティングレコードで許容されています。

2.3.2. Acct-Session-Id and Acct-Multi-Session-Id

2.3.2. アカウンティング・セッションIdとのAcct-Multi-Session-Id

[RFC2866] Section 5.5 describes Acct-Session-Id as Text within the figure summarizing the attribute format, but then goes on to state that "The String field SHOULD be a string of UTF-8 encoded 10646 characters".

[RFC2866]セクション5.5は、属性の形式をまとめた図内のテキストとしてアカウンティング・セッションIdを説明したが、その後という状態に進み、「StringフィールドはUTF-8の文字列でなければならないが10646個の文字をエンコード」。

[RFC2865] defines the Text type as "containing UTF-8 encoded 10646 characters", which is compatible with the description of Acct-Session-Id. Since other attributes are consistently described as "Text" within both the figure summarizing the attribute format, and the following attribute definition, it appears that this is a typographical error, and that Acct-Session-Id is of type Text, and not of type String.

[RFC2865]はアカウンティング・セッションIdの記述と互換性があり、「UTF-8は10646の文字エンコード含む」などのテキストタイプを定義します。他の属性が一貫フィギュア、属性の形式を要約し、次の属性定義の両方の中に「テキスト」として記載されているので、誤植であると表示され、アカウンティング・セッションIdは、Text型であること、そしてないタイプの文字列。

The definition of the Acct-Multi-Session-Id attribute also has typographical errors. It says:

Acct-Multi-Session-Id属性の定義には、誤植があります。それは言います：

A summary of the Acct-Session-Id attribute format ...

アカウンティング・セッションId属性のフォーマットの概要...

This text should read:

このテキストは、次のようになります。

A summary of the Acct-Multi-Session-Id attribute format ...

Acct-Multi-Session-Id属性のフォーマットの概要...

The Acct-Multi-Session-Id attribute is also defined as being of type String. However, the language in the text strongly recommends that implementors consider the attribute as being of type Text. It is unclear why the type String was chosen for this attribute when the type Text would be sufficient. This attribute SHOULD be treated as Text.

Acct-Multi-Session-Id属性もString型であると定義されています。ただし、テキスト内の言語が強く実装者がタイプテキストであるとして属性を検討することをお勧めします。 String型の型テキストは十分であろう、この属性のために選択した理由は不明です。この属性は、テキストとして扱われるべきです。

2.3.3. Request Authenticator

2.3.3. 要求認証

[RFC2866] Section 4.1 states:

[RFC2866]セクション4.1の状態：

The Request Authenticator of an Accounting-Request contains a 16- octet MD5 hash value calculated according to the method described in "Request Authenticator" above.

アカウンティング要求の要求認証は、上記の「要求認証」に記載の方法に従って計算さ16オクテットMD5ハッシュ値を含みます。

However, the text does not indicate any action to take when an Accounting-Request packet contains an invalid Request Authenticator. The following text should be considered to be part of the above description:

ただし、テキストは、アカウンティング要求パケットは無効な要求認証が含まれている場合に行う任意のアクションを示すものではありません。次のテキストは、上記の説明の一部であることを考慮する必要があります。

The Request Authenticator field MUST contain the correct data, as given by the above calculation. Invalid packets are silently discarded. Note that some early implementations always set the Request Authenticator to all zeros. New implementations of RADIUS clients MUST use the above algorithm to calculate the Request Authenticator field. New RADIUS server implementations MUST silently discard invalid packets.

上記計算によって与えられる要求認証フィールドは、正しいデータを含まなければなりません。不正なパケットは黙って破棄されます。いくつかの初期の実装は、常にすべてゼロに要求認証を設定することに注意してください。 RADIUSクライアントの新しい実装が要求認証フィールドを計算するために、上記のアルゴリズムを使用する必要があります。新しいRADIUSサーバの実装は静かに不正なパケットを捨てなければなりません。

2.3.4. Interim-Accounting-Interval

2.3.4. 暫定-アカウンティング間隔

[RFC2869] Section 2.1 states:

[RFC2869]セクション2.1の状態：

It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept.

静的にNAS自体の中間値を設定することも可能です。 NAS上にローカルに設定された値は、受け入れアクセスに見出される値を上書きしなければならないことに留意されたいです。

This requirement may be phrased too strongly. It is conceivable that a NAS implementation has a setting for a "minimum" value of Interim-Accounting-Interval, based on resource constraints in the NAS, and network loading in the local environment of the NAS. In such cases, the value administratively provisioned in the NAS should not be over-ridden by a smaller value from an Access-Accept message. The NAS's value could be over-ridden by a larger one, however. The intent is that the NAS sends accounting information at fixed intervals that are short enough so that the potential loss of billable revenue is limited, but also that the accounting updates are infrequent enough so that the NAS, network, and RADIUS server are not overloaded.

この要件は、あまりにも強く言うこともあります。 NASの実装は、NASのローカル環境でのNAS内のリソースの制約に基づいて暫定-アカウンティング間隔、の「最小」値、およびネットワークの負荷の設定を持っていることが考えられます。このような場合、管理NASにプロビジョニングされた値は、Access-Acceptメッセージから小さい方の値によってオーバー乗ってはなりません。 NASの値は、しかし、大きな1で上に苦しむ可能性があります。その意図は、NASは、請求可能な収入の潜在的な損失が制限されるように十分に短い一定間隔でアカウンティング情報を送信していることが、また、会計の更新がNAS、ネットワーク、およびRADIUSサーバが過負荷にならないように十分にまれであるということです。

2.3.5. Counter Values in the RADIUS Management Information Base (MIB)

2.3.5. RADIUS管理情報ベース（MIB）でカウンタ値

The RADIUS Authentication and Authorization Client MIB module ([RFC2618] [RFC4668]) includes counters of packet statistics. In the descriptive text of the MIB module, formulas are provided for certain counter objects. Implementors have noted apparent inconsistencies in the formulas that could result in negative values.

RADIUS認証および許可クライアントMIBモジュール（[RFC2618]、[RFC4668]）は、パケット統計のカウンタを含みます。 MIBモジュールの説明文では、式は、特定のカウンタオブジェクトのために提供されます。実装者は、負の値につながる可能性の式で明らかに矛盾を指摘しています。

Since the original MIB module specified in [RFC2618] had been widely implemented, the RADEXT WG chose not to change the object definitions or to create new ones within the revised MIB module [RFC4668]. However, this section explains the issues and provides guidance for implementors regarding the interpretation of the textual description and comments for certain MIB objects.

[RFC2618]で指定された元のMIBモジュールは広く実装されていたので、RADEXT WGは、オブジェクト定義を変更したり、修正されたMIBモジュール[RFC4668]の中に新しいものを作成しないことを選択しました。ただし、このセクションでは、問題を説明し、特定のMIBオブジェクトのためのテキスト記述およびコメントの解釈に関する実装するためのガイダンスを提供します。

The issues raised can be summarized as follows:

次のように提起された問題を要約することができます。

Issue (1):

特集（1）：

-- TotalIncomingPackets = Accepts + Rejects + Challenges + UnknownTypes -- -- TotalIncomingPackets - MalformedResponses - BadAuthenticators - -- UnknownTypes - PacketsDropped = Successfully received -- -- AccessRequests + PendingRequests + ClientTimeouts = -- Successfully Received

- TotalIncomingPackets =受け入れ+リジェクツ+課題+ UnknownTypes - - TotalIncomingPackets - MalformedResponses - BadAuthenticators - - UnknownTypes - PacketsDropped =正常に受信 - - AccessRequests + PendingRequests + ClientTimeouts = - 正常に受信

It appears that the value of "Successfully Received" could be negative, since various counters are subtracted from TotalIncomingPackets that are not included in the calculation of TotalIncomingPackets.

さまざまなカウンタがTotalIncomingPacketsの計算に含まれていませんTotalIncomingPacketsから減算されるので、「正常に受信さ」の値は、負になることができると思われます。

It also appears that "AccessRequests + PendingRequests + ClientTimeouts = Successfully Received" should read "AccessRequests + PendingRequests + ClientTimeouts = Successfully Transmitted".

また、 "AccessRequests + PendingRequests + ClientTimeouts =正常に送信され、" 読んでください "AccessRequests + PendingRequests + ClientTimeouts =正常に受信" と思われます。

"TotalIncomingPackets" and "Successfully Received" are temporary variables, i.e., not objects within the MIB module. The comment text in the MIB modules is intended, therefore, to aid in understanding. What's of consequence is the consistency of values of the objects in the MIB module, and that does not appear to be impacted by the inconsistencies noted above. It does appear, however, that the "Successfully Received" variable should be labeled "Successfully Transmitted".

「正常に受信」「TotalIncomingPackets」とは、MIBモジュール内の一時的な変数、すなわち、ではないオブジェクトです。 MIBモジュールでコメントテキストは、それゆえ、理解を助けるために、意図されます。何の結果ののはMIBモジュール内のオブジェクトの値の一貫性であり、それは、上記の不整合によって影響されるように表示されません。しかし、「受信に成功した」変数がラベル付けされなければならないことを「正常に送信」が表示されません。

In addition, the definition of Accept, Reject or Challenge counters indicates that they MUST be incremented before the message is validated. If the message is invalid, one of MalformedResponses, BadAuthenticators, or PacketsDropped counters will be additionally incremented. In that case, the first two equations are consistent, i.e., "Successfully Received" could not be negative.

また、受け入れ拒否または挑戦のカウンターの定義は、メッセージが検証される前に、彼らが増加しなければなりませんことを示しています。メッセージが無効な場合、MalformedResponses、BadAuthenticators、またはPacketsDroppedカウンタの1つは、さらにインクリメントされます。その場合には、最初の2つの式が一致している、すなわち、「正常に受信」負であることができませんでした。

Issue (2):

問題（2）：

It appears that the radiusAuthClientPendingRequests counter is decremented upon retransmission. That would mean a retransmitted packet is not considered as being pending, although such retransmissions can still be considered as being pending requests.

radiusAuthClientPendingRequestsカウンタが再送時にデクリメントされることが表示されます。すなわち、このような再送がまだ保留中の要求であると考えることができるが、再送パケットが、保留中であると考えていません意味します。

The definition of this MIB object in [RFC2618] is as follows:

次のように[RFC2618]でこのMIBオブジェクトの定義は次のとおりです。

The number of RADIUS Access-Request packets destined for this server that have not yet timed out or received a response. This variable is incremented when an Access-Request is sent and decremented due to receipt of an Access-Accept, Access-Reject or Access-Challenge, a timeout or retransmission.

まだタイムアウトまたは応答を受け取っていない、このサーバ宛てのRADIUSアクセス要求パケットの数。アクセス要求が原因のアクセス拒否またはアクセスチャレンジ、タイムアウトまたは再送信、-受け入れアクセスの受領に送信し、デクリメントされたときに、この変数がインクリメントされます。

This object purports to count the number of pending request packets. It is open to interpretation whether or not retransmissions of a request are to be counted as additional pending packets. In either event, it seems appropriate to treat retransmissions consistently with respect to incrementing and decrementing this counter.

このオブジェクトは、保留中の要求パケットの数をカウントすることを目的としています。要求の再送信が追加保留中のパケットとしてカウントするかどうかの解釈に開かれています。いずれにしても、このカウンタをインクリメントし、デクリメントに関して一貫して再送信を処理するために適切であるように思われます。

2.4. Multiple Filter-ID Attributes

2.4. 複数のフィルター-ID属性

[RFC2865] Section 5.11 states:

[RFC2865]セクション5.11状態：

Zero or more Filter-Id attributes MAY be sent in an Access-Accept packet.

ゼロ以上のフィルター-ID属性は、接続許可パケットで送信することができます。

In practice, the behavior of a RADIUS client receiving multiple Filter-ID attributes is implementation dependent. For example, some implementations treat multiple instances of the Filter-ID attribute as alternative filters; the first Filter-ID attribute having a name matching a locally defined filter is used, and the remaining ones are discarded. Other implementations may combine matching filters.

実際には、複数のフィルター-ID属性を受け取るRADIUSクライアントの動作は実装依存です。例えば、いくつかの実装では別のフィルタなどのフィルタの-ID属性の複数のインスタンスを扱います。ローカルに定義されたフィルタに一致する名前を有する第一のフィルタ-ID属性が使用され、残りのものは廃棄されます。他の実装は、整合フィルタを組み合わせることができます。

As a result, the interpretation of multiple Filter-ID attributes is undefined within RADIUS. The sending of multiple Filter-ID attributes within an Access-Accept SHOULD be avoided within heterogeneous deployments and roaming scenarios, where it is likely to produce unpredictable results.

その結果、複数のフィルタ-ID属性の解釈は、半径内に定義されていません。予期しない結果をもたらす可能性がある場合、複数のフィルター-IDは、受け入れアクセス内の属性の送信は、異種の展開とローミングのシナリオの中に避けるべきです。

2.5. Mandatory and Optional Attributes

2.5. 必須およびオプション属性

RADIUS attributes do not explicitly state whether they are optional or mandatory. Nevertheless, there are instances where RADIUS attributes need to be treated as mandatory.

RADIUS属性は、明示的に、彼らがオプションか必須であるかどうかを述べるません。それにもかかわらず、RADIUS属性が必須として処理する必要がある場合があります。

[RFC2865] Section 1.1 states:

[RFC2865]セクション1.1の状態：

A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer Apple Remote Access Protocol (ARAP) service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-accept authorizing an unavailable service as an access-reject instead.

指定されたサービスを実装していないNASは、そのサービスのRADIUS属性を実装してはなりません。たとえば、RADIUSを実装してはならないのAppleリモートアクセスプロトコル（ARAP）サービスを提供することができないNASがARAPの属性。 NASは、RADIUSの代わりに、拒否アクセスとして利用できないサービスを許可するアクセスは、受け入れ扱わなければなりません。

With respect to the Service-Type attribute, [RFC2865] Section 5.6 says:

service-type属性に関しては、[RFC2865]セクション5.6は述べています：

This Attribute indicates the type of service the user has requested, or the type of service to be provided. It MAY be used in both Access-Request and Access-Accept packets. A NAS is not required to implement all of these service types, and MUST treat unknown or unsupported Service-Types as though an Access-Reject had been received instead.

この属性は、ユーザーが要求したサービスの種類を示し、またはサービスの種類が提供されます。これは、アクセス要求とアクセス - 受け入れパケットの両方で使用されるかもしれません。 NASは、これらのサービスタイプのすべてを実現するために必要とされていない、と拒否アクセスが代わりに受信されたかのように、未知またはサポートされていないサービス・タイプを扱わなければなりません。

[RFC2865] Section 5 states:

[RFC2865]第5節の状態：

A RADIUS server MAY ignore Attributes with an unknown Type.

RADIUSサーバは、未知のタイプと属性を無視するかもしれません。

A RADIUS client MAY ignore Attributes with an unknown Type.

RADIUSクライアントは、未知のタイプと属性を無視するかもしれません。

With respect to Vendor-Specific Attributes (VSAs), [RFC2865] Section 5.26 states:

ベンダー固有の属性（VSAの）、[RFC2865]セクション5.26状態に関して：

Servers not equipped to interpret the vendor-specific information sent by a client MUST ignore it (although it may be reported). Clients which do not receive desired vendor-specific information SHOULD make an attempt to operate without it, although they may do so (and report they are doing so) in a degraded mode.

（それは報告されてもよいが）クライアントから送信されたベンダー固有の情報を解釈するために装備されていないサーバはそれを無視しなければなりません。希望ベンダー固有の情報を受信していないクライアントは、彼らがそうする（と彼らがそうしているレポート）かもしれないが劣化モードで、それなしで動作を試みます。

It is possible for either a standard attribute or a VSA to represent a request for an unavailable service. However, where the Type, Vendor-ID, or Vendor-Type is unknown, a RADIUS client will not know whether or not the attribute defines a service.

標準属性またはVSAのいずれかが利用できないサービスの要求を表現することが可能です。タイプ、ベンダーID、またはベンダータイプが不明ですが、RADIUSクライアントは、属性がサービスを定義するかどうかを知ることができません。

In general, it is best for a RADIUS client to err on the side of caution. On receiving an Access-Accept including an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject, as directed in [RFC2865] Section 1.1. On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition, and treat it as an Access-Reject. Unknown VSAs SHOULD be ignored by RADIUS clients.

一般的に、それは慎重を期して行われるようにRADIUSクライアントに最適です。 [RFC2865]セクション1.1に指示されるように実装されていないサービスのための既知のタイプの属性を含めて、接続許可を受信すると、RADIUSクライアントは、アクセス拒否としてそれを扱わなければなりません。未知の種類の属性を含めて、接続許可を受信すると、RADIUSクライアントは、それが潜在的なサービス定義であると仮定すべきである、と拒否アクセスとして扱います。未知のVSAは、RADIUSクライアントによって無視されるべきです。

In order to avoid introducing changes in default behavior, existing implementations that do not obey this recommendation should make the behavior configurable, with the legacy behavior being enabled by default. A configuration flag such as "treat unknown attributes as reject" can be exposed to the system administrator. If the flag is set to true, then Access-Accepts containing unknown attributes are treated as Access-Rejects. If the flag is set to false, then unknown attributes in Access-Accepts are silently ignored.

デフォルトの動作の変更を回避するため、この勧告に従わない既存の実装は、従来の動作がデフォルトで有効にされた状態で、動作が設定可能にする必要があります。「拒否として、未知の属性を扱う」などの設定フラグは、システム管理者に露出させることができます。フラグがtrueに設定されている場合は、未知の属性を含むアクセスは、受け入れのAccess-リジェクツとして扱われます。フラグがfalseに設定されている場合、受け入れてAccessで未知の属性は黙って無視されます。

On receiving a packet including an attribute of unknown Type, RADIUS authentication server implementations SHOULD ignore such attributes. However, RADIUS accounting server implementations typically do not need to understand attributes in order to write them to stable storage or pass them to the billing engine. Therefore, accounting server implementations SHOULD be equipped to handle unknown attributes.

未知の種類の属性を含むパケットを受信すると、RADIUS認証サーバの実装は、このような属性を無視すべきです。しかし、RADIUSアカウンティングサーバの実装は、一般的に安定したストレージに書き込むか、課金エンジンにそれらを渡すために属性を理解する必要はありません。したがって、会計サーバの実装は、未知の属性を処理するために装備する必要があります。

To avoid misinterpretation of service requests encoded within VSAs, RADIUS servers SHOULD NOT send VSAs containing service requests to RADIUS clients that are not known to understand them. For example, a RADIUS server should not send a VSA encoding a filter without knowledge that the RADIUS client supports the VSA.

VSAの中にエンコードされたサービス要求の誤解を避けるために、RADIUSサーバは、それらを理解することが知られていないRADIUSクライアントへのサービス要求を含むVSAを送るべきではありません。たとえば、RADIUSサーバは、RADIUSクライアントはVSAをサポートしていることを知ることなくフィルタをコードするVSAを送るべきではありません。

2.6. Interpretation of Access-Reject

2.6. アクセス拒否の解釈

2.6.1. Improper Use of Access-Reject

2.6.1. アクセス拒否の不適切な使用

The intent of an Access-Reject is to deny access to the requested service. [RFC2865] Section 2 states:

拒否アクセスの意図は、要求されたサービスへのアクセスを拒否することです。 [RFC2865]第2節の状態：

If any condition is not met, the RADIUS server sends an "Access-Reject" response indicating that this user request is invalid. If desired, the server MAY include a text message in the Access-Reject which MAY be displayed by the client to the user. No other Attributes (except Proxy-State) are permitted in an Access-Reject.

いずれかの条件が満たされない場合、RADIUSサーバは、このユーザの要求が無効であることを示す「アクセス拒否」の応答を送信します。必要に応じて、サーバーは、ユーザーにクライアントで表示されるかもしれないアクセス拒否にテキストメッセージを含んでいてもよいです。（プロキシ・ステートを除く）他の属性は、拒否アクセスで許可されていません。

This text makes it clear that RADIUS does not allow the provisioning of services within an Access-Reject. If the desire is to allow limited access, then an Access-Accept can be sent with attributes provisioning limited access. Attributes within an Access-Reject are restricted to those necessary to route the message (e.g., Proxy-State), attributes providing the user with an indication that access has been denied (e.g., an EAP-Message attribute containing an EAP-Failure), or attributes conveying an error message (e.g., a Reply-Message or Error-Cause attribute).

このテキストは、RADIUSはアクセス拒否内のサービスのプロビジョニングを許可していないことが明確にあることになります。欲求が制限されたアクセスを許可する場合は、[アクセス-受け入れ制限されたアクセス権をプロビジョニング属性を使用して送信することができます。拒否Access内の属性は、メッセージが（例えば、プロキシ・ステート）ルーティングするために必要なものに限定されている、（例えば、EAP-失敗を含むEAP-Messageアトリビュートを）拒否されているアクセスする表示をユーザに提供する属性または、エラーメッセージ（例えば、返信メッセージやエラー - 原因属性）を運搬する属性。

Unfortunately, there are examples where this requirement has been misunderstood. [RFC2869] Section 2.2 states:

残念ながら、この要件は誤解されている例があります。 [RFC2869]セクション2.2の状態：

If that authentication fails, the RADIUS server should return an Access-Reject packet to the NAS, with optional Password-Retry and Reply-Messages attributes. The presence of Password-Retry indicates the ARAP NAS MAY choose to initiate another challenge-response cycle...

認証が失敗した場合、RADIUSサーバは、オプションのパスワード再試行して、NASへのアクセス拒否パケットを返し、属性、メッセージ返信すべきです。パスワードの再試行の存在は、ARAP NASは別のチャレンジ・レスポンスサイクルを開始することを選択する可能性があることを示し...

This paragraph is problematic from two perspectives. Firstly, a Password-Retry attribute is being returned in an Access-Reject; this attribute does not fit into the categories established in [RFC2865]. Secondly, an Access-Reject packet is being sent in the context of a continuing authentication conversation; [RFC2865] requires use of an Access-Challenge for this. [RFC2869] uses the phrase "challenge-response" to describe this use of Access-Reject, indicating that the semantics of Access-Challenge are being used.

この段落は、2つの観点から問題があります。まず、パスワード再試行の属性が戻されているアクセス拒否。この属性は、[RFC2865]で設立のカテゴリに収まりません。第二に、アクセス拒否パケットは、継続認証会話のコンテキストで送信されています。 [RFC2865]はこのためのアクセスチャレンジの使用を必要とします。 [RFC2869]はアクセスチャレンジのセマンティクスが使用されていることを示す、アクセス拒否のこの使用を説明するために用語「チャレンジ・レスポンス」を使用します。

[RFC2865] Section 4.4 addresses the semantics of Access-Challenge being equivalent to Access-Reject in some cases:

[RFC2865]セクション4.4アドレスアクセスチャレンジのセマンティクスは、場合によっては、アクセス拒否と等価です。

If the NAS does not support challenge/response, it MUST treat an Access-Challenge as though it had received an Access-Reject instead.

NASがチャレンジ/レスポンスをサポートしていない場合は、アクセス拒否を代わりに受け取ったかのように、それはアクセスチャレンジを扱わなければなりません。

While it is difficult to correct existing deployments of [RFC2869], we make the following recommendations:

それは[RFC2869]の既存の展開を補正することは困難であるが、我々は以下の提言を行います。

[1] New RADIUS specifications and implementations MUST NOT use Access-Reject where the semantics of Access-Challenge are intended.

[1]新しいRADIUSの仕様と実装がアクセス拒否アクセスチャレンジの意味が意図されている場所を使用してはなりません。

[2] Access-Reject MUST mean denial of access to the requested service. In response to an Access-Reject, the NAS MUST NOT send any additional Access-Request packets for that user session.

[2]アクセス拒否は、要求されたサービスへのアクセスの拒否を意味する必要があります。アクセス拒否を受けて、NASはそのユーザセッションのための任意の追加のAccess-Requestパケットを送ってはいけません。

[3] New deployments of ARAP [RFC2869] SHOULD use Access-Challenge instead of Access-Reject packets in the conversations described in [RFC2869] Section 2.2.

[3] ARAPの新展開は、[RFC2869]、[RFC2869]セクション2.2に記載会話にパケットをアクセス拒否の代わりにアクセスチャレンジを使用するべきです。

We also note that the table of attributes in [RFC2869] Section 5.19 has an error for the Password-Retry attribute. It says:

また、[RFC2869]のセクション5.19での属性の表は、パスワード再試行属性のエラーを持っていることに注意してください。それは言います：

Request Accept Reject Challenge # Attribute 0 0 0-1 0 75 Password-Retry

リクエストはチャレンジ＃属性0 0 0-1 0 75パスワードの再試行を拒否受け入れます

However, the text in [RFC2869], Section 2.3.2 says that Password-Retry can be included within an Access-Challenge packet for EAP authentication sessions. We recommend a correction to the table that removes the "0-1" from the Reject column, and moves it to the Challenge column. We also add a "Note 2" to follow the existing "Note 1" in the document to clarify the use of this attribute.

ただし、[RFC2869]内のテキストは、セクション2.3.2には、パスワードの再試行がEAP認証セッションのためのAccess-Challengeパケット内に含まれることができることを言います。我々は拒否欄から「0-1」を削除し、チャレンジ列に移動し、テーブルに修正をお勧めします。また、この属性の使用を明確にするために、文書内の既存の「注1」に従うこと「（注2）」を追加します。

Request Accept Reject Challenge # Attribute 0 0 0 0-1 75 Password-Retry [Note 2]

0 0 0 0-1 75パスワード再試行[注2]チャレンジ＃属性を拒否要求受け入れ

[Note 2] As per RFC 3579, the use of the Password-Retry in EAP authentications is deprecated. The Password-Retry attribute can be used only for ARAP authentication.

[注2] RFC 3579に従って、EAP認証におけるパスワードの再試行の使用は推奨されています。パスワードの再試行の属性は、ARAP認証に使用することができます。

2.6.2. Service Request Denial

2.6.2. サービスリクエスト拒否

RADIUS has been deployed for purposes outside network access authentication, authorization, and accounting. For example, RADIUS has been deployed as a "back-end" for authenticating Voice Over IP (VOIP) connections, Hypertext Transfer Protocol (HTTP) sessions (e.g., Apache), File Transfer Protocol (FTP) sessions (e.g., proftpd), and machine logins for multiple operating systems (e.g., bsdi, pam, and gina). In those contexts, an Access-Reject sent to the RADIUS client MUST be interpreted as a rejection of the request for service, and the RADIUS client MUST NOT offer that service to the user.

RADIUSは、ネットワークアクセス認証、許可、アカウンティング外の目的のために配備されています。たとえば、RADIUSは、ボイスオーバーIP（VOIP）接続を認証するために、「バックエンド」として展開されてきた、ハイパーテキスト転送プロトコル（HTTP）セッション（例えば、アパッチ）、ファイル転送プロトコル（FTP）セッション（例えば、proftpdは）、複数のオペレーティングシステムのため、マシンのログイン（例えば、BSDI、PAM、およびGINA）。これらの状況では、アクセス拒否RADIUSクライアントに送信されるには、サービスの要求の拒否と解釈されなければならない、とRADIUSクライアントは、ユーザーにそのサービスを提供してはいけません。

For example, when an authentication failure occurs in the context of an FTP session, the normal semantics for rejecting FTP services apply. The rejection does not necessarily cause the FTP server to terminate the underlying TCP connection, but the FTP server MUST NOT offer any services protected by user authentication.

例えば、認証失敗がFTPセッションのコンテキストで発生した場合、FTPサービスを拒否するための通常のセマンティクスが適用されます。拒否は必ずしもFTPサーバーは、基礎となるTCP接続を終了することはありませんが、FTPサーバは、ユーザ認証で保護されたサービスを提供してはいけません。

Users may request multiple services from the NAS. Where those services are independent, the deployment MUST treat the RADIUS sessions as being independent.

ユーザーはNASからの複数のサービスを要求することができます。これらのサービスは独立している場合は、展開が独立したものとしてRADIUSセッションを扱わなければなりません。

For example, a NAS may offer multi-link services where a user may have multiple simultaneous network connections. In that case, an Access-Reject for a later multi-link connection request does not necessarily mean that earlier multi-link connections are torn down. Similarly, if a NAS offers both dialup and VOIP services, the rejection of a VOIP attempt does not mean that the dialup session is torn down.

例えば、NASは、ユーザーが複数の同時ネットワーク接続を有することができるマルチリンクサービスを提供することがあります。その場合、後のマルチリンク接続要求を拒否のアクセスは、必ずしも以前のマルチリンク接続が切断されることを意味するものではありません。 NASは、ダイヤルアップおよびVOIPの両方のサービスを提供していた場合も同様に、VOIPの試みの拒絶は、ダイヤルアップセッションが切断されていることを意味するものではありません。

2.7. Addressing

2.7. アドレッシング

2.7.1. Link-Local Addresses

2.7.1. リンクローカルアドレス

Since Link-Local addresses are unique only on the local link, if the NAS and RADIUS server are not on the same link, then an IPv6 Link-Local address [RFC4862] or an IPv4 Link-Local Address [RFC3927] cannot be used to uniquely identify the NAS. A NAS SHOULD NOT utilize a link-scope address within a NAS-IPv6-Address or NAS-IP-Address attribute. A RADIUS server receiving a NAS-IPv6-Address or NAS-IP-Address attribute containing a Link-Local address SHOULD NOT count such an attribute toward satisfying the requirements of [RFC3162] Section 2.1:

リンクローカルアドレスは、ローカルリンク上で一意であるため、NASとRADIUSサーバが同じリンク上にない場合は、その後、IPv6のリンクローカルアドレス[RFC4862]またはIPv4リンクローカルアドレス[RFC3927]はに使用することはできません一意NASを識別する。 NASはNAS-IPv6にアドレスまたはNAS-IP-Address属性内のリンクスコープアドレスを利用すべきではありません。 NAS-IPv6にアドレスやリンクローカルアドレスを含むNAS-IP-Address属性を受け取るRADIUSサーバは、[RFC3162]セクション2.1の要件を満たす方に、このような属性をカウントしてはなりません。

NAS-IPv6-Address and/or NAS-IP-Address MAY be present in an Access-Request packet; however, if neither attribute is present then NAS-Identifier MUST be present.

NAS-IPv6にアドレスおよび/またはNAS-IP-Addressはアクセス要求パケットに存在しているかもしれませ。どちらの属性が存在している場合しかし、その後、NAS-Identifierが存在しなければなりません。

2.7.2. Multiple Addresses

2.7.2. 複数アドレス

There are situations in which a RADIUS client or server may have multiple addresses. For example, a dual stack host can have both IPv4 and IPv6 addresses; a host that is a member of multiple VLANs could have IPv4 and/or IPv6 addresses on each VLAN; a host can have multiple IPv4 or IPv6 addresses on a single interface. However, [RFC2865] Section 5.44 only permits zero or one NAS-IP-Address attributes within an Access-Request, and [RFC3162] Section 3 only permits zero or one NAS-IPv6-Address attributes within an Access-Request. When a NAS has more than one global address and no ability to determine which is used for identification in a particular request, it is RECOMMENDED that the NAS include the NAS-Identifier attribute in an Access-Request in order to identify itself to the RADIUS server.

RADIUSクライアントまたはサーバが複数のアドレスを持っている可能性のある状況があります。例えば、デュアルスタックホストは、IPv4アドレスとIPv6アドレスの両方を持つことができます。複数のVLANのメンバーであるホストは、各VLANにIPv4および/またはIPv6アドレスを有することができます。ホストは、単一のインターフェイスに複数のIPv4またはIPv6アドレスを持つことができます。しかしながら、[RFC2865]セクション5.44は、ゼロまたはNAS-IP-Addressがアクセス - 要求内の属性、および[RFC3162]セクション3のみゼロまたはNAS-のIPv6アドレスは、アクセス要求内の属性のいずれかを可能にするものを可能にします。 NASは、複数のグローバルアドレスと特定の要求で識別するために使用されるかを決定する能力を有する場合、NASがRADIUSサーバに対して自身を識別するために、アクセス要求にNAS-ID属性を含めることが推奨されます。

[RFC2865] Section 3 states:

[RFC2865]セクション3つの状態：

A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.

RADIUS要求をプロキシできるように、RADIUSサーバは、使用する秘密を共有したかを決定するためにRADIUS UDPパケットの送信元IPアドレスを使用する必要があります。

Therefore, if a RADIUS client sends packets from more than one source address, a shared secret will need to be configured on both the client and server for each source address.

RADIUSクライアントは、複数の送信元アドレスからのパケットを送信する場合したがって、共有秘密は、各送信元アドレスのクライアントとサーバーの両方で設定する必要があります。

2.8. Idle-Timeout

2.8. アイドルタイムアウト

With respect to the Idle-Timeout attribute, [RFC2865] Section 5.28 states:

アイドルタイムアウト属性に関しては、[RFC2865]セクション5.28状態：

This Attribute sets the maximum number of consecutive seconds of idle connection allowed to the user before termination of the session or prompt. This Attribute is available to be sent by the server to the client in an Access-Accept or Access-Challenge.

この属性は、セッションまたはプロンプトが終了する前にユーザーに許可されるアイドル接続の連続した最大秒数を設定します。この属性は、アクセス-受け入れるか、またはアクセスチャレンジでクライアントにサーバによって送信することが可能です。

[RFC3580] Section 3.12 states:

[RFC3580]セクション3.12状態：

The Idle-Timeout attribute is described in [RFC2865]. For IEEE 802 media other than 802.11 the media are always on. As a result the Idle-Timeout attribute is typically only used with wireless media such as IEEE 802.11. It is possible for a wireless device to wander out of range of all Access Points. In this case, the Idle-Timeout attribute indicates the maximum time that a wireless device may remain idle.

アイドルタイムアウト属性は、[RFC2865]に記述されています。 IEEE 802.11のためのメディア以外の802枚のメディアは常にオンです。その結果、アイドルタイムアウト属性は、典型的にのみ例えばIEEE 802.11のような無線媒体と共に使用されます。ワイヤレスデバイスは、すべてのアクセスポイントの範囲外にさまようすることが可能です。この場合には、アイドルタイムアウト属性は、無線デバイスがアイドル状態のままであってもよい最大時間を示しています。

In the above paragraphs "idle" may not necessarily mean "no traffic"; the NAS may support filters defining what traffic is included in the idle time determination. As a result, an "idle connection" is defined by local policy in the absence of other attributes.

上記の段落では「アイドル」は必ずしも「トラフィック」を意味しないかもしれません。 NASは、アイドル時間の決意に含まれているものトラフィックを定義フィルタをサポートすることができます。結果として、「アイドル接続は、」他の属性が存在しない場合にローカルポリシーによって定義されています。

2.9. Unknown Identity

2.9. 不明なアイデンティティ

[RFC3748] Section 5.1 states:

[RFC3748]セクション5.1の状態：

If the Identity is unknown, the Identity Response field should be zero bytes in length.

アイデンティティが不明な場合は、アイデンティティ応答フィールドは長さがゼロバイトである必要があります。

However, [RFC2865] Section 5.1 describes the User-Name attribute as follows:

ただし、次のように[RFC2865]セクション5.1は、User-Name属性について説明します。

The String field is one or more octets.

文字列フィールドは1オクテット以上です。

How should the RADIUS client behave if it receives an EAP-Response/Identity that is zero octets in length?

どのようにRADIUSクライアントは、長さがゼロのオクテットであるEAP応答/アイデンティティを受信した場合に振る舞うべきですか？

[RFC2865] Section 5.1 states:

[RFC2865]セクション5.1の状態：

This Attribute indicates the name of the user to be authenticated. It MUST be sent in Access-Request packets if available.

この属性は、認証されるユーザの名前を示します。可能な場合はアクセス要求パケットで送らなければなりません。

This suggests that the User-Name attribute may be omitted if it is unavailable.

これは、それが使用できない場合User-Name属性を省略することができることを示唆しています。

However, [RFC3579] Section 2.1 states:

ただし、[RFC3579]セクション2.1の状態：

In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS initially sends an EAP-Request/Identity message to the peer, the NAS MUST copy the contents of the Type-Data field of the EAP-Response/Identity received from the peer into the User-Name attribute and MUST include the Type-Data field of the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request.

NASが最初にピアにEAP-Request / Identityメッセージを送信する場合、アクセス要求パケットを転送するために、非EAP意識RADIUSプロキシを可能にするために、NASは、EAP-のタイプのデータフィールドの内容をコピーする必要があります応答/アイデンティティは、User-Name属性にピアから受信し、後続のすべてのアクセス要求のUser-Name属性におけるEAP応答/アイデンティティのタイプのデータフィールドを含まなければなりません。

This suggests that the User-Name attribute should contain the contents of the Type-Data field of the EAP-Response/Identity, even if it is zero octets in length.

これは、User-Name属性は、それは長さがゼロのオクテットであっても、EAP応答/アイデンティティのタイプのデータフィールドの内容を含まなければならないことを示唆しています。

Note that [RFC4282] does not permit a Network Access Identifier (NAI) of zero octets, so that an EAP-Response/Identity with a Type-Data field of zero octets MUST NOT be construed as a request for privacy (e.g., anonymous NAI).

ゼロオクテットのタイプデータフィールドとEAP応答/アイデンティティがプライバシーのための要求（例えば、匿名NAIように解釈してはならないように、[RFC4282]は、ゼロオクテットのネットワークアクセス識別子（NAI）を許可していないことに注意してください）。

When a NAS receives an EAP-Response/Identity with a Type-Data field that is zero octets in length, it is RECOMMENDED that it either omit the User-Name attribute in the Access-Request or include the Calling-Station-Id in the User-Name attribute, along with a Calling-Station-Id attribute.

NASは、長さがゼロのオクテットで、タイプデータフィールドとEAP応答/アイデンティティを受信すると、どちらかのアクセス要求のUser-Name属性を省略するかで通話-駅-IDを含めることをお勧めしますユーザー名Calling-Station-IDアトリビュートとともに、属性。

2.10. Responses After Retransmissions

2.10. 再送信後の回答

Some implementations do not correctly handle the receipt of RADIUS responses after retransmissions. [RFC2865] Section 2.5 states:

いくつかの実装が正しく再送信した後、RADIUS応答の受信を処理しません。 [RFC2865]セクション2.5の状態：

If the NAS is retransmitting a RADIUS request to the same server as before, and the attributes haven't changed, you MUST use the same Request Authenticator, ID, and source port. If any attributes have changed, you MUST use a new Request Authenticator and ID.

NASは前と同じサーバーにRADIUS要求を再送信され、および属性が変更されていない場合は、同じ要求認証、ID、および送信元ポートを使用しなければなりません。いずれかの属性が変更されている場合は、新しい要求認証とIDを使用しなければなりません。

Note that changing the Request ID for a retransmission may have undesirable side effects. Since RADIUS does not have a clear definition of a "session", it is perfectly valid for a RADIUS server to treat a retransmission as a new session request, and to reject it due to, for example, the enforcement of restrictions on multiple simultaneous logins.

再送要求のIDを変更すると、望ましくない副作用を有することができることに注意してください。 RADIUSは、「セッション」の明確な定義を持っていないので、それは新しいセッション要求としての再送を治療するために、RADIUSサーバのための完全に有効であり、例えば、原因にそれを拒否するために、複数の同時ログインの制限の施行。

In that situation, the NAS may receive a belated Access-Accept for the first request, and an Access-Reject for the retransmitted request, both of which apply to the same "session".

そのような状況では、NASは遅れ接続許可最初の要求のために、同じ「セッション」には適用されどちらも再送要求のアクセス拒否を受信してもよいです。

We suggest that the contents of Access-Request packets SHOULD NOT be changed during retransmissions. If they must be changed due to the inclusion of an Event-Timestamp attribute, for example, then responses to earlier transmissions MUST be silently discarded. Any response to the current request MUST be treated as the definitive response, even if as noted above, it disagrees with earlier responses.

私たちは、アクセス要求パケットの内容が再送信中に変更されるべきでないことを示唆しています。彼らは原因イベントタイムスタンプ属性を含めることに変更しなければならない場合には、例えば、その後、以前の送信に応答が静かに捨てなければなりません。現在の要求に対する応答は、上述したように、それは以前の回答に同意しない場合でも、決定的な応答として扱わなければなりません。

This problem can be made worse by implementations that use a fixed retransmission timeout (30 seconds is common). We reiterate the suggestions in Section 2.1 about using congestive backoff. In that case, responses to earlier transmissions MAY be used as data points for congestive backoff, even if their contents are discarded.

この問題は、（30秒が一般的である）は、固定再送タイムアウトを使用して実装することによって悪化することができます。私たちは、うっ血性バックオフを使用する方法について、2.1節で提案を改めて表明する。その場合には、以前の送信に対する応答は、その内容が破棄された場合でも、うっ血バックオフのためのデータポイントとして使用することができます。

2.11. Framed-IPv6-Prefix

2.11. フレームを選ぶ-のIPv6プレフィックス

[RFC3162] Section 2.3 says:

[RFC3162]セクション2.3は述べています：

This Attribute indicates an IPv6 prefix (and corresponding route) to be configured for the user. It MAY be used in Access-Accept packets, and can appear multiple times. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer these prefix(es), but the server is not required to honor the hint. Since it is assumed that the NAS will plumb a route corresponding to the prefix, it is not necessary for the server to also send a Framed-IPv6-Route attribute for the same prefix.

この属性は、ユーザのために設定されるIPv6プレフィックス（及び対応するルート）を示しています。 access-acceptパケットで使用することができ、複数回出現することができます。それは、それはこれらの接頭語（es）を好むだろうサーバへのNASによってヒントとしてのAccess-Requestパケットで使用されるかもしれないが、サーバーはヒントを尊重する必要はありません。 NASが接頭語に対応したルートをplumbすることが想定されているため、サーバでも同じプレフィックスのための額縁-のIPv6ルート属性を送信するために、それは必要ありません。

An Internet Service Provider (ISP) may desire to support Prefix Delegation [RFC4818] at the same time that it would like to assign a prefix for the link between the NAS and the user. The intent of the paragraph was to enable the NAS to advertise the prefix (such as via a Router Advertisement). If the Framed-Routing attribute is used, it is also possible that the prefix would be advertised in a routing protocol such as Routing Information Protocol Next Generation (RIPNG). RFC 2865 Section 5.10 describes the purpose of Framed-Routing:

インターネットサービスプロバイダ（ISP）は、NASとユーザとの間のリンクの接頭辞を割り当てたいと同時に、プレフィックス委任[RFC4818]をサポートすることを望むかもしれません。段落の意図は、（例えば、ルータ広告などを介して）プレフィックスを通知するためにNASを可能にすることでした。入れるルーティング属性が使用される場合、その接頭辞は、ルーティング情報プロトコル次世代（RIPNG）などのルーティングプロトコルでアドバタイズされることも可能です。 RFC 2865のセクション5.10は、額縁・ルーティングの目的を説明します。

This Attribute indicates the routing method for the user, when the user is a router to a network. It is only used in Access-Accept packets.

この属性は、ユーザがネットワークにルータである場合、ユーザのルーティング方法を示します。これは、唯一のAccess-受け入れパケットで使用されています。

The description of the Prefix-Length field in RFC 3162 indicates excessively wide latitude:

RFC 3162にプレフィックスレングスフィールドの説明が過度広いラチチュードを示します。

The length of the prefix, in bits. At least 0 and no larger than 128.

ビットでプレフィックスの長さ、。少なくとも0と128よりも大きくありません。

This length appears too broad, because it is not clear what a NAS should do with a prefix of greater granularity than /64. For example, the Framed-IPv6-Prefix may contain a /128. This does not imply that the NAS should assign an IPv6 address to the end user, because RFC 3162 already defines a Framed-IPv6-Identifier attribute to handle the Identifier portion.

それはNASが/ 64より大きい粒度の接頭辞で何をすべきか明確ではないので、この長さは、広すぎる表示されます。例えば、入り-のIPv6プレフィックスは/ 128を含んでもよいです。これは、RFC 3162が既に識別子部分を処理するために入れる-IPv6の識別子属性を定義するためNASは、エンドユーザにIPv6アドレスを割り当てる必要があることを意味するものではありません。

It appears that the Framed-IPv6-Prefix is used for the link between the NAS and Customer Premises Equipment (CPE) only if a /64 prefix is assigned. When a /64 or larger prefix is sent, the intent is for the NAS to send a routing advertisement containing the information present in the Framed-IPv6-Prefix attribute.

/ 64プレフィックスが割り当てられている場合にのみフレームを選ぶ-のIPv6プレフィックスは、NASおよび顧客宅内機器（CPE）との間のリンクのために使用されていることが表示されます。 / 64以上のプレフィックスが送信されるときにNASが入り-のIPv6プレフィックスの属性に存在する情報を含むルーティング広告を送信するために、意図されます。

The CPE may also require a delegated prefix for its own use, if it is decrementing the Hop Limit field of IP headers. In that case, it should be delegated a prefix by the NAS via the Delegated-IPv6-Prefix attribute [RFC4818]. If the CPE is not decrementing Hop Limit, it does not require a delegated prefix.

それはIPヘッダのホップ制限フィールドをデクリメントされている場合CPEはまた、自身の使用のために委譲されたプレフィックスが必要な場合があります。その場合には、委任-のIPv6プレフィックスの属性[RFC4818]を介して、NASによってプレフィックスを委任されるべきです。 CPEは、ホップ制限をデクリメントされていない場合は、委任プレフィックスを必要としません。

3. Security Considerations

3.セキュリティの考慮事項

The contents of the State attribute are available to both the RADIUS client and observers of the RADIUS protocol. RADIUS server implementations should ensure that the State attribute does not disclose sensitive information to a RADIUS client or third parties observing the RADIUS protocol.

State属性の内容は、RADIUSクライアントとRADIUSプロトコルのオブザーバーの両方に使用可能です。 RADIUSサーバの実装は、State属性は、RADIUSクライアントまたはRADIUSプロトコルを観察し、第三者に機密情報を開示していないことを確認する必要があります。

The cache mechanism described in Section 2.2.2 is vulnerable to attacks when Access-Request packets do not contain a Message-Authenticator attribute. If the server accepts requests without a Message-Authenticator, then RADIUS packets can be trivially forged by an attacker. Cache entries can then be forcibly expired, negating the utility of the cache. This attack can be mitigated by following the suggestions in [RFC3579] Section 4, or by requiring the presence of Message-Authenticator, as described in Sections 2.1.1 and 2.2.2.

2.2.2項で説明したキャッシュ・メカニズムは、アクセス要求パケットはMessage-Authenticatorアトリビュートが含まれていない攻撃に対して脆弱です。サーバはメッセージ認証なしの要求を受け入れた場合、RADIUSパケットは自明攻撃者によって偽造することができます。キャッシュエントリは、強制的にキャッシュの有用性を否定、期限切れにすることができます。この攻撃は、[RFC3579]セクション4で提案に従うことにより、またはセクション2.1.1および2.2.2に記載されているように、メッセージ認証の存在を要求することによって緩和することができます。

Since this document describes the use of RADIUS for purposes of authentication, authorization, and accounting in a wide variety of networks, applications using these specifications are vulnerable to all of the threats that are present in other RADIUS applications. For a discussion of these threats, see [RFC2865], [RFC2607], [RFC3162], [RFC3579], and [RFC3580].

このドキュメントは、ネットワークの多種多様な認証、許可、アカウンティングの目的のためにRADIUSを使用することを記載しているため、これらの仕様を使用しているアプリケーションは、他のRADIUSアプリケーションに存在する脅威のすべてに対して脆弱です。これらの脅威の議論に関しては、[RFC2865]、[RFC2607]、[RFC3162]、[RFC3579]、および[RFC3580]を参照してください。

4. References

4.参考文献

4.1. Normative References

4.1. 引用規格

[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）でリモート認証ダイヤル"。

[RFC4818] Salowey, J. and R. Droms, "RADIUS Delegated-IPv6-Prefix Attribute", RFC 4818, April 2007.

[RFC4818] Salowey、J.とR. Droms、 "RADIUS委任-のIPv6-prefix属性"、RFC 4818、2007年4月。

4.2. Informative References

4.2. 参考文献

[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.

[RFC2607] Aboba、B.、およびJ. Vollbrecht、 "ローミング中のプロキシ連鎖とポリシー実装"、RFC 2607、1999年6月。

[RFC2618] Aboba, B. and G. Zorn, "RADIUS Authentication Client MIB", RFC 2618, June 1999.

[RFC2618] Aboba、B.およびG.ゾルン、 "RADIUS認証クライアントMIB"、RFC 2618、1999年6月。

[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.

[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。

[RFC2869] Rigney, C., Willats, W., and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.

[RFC2869] Rigney、C.、Willats、W.、およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。

[RFC3162] Aboba, B., Zorn, G., and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.

[RFC3162] Aboba、B.、ゾルン、G.、およびD.ミットン、 "RADIUSとIPv6"、RFC 3162、2001年8月。

[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.

[RFC3315] Droms、R.、編、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315 、2003年7月。

[RFC3576] Chiba, M., Dommety, G., Eklund, M., Mitton, D., and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.

、RFC 3576、2003年7月[RFC3576]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.、およびB. Aboba、 "ユーザーサービス（RADIUS）でリモート認証ダイヤルへのダイナミックな承認拡張機能"。

[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月。

[RFC3580] Congdon, P., Aboba, B., Smith, A., Zorn, G., and J. Roese, "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS) Usage Guidelines", RFC 3580, September 2003.

[RFC3580] Congdon氏、P.、Aboba、B.、スミス、A.、ゾルン、G.、およびJ.レーゼ、 "IEEE 802.1Xのリモート認証ダイヤルインユーザーサービス（RADIUS）使用上のガイドライン"、RFC 3580、2003年9月。

[RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004.

[RFC3748] Aboba、B.、ブルンク、L.、Vollbrecht、J.、カールソン、J.、およびH. Levkowetz、編、 "拡張認証プロトコル（EAP）"、RFC 3748、2004年6月。

[RFC3927] Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Configuration of IPv4 Link-Local Addresses", RFC 3927, May 2005.

[RFC3927]チェシャー、S.、Aboba、B.、およびE.ガットマン、 "IPv4のリンクローカルアドレスの動的構成"、RFC 3927、2005年5月。

[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月。

[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月。

[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007.

[RFC4862]トムソン、S.、Narten氏、T.、およびT.神明、 "IPv6のステートレスアドレス自動設定"、RFC 4862、2007年9月。

[PANA] Forsberg, D., Ohba, Y.,Ed., Patil, B., Tschofenig, H., and A. Yegin, "Protocol for Carrying Authentication for Network Access (PANA)", Work in Progress.

[PANA]フォースバーグ、D.、オオバ、Y.、編、パティル、B.、Tschofenig、H.、およびA. Yegin、 "プロトコル・ネットワークアクセス（PANA）の認証を実施するための" 進行中で働いています。

Acknowledgments

謝辞

The authors would like to acknowledge Glen Zorn and Bernard Aboba for contributions to this document.

作者はこのドキュメントへの貢献のためにグレンソーンとバーナードAbobaを確認したいと思います。

The alternate algorithm to [RFC3579] Section 2.6.1 that is described in Section 2.1.2 of this document was designed by Raghu Dendukuri.

このドキュメントのセクション2.1.2に記載されている[RFC3579]セクション2.6.1に代替アルゴリズムはラグーDendukuriによって設計されました。

The text discussing retransmissions in Section 2.2.1 is taken with minor edits from Section 9 of" Protocol for Carrying Authentication for Network Access (PANA)" [PANA].

2.2.1項に再送を議論するテキストは、「ネットワークアクセスの認証を実施するためのプロトコル（PANA）」[PANA]のセクション9から細部の編集で撮影しています。

Alan DeKok wishes to acknowledge the support of Quiconnect Inc., where he was employed during much of the work on this document.

アランDeKokは、彼がこのドキュメントの作業の多くの間に使用されたQuiconnect社のサポートを認めることを望みます。

David Nelson wishes to acknowledge the support of Enterasys Networks, where he was employed during much of the work on this document.

デビッド・ネルソンは、彼がこのドキュメントの作業の多くの間に使用されたエンテラシス・ネットワークのサポートを認めることを望みます。

Authors' Addresses

著者のアドレス

David B. Nelson Elbrys Networks, Inc. 75 Rochester Ave., Unit 3 Portsmouth, N.H. 03801 USA

デビッド・B・ネルソンElbrysネットワークス株式会社75ロチェスターアベニュー、3号機ポーツマス、N.H. 03801 USA

Phone: +1.603.570.2636 EMail: dnelson@elbrysnetworks.com

電話：+1.603.570.2636電子メール：dnelson@elbrysnetworks.com

Alan DeKok The FreeRADIUS Server Project http://freeradius.org/

アランDeKok FreeRADIUSサーバプロジェクトhttp://freeradius.org/

EMail: aland@freeradius.org

メールアドレス：aland@freeradius.org

Full Copyright Statement

完全な著作権声明

著作権（C）IETFトラスト（2007）。

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。