[要約] RFC 3576は、RADIUSサーバーからNASへDisconnectメッセージとCoAメッセージを送信し、進行中のユーザーセッションを動的に切断または認可変更する拡張を記述します。Disconnect-Request/ACK/NAKとCoA-Request/ACK/NAKの動作、パケット形式、AttributeによるNASおよびセッションの識別方法を規定します。既存実装との互換性や認可、なりすまし、リプレイ対策の制約も示し、IPsecの利用などの緩和策を推奨しています。
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)
RFC 3576 - 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コマンドを追加実装しました。これらの拡張コマンドは、DisconnectメッセージとChange-of-Authorization (CoA) メッセージをサポートします。Disconnectメッセージはユーザーセッションを直ちに終了させ、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として発行することが推奨されています。問題には、セキュリティ上の脆弱性と、Change-of-Authorization (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のユーザーを切断したり、その認可を変更したりするおそれがあります。この問題に対処するため、Reverse Path Forwarding (RPF) チェックが推奨されています。詳細については、セクション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リプレイ保護を使用しない場合は、すべてのメッセージにEvent-Timestamp Attributeを追加することが推奨されています。実装では、この属性を含まないメッセージを黙って破棄するよう設定できることが推奨されています。詳細については、セクション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 Attributeは、セッションの識別にも認可の変更にも使われるため、個々のAttributeがどちらの目的を果たすのか明確でない場合があります。
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.
[Diameter]ではこの問題は発生しません。認可変更は、識別だけに使うAttribute Value Pair (AVP) を含むコマンドで要求され、その後に、認可変更を指定する標準のRequest/Responseシーケンスが開始されます。そのため、Diameterのコマンド内で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.
RADIUSとDiameterでは認可変更要求の処理方法が異なるため、Diameter/RADIUSゲートウェイが、この仕様の既存実装をDiameterの同等メッセージに正しく変換することは困難、または不可能な場合があります。たとえば、既存のCoA-Request実装で識別に使われるAttributeを変更するDiameterコマンドは、そのような認可変更を既存実装で実行できないため変換できません。同様に、既存実装のDisconnect-RequestまたはCoA-RequestとDiameterとの変換も容易ではありません。1つのDisconnect-RequestまたはCoA-Requestを複数のDiameterコマンドに変換する必要があるためです。
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.
RADIUSとDiameterの変換を簡素化するため、値が"Authorize Only"のService-Type AttributeをDisconnect-RequestまたはCoA-Requestに任意で含めることができます。このRequestには識別用Attributeだけを含めます。Disconnect-RequestまたはCoA-Request内の"Authorize Only" Service-TypeをサポートするNASは、値が"Authorize Only"のService-Type Attributeと、値が"Request Initiated"のError-Cause Attributeを含むNAKで応答します。その後、NASは値が"Authorize Only"のService-Type Attributeを含むAccess-Requestを送信します。この手順はDiameterでの処理に似ているため、Diameter/RADIUSゲートウェイで変換しやすくなります。
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].
この文書では、仕様の要件を示すためにいくつかの語を使用し、多くの場合、それらを大文字で表記します。この文書における"MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および"OPTIONAL"は、[RFC2119]の記述に従って解釈します。
This document frequently uses the following terms:
この文書では、次の用語を頻繁に使用します。
Network Access Server (NAS): The device providing access to the network.
Network Access Server (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.
黙って破棄する：実装がそれ以上処理せずにパケットを破棄することです。実装は、黙って破棄したパケットの内容を含めてエラーを記録できるようにすべきです (SHOULD)。また、この事象を統計カウンターに記録すべきです (SHOULD)。
This section describes the most commonly implemented features of Disconnect and Change-of-Authorization messages.
このセクションでは、DisconnectメッセージとChange-of-Authorizationメッセージで最も一般的に実装されている機能について説明します。
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.
RADIUSサーバーは、NAS上のユーザーセッションを終了し、関連するセッションコンテキストをすべて破棄するためにDisconnect-Requestパケットを送信します。Disconnect-RequestパケットはUDPポート3799に送信され、セクション3で説明する識別用Attributeを含めて、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はDisconnect-ACKで応答します。セッションを切断して関連するセッションコンテキストをすべて破棄できなかった場合は、Disconnect-NAKで応答します。値が"Authorize Only"のService-Type Attributeを含むDisconnect-Requestには、NASはDisconnect-NAKで応答しなければなりません (MUST)。Disconnect-ACKを送信してはなりません (MUST NOT)。NASは、サポートされていない値のService-Type Attributeを含むDisconnect-RequestにもDisconnect-NAKで応答しなければなりません (MUST)。この場合、値が"Unsupported Service"のError-Cause Attributeを含めてもかまいません (MAY)。Disconnect-ACKには、Acct-Terminate-Cause (49) Attribute [RFC2866] を含め、値をAdmin-Resetの6に設定してもかまいません (MAY)。
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で説明する識別用Attributeとともに送信されます。使用するポートとパケット形式（セクション2.3で説明）は、Disconnect-Requestメッセージの場合と同じです。
The following attribute MAY be sent in a CoA-Request:
次の属性は、COA-Requestで送信できます (MAY)。
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)：識別用Attributeによって特定されるセッションに適用するデータフィルターリストの名前を示します。
+----------+ 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がユーザーセッションの認可を正常に変更できた場合、RADIUSサーバーからのCoA-RequestにCoA-ACKで応答します。Requestが失敗した場合はCoA-NAKで応答します。値が"Authorize Only"のService-Type Attributeを含むCoA-Requestには、NASはCoA-NAKで応答しなければなりません (MUST)。CoA-ACKを送信してはなりません (MUST NOT)。NASは、サポートされていない値のService-Type Attributeを含むCoA-RequestにもCoA-NAKで応答しなければなりません (MUST)。この場合、値が"Unsupported Service"のError-Cause Attributeを含めてもかまいません (MAY)。
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.
Disconnect-RequestまたはCoA-Requestメッセージの宛先ポートにはUDPポート3799を使用します。応答では送信元ポートと宛先ポートを逆にします。UDPのDataフィールドにはRADIUSパケットを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].
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
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:
Codeフィールドは1オクテットで、RADIUSパケットの種類を識別します。Codeフィールドが無効なパケットは、黙って破棄しなければなりません (MUST)。この拡張に割り当てられたRADIUSコード（10進数）は次のとおりです。
Identifier
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.
Identifierフィールドは1オクテットで、要求と応答の対応付けに使います。短時間内に、サーバーの送信元IPアドレス、送信元UDPポート、およびIdentifierが同じ要求を受信した場合、RADIUSクライアントは重複要求を検出できます。
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]で定義されているRADIUSとは異なり、Disconnect-Requestおよび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.
Attributesフィールドの内容が変わるたびに、または以前の要求に対する有効な応答を受信したときは、Identifierフィールドを変更しなければなりません (MUST)。内容が同一のパケットを再送する場合、Identifierは変更せず維持しなければなりません (MUST)。
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サーバーが以前と同じクライアントにDisconnect-RequestまたはCoA-Requestを再送し、Attributesに変更がない場合は、同じRequest Authenticator、Identifier、および送信元ポートを使用しなければなりません (MUST)。Attributesに変更がある場合は、新しいAuthenticatorとIdentifierを使用しなければなりません (MUST)。
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.
Event-Timestamp Attributeを含める場合、パケットの再送時にこのAttributeの値が更新されます。その結果Attributesフィールドの内容が変わるため、新しいIdentifierと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.
プライマリプロキシへのRequestが失敗し、セカンダリプロキシが利用可能な場合は、セカンダリプロキシにも問い合わせます。フェイルオーバーアルゴリズムの問題については[AAATransport]で説明されています。これは新しい要求であるため、新しいRequest AuthenticatorとIdentifierを使用しなければなりません (MUST)。ただし、RADIUSサーバーがクライアントに直接送信する場合、通常フェイルオーバーは意味をなしません。DisconnectまたはCoAメッセージは、セッションが存在するNASに届ける必要があるためです。
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.
Lengthフィールドは2オクテットです。Code、Identifier、Length、Authenticator、およびAttributeフィールドを含むパケットの長さを示します。Lengthフィールドで示される範囲外のオクテットはパディングとして扱い、受信時に無視しなければなりません (MUST)。Lengthフィールドで示される長さよりパケットが短い場合は、黙って破棄しなければなりません (MUST)。最小長は20、最大長は4096です。
Authenticator
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
Request Authenticator
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.
DisconnectまたはCoA-RequestのRequest Authenticatorは、RADIUS Access-RequestのRequest Authenticatorと同じ方法では計算できません。Disconnect-RequestにもCoA-RequestにもUser-Password Attributeが含まれないためです。
Response Authenticator
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.
Responseパケット（Disconnect-ACK、Disconnect-NAK、CoA-ACK、CoA-NAKなど）のAuthenticatorフィールドをResponse Authenticatorと呼びます。このフィールドには、Code、Identifier、Length、応答対象パケットのRequest Authenticatorフィールド、および存在する場合は応答Attributesからなるオクテット列に、共有シークレットを続けて計算した一方向MD5ハッシュが格納されます。得られた16オクテットのMD5ハッシュ値を、ResponseパケットのAuthenticatorフィールドに格納します。
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サーバー間で共有するパスワード）は、適切に選ばれたパスワードと同程度以上の長さを持ち、推測困難であるべきです (SHOULD)。RADIUSクライアントは、プロキシ経由の要求を処理できるよう、RADIUS UDPパケットの送信元IPアドレスに基づいて使用する共有シークレットを決定しなければなりません (MUST)。
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.
DisconnectおよびCoA-Requestメッセージでは、すべてのAttributeを必須として扱います。未対応のAttributeまたはAttribute値を1つ以上含むCoA-Requestを受信したNASは、CoA-NAKで応答しなければなりません (MUST)。未対応のAttributeまたはAttribute値を1つ以上含むDisconnect-Requestには、Disconnect-NAKで応答しなければなりません (MUST)。CoA-Requestによる状態変更は不可分でなければなりません (MUST)。Requestが成功した場合はCoA-ACKを送信し、要求された認可変更をすべて適用しなければなりません (MUST)。CoA-Requestが失敗した場合はCoA-NAKを送信しなければなりません (MUST)。また、要求された認可変更を適用してはなりません (MUST NOT)。同様に、失敗したDisconnect-Requestによって状態を変更してはなりません (MUST NOT)。この場合はDisconnect-NAKを送信しなければなりません (MUST)。
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.
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で指定されていないAttributeをDisconnectメッセージまたはCoAメッセージに含めるべきではありません (SHOULD NOT)。予測できない結果を招くおそれがあるためです。
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.
転送プロキシを使用する場合、プロキシはパケットが各方向に通過するときに変更できる必要があります。DisconnectまたはCoA-Requestを転送するプロキシはProxy-State Attributeを追加してもかまいません (MAY)。応答を転送する際は、自身が追加したProxy-State Attributeを削除しなければなりません (MUST)。Proxy-Stateは他のProxy-Stateの後に追加または削除しますが、Attributesリスト内の位置について、それ以外の前提を置くことはできません。DisconnectおよびCoAの応答はパケット全体の内容に基づいて認証されるため、Proxy-State Attributeを取り除くと完全性検査が無効になります。そのため、プロキシは認証値を再計算する必要があります。転送プロキシは、パケット内にすでに存在するProxy-State、State、またはClass Attributeを変更してはなりません (MUST NOT)。
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.
サーバーから受信したDisconnect-RequestまたはCoA-RequestにProxy-State Attributeが含まれる場合、転送プロキシはサーバーへの応答にもそのAttributeを含めなければなりません (MUST)。プロキシは要求を転送するとき、Proxy-State Attributeを要求に含めても (MAY)、省略してもかまいません (MAY)。要求から省略した場合は、サーバーに応答を送信する前に、そのAttributeを応答に付加しなければなりません (MUST)。
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.
Disconnect-RequestおよびCoA-Requestパケットでは、NASとそのNAS上のユーザーセッションを一意に識別するために特定のAttributeを使用します。Requestメッセージに含まれるNAS識別用Attributeがすべて一致しなければ、Disconnect-RequestまたはCoA-Requestは成功しません (MUST)。一致しない場合はDisconnect-NAKまたはCoA-NAKを送信すべきです (SHOULD)。セッション識別用Attributeについては、User-NameおよびAcct-Session-Id Attributeが含まれている場合、Disconnect-RequestまたはCoA-Requestが成功するにはそれらが一致しなければなりません (MUST)。その他のセッション識別用Attributeも一致すべきです (SHOULD)。セッション識別用Attributeの不一致を検出した場合は、Disconnect-NAKまたはCoA-NAKを送信すべきです (SHOULD)。NASまたはセッション識別用Attributeを使って一意または複数のセッションに対応付ける方法は、この文書の範囲外です。識別用Attributeには、以下に説明するNAS識別用Attributeとセッション識別用Attributeがあります。
NAS identification attributes
NAS識別用Attribute
Session identification attributes
セッション識別用Attribute
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のセキュリティ上の懸念に対処するため、Disconnect-RequestまたはCoA-RequestパケットにはUser-Name Attributeを含めるべきです (SHOULD)。追加のセッション識別用Attributeを1つ以上含めてもかまいません (MAY)。セクション5.2のセキュリティ上の懸念に対処するため、Disconnect-RequestまたはCoA-RequestパケットにはNAS-IP-AddressまたはNAS-IPv6-Address Attributeを1つ以上含めるべきです (SHOULD)。加えてNAS-Identifier Attributeを含めてもかまいません (MAY)。
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つでも実行できない場合、または未対応のAttributeもしくはAttribute値が1つでもある場合は、CoA-NAKを送信しなければなりません (MUST)。同様に、Disconnect-Requestに未対応のAttributeまたはAttribute値が1つでも含まれる場合は、Disconnect-NAKを送信しなければなりません (MUST)。
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.
値が"Authorize Only"のService-Type AttributeをCoA-RequestまたはDisconnect-Requestに含める場合、認可変更を表すAttributeを含めてはなりません (MUST NOT)。識別用Attributeだけを指定できます。このようなCoA-RequestにNASまたはセッション識別用Attribute以外が含まれる場合、実装はCoA-NAKを送信しなければなりません (MUST)。値が"Unsupported Attribute"のError-Cause Attributeを含めてもかまいません (MAY)。同様に、このようなDisconnect-RequestにNASまたはセッション識別用Attribute以外が含まれる場合、実装はDisconnect-NAKを送信しなければなりません (MUST)。値が"Unsupported Attribute"のError-Cause Attributeを含めてもかまいません (MAY)。
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がDisconnect-RequestまたはCoA-Requestメッセージに従えない場合があります。Error-Cause Attributeは問題の原因を詳しく示します。このAttributeはDisconnect-ACK、Disconnect-NAK、またはCoA-NAKメッセージに含めてもかまいません (MAY)。
A summary of the Error-Cause Attribute format is shown below. The fields are transmitted from left to right.
Error-Cause Attributeの形式を以下に示します。各フィールドは左から右に送信されます。
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
Error-Causeの値101
Length
長さ
6
6
Value
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:
Valueフィールドは4オクテットで、エラー原因を表す整数を格納します。値0～199および300～399は予約済みです。値200～299は処理の成功を表すため、Disconnect-ACKまたはCoA-ACK内でのみ送信できます。Disconnect-NAKまたはCoA-NAK内で送信してはなりません (MUST NOT)。値400～499はRADIUSサーバーで発生した致命的エラーを表します。CoA-NAKまたはDisconnect-NAK内で送信してもかまいません (MAY) が、CoA-ACKまたはDisconnect-ACK内で送信してはなりません (MUST NOT)。値500～599はNASまたはRADIUSプロキシで発生した致命的エラーを表します。CoA-NAKまたはDisconnect-NAK内で送信してもかまいません (MAY) が、CoA-ACKまたはDisconnect-ACK内で送信してはなりません (MUST NOT)。RADIUSサーバーはError-Cause値を記録すべきです (SHOULD)。Error-Causeの値（10進数）は次のとおりです。
# 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.
ユーザーセッションがすでに終了しているものの、残存するセッションコンテキストが見つかり、正常に削除された場合、Disconnect-Requestへの応答として"Residual Session Context Removed"を送信します。この値はDisconnect-ACK内でのみ送信し、CoA-ACK、Disconnect-NAK、またはCoA-NAK内で送信してはなりません (MUST NOT)。
"Invalid EAP Packet (Ignored)" is a non-fatal error that MUST NOT be sent by implementations of this specification.
"Invalid EAP Packet (Ignored)"は致命的でないエラーです。この仕様の実装はこれを送信してはなりません (MUST NOT)。
"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.
"Unsupported Attribute"は、Requestに未対応のAttribute（Vendor-Specific AttributeやEAP-Message Attributeなど）が含まれる場合に送信する致命的エラーです。
"Missing Attribute" is a fatal error sent if critical attributes (such as NAS or session identification attributes) are missing from a Request.
"Missing Attribute"は、Requestに必須のAttribute（NASまたはセッション識別用Attributeなど）が含まれていない場合に送信する致命的エラーです。
"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 Identification Mismatch"は、1つ以上のNAS識別用Attribute（セクション3を参照）が、Requestを受信したNASの識別情報と一致しない場合に送信する致命的エラーです。
"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.
"Invalid Request"は、Requestのその他の部分が無効な場合に送信する致命的エラーです。たとえば、EAP-Message AttributeなどのAttributeが正しい形式でない場合が該当します。
"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 Service"は、Requestに含まれるService-Type Attributeの値が無効または未対応の場合に送信する致命的エラーです。
"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.
"Unsupported Extension"は、DisconnectメッセージやCoAメッセージなどの拡張機能がサポートされていない場合に送信する致命的エラーです。通常、NASへのRequest転送を試みた後にICMP Port Unreachableメッセージを受信したプロキシが送信します。
"Administratively Prohibited" is a fatal error sent if the NAS is configured to prohibit honoring of Request messages for the specified session.
"Administratively Prohibited"は、指定されたセッションに対するRequestに従わないよう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.
"Request Not Routable"は、RADIUSプロキシが送信してもよい (MAY) 致命的エラーですが、NASは送信してはなりません (MUST NOT)。RADIUSプロキシがRequestをNASへ転送する方法を特定できなかったことを示します。たとえば、プロキシのレルムルーティングテーブルに必要なエントリーがない場合に発生します。
"Session Context Not Found" is a fatal error sent if the session context identified in the Request does not exist on the NAS.
"Session Context Not Found"は、Requestで識別されたセッションコンテキストが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.
"Session Context Not Removable"は、NASがセッションコンテキストを特定できたものの、何らかの理由で削除できなかった場合にDisconnect-Requestへの応答として送信する致命的エラーです。Disconnect-NAK内でのみ送信し、CoA-ACK、CoA-NAK、またはDisconnect-ACK内で送信してはなりません (MUST NOT)。
"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.
"Other Proxy Processing Error"は、ルーティング以外の理由でプロキシがRequestを処理できなかった場合に、その応答として送信する致命的エラーです。
"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.).
"Resources Unavailable"は、NASの利用可能なリソース（メモリ、不揮発性ストレージなど）が不足し、Requestに従えない場合に送信する致命的エラーです。
"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.
"Request Initiated"は、値が"Authorize Only"のService-Type Attributeを含むRequestへの応答として送信する致命的エラーです。Disconnect-RequestまたはCoA-Requestには従わなかったものの、値が"Authorize Only"のService-Type Attributeを含むRADIUS Access-RequestをRADIUSサーバーへ送信中であることを示します。
The following table provides a guide to which attributes may be found in which packets, and in what quantity.
次の表は、各パケットにどのAttributeがいくつ含まれるかを示します。
Change-of-Authorization Messages
Change-of-Authorizationメッセージ
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
Disconnectメッセージ
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またはセッション識別用AttributeをDisconnect-RequestまたはCoA-Requestに含める場合、それらは識別だけに使用します。これらのAttributeを識別以外の目的（たとえば、CoA-Requestで認可変更を要求する目的）に使用してはなりません (MUST NOT)。
[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 Attributeは、ユーザーに表示するメッセージに使用します。このメッセージはDisconnect-RequestまたはCoA-Requestが成功した場合にのみ表示され、その後Disconnect-ACKまたはCoA-ACKが送信されます。認証にEAPを使用する場合は、代わりにEAP-Message/Notification-Request Attributeを送信し、Disconnect-ACKまたはCoA-ACKにはEAP-Message/Notification-Response Attributeを含めます。
[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に含める場合、これらのAttributeは認可変更要求を表します。CoA-Requestから省略されたAttributeについて、NASはその値を変更しないものとして扱います。CoA-Requestに含まれるAttributeは、同じ種類の既存値をすべて置き換えます。
[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] 成功したDisconnect-Request（その後Disconnect-ACKが送信されるもの）に含まれる場合、クライアントはClass Attributeを変更せず、Accounting Stopパケットでアカウンティングサーバーへ送信すべきです (SHOULD)。Disconnect-Requestが失敗した場合、Class Attributeは処理されません。
[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に含める場合、これらのAttributeは認可変更要求を表します。成功したCoA-RequestにTunnel Attributeが含まれる場合、既存のTunnel Attributeをすべて削除し、新しいAttributeに置き換えます。
[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 Only"のService-Type Attributeは、そのRequestにNASおよびセッション識別用Attributeだけが含まれ、NASが値が"Authorize Only"のService-Type Attributeを含むAccess-Requestを送信して再認可を試みることを示します。これにより、Diameterでサポートされるものに似た利用形態が可能になり、両プロトコル間の変換が容易になります。Disconnect-RequestおよびCoA-RequestでのService-Type Attributeのサポートは任意です。含まれない場合、Requestには識別用Attributeと認可用Attributeの両方を含めることができます。Disconnect-Request内の値が"Authorize Only"のService-Type AttributeをサポートしないNASは、Service-Type Attributeを含まないDisconnect-NAKで応答しなければなりません (MUST)。値が"Unsupported Service"のError-Cause Attributeを含めてもかまいません (MAY)。CoA-Request内の同Attribute値をサポートしないNASは、Service-Type Attributeを含まないCoA-NAKで応答しなければなりません (MUST)。値が"Unsupported Service"のError-Cause Attributeを含めてもかまいません (MAY)。
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内の"Authorize Only" Service-Type値をサポートするNASは、それぞれService-Type Attribute（値は"Authorize Only"）とError-Cause Attribute（値は"Request Initiated"）を含むDisconnect-NAKまたはCoA-NAKで応答しなければなりません (MUST)。続いてNASは、値が"Authorize Only"のService-Type Attributeを含むAccess-RequestをRADIUSサーバーへ送信します。このAccess-Requestには、DisconnectまたはCoA-RequestのNAS Attributeに加え、[RFC2865]、[RFC2868]、[RFC2869]、および[RFC3162]でAccess-Requestへの包含が認められているRequestのセッションAttributeを含めるべきです (SHOULD)。[RFC2869]のセクション5.19に記載されているように、User-Password、CHAP-Password、ARAP-Password、またはEAP-Message Attributeを含まないAccess-RequestにはMessage-Authenticator Attributeを含めるべきです (SHOULD)。RADIUSサーバーは、セッションを再認可するAccess-Accept、または再認可を拒否するAccess-Rejectを返します。
[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] RADIUSサーバーはDisconnect-RequestまたはCoA-RequestでState AttributeをNASに送信できます。NASは後続のACKまたはNAKメッセージで、これを変更せずにRADIUSサーバーへ返さなければなりません (MUST)。値が"Authorize Only"のService-Type AttributeとState Attributeの両方をDisconnect-RequestまたはCoA-Requestに含める場合、NASは、該当するAccess-RequestをRADIUSサーバーへ送信するときにState Attributeを変更せずに含めなければなりません (MUST)。RADIUSサーバーは、値がRADIUS-RequestのTermination-Action Attributeを含むCoA-RequestでもState AttributeをNASに送信できます。クライアントが現在のセッション終了時に新しいAccess-Requestを送信してTermination-Actionを実行する場合、そのAccess-RequestにState Attributeを変更せずに含めなければなりません (MUST)。いずれの場合も、クライアントはAttributeをローカルで解釈してはなりません (MUST NOT)。Disconnect-RequestまたはCoA-Requestパケットに含めるState Attributeは0個または1個です。State Attributeの使用方法は実装に依存します。Access-Request内のState AttributeをRADIUSサーバーが認識しない場合、Access-Rejectを送信しなければなりません (MUST)。
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.
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]の名前空間を使用します（<http://www.iana.org/assignments/radius-types>を参照）。RADIUS Packet Type Codesのセクションに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 Only"のService-Typeを新たに割り当てるよう要求します。この文書はUDP [RFC768]の名前空間も使用します（<http://www.iana.org/assignments/port-numbers>を参照）。著者はRegistered Portsの範囲からポートを割り当てるよう要求します。最後に、この仕様はError-Cause Attribute (101) に次の10進値を割り当てます。
# 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を複数のプロバイダーで共有している場合、あるプロバイダーが別のプロバイダーのセッションに影響するDisconnect-RequestまたはCoA-Requestを送信できる状態は望ましくありません。
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プロキシは、信頼されていない送信元から届いたDisconnect-RequestまたはCoA-Requestを黙って破棄しなければなりません (MUST)。通常、RADIUSプロキシはReverse Path Forwarding (RPF) チェックを実行し、Disconnect-RequestまたはCoA-Requestが認可されたRADIUSサーバーから送られたことを確認すべきです (SHOULD)。また、特定の種類のセッションに関するDisconnect-RequestまたはCoA-Requestについて、追加の送信元を明示的に認可できるようにすべきです (SHOULD)。たとえば、特定の送信元に対して、あるレルム群のユーザーに関する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チェックでは、プロキシはDisconnect-RequestまたはCoA-Request内のセッション識別用Attributeを使い、同等のAccess-Requestを転送できるRADIUSサーバーを特定します。Disconnect-RequestまたはCoA-Requestの送信元アドレスがその集合に含まれていれば、Requestを転送します。含まれていなければ、黙って破棄しなければなりません (MUST)。
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.
通常、プロキシはUser-Name Attributeに含まれるNetwork Access Identifier [RFC2486]からレルムを取り出し、プロキシのルーティングテーブルで対応するRADIUSサーバーを特定します。そのレルムのRADIUSサーバー群とパケットの送信元アドレスを照合します。RADIUSプロキシがない場合は、NAS自体がRPFチェックを実行する必要があります。
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.
Disconnect-RequestまたはCoA-Requestの送信認可は、送信元アドレスと対応する共有シークレットに基づいて判定されるため、NASまたはプロキシはRADIUSサーバーごとに異なる共有シークレットを設定すべきです (SHOULD)。
A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied.
RADIUSサーバーは、プロキシ経由のRADIUS要求を処理できるよう、RADIUS UDPパケットの送信元IPアドレスに基づいて使用する共有シークレットを決定しなければなりません (MUST)。
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 Attributeは通常、RADIUSサーバーが観測する送信元アドレスとは一致しません。NAS-Identifier Attributeには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識別用Attributeの正しさを検証できません。このため、不正なNASがRADIUS Access-Request内のNAS-IP-Address、NAS-IPv6-Address、またはNAS-Identifier Attributeを偽造し、別のNASになりすます可能性があります。不正なNASは、Called-Station-Id、Calling-Station-Id、またはOriginating-Line-Info [NASREQ]などのセッション識別用Attributeも偽造できます。これによりRADIUSサーバーを欺き、攻撃者が標的とするNASに、偽造されたセッション識別用Attributeを含むDisconnect-Requestまたは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識別用Attribute（セクション3を参照）がNASから届いたパケットの送信元アドレスと一致するか確認すべきです (SHOULD)。Attributeが1つでも一致しない場合、Disconnect-RequestまたはCoA-Requestを黙って破棄すべきです (SHOULD)。
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 AttributeはFQDNである必要がないため、送信元アドレスとの照合に使うIPアドレスへ名前解決できない場合があります。また、RADIUSクライアントとプロキシの間にNATがある場合、NAS-IP-AddressまたはNAS-IPv6-Address Attributeを確認できないことがあります。
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.
DisconnectメッセージまたはCoAメッセージ固有のセキュリティ脆弱性に加え、この文書で説明するプロトコル交換にはRADIUS [RFC2865]と同じ脆弱性があります。セキュリティを強化するため、IPsecの使用が推奨されます (SHOULD)。
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.
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では共有シークレットを機密性、完全性保護、および認証のために使います。そのため、RADIUSのアプリケーション層セキュリティを代替できる十分なセキュリティサービスを提供するには、非NULL変換を使用するIPsec ESPが必要です。したがって、IPsec AHまたはNULL暗号化のESPを使用する場合でも、通常は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.
非NULL変換を使用するIPsec ESP上でRADIUSを実行する場合、NASとRADIUSサーバー間の共有シークレットを設定しなくてもかまいません (MAY)。この場合、長さ0の共有シークレットを仮定しなければなりません (MUST)。ただし、受信トラフィックがIPsecで保護されているかどうか判定できないRADIUSサーバーには、NULLでないRADIUS共有シークレットを設定しなければなりません (MUST)。
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.
RADIUSでIPsec ESPを使用する場合、パケットごとの認証、完全性、およびリプレイ保護を使用しなければなりません (MUST)。暗号化変換として3DES-CBCをサポートしなければなりません (MUST)。AES-CBCもサポートすべきです (SHOULD)。サポートする場合は、優先する暗号化変換としてAES-CBCを提示すべきです (SHOULD)。認証変換としてHMAC-SHA1-96をサポートしなければなりません (MUST)。暗号化変換にDES-CBCを使用すべきではありません (SHOULD NOT)。
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ポリシーは、"Initiate IPsec, from me to any destination port UDP 1812"です。このポリシーにより、RADIUSクライアントはRADIUSトラフィックを送信する前にIPsec SAを確立します。クライアントが通信するRADIUSサーバーの一部がIPsecに対応しない場合、たとえば"Initiate IPsec, from me to IPsec-Capable-RADIUS-Server, destination port UDP 1812"のような、より限定的なポリシーが必要です。
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.
この仕様を実装するクライアントでは、ポリシーを"Accept IPsec, from any to me, destination port 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ポリシーは、"Accept IPsec, from any to me, destination port 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".
この仕様を実装するサーバーでは、ポリシーを"Initiate IPsec, from me to any, destination port UDP 3799"とします。この設定により、RADIUSサーバーは任意のRADIUSクライアントへ拡張トラフィックを送信するときにIPsecを開始します。サーバーが通信するRADIUSクライアントの一部がIPsecに対応しない場合は、たとえば"Initiate IPsec, from me to IPsec-capable-RADIUS-client, destination port UDP 3799"のような、より限定的なポリシーが必要です。
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サーバーは、そのホストがネットワークアクセスを提供する認可を受けているか確認すべきです (SHOULD)。同様に、ホストをRADIUSサーバーとして有効にする前に、RADIUSクライアントは、そのホストがその役割を担う認可を受けているか確認すべきです (SHOULD)。
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アドレス（事前共有鍵を使うIKE Aggressive Modeの場合）またはFQDN（証明書認証の場合）を設定できます。また、RADIUSクライアント用の個別の認証局 (CA) がある場合、RADIUSサーバーはIPsecで使う信頼アンカー [RFC3280] としてそのCAを設定できます。
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 Aggressive Modeの場合）またはFQDN（証明書認証の場合）を設定できます。また、RADIUSサーバー用の個別のCAがある場合、RADIUSクライアントはIPsecで使う信頼アンカーとしてそのCAを設定できます。
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ではポートごとに証明書ポリシーを設定できません。そのため、証明書ポリシーはRADIUSクライアントおよびサーバーでのIPsecのすべての用途に適用する必要があります。証明書認証だけをサポートする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対応アクセスポイントなど）、事前共有鍵を使うMain Mode [RFC2409]はグループ事前共有鍵が必要になるため使用すべきではありません (SHOULD NOT)。代わりにAggressive Modeを使用すべきです (SHOULD)。RADIUSクライアントのアドレスが静的に割り当てられている場合は、Aggressive ModeまたはMain Modeを使用してもかまいません (MAY)。証明書認証ではMain Modeを使用すべきです (SHOULD)。
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.
Aggressive Modeでも識別情報を事前共有鍵に対応付けられるよう、IKE Phase 1のIdentity Payloadの選択には注意が必要です。ID_IPV4_ADDRまたはID_IPV6_ADDR Identity Payloadを使うときにアドレスが動的に割り当てられる場合、識別情報を鍵に対応付けられません。そのため、実運用上は引き続きグループ事前共有鍵が必要になります。したがって、事前共有鍵を使うAggressive ModeでIPアドレスが動的に割り当てられる場合は、ID_FQDN Identity Payloadを使用すべきです (SHOULD)。この方法には、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 SAで交渉したものとは異なるセキュリティサービスを必要とするRADIUS通信では、新しいIPsec SAを交渉する必要があります。サービス品質の要件に応じてRADIUS通信を異なる方法で処理する場合も、IPsec SAを分けることが推奨されます。同じ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のリプレイ保護を使用しない場合、すべてのメッセージにEvent-Timestamp (55) Attribute [RFC2869]を含めるべきです (SHOULD)。このAttributeがある場合、NASとRADIUSサーバーは、Event-Timestamp Attributeの値が許容時間幅内の現在時刻を示すことを確認しなければなりません (MUST)。値が現在時刻から許容範囲を外れている場合、メッセージを黙って破棄しなければなりません (MUST)。このためネットワーク内で時刻を同期する必要があります。同期には、[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サーバーの両方で、Event-Timestamp Attributeのないメッセージを黙って破棄するよう設定できるべきです (SHOULD)。推奨されるデフォルトの時間幅は300秒です。
Disconnect Request with User-Name:
User-Nameを含むDisconnect-Request：
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を含むDisconnect-Request：
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を含むDisconnect-Request：
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., "Network Time Protocol (version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, April 1992.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC 2486, January 1999.
[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. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[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, June 2000.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[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, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.
[RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RADIANA] Aboba, B., "IANA Considerations for RADIUS (Remote Authentication Dial In User Service)", RFC 3575, July 2003.
[RFC2882] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882] Mitton, D., "Network Access Server Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[AAATransport] Aboba, B. and J. Wood, "Authentication, Authorization and Accounting (AAA) Transport Profile", RFC 3539, June 2003.
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress.
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress.
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Work in Progress.
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Work in Progress.
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に知らせるよう求めます。情報は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 Turnpike Street #154 North Andover, MA 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.
この文書およびその翻訳は、上記の著作権表示とこの段落をすべての複製物および派生物に含めることを条件に、他者へ複製・提供できます。また、この文書について論評または説明する派生物や、その実装を支援する派生物は、全部または一部を問わず、制限なく作成、複製、公開、配布できます。ただし、著作権表示やInternet Societyその他のインターネット組織への言及を削除するなど、この文書自体を変更してはなりません。例外は、インターネット標準の策定に必要な場合（その場合はInternet Standards Processで定める著作権手続きに従います）と、英語以外の言語へ翻訳する場合です。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の限定的な許諾は永続的であり、Internet Society、その後継者、または譲受人によって取り消されません。
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.
この文書およびここに含まれる情報は「現状有姿」で提供されます。INTERNET SOCIETYおよびINTERNET ENGINEERING TASK FORCEは、ここに含まれる情報の使用が権利を侵害しないことの保証、商品性または特定目的への適合性に関する黙示の保証を含め、明示または黙示を問わず、すべての保証を否認します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能の資金は、現在Internet Societyが提供しています。