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

原文URL : https://datatracker.ietf.org/doc/html/rfc5080
タイトル : RFC 5080 - 一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）の実装の問題と提案された修正
翻訳編集 : 自動生成

[要約] 要約： RFC 5080は、RADIUSの実装に関する一般的な問題と修正案について説明しています。目的：このRFCの目的は、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

一般的なリモート認証ダイヤルインユーザーサービス（RADIUS）の実装の問題と提案された修正

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）の実装に見られる一般的な問題について説明し、いくつかの修正を提案します。該当する場合、以前の半径仕様のあいまいさとエラーが明確になります。

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実装で見られる一般的な問題を説明し、いくつかの修正を示唆しています。該当する場合、以前の半径仕様のあいまいさとエラーが明確になります。

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は、802.11を介したネットワークアクセスやポイントツーポイントプロトコル（PPP）など、ユーザーにサービスを提供します。

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].

このドキュメントでは、仕様の要件を示すためにいくつかの単語を使用しています。「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[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状態：

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-Requestの値を持つ終端アクション属性も含むアクセスアセプトで、サーバーからクライアントに送信できます。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クライアントの実装では、再起動したEAP認証プロセスを進行中のプロセスの継続（同じNASとポートの同じユーザーによる）と区別するために、状態属性を適切に使用しません。EAPメッセージ属性がAccess-ChallengeまたはAccess-Accept属性に含まれている場合、RADIUSサーバーには状態属性も含める必要があります。この方法で状態属性を使用するための追加の利点については、要求に応じてセクション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つの認証セッションに結び付ける場合、サーバーの責任です。[RFC2865]セクション5.24で定義されているように、状態は、その課題があれば、新しいAccess-Requestの返信でクライアントからサーバーに修正されずに送られなければなりません。

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.

ほとんどのサーバーの実装では、アクセスチャレンジパケットに状態属性が存在する必要がありますが、一部の課題応答システムは、認証セッションを追跡するために状態属性を使用することなく、最初の要求とチャレンジへの応答と区別できます。これらのシステムのアクセスチャレンジとその後のアクセスリクエストパケットは、状態属性を含める必要はありません。

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.

その他の認証メカニズムは、アクセスリクエスト /アクセスチャレンジパケットのシーケンスを1つの継続的な認証セッションに結び付ける必要があります。これらの認証メカニズムを実装するサーバーには、Access-Challengeパケットに状態属性を含める必要があります。

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属性を使用してマルチパケットセッションを作成することは、今日の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.

状態属性の唯一の許容値は、Access-Accept、Access-Challenge、COA-Request、または切断リケストパケットで提供される値です。RADIUSクライアントは、以前にサーバーから受信した状態属性の値のみを使用する必要があります。同じユーザーとポートのアクセスチャレンジで州の属性が以前に受信されていても、新しいまたは再起動された認証実行の結果として送信されるアクセスリクエストは、状態属性を含めてはなりません。

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.

[authorizeのみを持つサービスタイプの属性を含むアクセス再クエストパケット（17）には、状態属性を含める必要があります。Value Call Check（10）を備えたサービスタイプの属性を含むAccess-Requestパケットは、状態属性を含めるべきではありません。承認チェックを実行する他のアクセスレクエストパケットには、状態属性が含まれている必要があります。この最後の要件は、多くの場合、Access-Acceptが状態属性を含める必要があることを意味します。これは、承認チェックを実行する後のアクセス要求で使用できます。

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.

コールチェックの標準的なユースケースは、電話番号やメディアアクセス制御（MAC）アドレスなどのエンドポイント識別子情報のみに基づいて、発話中の識別子情報、およびオプションではステーション-IDと呼ばれます。このユースケースでは、NASには、アクセスリケストに含めるのに適した状態属性を取得する方法がありません。その他の非標準のコールチェックの使用は、状態属性の使用を必要または許可する場合がありますが、このドキュメントの範囲を超えています。

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.

Value Call Checkを備えたサービスタイプの属性を備えたAccess-Requestでは、ユーザー名とユーザーパスワードの属性が同じ値（MACアドレスなど）を含めることは推奨されません。通話チェックのサービスタイプを使用せずにMACアドレスチェックを実装することは推奨されません。このプラクティスは、攻撃者にユーザーパスワードフィールドのクリアテキストと暗号テキストの両方を提供し、RADIUSプロトコルのセキュリティに対する多くの攻撃を許可します。たとえば、リクエスト認証機がグローバルおよび時間的な一意性に関する[RFC2865]要件を満たしていない場合、上記のプラクティスは、無関係なユーザーの他のアクセスリケストのユーザーパスワード属性の妥協につながる可能性があります。Cipher-Textへのアクセスにより、オフラインの辞書攻撃が可能になり、共有された秘密を公開する可能性があり、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.

Call Checkを含む承認チェックを実行するAccess-Requestパケットには、メッセージAuthenticator属性を含める必要があります。Access-Requestの承認チェックを実行する回答への応答は、アクセスリケストに状態属性が含まれている場合を除き、ユーザー（トンネルパスワードなど）に関する機密情報を含めてはなりません。ここでの州の使用により、承認チェックは以前のユーザー認証に関連付けることができます。その場合、サーバーはそのユーザーに関する機密情報を使用して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. Request-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-IDENTIFIER、NAS-IPV6-Address、NAS-IPV4-Addressが含まれます。セッション識別属性には、ユーザー名、NASポート、NASポートタイプ、NASポートID、Calling-Station-ID、およびOriginating-Line-INFOが含まれます。

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）アドレス、および状態属性を「キー」として使用します。状態属性は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
      }

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

このアルゴリズムは、ホームサーバーが中間半径プロキシを介してメッセージを受信する状況など、さまざまな状況でうまく機能するようです。

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.

もう一方の極端な場合、ユーザーは認証を数分待つことをいとわない。したがって、2分後のTCPデータの信頼できる配信は役に立ちません。代替サーバーをより速く使用すると、ユーザーがあきらめる前にアクセスを得ることができます。

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秒以下のデフォルトの再送信タイムアウトを利用して、過度に積極的な再送信動作を実装しています。大規模に展開すると、これらの実装はうっ血性崩壊の影響を受けやすくなります。たとえば、停電の結果として、1秒の固定再送信タイマーを備えた3,000のNASデバイスを備えたネットワークは、1秒あたり3,000半径のアクセス要求を継続的に生成します。これは、ほとんどの半径サーバーを圧倒するのに十分です。

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.

RADIUSサーバーは、短期間で同じクライアントソースIPアドレスとソースUDPポートと識別子がある場合、重複する要求を検出できます。

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

また、[RFC4669]のセクション7では、radiusiuthauthservdupaccessrequestsオブジェクトを次のように定義しています。

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サーバーは認証要求を2回処理し、ユーザーが2回ログインしているという誤った結論につながる場合があります。その動作は望ましくないため、重複した検出が望ましいです。第二に、サーバーは重複リクエストだけでなく、それらのリクエストへの返信も追跡することができます。この動作により、サーバーは、リクエストの重複に応じて重複した返信を送信することができ、ネットワークの安定性が向上します。

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パケットは、サーバーからのアクセスチャレンジに応じてクライアントによって送信される場合があるため、これらのパケットは論理的に順序付けられたストリームを形成するため、さまざまなセッション用のアクセスリケストパケットよりも追加の順序付け要件があります。重複検出の実装は、新しいパケットが1回だけ処理され、順序が確保されます。

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.

したがって、RADIUSサーバーは、[RFC2865]のセクション3で説明されているように、Access-Requestパケットの重複検出を実装する必要があります。また、実装は、アクセスリケストパケットに応じて送信する応答（アクセスaccept、アクセスチャレンジ、またはアクセス拒否）をキャッシュする必要があります。サーバーが既に応答を送信している有効な複製アクセスリケストを受信した場合、リクエストを再処理せずに元の応答を再送信する必要があります。サーバーは、応答がまだ送信されていない重複するアクセス要求を静かに廃棄する必要があります。

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.

サーバーが、ソースアドレス、ソースポート、半径識別子、および受信ソケットのキャッシュされたアクセスリクエストパケットと一致する有効なアクセスリクエストパケットを受信した場合、キャッシュエントリをパージする必要がありますが、リクエスト認証機フィールドは1つとは異なります。キャッシュされたパケット。リクエストにメッセージauthenticator属性が含まれている場合、[RFC3580]セクション3.2で説明されているように、リクエストを処理する必要があります。無効なメッセージ-Authenticatorsを備えたパケットは、キャッシュに何らかの形で影響を与えてはなりません。

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.

ただし、メッセージAuthenticator属性を含むアクセスパケットは、簡単に偽造されている場合でも、常にキャッシュに影響します。この問題を回避するために、Access-RequestパケットにMessage-Authenticator属性の存在を要求するようにサーバーの実装を構成することができます。メッセージ-Authenticator属性を含む要求は、静かに破棄される場合があります。

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

クライアントの実装には、この問題を軽減するために、すべてのAccess-Requestにメッセージ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 Access-Requestパケットを優先的に受け入れることです。そのため、一度始めたマルチラウンド認証会話は成功する可能性が高くなります。同様に、リクエストをプロキシしているサーバーは、NASからの新しいリクエストを処理する前に、Homeサーバーからアクセスアクセプト、アクセスチャレンジ、またはアクセス拒否パケットを優先的に処理する必要があります。

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出力オクセット、ACCTセッションタイム、ACCT入力パケット、ACCT出力パケット、ACCTターミネート原因属性が「会計のためにのみ存在することができることを示しています。ACCTステータスタイプが停止するように設定されているレコード」。

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-Status-Type = Interim-Update（3）を使用）には、ACCT期間の原因属性を除き、会計STOPメッセージに通常見られるすべての属性が含まれることが想定されています。

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. ACCT-SESSION-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では、ACCT-SESSION-IDは属性形式を要約する図内のテキストとして説明しますが、「文字列フィールドは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]は、テキストタイプを「UTF-8エンコード10646文字を含む」と定義します。これは、ACCT-Session-IDの説明と互換性があります。他の属性は、属性形式を要約する図と次の属性定義の両方で「テキスト」として一貫して記述されるため、これは誤植であり、acct-session-idはタイプのテキストであり、タイプではないように見えます。弦。

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 ...

