[要約] RFC 3576は、RADIUSに動的認証拡張を提供するための規格であり、ユーザーの認証と認可を効率的に行うことを目的としています。
Network Working Group M. Chiba
Request for Comments: 3576 G. Dommety
Category: Informational M. Eklund
Cisco Systems, Inc.
D. Mitton
Circular Logic, UnLtd.
B. Aboba
Microsoft Corporation
July 2003
Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)
リモート認証への動的な認証拡張ユーザーサービス（RADIUS）のダイヤル
Status of this Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
Abstract
概要
This document describes a currently deployed extension to the Remote Authentication Dial In User Service (RADIUS) protocol, allowing dynamic changes to a user session, as implemented by network access server products. This includes support for disconnecting users and changing authorizations applicable to a user session.
このドキュメントでは、ネットワークアクセスサーバー製品によって実装されているように、ユーザーセッションの動的な変更を可能にする、ユーザーサービス（RADIUS）プロトコルのリモート認証ダイヤルへの現在展開されている拡張機能について説明します。これには、ユーザーの切断やユーザーセッションに適用される承認の変更のサポートが含まれます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Applicability. . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . 5
1.3. Terminology. . . . . . . . . . . . . . . . . . . . . . . 5
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. Disconnect Messages (DM) . . . . . . . . . . . . . . . . 5
2.2. Change-of-Authorization Messages (CoA) . . . . . . . . . 6
2.3. Packet Format. . . . . . . . . . . . . . . . . . . . . . 7
3. Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1. Error-Cause. . . . . . . . . . . . . . . . . . . . . . . 13
3.2. Table of Attributes. . . . . . . . . . . . . . . . . . . 16
4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 20
5. Security Considerations. . . . . . . . . . . . . . . . . . . . 21
5.1. Authorization Issues . . . . . . . . . . . . . . . . . . 21
5.2. Impersonation. . . . . . . . . . . . . . . . . . . . . . 22
5.3. IPsec Usage Guidelines . . . . . . . . . . . . . . . . . 22
5.4. Replay Protection. . . . . . . . . . . . . . . . . . . . 25
6. Example Traces . . . . . . . . . . . . . . . . . . . . . . . . 26
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Normative References . . . . . . . . . . . . . . . . . . 26
7.2. Informative References . . . . . . . . . . . . . . . . . 27
8. Intellectual Property Statement. . . . . . . . . . . . . . . . 28
9. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 28
10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
11. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
The RADIUS protocol, defined in [RFC2865], does not support unsolicited messages sent from the RADIUS server to the Network Access Server (NAS).
[RFC2865]で定義されているRADIUSプロトコルは、RADIUSサーバーからネットワークアクセスサーバー（NAS）に送信された未承諾メッセージをサポートしていません。
However, there are many instances in which it is desirable for changes to be made to session characteristics, without requiring the NAS to initiate the exchange. For example, it may be desirable for administrators to be able to terminate a user session in progress. Alternatively, if the user changes authorization level, this may require that authorization attributes be added/deleted from a user session.
ただし、NASが交換を開始することを要求することなく、セッション特性に変更を加えることが望ましい多くの例があります。たとえば、管理者が進行中のユーザーセッションを終了できることが望ましい場合があります。または、ユーザーが承認レベルを変更する場合、これにはユーザーセッションから承認属性を追加/削除する必要がある場合があります。
To overcome these limitations, several vendors have implemented additional RADIUS commands in order to be able to support unsolicited messages sent from the RADIUS server to the NAS. These extended commands provide support for Disconnect and Change-of-Authorization (CoA) messages. Disconnect messages cause a user session to be terminated immediately, whereas CoA messages modify session authorization attributes such as data filters.
これらの制限を克服するために、いくつかのベンダーがRADIUSサーバーからNASに送信された未承諾メッセージをサポートできるように、追加のRADIUSコマンドを実装しています。これらの拡張コマンドは、切断および承認の変更（COA）メッセージのサポートを提供します。メッセージを切断すると、ユーザーセッションがすぐに終了しますが、COAメッセージはデータフィルターなどのセッション承認属性を変更します。
This protocol is being recommended for publication as an Informational RFC rather than as a standards-track RFC because of problems that cannot be fixed without creating incompatibilities with deployed implementations. This includes security vulnerabilities, as well as semantic ambiguities resulting from the design of the Change-of-Authorization (CoA) commands. While fixes are recommended, they cannot be made mandatory since this would be incompatible with existing implementations.
このプロトコルは、展開された実装と非互換性を作成せずに修正できない問題のため、標準トラックRFCとしてではなく、情報RFCとして公開するために推奨されています。これには、セキュリティの脆弱性と、承認の変化（COA）コマンドの設計に起因する意味的なあいまいさが含まれます。修正は推奨されますが、これは既存の実装と互換性がないため、必須にすることはできません。
Existing implementations of this protocol do not support authorization checks, so that an ISP sharing a NAS with another ISP could disconnect or change authorizations for another ISP's users. In order to remedy this problem, a "Reverse Path Forwarding" check is recommended. See Section 5.1. for details.
このプロトコルの既存の実装は、認可チェックをサポートしていないため、ISPはNASを別のISPと共有することで、別のISPユーザーの認可を切断または変更する可能性があります。この問題を改善するために、「逆パス転送」チェックが推奨されます。セクション5.1を参照してください。詳細については。
Existing implementations utilize per-packet authentication and integrity protection algorithms with known weaknesses [MD5Attack]. To provide stronger per-packet authentication and integrity protection, the use of IPsec is recommended. See Section 5.3. for details.
既存の実装では、パケットごとの認証と整合性保護アルゴリズムが既知の弱点[MD5ATTACK]を使用します。より強力なパケット認証と整合性保護を提供するには、IPSECの使用をお勧めします。セクション5.3を参照してください。詳細については。
Existing implementations lack replay protection. In order to support replay detection, it is recommended that the Event-Timestamp Attribute be added to all messages in situations where IPsec replay protection is not employed. Implementations should be configurable to silently discard messages lacking the Event-Timestamp Attribute. See Section 5.4. for details.
既存の実装には、リプレイ保護がありません。リプレイの検出をサポートするために、IPSECリプレイ保護が採用されていない状況では、すべてのメッセージにイベントタイミスタンプ属性を追加することをお勧めします。実装は、イベントタイムスタンプ属性を欠くメッセージを静かに破棄するために構成できる必要があります。セクション5.4を参照してください。詳細については。
The approach taken with CoA commands in existing implementations results in a semantic ambiguity. Existing implementations of the CoA-Request identify the affected session, as well as supply the authorization changes. Since RADIUS Attributes included within existing implementations of the CoA-Request can be used for session identification or authorization change, it may not be clear which function a given attribute is serving.
既存の実装でCOAコマンドで取られたアプローチは、セマンティックな曖昧さをもたらします。COA-Requestの既存の実装は、影響を受けるセッションを識別し、認可の変更を提供します。COA-Requestの既存の実装に含まれるRADIUS属性は、セッションの識別または承認の変更に使用できるため、特定の属性がどの機能を提供しているかは明らかではありません。
The problem does not exist within [Diameter], in which authorization change is requested by a command using Attribute Value Pairs (AVPs) solely for identification, resulting in initiation of a standard Request/Response sequence where authorization changes are supplied. As a result, in no command can Diameter AVPs have multiple potential meanings.
この問題は[直径]内に存在しません。この場合、承認の変更が識別のためだけに属性値ペア（AVP）を使用してコマンドによって要求されるため、認可変更が提供される標準要求/応答シーケンスの開始が行われます。その結果、COMMANDの直径はありませんAVPには複数の潜在的な意味があります。
Due to differences in handling change-of-authorization requests in RADIUS and Diameter, it may be difficult or impossible for a Diameter/RADIUS gateway to successfully translate existing implementations of this specification to equivalent messages in Diameter. For example, a Diameter command changing any attribute used for identification within existing CoA-Request implementations cannot be translated, since such an authorization change is impossible to carry out in existing implementations. Similarly, translation between existing implementations of Disconnect-Request or CoA-Request messages and Diameter is tricky because a Disconnect-Request or CoA-Request message will need to be translated to multiple Diameter commands.
半径と直径の承認の変化要求の処理の違いにより、直径/半径のゲートウェイがこの仕様の既存の実装を直径の等価メッセージに正常に変換することは困難または不可能かもしれません。たとえば、既存のCOA-Requestの実装内で識別に使用される属性を変更する直径コマンドを変更することは、既存の実装で実行されることは不可能であるため、翻訳することはできません。同様に、切断要求またはCOA-Requestメッセージと直径の既存の実装間の翻訳は、切断要求またはCOA-Requestメッセージを複数の直径コマンドに変換する必要があるため、難しいです。
To simplify translation between RADIUS and Diameter, a Service-Type Attribute with value "Authorize Only" can (optionally) be included within a Disconnect-Request or CoA-Request. Such a Request contains only identification attributes. A NAS supporting the "Authorize Only" Service-Type within a Disconnect-Request or CoA-Request responds with a NAK containing a Service-Type Attribute with value "Authorize Only" and an Error-Cause Attribute with value "Request Initiated". The NAS will then send an Access-Request containing a Service-Type Attribute with a value of "Authorize Only". This usage sequence is akin to what occurs in Diameter and so is more easily translated by a Diameter/RADIUS gateway.
半径と直径の間の翻訳を簡素化するために、値「Authorizeのみ」を持つサービスタイプの属性を（オプションで）切断またはCOA-Requestに含めることができます。このようなリクエストには、識別属性のみが含まれます。disconnect-requestまたはcoa-request内の「承認のみ」のサービスタイプをサポートするNASは、値「認証」を持つサービスタイプの属性を含むNAKと、値「リクエストを開始」のエラー（誤差属性属性を含むNAK）で応答します。NASは、「承認のみ」の値を持つサービスタイプの属性を含むアクセスリケストを送信します。この使用シーケンスは、直径内で発生するものに似ているため、直径/半径のゲートウェイでより簡単に翻訳されます。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. 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]に記載されているように解釈される。
This document frequently uses the following terms:
このドキュメントは、頻繁に次の用語を使用します。
Network Access Server (NAS): The device providing access to the network.
ネットワークアクセスサーバー（NAS）：ネットワークへのアクセスを提供するデバイス。
service: The NAS provides a service to the user, such as IEEE 802 or PPP.
サービス：NASは、IEEE 802やPPPなど、ユーザーにサービスを提供します。
session: Each service provided by the NAS to a user constitutes a session, with the beginning of the session defined as the point where service is first provided and the end of the session defined as the point where service is ended. A user may have multiple sessions in parallel or series if the NAS supports that.
セッション：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.
静かに破棄：これは、実装がさらに処理せずにパケットを破棄することを意味します。実装は、静かに破棄されたパケットの内容を含むエラーを記録する機能を提供し、統計カウンターにイベントを記録する必要があります。
This section describes the most commonly implemented features of Disconnect and Change-of-Authorization messages.
このセクションでは、切断および承認の変更メッセージの最も一般的に実装されている機能について説明します。
A Disconnect-Request packet is sent by the RADIUS server in order to terminate a user session on a NAS and discard all associated session context. The Disconnect-Request packet is sent to UDP port 3799, and identifies the NAS as well as the user session to be terminated by inclusion of the identification attributes described in Section 3.
NASでユーザーセッションを終了し、関連するすべてのセッションコンテキストを破棄するために、RADIUSサーバーによって切断パケットが送信されます。切断パケットはUDPポート3799に送信され、セクション3で説明されている識別属性を含めることにより、NASとユーザーセッションを識別します。
+----------+ Disconnect-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | Disconnect-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a Disconnect-Request packet sent by a RADIUS server with a Disconnect-ACK if all associated session context is discarded and the user session is no longer connected, or a Disconnect-NAK, if the NAS was unable to disconnect the session and discard all associated session context. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with value "Authorize Only" with a Disconnect-NAK; a Disconnect-ACK MUST NOT be sent. A NAS MUST respond to a Disconnect-Request including a Service-Type Attribute with an unsupported value with a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A Disconnect-ACK MAY contain the Attribute Acct-Terminate-Cause (49) [RFC2866] with the value set to 6 for Admin-Reset.
NASは、関連するすべてのセッションコンテキストが破棄され、ユーザーセッションが接続されなくなった場合、RADIUSサーバーから送信された切断サーバーによって送信された切断パケットに応答します。関連するすべてのセッションコンテキストを破棄します。NASは、disconnect-nakで「承認のみ」を持つサービスタイプの属性を含む切断要求に応答する必要があります。切断されたものを送信してはなりません。NASは、断絶型属性を含む断絶型属性を含む切断要求に応答する必要があります。値「サポートされていないサービス」を持つエラー（サポートされていないサービス」が含まれる場合があります。切断-CACKには、属性ACCTターミネート（49）[RFC2866]を含む属性が含まれ、admin-resetの値は6に設定されています。
CoA-Request packets contain information for dynamically changing session authorizations. This is typically used to change data filters. The data filters can be of either the ingress or egress kind, and are sent in addition to the identification attributes as described in section 3. The port used, and packet format (described in Section 2.3.), are the same as that for Disconnect-Request Messages.
COA-Requestパケットには、セッションの承認を動的に変更するための情報が含まれています。これは通常、データフィルターを変更するために使用されます。データフィルターは、侵入または出口のいずれかであり、セクション3で説明されている識別属性に加えて送信されます。-requestメッセージ。
The following attribute MAY be sent in a CoA-Request:
次の属性は、COA-Requestで送信できます。
Filter-ID (11) - Indicates the name of a data filter list to be applied for the session that the identification attributes map to.
Filter -ID（11） - 識別属性がマップするセッションに適用されるデータフィルターリストの名前を示します。
+----------+ CoA-Request +----------+
| | <-------------------- | |
| NAS | | RADIUS |
| | CoA-Response | Server |
| | ---------------------> | |
+----------+ +----------+
The NAS responds to a CoA-Request sent by a RADIUS server with a CoA-ACK if the NAS is able to successfully change the authorizations for the user session, or a CoA-NAK if the Request is unsuccessful. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with value "Authorize Only" with a CoA-NAK; a CoA-ACK MUST NOT be sent. A NAS MUST respond to a CoA-Request including a Service-Type Attribute with an unsupported value with a CoA-NAK; an Error-Cause Attribute with value "Unsupported Service" MAY be included.
NASは、NASがユーザーセッションの承認を正常に変更できる場合は、COA-ackを使用してRADIUSサーバーから送信されたCOA-Requestに応答します。NASは、COA-NAKで「承認のみ」を持つサービスタイプの属性を含むCOA-Requestに応答する必要があります。COA-ackを送信してはなりません。NASは、COA-NAKでサポートされていない値を持つサービスタイプの属性を含むCOA-Requestに応答する必要があります。値「サポートされていないサービス」を持つエラー（サポートされていないサービス」が含まれる場合があります。
For either Disconnect-Request or CoA-Request messages UDP port 3799 is used as the destination port. For responses, the source and destination ports are reversed. Exactly one RADIUS packet is encapsulated in the UDP Data field.
切断されたRequestまたはCOA-Requestメッセージのいずれかの場合、UDPポート3799は宛先ポートとして使用されます。応答のために、ソースと宛先ポートが逆転します。UDPデータフィールドには、正確に1つの半径パケットがカプセル化されています。
A summary of the data format is shown below. The fields are transmitted from left to right.
データ形式の概要を以下に示します。フィールドは左から右に送信されます。
The packet format consists of the fields: Code, Identifier, Length, Authenticator, and Attributes in Type:Length:Value (TLV) format. All fields hold the same meaning as those described in RADIUS [RFC2865]. The Authenticator field MUST be calculated in the same way as is specified for an Accounting-Request in [RFC2866].
パケット形式は、タイプ：長さ：値（TLV）形式のコード、識別子、長さ、認証器、および属性のフィールドで構成されています。すべてのフィールドは、半径[RFC2865]に記載されているフィールドと同じ意味を保持しています。[RFC2866]の会計要件に指定されているのと同じ方法で、認証器フィールドを計算する必要があります。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
The Code field is one octet, and identifies the type of RADIUS packet. Packets received with an invalid Code field MUST be silently discarded. RADIUS codes (decimal) for this extension are assigned as follows:
コードフィールドは1オクテットで、RADIUSパケットのタイプを識別します。無効なコードフィールドで受信したパケットは、静かに破棄する必要があります。この拡張機能のRADIUSコード（小数）は次のように割り当てられます。
40 - Disconnect-Request [RFC2882]
41 - Disconnect-ACK [RFC2882]
42 - Disconnect-NAK [RFC2882]
43 - CoA-Request [RFC2882]
44 - CoA-ACK [RFC2882]
45 - CoA-NAK [RFC2882]
Identifier
識別子
The Identifier field is one octet, and aids in matching requests and replies. The RADIUS client can detect a duplicate request if it has the same server source IP address and source UDP port and Identifier within a short span of time.
識別子フィールドは1つのオクテットであり、リクエストと返信のマッチングに役立ちます。RADIUSクライアントは、同じサーバーソースIPアドレスとソースUDPポートと識別子が短期間で識別子を持っている場合、重複した要求を検出できます。
Unlike RADIUS as defined in [RFC2865], the responsibility for retransmission of Disconnect-Request and CoA-Request messages lies with the RADIUS server. If after sending these messages, the RADIUS server does not receive a response, it will retransmit.
[RFC2865]で定義されている半径とは異なり、切断リケストおよびCOA-Requestメッセージの再送信の責任は、RADIUSサーバーにあります。これらのメッセージを送信した後、RADIUSサーバーが応答を受信しない場合、再送信されます。
The Identifier field MUST be changed whenever the content of the Attributes field changes, or whenever a valid reply has been received for a previous request. For retransmissions where the contents are identical, the Identifier MUST remain unchanged.
識別子フィールドは、属性のコンテンツがフィールドが変更されたとき、または以前のリクエストに対して有効な返信を受信するたびに変更する必要があります。内容が同一である再送信の場合、識別子は変更されないままでなければなりません。
If the RADIUS server is retransmitting a Disconnect-Request or CoA-Request to the same client as before, and the Attributes have not changed, the same Request Authenticator, Identifier and source port MUST be used. If any Attributes have changed, a new Authenticator and Identifier MUST be used.
RADIUSサーバーが以前と同じクライアントに切断リケストまたはCoA-Requestを再送信している場合、属性が変更されていない場合、同じ要求認証機、識別子、ソースポートを使用する必要があります。属性が変更された場合、新しい認証器と識別子を使用する必要があります。
Note that if the Event-Timestamp Attribute is included, it will be updated when the packet is retransmitted, changing the content of the Attributes field and requiring a new Identifier and Request Authenticator.
イベントタイムスタンプ属性が含まれている場合、パケットが再送信されたときに更新され、属性フィールドのコンテンツが変更され、新しい識別子とリクエスト認証機が必要であることに注意してください。
If the Request to a primary proxy fails, a secondary proxy must be queried, if available. Issues relating to failover algorithms are described in [AAATransport]. Since this represents a new request, a new Request Authenticator and Identifier MUST be used. However, where the RADIUS server is sending directly to the client, failover typically does not make sense, since Disconnect or CoA messages need to be delivered to the NAS where the session resides.
プライマリプロキシへのリクエストが失敗した場合、利用可能な場合は二次プロキシを照会する必要があります。フェイルオーバーアルゴリズムに関連する問題は、[aaatransport]で説明されています。これは新しいリクエストを表すため、新しいリクエスト認証器と識別子を使用する必要があります。ただし、RADIUSサーバーがクライアントに直接送信している場合、セッションが存在するNASに切断またはCOAメッセージを配信する必要があるため、フェールオーバーは通常意味がありません。
Length
長さ
The Length field is two octets. It indicates the length of the packet including the Code, Identifier, Length, Authenticator and Attribute fields. Octets outside the range of the Length field MUST be treated as padding and ignored on reception. If the packet is shorter than the Length field indicates, it MUST be silently discarded. The minimum length is 20 and the maximum length is 4096.
長さフィールドは2オクテットです。コード、識別子、長さ、認証器、属性フィールドを含むパケットの長さを示します。長さフィールドの範囲外のオクテットは、パディングとして扱われ、レセプションで無視する必要があります。パケットが長さのフィールドが示すよりも短い場合、静かに廃棄する必要があります。最小長は20で、最大長は4096です。
Authenticator
認証者
The Authenticator field is sixteen (16) octets. The most significant octet is transmitted first. This value is used to authenticate the messages between the RADIUS server and client.
Authenticatorフィールドは16個のオクテットです。最も重要なオクテットが最初に送信されます。この値は、RADIUSサーバーとクライアント間のメッセージを認証するために使用されます。
Request Authenticator
Authenticatorをリクエストします
In Request packets, the Authenticator value is a 16 octet MD5 [RFC1321] checksum, called the Request Authenticator. The Request Authenticator is calculated the same way as for an Accounting-Request, specified in [RFC2866].
リクエストパケットでは、Authenticator値は16 Octet MD5 [RFC1321]チェックサムで、リクエストAuthenticatorと呼ばれます。リクエスト認証器は、[RFC2866]で指定された会計要因と同じ方法で計算されます。
Note that the Request Authenticator of a Disconnect or CoA-Request cannot be done the same way as the Request Authenticator of a RADIUS Access-Request, because there is no User-Password Attribute in a Disconnect-Request or CoA-Request.
切断またはCOA-Requestのリクエスト認証者は、Radius Access-Requestのリクエスト認証者と同じ方法で実行できないことに注意してください。
Response Authenticator
応答認証器
The Authenticator field in a Response packet (e.g. Disconnect-ACK, Disconnect-NAK, CoA-ACK, or CoA-NAK) is called the Response Authenticator, and contains a one-way MD5 hash calculated over a stream of octets consisting of the Code, Identifier, Length, the Request Authenticator field from the packet being replied to, and the response Attributes if any, followed by the shared secret. The resulting 16 octet MD5 hash value is stored in the Authenticator field of the Response packet.
応答パケットの認証装置フィールド（例：切断、切断、COA-ack、またはCOA-NAK）は、応答認証器と呼ばれ、コードからなるオクテットのストリーム上で計算された一方向MD5ハッシュを含みます、識別子、長さ、回答されているパケットからのリクエスト認証器フィールド、および応答属性がある場合は、共有秘密が続きます。結果の16 Octet MD5ハッシュ値は、応答パケットの認証フィールドに保存されます。
Administrative note: As noted in [RFC2865] Section 3, the secret (password shared between the client and the RADIUS server) SHOULD be at least as large and unguessable as a well-chosen password. RADIUS clients MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that requests can be proxied.
管理ノート：[RFC2865]セクション3に記載されているように、シークレット（クライアントとRADIUSサーバーの間で共有されたパスワード）は、少なくとも適切に選択されたパスワードと同じくらい大きく、装備できません。RADIUSクライアントは、RADIUS UDPパケットのソースIPアドレスを使用して、使用する共有シークレットを決定する必要があります。そうすることで、リクエストをプロにすることができます。
Attributes
属性
In Disconnect and CoA-Request messages, all Attributes are treated as mandatory. A NAS MUST respond to a CoA-Request containing one or more unsupported Attributes or Attribute values with a CoA-NAK; a Disconnect-Request containing one or more unsupported Attributes or Attribute values MUST be answered with a Disconnect-NAK. State changes resulting from a CoA-Request MUST be atomic: if the Request is successful, a CoA-ACK is sent, and all requested authorization changes MUST be made. If the CoA-Request is unsuccessful, a CoA-NAK MUST be sent, and the requested authorization changes MUST NOT be made. Similarly, a state change MUST NOT occur as a result of an unsuccessful Disconnect-Request; here a Disconnect-NAK MUST be sent.
切断およびCOA-Requestメッセージでは、すべての属性が必須として扱われます。NASは、1つ以上のサポートされていない属性または属性値をCOA-NAKで含むCOA-Requestに応答する必要があります。1つまたは複数のサポートされていない属性または属性値を含む切断要求は、切断されたもので回答する必要があります。COA-Requestから生じる状態の変更は原子でなければなりません。リクエストが成功した場合、COA-ackが送信され、すべての要求された承認の変更を行う必要があります。COA-Requestが失敗した場合、COA-NAKを送信する必要があり、要求された承認の変更を行う必要はありません。同様に、状態の変更が失敗した結果として発生してはなりません。ここでは、切断されたものを送信する必要があります。
Since within this specification attributes may be used for identification, authorization or other purposes, even if a NAS implements an attribute for use with RADIUS authentication and accounting, it may not support inclusion of that attribute within Disconnect-Request or CoA-Request messages, given the difference in attribute semantics. This is true even for attributes specified within [RFC2865], [RFC2868], [RFC2869] or [RFC3162] as allowable within Access-Accept messages.
この仕様内では、識別、承認、またはその他の目的に属性が使用される可能性があるため、NASがRADIUS認証と会計で使用する属性を実装していても、その属性の含有を、disconnect-requestまたはcoa-requestメッセージに含めることをサポートしない場合があります。属性セマンティクスの違い。これは、[RFC2865]、[RFC2868]、[RFC2869]、または[RFC3162]内で指定された属性にも当てはまります。
As a result, attributes beyond those specified in Section 3.2. SHOULD NOT be included within Disconnect or CoA messages since this could produce unpredictable results.
その結果、セクション3.2で指定されている属性を超えた属性。これにより予測不可能な結果が生じる可能性があるため、切断メッセージまたはCOAメッセージに含めるべきではありません。
When using a forwarding proxy, the proxy must be able to alter the packet as it passes through in each direction. When the proxy forwards a Disconnect or CoA-Request, it MAY add a Proxy-State Attribute, and when the proxy forwards a response, it MUST remove its Proxy-State Attribute if it added one. Proxy-State is always added or removed after any other Proxy-States, but no other assumptions regarding its location within the list of Attributes can be made. Since Disconnect and CoA responses are authenticated on the entire packet contents, the stripping of the Proxy-State Attribute invalidates the integrity check - so the proxy needs to recompute it. A forwarding proxy MUST NOT modify existing Proxy-State, State, or Class Attributes present in the packet.
転送プロキシを使用する場合、プロキシは各方向に通過するときにパケットを変更できる必要があります。プロキシが切断またはCoA-Requestを転送すると、プロキシ状態属性を追加する可能性があり、プロキシが応答を転送する場合、追加した場合はプロキシステート属性を削除する必要があります。プロキシステートは、他のプロキシステートの後に常に追加または削除されますが、属性リスト内のその場所に関する他の仮定を作成することはできません。切断およびCOA応答はパケットコンテンツ全体で認証されるため、プロキシステート属性のストリッピングは整合性チェックを無効にします。そのため、プロキシはそれを再計算する必要があります。転送プロキシは、パケットに存在する既存のプロキシ状態、状態、またはクラスの属性を変更してはなりません。
If there are any Proxy-State Attributes in a Disconnect-Request or CoA-Request received from the server, the forwarding proxy MUST include those Proxy-State Attributes in its response to the server. The forwarding proxy MAY include the Proxy-State Attributes in the Disconnect-Request or CoA-Request when it forwards the request, or it MAY omit them in the forwarded request. If the forwarding proxy omits the Proxy-State Attributes in the request, it MUST attach them to the response before sending it to the server.
サーバーから受信した切断リケストまたはCOA-Requestにプロキシステート属性がある場合、転送プロキシには、サーバーへの応答にそれらのプロキシ状態属性を含める必要があります。転送プロキシには、リクエストを転送したときに、切断リケストまたはCOA-Requestにプロキシステート属性を含めるか、転送されたリクエストでそれらを省略する場合があります。転送プロキシがリクエスト内のプロキシ状態属性を省略した場合、サーバーに送信する前に応答に添付する必要があります。
In Disconnect-Request and CoA-Request packets, certain attributes are used to uniquely identify the NAS as well as a user session on the NAS. All NAS identification attributes included in a Request message MUST match in order for a Disconnect-Request or CoA-Request to be successful; otherwise a Disconnect-NAK or CoA-NAK SHOULD be sent. For session identification attributes, the User-Name and Acct-Session-Id Attributes, if included, MUST match in order for a Disconnect-Request or CoA-Request to be successful; other session identification attributes SHOULD match. Where a mismatch of session identification attributes is detected, a Disconnect-NAK or CoA-NAK SHOULD be sent. The ability to use NAS or session identification attributes to map to unique/multiple sessions is beyond the scope of this document. Identification attributes include NAS and session identification attributes, as described below.
切断-RequestおよびCOA-Requestパケットでは、特定の属性を使用して、NASとNASのユーザーセッションを一意に識別します。リクエストメッセージに含まれるすべてのNAS識別属性は、切断リケストまたはCOA-Requestが成功するために一致する必要があります。それ以外の場合は、切断されたNAKまたはCOA-NAKを送信する必要があります。セッション識別属性の場合、ユーザー名とacct-session-id属性が含まれている場合は、切断リケストまたはCOA-Requestが成功するために一致する必要があります。他のセッション識別属性は一致する必要があります。セッション識別属性の不一致が検出される場合、切断されたNAKまたはCOA-NAKを送信する必要があります。NASまたはセッション識別属性を使用して、一意/複数のセッションにマップする機能は、このドキュメントの範囲を超えています。識別属性には、以下で説明するように、NASおよびセッション識別属性が含まれます。
NAS identification attributes
NAS識別属性
Attribute # Reference Description
--------- --- --------- -----------
NAS-IP-Address 4 [RFC2865] The IPv4 address of the NAS.
NAS-Identifier 32 [RFC2865] String identifying the NAS.
NAS-IPv6-Address 95 [RFC3162] The IPv6 address of the NAS.
Session identification attributes
セッション識別属性
Attribute # Reference Description
--------- --- --------- -----------
User-Name 1 [RFC2865] The name of the user
associated with the session.
NAS-Port 5 [RFC2865] The port on which the
session is terminated.
Framed-IP-Address 8 [RFC2865] The IPv4 address associated
with the session.
Called-Station-Id 30 [RFC2865] The link address to which
the session is connected.
Calling-Station-Id 31 [RFC2865] The link address from which
the session is connected.
Acct-Session-Id 44 [RFC2866] The identifier uniquely
identifying the session
on the NAS.
Acct-Multi-Session-Id 50 [RFC2866] The identifier uniquely
identifying related sessions.
NAS-Port-Type 61 [RFC2865] The type of port used.
NAS-Port-Id 87 [RFC2869] String identifying the port
where the session is.
Originating-Line-Info 94 [NASREQ] Provides information on the
characteristics of the line
from which a session
originated.
Framed-Interface-Id 96 [RFC3162] The IPv6 Interface Identifier
associated with the session;
always sent with
Framed-IPv6-Prefix.
Framed-IPv6-Prefix 97 [RFC3162] The IPv6 prefix associated
with the session, always sent
with Framed-Interface-Id.
To address security concerns described in Section 5.1., the User-Name Attribute SHOULD be present in Disconnect-Request or CoA-Request packets; one or more additional session identification attributes MAY also be present. To address security concerns described in Section 5.2., one or more of the NAS-IP-Address or NAS-IPv6-Address Attributes SHOULD be present in Disconnect-Request or CoA-Request packets; the NAS-Identifier Attribute MAY be present in addition.
セクション5.1で説明されているセキュリティの懸念に対処するには、ユーザー名属性を切断またはCOA-Requestパケットに存在する必要があります。1つ以上の追加セッション識別属性も存在する場合があります。セクション5.2。で説明されているセキュリティの懸念に対処するには、NAS-IP-AddressまたはNAS-IPV6-Addressの属性の1つ以上が、切断リケストまたはCOA-Requestパケットに存在する必要があります。さらに、Nas-Identifier属性が存在する場合があります。
If one or more authorization changes specified in a CoA-Request cannot be carried out, or if one or more attributes or attribute-values is unsupported, a CoA-NAK MUST be sent. Similarly, if there are one or more unsupported attributes or attribute values in a Disconnect-Request, a Disconnect-NAK MUST be sent.
COA-Requestで指定された1つ以上の許可変更を実行できない場合、または1つ以上の属性または属性値がサポートされていない場合は、COA-NAKを送信する必要があります。同様に、切断要求に1つ以上のサポートされていない属性または属性値がある場合、切断されたものを送信する必要があります。
Where a Service-Type Attribute with value "Authorize Only" is included within a CoA-Request or Disconnect-Request, attributes representing an authorization change MUST NOT be included; only identification attributes are permitted. If attributes other than NAS or session identification attributes are included in such a CoA-Request, implementations MUST send a CoA-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included. Similarly, if attributes other than NAS or session identification attributes are included in such a Disconnect-Request, implementations MUST send a Disconnect-NAK; an Error-Cause Attribute with value "Unsupported Attribute" MAY be included.
値「承認のみ」を持つサービスタイプの属性がCOA-Requestまたは切断リケスト内に含まれる場合、承認の変更を表す属性を含める必要はありません。識別属性のみが許可されます。NASまたはセッション識別属性以外の属性がこのようなCOA-Requestに含まれている場合、実装はCOA-NAKを送信する必要があります。値「サポートされていない属性」を持つエラー（サポートされていない属性」が含まれる場合があります。同様に、NASまたはセッション識別属性以外の属性がこのような切断要求に含まれている場合、実装は切断されたものを送信する必要があります。値「サポートされていない属性」を持つエラー（サポートされていない属性」が含まれる場合があります。
Description
説明
It is possible that the NAS cannot honor Disconnect-Request or CoA-Request messages for some reason. The Error-Cause Attribute provides more detail on the cause of the problem. It MAY be included within Disconnect-ACK, Disconnect-NAK and CoA-NAK messages.
何らかの理由で、NASが切断された要求またはCOA-Requestメッセージを尊重できない可能性があります。エラー原因属性は、問題の原因に関する詳細を提供します。それは、切断された、切断された、disconnect-nak、およびcoa-nakメッセージに含まれる場合があります。
A summary of the Error-Cause Attribute format is shown below. The fields are transmitted from left to right.
エラー原因属性形式の概要を以下に示します。フィールドは左から右に送信されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
101 for Error-Cause
エラー原因については101
Length
長さ
6
6
Value
価値
The Value field is four octets, containing an integer specifying the cause of the error. Values 0-199 and 300-399 are reserved. Values 200-299 represent successful completion, so that these values may only be sent within Disconnect-ACK or CoA-ACK message and MUST NOT be sent within a Disconnect-NAK or CoA-NAK. Values 400-499 represent fatal errors committed by the RADIUS server, so that they MAY be sent within CoA-NAK or Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Values 500-599 represent fatal errors occurring on a NAS or RADIUS proxy, so that they MAY be sent within CoA-NAK and Disconnect-NAK messages, and MUST NOT be sent within CoA-ACK or Disconnect-ACK messages. Error-Cause values SHOULD be logged by the RADIUS server. Error-Code values (expressed in decimal) include:
値フィールドは4オクテットで、エラーの原因を指定する整数が含まれています。値0-199および300-399は予約されています。値200-299は正常な完了を表します。そのため、これらの値はdisconnect-ackまたはcoa-ackメッセージ内でのみ送信され、disconnect-nakまたはcoa-nak内で送信されないようにします。値400-499は、RADIUSサーバーが犯した致命的なエラーを表します。これにより、COA-NAKまたは切断されたNAKメッセージ内で送信され、COA-CACKまたは切断されるメッセージ内で送信してはなりません。値500-599は、NASまたはRADIUSプロキシで発生する致命的なエラーを表し、COA-NAK内で送信してNAKメッセージを切断することができ、COA-ackまたはdisconnect-quackメッセージ内で送信してはなりません。RADIUSサーバーによってエラー原因値を記録する必要があります。エラーコード値（小数で表される）は次のとおりです。
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
"Residual Session Context Removed" is sent in response to a Disconnect-Request if the user session is no longer active, but residual session context was found and successfully removed. This value is only sent within a Disconnect-ACK and MUST NOT be sent within a CoA-ACK, Disconnect-NAK or CoA-NAK.
ユーザーセッションがアクティブではなくなったが、残留セッションのコンテキストが見つかり、正常に削除された場合、「残留セッションコンテキスト削除」は切断要求に応じて送信されます。この値は、切断済みのみ内で送信され、COA-ack、disconnect-nak、またはcoa-nak内で送信してはなりません。
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification.
「無効なEAPパケット（無視）」は、この仕様の実装によって送信されてはならない致命的ではないエラーです。
"Unsupported Attribute" is a fatal error sent if a Request contains an attribute (such as a Vendor-Specific or EAP-Message Attribute) that is not supported.
「サポートされていない属性」は、リクエストにサポートされていない属性（ベンダー固有の属性やEAPメッセージ属性など）が含まれている場合に送信される致命的なエラーです。
"Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request.
「属性の欠落」は、リクエストから重要な属性（NASやセッション識別属性など）が欠落している場合に送信される致命的なエラーです。
"NAS Identification Mismatch" is a fatal error sent if one or more NAS identification attributes (see Section 3.) do not match the identity of the NAS receiving the Request.
「NAS識別の不一致」は、1つ以上のNAS識別属性（セクション3を参照）が要求を受け取ったNASのIDと一致しない場合に送信される致命的なエラーです。
"Invalid Request" is a fatal error sent if some other aspect of the Request is invalid, such as if one or more attributes (such as EAP-Message Attribute(s)) are not formatted properly.
「無効な要求」は、1つ以上の属性（EAPメッセージ属性など）が適切にフォーマットされていない場合など、リクエストの他の側面が無効である場合に送信される致命的なエラーです。
"Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value.
「サポートされていないサービス」は、リクエストに含まれるサービスタイプの属性が無効またはサポートされていない値で送信された場合に送信される致命的なエラーです。
"Unsupported Extension" is a fatal error sent due to lack of support for an extension such as Disconnect and/or CoA messages. This will typically be sent by a proxy receiving an ICMP port unreachable message after attempting to forward a Request to the NAS.
「サポートされていない拡張機能」は、切断やCOAメッセージなどの拡張機能のサポートがないために送信される致命的なエラーです。これは通常、NASにリクエストを転送しようとした後、ICMPポートの到達不可能なメッセージを受信するプロキシによって送信されます。
"Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session.
「管理上禁止」とは、指定されたセッションのリクエストメッセージの敬意を禁止するようにNASが構成されている場合、致命的なエラーが送信されます。
"Request Not Routable" is a fatal error which MAY be sent by a RADIUS proxy and MUST NOT be sent by a NAS. It indicates that the RADIUS proxy was unable to determine how to route the Request to the NAS. For example, this can occur if the required entries are not present in the proxy's realm routing table.
「リクエストはルーティングできない」とは、RADIUSプロキシによって送信される可能性のある致命的なエラーであり、NASによって送信されてはなりません。これは、RADIUSプロキシがNASにリクエストをルーティングする方法を決定できなかったことを示しています。たとえば、これは、必要なエントリがプロキシのレルムルーティングテーブルに存在しない場合に発生する可能性があります。
"Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS.
「セッションのコンテキストが見つかりません」は、要求で特定されたセッションコンテキストがNASに存在しない場合に送信される致命的なエラーです。
"Session Context Not Removable" is a fatal error sent in response to a Disconnect-Request if the NAS was able to locate the session context, but could not remove it for some reason. It MUST NOT be sent within a CoA-ACK, CoA-NAK or Disconnect-ACK, only within a Disconnect-NAK.
「セッションのコンテキストが取り外しできない」は、NASがセッションコンテキストを見つけることができたが、何らかの理由でそれを削除できなかった場合、切断要求に応じて送信された致命的なエラーです。COA-ack、coa-nak、またはdisconnect-fack内でのみ送信してはなりません。
"Other Proxy Processing Error" is a fatal error sent in response to a Request that could not be processed by a proxy, for reasons other than routing.
「その他のプロキシ処理エラー」は、ルーティング以外の理由で、プロキシによって処理できないリクエストに応じて送信された致命的なエラーです。
"Resources Unavailable" is a fatal error sent when a Request could not be honored due to lack of available NAS resources (memory, non-volatile storage, etc.).
「リソースは利用できない」とは、利用可能なNASリソース（メモリ、不揮発性ストレージなど）が不足しているためにリクエストを尊重できなかった場合に致命的なエラーが送信されます。
"Request Initiated" is a fatal error sent in response to a Request including a Service-Type Attribute with a value of "Authorize Only". It indicates that the Disconnect-Request or CoA-Request has not been honored, but that a RADIUS Access-Request including a Service-Type Attribute with value "Authorize Only" is being sent to the RADIUS server.
「リクエスト開始」は、「承認のみ」の値を持つサービスタイプの属性を含むリクエストに応じて送信された致命的なエラーです。これは、disconnect-requestまたはCOA-Requestが尊重されていないことを示していますが、値「Authorizeのみ」を持つサービスタイプの属性を含むRADIUSアクセスリケストがRADIUSサーバーに送信されていることを示しています。
The following table provides a guide to which attributes may be found in which packets, and in what quantity.
次の表には、どの属性がどのパケットで、どの量の属性が見つかるかについてのガイドを示します。
Change-of-Authorization Messages
承認メッセージの変更
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 7 Framed-Protocol [Note 3]
0-1 0 0 8 Framed-IP-Address [Note 1]
0-1 0 0 9 Framed-IP-Netmask [Note 3]
0-1 0 0 10 Framed-Routing [Note 3]
0+ 0 0 11 Filter-ID [Note 3]
0-1 0 0 12 Framed-MTU [Note 3]
0+ 0 0 13 Framed-Compression [Note 3]
0+ 0 0 14 Login-IP-Host [Note 3]
0-1 0 0 15 Login-Service [Note 3]
0-1 0 0 16 Login-TCP-Port [Note 3]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0 0 19 Callback-Number [Note 3]
0-1 0 0 20 Callback-Id [Note 3]
0+ 0 0 22 Framed-Route [Note 3]
0-1 0 0 23 Framed-IPX-Network [Note 3]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 3]
0+ 0 0 26 Vendor-Specific [Note 3]
0-1 0 0 27 Session-Timeout [Note 3]
0-1 0 0 28 Idle-Timeout [Note 3]
0-1 0 0 29 Termination-Action [Note 3]
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
0-1 0 0 34 Login-LAT-Service [Note 3]
0-1 0 0 35 Login-LAT-Node [Note 3]
0-1 0 0 36 Login-LAT-Group [Note 3]
0-1 0 0 37 Framed-AppleTalk-Link [Note 3]
0+ 0 0 38 Framed-AppleTalk-Network [Note 3]
0-1 0 0 39 Framed-AppleTalk-Zone [Note 3]
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 62 Port-Limit [Note 3]
0-1 0 0 63 Login-LAT-Port [Note 3]
0+ 0 0 64 Tunnel-Type [Note 5]
0+ 0 0 65 Tunnel-Medium-Type [Note 5]
0+ 0 0 66 Tunnel-Client-Endpoint [Note 5]
0+ 0 0 67 Tunnel-Server-Endpoint [Note 5]
0+ 0 0 69 Tunnel-Password [Note 5]
0-1 0 0 71 ARAP-Features [Note 3]
0-1 0 0 72 ARAP-Zone-Access [Note 3]
0+ 0 0 78 Configuration-Token [Note 3]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0+ 0 0 81 Tunnel-Private-Group-ID [Note 5]
0+ 0 0 82 Tunnel-Assignment-ID [Note 5]
0+ 0 0 83 Tunnel-Preference [Note 5]
0-1 0 0 85 Acct-Interim-Interval [Note 3]
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 88 Framed-Pool [Note 3]
0+ 0 0 90 Tunnel-Client-Auth-ID [Note 5]
0+ 0 0 91 Tunnel-Server-Auth-ID [Note 5]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0+ 0 0 98 Login-IPv6-Host [Note 3]
0+ 0 0 99 Framed-IPv6-Route [Note 3]
0-1 0 0 100 Framed-IPv6-Pool [Note 3]
0 0 0+ 101 Error-Cause
Request ACK NAK # Attribute
Disconnect Messages
メッセージを切断します
Request ACK NAK # Attribute
0-1 0 0 1 User-Name [Note 1]
0-1 0 0 4 NAS-IP-Address [Note 1]
0-1 0 0 5 NAS-Port [Note 1]
0-1 0 0-1 6 Service-Type [Note 6]
0-1 0 0 8 Framed-IP-Address [Note 1]
0+ 0 0 18 Reply-Message [Note 2]
0-1 0-1 0-1 24 State [Note 7]
0+ 0 0 25 Class [Note 4]
0+ 0 0 26 Vendor-Specific
0-1 0 0 30 Called-Station-Id [Note 1]
0-1 0 0 31 Calling-Station-Id [Note 1]
0-1 0 0 32 NAS-Identifier [Note 1]
0+ 0+ 0+ 33 Proxy-State
Request ACK NAK # Attribute
Request ACK NAK # Attribute
0-1 0 0 44 Acct-Session-Id [Note 1]
0-1 0-1 0 49 Acct-Terminate-Cause
0-1 0 0 50 Acct-Multi-Session-Id [Note 1]
0-1 0-1 0-1 55 Event-Timestamp
0-1 0 0 61 NAS-Port-Type [Note 1]
0+ 0-1 0 79 EAP-Message [Note 2]
0-1 0-1 0-1 80 Message-Authenticator
0-1 0 0 87 NAS-Port-Id [Note 1]
0-1 0 0 94 Originating-Line-Info [Note 1]
0-1 0 0 95 NAS-IPv6-Address [Note 1]
0-1 0 0 96 Framed-Interface-Id [Note 1]
0+ 0 0 97 Framed-IPv6-Prefix [Note 1]
0 0+ 0+ 101 Error-Cause
Request ACK NAK # Attribute
[Note 1] Where NAS or session identification attributes are included in Disconnect-Request or CoA-Request messages, they are used for identification purposes only. These attributes MUST NOT be used for purposes other than identification (e.g. within CoA-Request messages to request authorization changes).
[注1] NASまたはセッション識別属性が切断要件またはCOA-Requestメッセージに含まれている場合、識別目的でのみ使用されます。これらの属性は、識別以外の目的に使用してはなりません（たとえば、COA-Requestメッセージ内で認証の変更を要求するため）。
[Note 2] The Reply-Message Attribute is used to present a displayable message to the user. The message is only displayed as a result of a successful Disconnect-Request or CoA-Request (where a Disconnect-ACK or CoA-ACK is subsequently sent). Where EAP is used for authentication, an EAP-Message/Notification-Request Attribute is sent instead, and Disconnect-ACK or CoA-ACK messages contain an EAP-Message/Notification-Response Attribute.
[注2] Reply-Message属性は、ユーザーに表示可能なメッセージを提示するために使用されます。このメッセージは、切断リケストまたはCOA-Requestが成功した結果としてのみ表示されます（その後、切断されたcoCACKまたはCOA-ackが送信されます）。EAPが認証に使用される場合、代わりにEAPメッセージ/通知と通知のリクエスト属性が送信され、切断またはCOA-ackメッセージには、EAPメッセージ/通知 - 応答属性が含まれています。
[Note 3] When included within a CoA-Request, these attributes represent an authorization change request. When one of these attributes is omitted from a CoA-Request, the NAS assumes that the attribute value is to remain unchanged. Attributes included in a CoA-Request replace all existing value(s) of the same attribute(s).
[注3] COA-Requestに含まれる場合、これらの属性は認証変更リクエストを表します。これらの属性のいずれかがCOA-Requestから省略されると、NASは属性値が変更されていないと想定しています。COA-Requestに含まれる属性は、同じ属性のすべての既存の値を置き換えます。
[Note 4] When included within a successful Disconnect-Request (where a Disconnect-ACK is subsequently sent), the Class Attribute SHOULD be sent unmodified by the client to the accounting server in the Accounting Stop packet. If the Disconnect-Request is unsuccessful, then the Class Attribute is not processed.
[注4]成功した切断要求（その後の切断-CACKが送信される場合）に含まれる場合、クラス属性は、会計停止パケットの会計サーバーにクライアントによって修正されずに送信される必要があります。切断リケストが失敗した場合、クラス属性は処理されません。
[Note 5] When included within a CoA-Request, these attributes represent an authorization change request. Where tunnel attribute(s) are sent within a successful CoA-Request, all existing tunnel attributes are removed and replaced by the new attribute(s).
[注5] COA-Requestに含まれる場合、これらの属性は認証変更リクエストを表します。トンネル属性が成功したCOA-Request内で送信される場合、既存のトンネル属性はすべて削除され、新しい属性に置き換えられます。
[Note 6] When included within a Disconnect-Request or CoA-Request, a Service-Type Attribute with value "Authorize Only" indicates that the Request only contains NAS and session identification attributes, and that the NAS should attempt reauthorization by sending an Access-Request with a Service-Type Attribute with value "Authorize Only". This enables a usage model akin to that supported in Diameter, thus easing translation between the two protocols. Support for the Service-Type Attribute is optional within CoA-Request and Disconnect-Request messages; where it is not included, the Request message may contain both identification and authorization attributes. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a Disconnect-Request MUST respond with a Disconnect-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included. A NAS that does not support the Service-Type Attribute with the value "Authorize Only" within a CoA-Request MUST respond with a CoA-NAK including no Service-Type Attribute; an Error-Cause Attribute with value "Unsupported Service" MAY be included.
[注6] disconnect-requestまたはcoa-requestに含まれる場合、値「Authorizeのみ」を持つサービスタイプの属性は、要求にNASとセッション識別属性のみが含まれ、NASはアクセスを送信して再承認を試みる必要があることを示します。 - 値「authorizeのみ」を持つサービスタイプの属性を使用したリクエスト。これにより、直径がサポートされるものと同様の使用モデルが可能になり、2つのプロトコル間の翻訳が緩和されます。Service-Type属性のサポートは、COA-Requestおよび切断要求メッセージ内でオプションです。含まれていない場合、リクエストメッセージには識別属性と承認属性の両方が含まれる場合があります。disconnect-request内の値「Authorizeのみ」を持つサービスタイプの属性をサポートしていないNASは、サービスタイプの属性を含む切断されたもので応答する必要があります。値「サポートされていないサービス」を持つエラー（サポートされていないサービス」が含まれる場合があります。COA-Request内の値「Authorizeのみ」を持つサービスタイプの属性をサポートしていないNASは、サービスタイプの属性を含むCOA-NAKで応答する必要があります。値「サポートされていないサービス」を持つエラー（サポートされていないサービス」が含まれる場合があります。
A NAS supporting the "Authorize Only" Service-Type value within Disconnect-Request or CoA-Request messages MUST respond with a Disconnect-NAK or CoA-NAK respectively, containing a Service-Type Attribute with value "Authorize Only", and an Error-Cause Attribute with value "Request Initiated". The NAS then sends an Access-Request to the RADIUS server with a Service-Type Attribute with value "Authorize Only". This Access-Request SHOULD contain the NAS attributes from the Disconnect or CoA-Request, as well as the session attributes from the Request legal for inclusion in an Access-Request as specified in [RFC2865], [RFC2868], [RFC2869] and [RFC3162]. As noted in [RFC2869] Section 5.19, a Message-Authenticator attribute SHOULD be included in an Access-Request that does not contain a User-Password, CHAP-Password, ARAP-Password or EAP-Message Attribute. The RADIUS server should send back an Access-Accept to (re-)authorize the session or an Access-Reject to refuse to (re-)authorize it.
disconnect-requestまたはcoa-requestメッセージ内の「承認のみ」のサービスタイプの値をサポートするNASは、それぞれ「承認のみ」を持つサービスタイプの属性を含むdisconnect-nakまたはcoa-nakでそれぞれ応答する必要があります。 - 値「リクエストが開始された」を備えた属性。次に、NASは、value型属性を持つ「authorizeのみ」を持つサービスタイプの属性を持つRADIUSサーバーにアクセスリケストを送信します。このAccess-Requestには、[RFC2865]、[RFC2868]、[RFC2869]、[RFC2869]、[RFC2869]、[RFC2869]に指定されているアクセスリケストに含めるための合法的なリクエストのセッション属性と同様に、切断またはCOA-RequestのNAS属性を含める必要があります。RFC3162]。[RFC2869]セクション5.19に記載されているように、メッセージauthenticatorの属性は、ユーザーパスワード、チャップパスワード、ARAPパスワード、またはEAPメッセージ属性を含まないアクセス要求に含める必要があります。RADIUSサーバーは、セッションを（再）承認するためにアクセスacceptを送り返すか、それを拒否するためのアクセス拒否を（再）承認する必要があります。
[Note 7] The State Attribute is available to be sent by the RADIUS server to the NAS in a Disconnect-Request or CoA-Request message and MUST be sent unmodified from the NAS to the RADIUS server in a subsequent ACK or NAK message. If a Service-Type Attribute with value "Authorize Only" is included in a Disconnect-Request or CoA-Request along with a State Attribute, then the State Attribute MUST be sent unmodified from the NAS to the RADIUS server in the resulting Access-Request sent to the RADIUS server, if any. The State Attribute is also available to be sent by the RADIUS server to the NAS in a CoA-Request that also includes a Termination-Action Attribute with the value of RADIUS-Request. If the client 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. In either usage, the client MUST NOT interpret the Attribute locally. A Disconnect-Request or CoA-Request packet must have only zero or one State Attribute. Usage of the State Attribute is implementation dependent. If the RADIUS server does not recognize the State Attribute in the Access-Request, then it MUST send an Access-Reject.
[注7] State属性は、RADIUSサーバーからdisconnect-RequestまたはCoA-RequestメッセージでNASに送信でき、その後のACKまたはNAKメッセージでNASからRADIUSサーバーに修正されていないように送信する必要があります。値「Authorizeのみ」を持つサービスタイプの属性が、状態属性とともにdisconnect-requestまたはcoa-requestに含まれている場合、状態属性は、結果のアクセスリケストでNASからRADIUSサーバーに修正されていないと送信する必要があります。ある場合はRADIUSサーバーに送信されます。状態属性は、RADIUSサーバーからRADIUS-Requestの値を持つ終端アクション属性も含むCOA-RequestでNASに送信することもできます。クライアントが、現在のセッションの終了時に新しいアクセスリケストを送信して終了アクションを実行する場合、そのアクセスリケストに変更されていない状態属性を含める必要があります。どちらの使用法でも、クライアントは属性をローカルに解釈してはなりません。切断 - レクエストまたはCOA-Requestパケットには、ゼロまたは1つの状態属性のみが必要です。状態属性の使用は実装に依存します。RADIUSサーバーがAccess-Requestの状態属性を認識していない場合、Access-Rejectを送信する必要があります。
The following table defines the meaning of the above table entries.
次の表は、上記のテーブルエントリの意味を定義しています。
0 This attribute MUST NOT be present in packet. 0+ Zero or more instances of this attribute MAY be present in packet. 0-1 Zero or one instance of this attribute MAY be present in packet. 1 Exactly one instance of this attribute MUST be present in packet.
0この属性はパケットに存在してはなりません。この属性の0ゼロ以上のインスタンスがパケットに存在する場合があります。この属性の0-1インスタンスまたは1つのインスタンスがパケットに存在する場合があります。1この属性の1つのインスタンスがパケットに存在する必要があります。
This document uses the RADIUS [RFC2865] namespace, see <http://www.iana.org/assignments/radius-types>. There are six updates for the section: RADIUS Packet Type Codes. These Packet Types are allocated in [RADIANA]:
このドキュメントでは、radius [rfc2865] namespaceを使用しています。セクションには、RADIUSパケットタイプコードの6つの更新があります。これらのパケットタイプは[Radiana]に割り当てられています。
40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK 43 - CoA-Request 44 - CoA-ACK 45 - CoA-NAK
40 -disconnect -request 41 -disconnect -ack 42 -disconnect -nak 43 -coa -request 44 -coa -ack 45 -coa -nak
Allocation of a new Service-Type value for "Authorize Only" is requested. This document also uses the UDP [RFC768] namespace, see <http://www.iana.org/assignments/port-numbers>. The authors request a port assignment from the Registered ports range. Finally, this specification allocates the Error-Cause Attribute (101) with the following decimal values:
「Authorizeのみ」に新しいサービスタイプの値の割り当てが要求されます。このドキュメントでは、udp [rfc768] namespaceも使用しています。著者は、登録されたポートの範囲からポート割り当てを要求します。最後に、この仕様では、次の小数値でエラー原因属性（101）が割り当てられます。
# Value
--- -----
201 Residual Session Context Removed
202 Invalid EAP Packet (Ignored)
401 Unsupported Attribute
402 Missing Attribute
403 NAS Identification Mismatch
404 Invalid Request
405 Unsupported Service
406 Unsupported Extension
501 Administratively Prohibited
502 Request Not Routable (Proxy)
503 Session Context Not Found
504 Session Context Not Removable
505 Other Proxy Processing Error
506 Resources Unavailable
507 Request Initiated
Where a NAS is shared by multiple providers, it is undesirable for one provider to be able to send Disconnect-Request or CoA-Requests affecting the sessions of another provider.
NASが複数のプロバイダーによって共有されている場合、あるプロバイダーが別のプロバイダーのセッションに影響を与える切断リケストまたはCOA要求を送信できることは望ましくありません。
A NAS or RADIUS proxy MUST silently discard Disconnect-Request or CoA-Request messages from untrusted sources. By default, a RADIUS proxy SHOULD perform a "reverse path forwarding" (RPF) check to verify that a Disconnect-Request or CoA-Request originates from an authorized RADIUS server. In addition, it SHOULD be possible to explicitly authorize additional sources of Disconnect-Request or CoA-Request packets relating to certain classes of sessions. For example, a particular source can be explicitly authorized to send CoA-Request messages relating to users within a set of realms.
NASまたはRADIUSプロキシは、信頼されていないソースからの切断リケストまたはCOA-Requestメッセージを静かに破棄する必要があります。デフォルトでは、RADIUSプロキシは「リバースパス転送」（RPF）チェックを実行して、切断リケストまたはCOA-Requestが認定RADIUSサーバーから発生していることを確認する必要があります。さらに、特定のクラスのセッションに関連するdeconnect-requestまたはCOA-Requestパケットの追加のソースを明示的に許可することが可能です。たとえば、特定のソースは、一連のレルム内のユーザーに関連するCOA-Requestメッセージを送信することを明示的に許可できます。
To perform the RPF check, the proxy uses the session identification attributes included in Disconnect-Request or CoA-Request messages, in order to determine the RADIUS server(s) to which an equivalent Access-Request could be routed. If the source address of the Disconnect-Request or CoA-Request is within this set, then the Request is forwarded; otherwise it MUST be silently discarded.
RPFチェックを実行するために、プロキシは、同等のアクセスリケストをルーティングできるRADIUSサーバーを決定するために、切断またはCOA-Requestメッセージに含まれるセッション識別属性を使用します。disconnect-requestまたはCOA-Requestのソースアドレスがこのセット内にある場合、リクエストは転送されます。それ以外の場合は、静かに廃棄する必要があります。
Typically the proxy will extract the realm from the Network Access Identifier [RFC2486] included within the User-Name Attribute, and determine the corresponding RADIUS servers in the proxy routing tables. The RADIUS servers for that realm are then compared against the source address of the packet. Where no RADIUS proxy is present, the RPF check will need to be performed by the NAS itself.
通常、プロキシは、ユーザー名属性内に含まれるネットワークアクセス識別子[RFC2486]からレルムを抽出し、プロキシルーティングテーブルの対応する半径サーバーを決定します。その領域のRADIUSサーバーは、パケットのソースアドレスと比較されます。半径プロキシが存在しない場合、RPFチェックはNAS自体が実行する必要があります。
Since authorization to send a Disconnect-Request or CoA-Request is determined based on the source address and the corresponding shared secret, the NASes or proxies SHOULD configure a different shared secret for each RADIUS server.
切断リケストまたはCOA-Requestを送信する許可は、ソースアドレスと対応する共有秘密に基づいて決定されるため、NasesまたはProxiesは各RADIUSサーバーの異なる共有シークレットを構成する必要があります。
[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リクエストをプロキシできるように、使用する共有シークレットを決定する必要があります。
When RADIUS requests are forwarded by a proxy, the NAS-IP-Address or NAS-IPv6-Address Attributes will typically not match the source address observed by the RADIUS server. Since the NAS-Identifier Attribute need not contain an FQDN, this attribute may not be resolvable to the source address observed by the RADIUS server, even when no proxy is present.
RADIUS要求がプロキシによって転送されると、NAS-IP-AddressまたはNAS-IPV6-Address属性は、通常、RADIUSサーバーによって観察されるソースアドレスと一致しません。NAS-Identifier属性にはFQDNが含まれている必要がないため、プロキシが存在しない場合でも、この属性はRADIUSサーバーによって観察されたソースアドレスに対して解決できない場合があります。
As a result, the authenticity check performed by a RADIUS server or proxy does not verify the correctness of NAS identification attributes. This makes it possible for a rogue NAS to forge NAS-IP-Address, NAS-IPv6-Address or NAS-Identifier Attributes within a RADIUS Access-Request in order to impersonate another NAS. It is also possible for a rogue NAS to forge session identification attributes such as the Called-Station-Id, Calling-Station-Id, or Originating-Line-Info [NASREQ]. This could fool the RADIUS server into sending Disconnect-Request or CoA-Request messages containing forged session identification attributes to a NAS targeted by an attacker.
その結果、RADIUSサーバーまたはプロキシによって実行される信頼性チェックは、NAS識別属性の正確性を検証しません。これにより、Rogue NASがNAS-IP-Address、Nas-IPV6-Address、またはNAS-IDENTIFIER属性を、RADIUS Access-Request内で別のNASになりすまして可能にします。また、Rogue NASが、呼び出されたステーションID、Calling-Station-ID、または発信元Line-INFO [NASREQ]などのセッション識別属性を偽造することも可能です。これにより、RADIUSサーバーを欺いて、攻撃者が標的とするNASへの偽造セッション識別属性を含む切断レクエストまたはCOA-Requestメッセージを送信する可能性があります。
To address these vulnerabilities RADIUS proxies SHOULD check whether NAS identification attributes (see Section 3.) match the source address of packets originating from the NAS. Where one or more attributes do not match, Disconnect-Request or CoA-Request messages SHOULD be silently discarded.
これらの脆弱性に対処するために、RADIUSプロキシは、NASの識別属性（セクション3を参照）であるかどうかを確認する必要があります（セクション3を参照）。1つ以上の属性が一致しない場合、切断されたレクエストまたはCOA-Requestメッセージを静かに破棄する必要があります。
Such a check may not always be possible. Since the NAS-Identifier Attribute need not correspond to an FQDN, it may not be resolvable to an IP address to be matched against the source address. Also, where a NAT exists between the RADIUS client and proxy, checking the NAS-IP-Address or NAS-IPv6-Address Attributes may not be feasible.
このようなチェックが常に可能であるとは限りません。NAS-Identifier属性はFQDNに対応する必要はないため、IPアドレスがソースアドレスと一致させることは解決できない場合があります。また、RADIUSクライアントとプロキシの間にNATが存在する場合、NAS-IP-AddressまたはNAS-IPV6-Addressの属性をチェックすることは実行不可能な場合があります。
In addition to security vulnerabilities unique to Disconnect or CoA messages, the protocol exchanges described in this document are susceptible to the same vulnerabilities as RADIUS [RFC2865]. It is RECOMMENDED that IPsec be employed to afford better security.
切断またはCOAメッセージに固有のセキュリティの脆弱性に加えて、このドキュメントで説明されているプロトコル交換は、半径と同じ脆弱性を受けやすい[RFC2865]。より良いセキュリティを提供するために、IPSECを採用することをお勧めします。
Implementations of this specification SHOULD support IPsec [RFC2401] along with IKE [RFC2409] for key management. IPsec ESP [RFC2406] with a non-null transform SHOULD be supported, and IPsec ESP with a non-null encryption transform and authentication support SHOULD be used to provide per-packet confidentiality, authentication, integrity and replay protection. IKE SHOULD be used for key management.
この仕様の実装は、キー管理のためにIKE [RFC2401]とIKE [RFC2409]とともにサポートする必要があります。非ヌル変換を備えたIPSEC ESP [RFC2406]をサポートする必要があり、非ヌル暗号化変換と認証サポートを備えたIPSEC ESPを使用して、パケットごとの機密性、認証、整合性、リプレイ保護を提供する必要があります。IKEはキー管理に使用する必要があります。
Within RADIUS [RFC2865], a shared secret is used for hiding Attributes such as User-Password, as well as used in computation of the Response Authenticator. In RADIUS accounting [RFC2866], the shared secret is used in computation of both the Request Authenticator and the Response Authenticator.
RADIUS [RFC2865]内で、共有秘密は、ユーザーパスワードなどの属性を隠すために使用され、応答認証器の計算で使用されます。Radius Accounting [RFC2866]では、共有された秘密は、リクエスト認証器と応答認証器の両方の計算に使用されます。
Since in RADIUS a shared secret is used to provide confidentiality as well as integrity protection and authentication, only use of IPsec ESP with a non-null transform can provide security services sufficient to substitute for RADIUS application-layer security. Therefore, where IPsec AH or ESP null is used, it will typically still be necessary to configure a RADIUS shared secret.
Radiusでは、共有された秘密が機密性と整合性の保護と認証を提供するために使用されるため、非ヌル変換でIPSEC ESPを使用することのみが、RADIUSアプリケーション層セキュリティを代用するのに十分なセキュリティサービスを提供できます。したがって、IPSEC AHまたはESP Nullが使用される場合、通常、RADIUS共有秘密を構成する必要があります。
Where RADIUS is run over IPsec ESP with a non-null transform, the secret shared between the NAS and the RADIUS server MAY NOT be configured. In this case, a shared secret of zero length MUST be assumed. However, a RADIUS server that cannot know whether incoming traffic is IPsec-protected MUST be configured with a non-null RADIUS shared secret.
非ヌル変換でIPSEC ESPを介してRADIUSが実行される場合、NASとRADIUSサーバーの間で共有される秘密は構成されていない場合があります。この場合、ゼロの長さの共有秘密を想定する必要があります。ただし、着信トラフィックがIPSECで保護されているかどうかを知ることができないRADIUSサーバーは、非NULL RADIUS共有秘密で構成する必要があります。
When IPsec ESP is used with RADIUS, per-packet authentication, integrity and replay protection MUST be used. 3DES-CBC MUST be supported as an encryption transform and AES-CBC SHOULD be supported. AES-CBC SHOULD be offered as a preferred encryption transform if supported. HMAC-SHA1-96 MUST be supported as an authentication transform. DES-CBC SHOULD NOT be used as the encryption transform.
IPSEC ESPがRADIUSで使用される場合、パケットごとの認証、整合性、リプレイ保護を使用する必要があります。3DES-CBCは暗号化変換としてサポートする必要があり、AES-CBCをサポートする必要があります。AES-CBCは、サポートされている場合は、優先暗号化変換として提供する必要があります。HMAC-SHA1-96は、認証変換としてサポートする必要があります。DES-CBCは、暗号化変換として使用しないでください。
A typical IPsec policy for an IPsec-capable RADIUS client is "Initiate IPsec, from me to any destination port UDP 1812". This IPsec policy causes an IPsec SA to be set up by the RADIUS client prior to sending RADIUS traffic. If some RADIUS servers contacted by the client do not support IPsec, then a more granular policy will be required: "Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812."
IPSEC対応RADIUSクライアントの典型的なIPSECポリシーは、「私から任意の宛先ポートUDP 1812までのIPSECを開始」です。このIPSECポリシーにより、RADIUSトラフィックを送信する前に、IPSEC SAがRADIUSクライアントによって設定されます。クライアントから連絡された一部のRADIUSサーバーがIPSECをサポートしていない場合、より詳細なポリシーが必要になります。
For a client implementing this specification, the policy would be "Accept IPsec, from any to me, destination port UDP 3799". This causes the RADIUS client to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS servers connecting to an IPsec-enabled RADIUS client, since some RADIUS servers may not support IPsec.
この仕様を実装するクライアントの場合、ポリシーは「IPSECを受け入れ、私から宛先ポートUDP 3799」になります。これにより、RADIUSクライアントはIPSECの使用を受け入れます（必要ありません）。一部のRADIUSサーバーはIPSECをサポートしていない場合があるため、IPSEC対応RADIUSクライアントに接続するすべてのRADIUSサーバーにIPSECを要求することは適切ではない場合があります。
For an IPsec-capable RADIUS server, a typical IPsec policy is "Accept IPsec, from any to me, destination port 1812". This causes the RADIUS server to accept (but not require) use of IPsec. It may not be appropriate to require IPsec for all RADIUS clients connecting to an IPsec-enabled RADIUS server, since some RADIUS clients may not support IPsec.
IPSEC利用可能なRADIUSサーバーの場合、典型的なIPSECポリシーは「IPSECを受け入れ、私から宛先ポート1812」です。これにより、RADIUSサーバーはIPSECの使用を受け入れます（必要ありません）。一部のRADIUSクライアントはIPSECをサポートしていない場合があるため、IPSEC対応RADIUSサーバーに接続するすべてのRADIUSクライアントにIPSECを要求することは適切ではない場合があります。
For servers implementing this specification, the policy would be "Initiate IPsec, from me to any, destination port UDP 3799". This causes the RADIUS server to initiate IPsec when sending RADIUS extension traffic to any RADIUS client. If some RADIUS clients contacted by the server do not support IPsec, then a more granular policy will be required, such as "Initiate IPsec, from me to IPsec-capable-RADIUS-client, destination port UDP 3799".
この仕様を実装するサーバーの場合、ポリシーは「私から任意の宛先ポートUDP 3799までのIPSECを開始する」です。これにより、RADIUS拡張トラフィックを任意のRADIUSクライアントに送信するときに、RADIUSサーバーがIPSECを開始します。サーバーから連絡された一部のRADIUSクライアントがIPSECをサポートしていない場合、「私からIPSEC対応、Destination Port UDP 3799までのIPSECを開始する」など、より詳細なポリシーが必要になります。
Where IPsec is used for security, and no RADIUS shared secret is configured, it is important that the RADIUS client and server perform an authorization check. Before enabling a host to act as a RADIUS client, the RADIUS server SHOULD check whether the host is authorized to provide network access. Similarly, before enabling a host to act as a RADIUS server, the RADIUS client SHOULD check whether the host is authorized for that role.
IPSECがセキュリティに使用され、RADIUS共有秘密が構成されていない場合、RADIUSクライアントとサーバーが承認チェックを実行することが重要です。ホストがRADIUSクライアントとして機能するようにする前に、RADIUSサーバーは、ホストがネットワークアクセスを提供する権限を与えられているかどうかを確認する必要があります。同様に、ホストがRADIUSサーバーとして機能することを可能にする前に、RADIUSクライアントはホストがその役割に対して許可されているかどうかを確認する必要があります。
RADIUS servers can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS clients. Alternatively, if a separate Certification Authority (CA) exists for RADIUS clients, then the RADIUS server can configure this CA as a trust anchor [RFC3280] for use with IPsec.
RADIUSサーバーは、RADIUSクライアントのIPアドレス（Pre-Sharedキーを使用したIKEアグレッシブモードの場合）またはFQDNS（証明書認証用）で構成できます。あるいは、RADIUSクライアントに個別の認証機関（CA）が存在する場合、RADIUSサーバーは、このCAをIPSECで使用するための信頼アンカー[RFC3280]として設定できます。
Similarly, RADIUS clients can be configured with the IP addresses (for IKE Aggressive Mode with pre-shared keys) or FQDNs (for certificate authentication) of RADIUS servers. Alternatively, if a separate CA exists for RADIUS servers, then the RADIUS client can configure this CA as a trust anchor for use with IPsec.
同様に、RADIUSクライアントは、RADIUSサーバーのIPアドレス（事前共有キーを使用したIKEアグレッシブモードの場合）またはFQDNS（証明書認証用）で構成できます。または、RADIUSサーバーに別のCAが存在する場合、RADIUSクライアントはこのCAをIPSECで使用する信頼アンカーとして構成できます。
Since unlike SSL/TLS, IKE does not permit certificate policies to be set on a per-port basis, certificate policies need to apply to all uses of IPsec on RADIUS clients and servers. In IPsec deployment supporting only certificate authentication, a management station initiating an IPsec-protected telnet session to the RADIUS server would need to obtain a certificate chaining to the RADIUS client CA. Issuing such a certificate might not be appropriate if the management station was not authorized as a RADIUS client.
SSL/TLSとは異なり、IKEは証明書ポリシーをポートごとに設定することを許可していません。証明書認証のみをサポートするIPSEC展開では、RADIUSサーバーにIPSECで保護されたTelnetセッションを開始する管理ステーションでは、RADIUSクライアントCAにチェーンチェーンを接続する証明書を取得する必要があります。管理ステーションがRADIUSクライアントとして許可されていない場合、そのような証明書を発行することは適切ではないかもしれません。
Where RADIUS clients may obtain their IP address dynamically (such as an Access Point supporting DHCP), Main Mode with pre-shared keys [RFC2409] SHOULD NOT be used, since this requires use of a group pre-shared key; instead, Aggressive Mode SHOULD be used. Where RADIUS client addresses are statically assigned, either Aggressive Mode or Main Mode MAY be used. With certificate authentication, Main Mode SHOULD be used.
RADIUSクライアントがIPアドレスを動的に取得できる場合（DHCPをサポートするアクセスポイントなど）、プレッシャーキーを使用したメインモード[RFC2409]は使用しないでください。代わりに、アグレッシブモードを使用する必要があります。RADIUSクライアントアドレスが静的に割り当てられている場合、積極的なモードまたはメインモードのいずれかを使用できます。証明書認証を使用すると、メインモードを使用する必要があります。
Care needs to be taken with IKE Phase 1 Identity Payload selection in order to enable mapping of identities to pre-shared keys, even with Aggressive Mode. Where the ID_IPV4_ADDR or ID_IPV6_ADDR Identity Payloads are used and addresses are dynamically assigned, mapping of identities to keys is not possible, so that group pre-shared keys are still a practical necessity. As a result, the ID_FQDN identity payload SHOULD be employed in situations where Aggressive mode is utilized along with pre-shared keys and IP addresses are dynamically assigned. This approach also has other advantages, since it allows the RADIUS server and client to configure themselves based on the fully qualified domain name of their peers.
IKEフェーズ1のIDペイロード選択には、積極的なモードであっても、事前に共有キーへのアイデンティティのマッピングを可能にするために注意する必要があります。ID_IPV4_ADDRまたはID_IPV6_ADDRアイデンティティペイロードが使用され、アドレスが動的に割り当てられる場合、キーへのアイデンティティのマッピングは不可能であるため、グループの事前共有キーは依然として実用的な必要性です。その結果、ID_FQDN IDペイロードは、積極的なモードが事前に共有キーとともに使用され、IPアドレスが動的に割り当てられる状況で使用する必要があります。また、このアプローチには他の利点があります。これにより、RADIUSサーバーとクライアントは、ピアの完全に適格なドメイン名に基づいて自分自身を構成できるようにするためです。
Note that with IPsec, security services are negotiated at the granularity of an IPsec SA, so that RADIUS exchanges requiring a set of security services different from those negotiated with existing IPsec SAs will need to negotiate a new IPsec SA. Separate IPsec SAs are also advisable where quality of service considerations dictate different handling RADIUS conversations. Attempting to apply different quality of service to connections handled by the same IPsec SA can result in reordering, and falling outside the replay window. For a discussion of the issues, see [RFC2983].
IPSECでは、IPSEC SAの粒度でセキュリティサービスが交渉されているため、既存のIPSEC SASと交渉されたものとは異なる一連のセキュリティサービスを必要とする半径交換は、新しいIPSEC SAと交渉する必要があることに注意してください。また、サービス品質の考慮事項がさまざまな処理ラジアス会話を決定する場合、個別のIPSEC SASも推奨されます。同じIPSEC SAによって処理された接続に異なる品質のサービスを適用しようとすると、再注文やリプレイウィンドウの外に落ちる可能性があります。問題の議論については、[RFC2983]を参照してください。
Where IPsec replay protection is not used, the Event-Timestamp (55) Attribute [RFC2869] SHOULD be included within all messages. When this attribute is present, both the NAS and the RADIUS server MUST check that the Event-Timestamp Attribute is current within an acceptable time window. If the Event-Timestamp Attribute is not current, then the message MUST be silently discarded. This implies the need for time synchronization within the network, which can be achieved by a variety of means, including secure NTP, as described in [NTPAUTH].
IPSECリプレイ保護が使用されていない場合、イベントタメスタンプ（55）属性[RFC2869]をすべてのメッセージに含める必要があります。この属性が存在する場合、NASとRADIUSサーバーの両方が、イベントタメスタンプ属性が許容可能な時間枠内で最新であることを確認する必要があります。イベントタイミスタンプ属性が最新のものでない場合、メッセージは静かに破棄する必要があります。これは、[ntpauth]で説明されているように、安全なNTPを含むさまざまな手段で達成できるネットワーク内での時間同期の必要性を意味します。
Both the NAS and the RADIUS server SHOULD be configurable to silently discard messages lacking an Event-Timestamp Attribute. A default time window of 300 seconds is recommended.
NASとRADIUSサーバーの両方は、イベントタイミスタン属性を欠くメッセージを静かに破棄するように構成可能である必要があります。300秒のデフォルトのタイムウィンドウをお勧めします。
Disconnect Request with User-Name:
ユーザー名でリクエストを切断します：
0: xxxx xxxx xxxx xxxx xxxx 2801 001c 1b23 .B.....$.-(....#
16: 624c 3543 ceba 55f1 be55 a714 ca5e 0108 bL5C..U..U...^..
32: 6d63 6869 6261
Disconnect Request with Acct-Session-ID:
ACCT-SESSION-IDでリクエストを切断します。
0: xxxx xxxx xxxx xxxx xxxx 2801 001e ad0d .B..... ~.(.....
16: 8e53 55b6 bd02 a0cb ace6 4e38 77bd 2c0a .SU.......N8w.,.
32: 3930 3233 3435 3637 90234567
Disconnect Request with Framed-IP-Address:
framed-ip-addressでリクエストを切断します：
0: xxxx xxxx xxxx xxxx xxxx 2801 001a 0bda .B....."2.(.....
16: 33fe 765b 05f0 fd9c c32a 2f6b 5182 0806 3.v[.....*/kQ...
32: 0a00 0203
[RFC1305] Mills, D., "Network Time Protocol (version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1305] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装、分析」、RFC 1305、1992年3月。
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest、R。、「MD5メッセージダイジストアルゴリズム」、RFC 1321、1992年4月。
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[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月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent、S。およびR. Atkinson、「インターネットプロトコルのセキュリティアーキテクチャ」、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent、S。およびR. Atkinson、「IPカプセンシングセキュリティペイロード（ESP）」、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins、D。およびD. Carrel、「The Internet Key Exchange（IKE）」、RFC 2409、1998年11月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba、B。およびM. Beadles、「ネットワークアクセス識別子」、RFC 2486、1999年1月。
[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月。
[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。and 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月。
[RFC3280] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RFC3280] Housley、R.、Polk、W.、Ford、W。and D. Solo、「インターネットX.509公開キーインフラストラクチャ証明書および証明書取消リスト（CRL）プロファイル」、RFC 3280、2002年4月。
[RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[Radiana] Aboba、B。、「Radius（ユーザーサービスのリモート認証ダイヤル）に関するIANAの考慮事項」、RFC 3575、2003年7月。
[RFC2882] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882] Mitton、D。、「ネットワークアクセスサーバー要件：RADIUSプラクティスの拡張」、RFC 2882、2000年7月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black、D。「差別化されたサービスとトンネル」、RFC 2983、2000年10月。
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[aaatransport] Aboba、B。and J. Wood、「認証、承認、会計（AAA）輸送プロファイル」、RFC 3539、2003年6月。
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress.
[直径] Calhoun、P.、et al。、「直径ベースプロトコル」、進行中の作業。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin、H。、「最近の攻撃後のMD5のステータス」、Cryptobytes Vol.2 No.2、1996年夏。
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
[Nasreq] Calhoun、P.、et al。、「Diameter Network Access Serverアプリケーション」、進行中の作業。
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Work in Progress.
[NTPAUTH] Mills、D。、「ネットワーク時間プロトコルの公開キー暗号化」、進行中の作業。
The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 Secretariat.
IETFは、知的財産またはその他の権利の有効性または範囲に関して、この文書に記載されているテクノロジーの実装または使用に関連すると主張される可能性のある他の権利、またはそのような権利に基づくライセンスがどの程度であるかについての程度に関連する可能性があるという立場はありません。利用可能;また、そのような権利を特定するために努力したことも表明していません。標準トラックおよび標準関連の文書における権利に関するIETFの手順に関する情報は、BCP-11に記載されています。出版のために利用可能にされた権利の請求のコピーと、利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、関心のある当事者に、この基準を実践するために必要な技術をカバーする可能性のある著作権、特許、または特許出願、またはその他の独自の権利を注意深く招待するよう招待しています。情報をIETFエグゼクティブディレクターに宛ててください。
This protocol was first developed and distributed by Ascend Communications. Example code was distributed in their free server kit.
このプロトコルは、Ascend Communicationsによって最初に開発および配布されました。サンプルコードは、無料のサーバーキットに配布されました。
The authors would like to acknowledge the valuable suggestions and feedback from the following people:
著者は、次の人々からの貴重な提案とフィードバックを認めたいと思います。
Avi Lior <avi@bridgewatersystems.com>,
Randy Bush <randy@psg.net>,
Steve Bellovin <smb@research.att.com>
Glen Zorn <gwz@cisco.com>,
Mark Jones <mjones@bridgewatersystems.com>,
Claudio Lapidus <clapidus@hotmail.com>,
Anurag Batta <Anurag_Batta@3com.com>,
Kuntal Chowdhury <chowdury@nortelnetworks.com>, and
Tim Moore <timmoore@microsoft.com>.
Russ Housley <housley@vigilsec.com>
Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134
Murtaza Chiba Cisco Systems、Inc。170 West Tasman Dr. San Jose CA、95134
EMail: mchiba@cisco.com
Phone: +1 408 525 7198
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
Gopal Dommety Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134
EMail: gdommety@cisco.com
Phone: +1 408 525 1404
Mark Eklund Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
Mark Eklund Cisco Systems、Inc。170 West Tasman Dr. San Jose、CA 95134
EMail: meklund@cisco.com
Phone: +1 865 671 6255
David Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845
David Mitton Circular Logic Unltd。733ターンパイクストリート＃154ノースアンドーバー、マサチューセッツ州01845
EMail: david@mitton.com
Phone: +1 978 683 1814
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond、WA 98052
EMail: bernarda@microsoft.com
Phone: +1 425 706 6605
Fax: +1 425 936 7329
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（c）The Internet Society（2003）。無断転載を禁じます。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
このドキュメントと翻訳は他の人にコピーされて提供される場合があります。また、それについてコメントまたは説明する派生作品、またはその実装を支援することは、いかなる種類の制限なしに、準備、コピー、公開、および部分的に配布される場合があります。、上記の著作権通知とこの段落がそのようなすべてのコピーとデリバティブ作品に含まれている場合。ただし、このドキュメント自体は、インターネット協会や他のインターネット組織への著作権通知や参照を削除するなど、いかなる方法でも変更できない場合があります。インターネット標準プロセスに従うか、英語以外の言語に翻訳するために必要な場合に従う必要があります。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限られた許可は永続的であり、インターネット社会やその後継者または譲受人によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
このドキュメントと本書に含まれる情報は、「現状」に基づいて提供されており、インターネット社会とインターネットエンジニアリングタスクフォースは、ここにある情報の使用が行われないという保証を含むがこれらに限定されないすべての保証を否認します。特定の目的に対する商品性または適合性の権利または黙示的な保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。