ACCT-Session-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属性は、型文字列のものとして定義されます。ただし、テキストの言語は、実装者が属性をタイプテキストのものと見なすことを強く推奨しています。タイプテキストで十分である場合、この属性に対してタイプ文字列が選択された理由は不明です。この属性はテキストとして扱う必要があります。

2.3.3. Request Authenticator

2.3.3. Authenticatorをリクエストします

[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.

Accounting-Requestのリクエスト認証機には、上記の「リクエスト認証器」で説明されている方法に従って計算された16-Octet 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でローカルに構成された値は、Access-Acceptで見つかった値をオーバーライドする必要があることに注意してください。

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で管理的にプロビジョニングされた値は、アクセスacceptメッセージからのより小さな値によって過剰に供給されるべきではありません。ただし、NASの価値は、より大きなものによっては乱れている可能性があります。意図は、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

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.

Total IncomingPacketsの計算に含まれていないTotalIncomingPacketsからさまざまなカウンターが差し引かれるため、「正常に受信」の値は負になる可能性があるようです。

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

また、「AccessRequests PlideStrequests ClientTimeAuts =正常に受信する」は、「ClientSrequests clientTimeAuts =正常に送信される」を読み取る必要があるように見えます。

"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".

「Total IncomingPackets」と「正常に受信」は、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 Access-Requestパケットの数は、まだ回答がまだタイムアウトされていないか、受信されていません。この変数は、アクセス許容書、アクセス拒否またはアクセスチャレンジ、タイムアウトまたは再送信の受領により、アクセスリケストが送信および減少すると増加します。

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. 複数のFilter-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.

実際には、複数のFilter-ID属性を受信するRADIUSクライアントの動作は実装に依存しています。たとえば、一部の実装では、Filter-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属性の解釈は、半径内で未定義です。Access-Accept内の複数のFilter-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属性は、オプションであるか必須かを明示的に述べていません。それにもかかわらず、半径属性を必須として扱う必要がある場合があります。

[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属性を実装してはなりません。たとえば、Appleリモートアクセスプロトコル（ARAP）サービスを提供できないNASは、ARAPのRADIUS属性を実装してはなりません。NASは、代わりに、利用できないサービスをAccess-rejectとして承認するRADIUSアクセスacceptを扱う必要があります。

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.

この属性は、ユーザーが要求したサービスのタイプ、または提供されるサービスのタイプを示します。Access-RequestとAccess-Acceptパケットの両方で使用できます。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クライアントが注意を払うのが最適です。実装されていないサービスの既知のタイプの属性を含むアクセス認定を受信すると、RADIUSクライアントは、[RFC2865]セクション1.1に指示されているように、アクセス除去として扱う必要があります。不明なタイプの属性を含むアクセス認定を受信すると、RADIUSクライアントはそれが潜在的なサービス定義であると想定し、それをアクセス除去として扱う必要があります。RADIUSクライアントは、不明なVSAを無視する必要があります。

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に設定されている場合、不明な属性を含むアクセスアクセプトはアクセス拒否として扱われます。フラグがfalseに設定されている場合、Access-Acceptsの不明な属性は静かに無視されます。

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.

VSAS内でエンコードされたサービス要求の誤解を避けるために、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:

Access-Rejectの意図は、要求されたサービスへのアクセスを拒否することです。[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サーバーは、このユーザー要求が無効であることを示す「アクセス - リジェクト」応答を送信します。必要に応じて、サーバーには、クライアントがユーザーに表示する可能性のあるAccess-rejectにテキストメッセージを含めることができます。他の属性（プロキシステートを除く）は、アクセス抵抗で許可されていません。

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-Acceptを属性プロビジョニング限定アクセスで送信できます。アクセス抵抗内の属性は、メッセージをルーティングするために必要な属性（例えば、プロキシステート）に制限されており、アクセスが拒否されたことをユーザーに提供する属性（たとえば、EAP-failureを含むEAPメッセージ属性）、または、エラーメッセージを伝える属性（例：返信メッセージまたはエラー原因属性）。

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サーバーは、オプションのパスワード再生と応答メッセージの属性を使用して、Access-rejectパケットを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] 新しい半径の仕様と実装は、アクセスチャレンジのセマンティクスが意図されている場合、アクセス除外を使用しないでください。

[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] アクセス - リジェクトは、要求されたサービスへのアクセスの拒否を意味する必要があります。Access-Rejectに応じて、NASはそのユーザーセッションに追加のアクセスリケストパケットを送信してはなりません。

[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 Password-Retry

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認証セッションのためにアクセスチャレンジパケットに含めることができると述べています。拒否列から「0-1」を削除し、チャレンジ列に移動するテーブルの修正をお勧めします。また、「ノート2」を追加して、この属性の使用を明確にするために、ドキュメントの既存の「注1」に従います。

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

request Accept Accept Challenge＃属性0 0 0 0-1 75 Password-Retry [注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）セッション（Apacheなど）、ファイル転送プロトコル（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は、ユーザーが複数の同時ネットワーク接続を持つことができるマルチリンクサービスを提供する場合があります。その場合、後のマルチリンク接続要求のアクセス - rejectは必ずしも以前のマルチリンク接続が取り壊されることを意味するわけではありません。同様に、NASがダイヤルアップサービスとVoIPサービスの両方を提供している場合、VoIPの試みの拒否は、ダイヤルアップセッションが取り壊されていることを意味しません。

2.7. Addressing

2.7. アドレッシング

2.7.1. Link-Local Addresses

2.7.1. Link-Localアドレス

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:

Link-Localアドレスはローカルリンクでのみ一意であるため、NASとRADIUSサーバーが同じリンク上にない場合、IPv6 Link-Localアドレス[RFC4862]またはIPv4 Link-Localアドレス[RFC3927]を使用できません。NASを独自に特定します。NASは、NAS-IPv6-AddressまたはNAS-IP-Address属性内のリンクスコープアドレスを利用しないでください。Link-Localアドレスを含むNAS-IPV6-Addressまたは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-Addressおよび/または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は、アクセスリケスト内のゼロまたは1つのNAS-IPアドレス属性のみを許可し、[RFC3162]セクション3では、アクセスレクスト内のゼロまたは1つのNAS-IPV6-Address属性のみを許可します。NASが複数のグローバルアドレスを持ち、特定のリクエストで識別に使用されるものを決定する能力がない場合、NASはRADIUSサーバーに識別するためにAccess-RequestにNAS-IDENTIFIER属性を含めることをお勧めします。

[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 UDPパケットのソースIPアドレスを使用して、RADIUSリクエストをプロキシできるように、使用する共有シークレットを決定する必要があります。

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.

この属性は、セッションまたはプロンプトが終了する前に、ユーザーに許可されているアイドル接続の連続した最大数を設定します。この属性は、Access-Acceptまたは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]で説明されています。802.11以外のIEEE 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.

アイデンティティが不明な場合、ID応答フィールドの長さはゼロバイトでなければなりません。

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

ただし、[RFC2865]セクション5.1では、ユーザー名属性を次のように説明しています。

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.

これは、ユーザー名属性が利用できない場合は省略される可能性があることを示唆しています。

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.

EAP以外の認識RADIUSプロキシがアクセスレクエストパケットを転送することを許可するために、NASが最初にEAP-Request/IDメッセージをピアに送信する場合、NASはEAP-のタイプデータフィールドの内容をコピーする必要があります。ピアからユーザー名属性に受け取った応答/アイデンティティは、その後のすべてのAccess-Requestのユーザー名属性にEAP応答/IDのタイプデータフィールドを含める必要があります。

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.

これは、ユーザー名属性に、長さがゼロオクテットであっても、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).

[RFC4282]は、ゼロオクテットのネットワークアクセス識別子（NAI）を許可していないため、ゼロオクテットのタイプデータフィールドを持つEAP応答/アイデンティティをプライバシーのリクエストとして解釈する必要はないことに注意してください（例えば、匿名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応答/アイデンティティを受信する場合、アクセスリケストでユーザー名属性を省略するか、またはユーザー名属性、および呼び出しステーション-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:

一部の実装では、再送信後の半径応答の受信を正しく処理しません。[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要求を再送信しており、属性が変更されていない場合は、同じリクエストAuthenticator、ID、およびソースポートを使用する必要があります。属性が変更されている場合は、新しいリクエストAuthenticatorと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は最初のリクエストのために遅ればせながらアクセスacceptを受け取ることができ、再送信要求にアクセス拒否を受け取ることができます。どちらも同じ「セッション」に適用されます。

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. framed-ipv6-prefix

[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パケットで使用でき、複数回表示できます。Access-Requestパケットでは、これらのプレフィックス（ES）を好むことをNASがサーバーにヒントとして使用できますが、サーバーはヒントを尊重する必要はありません。NASはプレフィックスに対応するルートを配置すると想定されるため、サーバーが同じプレフィックスにフレーム-IPv6-Route属性を送信する必要はありません。

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-Acceptパケットでのみ使用されます。

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-PrefixにはA /128が含まれている場合があります。これは、NASがIPv6アドレスをエンドユーザーに割り当てる必要があることを意味するものではありません。これは、RFC 3162が識別子部分を処理するためのフレーム-IPV6-IDENTIFIER属性を既に定義しているためです。

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.

framed-ipv6-prefixは、A /64プレフィックスが割り当てられている場合にのみ、NASと顧客施設機器（CPE）の間のリンクに使用されているようです。A /64以下のプレフィックスが送信されると、NASがフレーム付き-IPV6-Prefix属性に存在する情報を含むルーティング広告を送信することです。

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.

CPEは、IPヘッダーのホップ制限フィールドが減少している場合、独自の使用のために委任されたプレフィックスを必要とする場合があります。その場合、委任された-IPV6-Prefix属性[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.

状態属性の内容は、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で説明されているキャッシュメカニズムは、Access-RequestパケットにメッセージAuthenticator属性が含まれていない場合、攻撃に対して脆弱です。サーバーがメッセージauthenticatorなしでリクエストを受け入れる場合、RADIUSパケットは攻撃者によって簡単に偽造される可能性があります。キャッシュエントリを強制的に有効にすることができ、キャッシュのユーティリティを無効にします。この攻撃は、セクション4の[RFC3579]の提案に従って、またはセクション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アプリケーションに存在するすべての脅威に対して脆弱です。これらの脅威の議論については、[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] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.

[RFC2865] Rigney、C.、Willens、S.、Rubens、A。、およびW. Simpson、「リモート認証ダイヤルインユーザーサービス（RADIUS）」、RFC 2865、2000年6月。

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

[RFC4818] Salowey、J。およびR. Droms、「Radius Delegated-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. Zorn、「Radius認証クライアントMIB」、RFC 2618、1999年6月。

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

[RFC2866] Rigney、C。、「Radius Accounting」、RFC 2866、2000年6月。

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

[RFC2869] Rigney、C.、Willats、W。、およびP. Calhoun、「Radius Extensions」、RFC 2869、2000年6月。

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

[RFC3162] Aboba、B.、Zorn、G。、およびD. Mitton、「Radius and 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.、Ed。、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「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.

[RFC3576] Chiba、M.、Dommety、G.、Eklund、M.、Mitton、D.、およびB. Aboba、「リモート認証のダイヤルインユーザーサービス（RADIUS）への動的認証拡張」、RFC 3576、2003年7月。

[RFC3579] Aboba, B. and P. Calhoun, "RADIUS (Remote Authentication Dial In User Service) Support For Extensible Authentication Protocol (EAP)", RFC 3579, September 2003.

[RFC3579] Aboba、B。およびP. Calhoun、「RADIUS（リモート認証ダイヤルインユーザーサービス）拡張可能な認証プロトコル（EAP）のサポート」、RFC 3579、2003年9月。

[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.、Smith、A.、Zorn、G。、およびJ. Roese、「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.、Blunk、L.、Vollbrecht、J.、Carlson、J.、およびH. Levkowetz、ed。、「拡張可能な認証プロトコル（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] Cheshire、S.、Aboba、B。、およびE. Guttman、「IPv4 Link-Localアドレスの動的構成」、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。、「RADIUS認証クライアントMIB for IPv6」、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] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、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] Forsberg、D.、Ohba、Y.、ed。、ed。、Patil、B.、Tschofenig、H。、およびA. Yegin、「ネットワークアクセスのための認証を運ぶためのプロトコル（PANA）」、進行中の作業。

Acknowledgments

謝辞

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

著者は、この文書への貢献についてグレン・ゾーンとバーナード・アボバに感謝します。

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の代替アルゴリズムは、Raghu 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.

Alan Dekokは、QuiConnect Inc.の支援を認めたいと考えています。Quiconnect Inc.は、この文書の作業の多くで雇用されていました。

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

David Nelsonは、Enterasys Networksのサポートを認めたいと考えています。EnterasysNetworksは、このドキュメントの作業の多くで雇用されていました。

Authors' Addresses

著者のアドレス

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

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

   Phone: +1.603.570.2636
   EMail: dnelson@elbrysnetworks.com

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

Alan Dekok Freeradius Server Project http://freeradius.org/

   EMail: aland@freeradius.org

Full Copyright Statement

完全な著作権声明

著作権（c）The IETF Trust（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.

このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。

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.

IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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への情報をお問い合わせください。