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)
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.
著作権（C）インターネット協会（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プロトコルは、ネットワーク・アクセス・サーバ（NAS）にRADIUSサーバから送信される迷惑メールをサポートしていません。
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.
これらの制限を克服するために、いくつかのベンダーは、NASにRADIUSサーバから送信された迷惑メッセージをサポートすることができるようにするために追加の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のリクエストの既存の実装では、影響を受けたセッションを識別、並びに許可の変更を供給する。 CoAのリクエストの既存の実装内に含まれる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）内に存在しません。その結果、コマンドなしで直径の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および径の変化-の承認要求を処理の違いによる、成功し、直径が同等のメッセージに、この仕様の既存の実装を変換するために直径/ RADIUSゲートウェイのための困難または不可能であろう。そのような許可の変更は、既存の実装で行うことは不可能であるため、例えば、既存のCoAリクエスト実装内で識別するために使用される任意の属性を変更直径コマンドは、変換できません。切断リクエスト又はアシルCoA-Requestメッセージは、複数のDiameterコマンドに翻訳する必要があるため、同様に、切断リクエスト又はアシル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.
RADIUSと直径との間の変換を簡素化するために、値service-type属性は、「のみ許可」（任意に）切断リクエスト又はアシルCoA - 要求内に含めることができます。そのような要求は、唯一の識別属性が含まれています。外しリクエストまたはCoAのリクエストの中に「オーソライズのみ」サービスタイプをサポートするNASは、NAKが「唯一認可」とエラー-原因が値「開始した要求」と属性値とのservice-type属性を含むで応答します。 NASは、「唯一の認可」の値を持つservice-type属性を含むアクセス要求を送信します。この使用順序は、直径が発生するものに似ているので、より容易に直径/ 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"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[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はセッションを切断することができなかった場合、NASは、すべての関連するセッションコンテキストを破棄されていないと、ユーザーセッションがもはや接続されている場合は外し-ACKとRADIUSサーバによって送信された接続解除要求パケットに応答、または接続解除-NAKそして、すべての関連するセッションコンテキストを破棄します。 NASは外し-NAKを持つ値でservice-type属性「のみの認可」を含む外し-要求に応答しなければなりません。外し-ACKを送ってはいけません。 NASは外し-NAKでサポートされていない値を持つservice-type属性を含む外し-要求に応答しなければなりません。値「サポートされていないサービス」とのエラー原因の属性が含まれるかもしれません。切断-ACKは、管理・リセットのために6に設定された値を持つ属性のAcct-終了原因（49）[RFC2866]を含むかもしれません。
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に使用されるポート、およびパケット形式で記載されているように属性に加えて送信される（セクション2.3に記載。）、切断用のものと同じです-requestメッセージ。
The following attribute MAY be sent in a CoA-Request:
以下の属性は、CoAのリクエストで送信することができます。
Filter-ID (11) - Indicates the name of a data filter list to be applied for the session that the identification attributes map to.
フィルタ-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-NAKの権限を変更することができる場合のCoA-ACKとRADIUSサーバによって送信されたCoAのリクエストに応答します。 NASは、アシルCoA-NAKを持つ値でservice-type属性「のみの認可」を含むアシルCoA-要求に応答しなければなりません。アシルCoA-ACKを送ってはいけません。 NASは、アシルCoA-NAKでサポートされていない値を持つservice-type属性を含むアシルCoA-要求に応答しなければなりません。値「サポートされていないサービス」とのエラー原因の属性が含まれるかもしれません。
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.
外しリクエストまたはCoAのリクエストメッセージUDPポート3799のいずれかの場合は宛先ポートとして使用されています。応答のために、送信元と宛先ポートが逆になっています。正確に1つのRADIUSパケットがUDPデータフィールドにカプセル化されます。
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）形式。すべてのフィールドはRADIUS [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]
40 - 切断 - 要求[RFC2882] 41 - ディス-ACK [RFC2882] 42 - 切断 - NAK [RFC2882] 43 - アシルCoAリクエスト[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つのオクテットであり、要求と応答のマッチングを助けます。それは時間の短いスパン内の同じサーバーの送信元IPアドレスと送信元UDPポートと識別子を持っている場合、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とは異なり、接続解除 - 要求と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]に記載されています。この新しい要求を表しているので、新たな要求認証識別子を使用しなければなりません。外したりCoAのメッセージは、セッションがどこにあるNASに配信する必要があるためしかし、RADIUSサーバがクライアントに直接送信された場合、フェイルオーバーは一般的に、意味がありません。
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.
認証フィールドは、16（16）オクテットです。最も重要なオクテットが最初に送信されます。この値は、RADIUSサーバとクライアント間のメッセージを認証するために使用されます。
Request 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].
要求パケットで、認証値は、要求認証と呼ばれ、16オクテットMD5 [RFC1321]のチェックサムです。要求認証は、[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のリクエストにはユーザーパスワード属性が存在しないので、外したり、COA要求の要求認証は、RADIUSアクセス要求の要求認証と同じ方法で行うことができないことに注意してください。
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パケット（例えば外し-ACK、外し-NAK、アシルCoA-ACK、またはアシルCoA-NAK）における認証フィールドはレスポンス認証と呼ばれ、コードから成る八重奏のストリームに関して計算一方向MD5ハッシュが含まれています、識別子、長さ、パケットから要求認証フィールドがに答えたされ、もしあれば応答は、共有秘密が続く、属性。得られた16オクテット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.
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認証およびアカウンティングで使用するための属性を実装しても、それは切断リクエスト又はアシルCoA-Requestメッセージ内にその属性を含めることをサポートしていない場合があり、識別、許可又は他の目的のために使用することができるので属性の意味の違い。これは、Access-受諾メッセージの中に許容として[RFC2868]、[RFC2869]か[RFC3162]も[RFC2865]の中に指定した属性についても同様です。
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を転送するとき、それはプロキシ状態属性を追加することができ、プロキシが応答を転送するとき、それは1を追加した場合、それはそのプロキシ状態属性を削除する必要があります。プロキシ状態は常に追加されたり、他のプロキシ・国後に削除されますが、属性のリスト内の位置に関しては、他の仮定がなされていないことができています。切断と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.
切断リクエストとCoA-Requestパケットでは、特定の属性を一意NAS並びにNAS上のユーザセッションを識別するために使用されます。要求メッセージに含まれるすべてのNAS識別属性が切断リクエストまたは成功するのCoA-要求のために一致しなければなりません。そうでない場合は外し-NAKまたはCoAの-NAKを送ってください。アカウンティング・セッションId属性ユーザ名とセッション識別属性については、含まれている場合、切断リクエストまたは成功するのCoA-要求のために一致しなければなりません。他のセッション識別属性が一致している必要があります。セッション識別属性の不一致が検出された場合、切断-NAKまたはアシルCoA-NAKが送信されるべきです。 NASやセッションIDを使用する能力は、このドキュメントの範囲を超えてユニークな/複数のセッションにマップする属性。後述のように識別属性は、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で説明したセキュリティ上の懸念に対処するために、User-Name属性は外しリクエストまたはアシルCoA-Requestパケット中に存在すべきです。 1つの以上の追加のセッション識別属性が存在してもよいです。 5.2節で説明したセキュリティ上の懸念に対処するために、1またはNAS-IP-アドレスまたはNAS-IPv6のアドレス属性の多くを外し、要求またはアシル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のリクエストで指定された一つ以上の許可の変更を行うことができない、または1つ以上の属性や属性値がサポートされていない場合、アシルCoA-NAKを送らなければなりません場合。一つ以上のサポートされていない属性または属性値が外し-Requestに存在する場合も同様に、外し-NAKを送らなければなりません。
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.
値のservice-type属性「のみ認可」は、COA要求または切断し、リクエストに含まれている場合は、含んではいけません承認変化を表す属性。唯一の識別属性が許可されています。 NAS又はセッション識別属性以外の属性は、このようなアシルCoA-Requestに含まれている場合、実装は、アシルCoA-NAKを送信しなければなりません。値「サポートされていない属性」とのエラー原因の属性が含まれるかもしれません。 NAS又はセッション識別属性以外の属性は、例えば切断、要求に含まれている場合、同様に、実装は、切断-NAKを送信しなければなりません。値「サポートされていない属性」とのエラー原因の属性が含まれるかもしれません。
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メッセージを尊重できない可能性があります。エラー原因の属性は、問題の原因について詳しく説明します。それは外し-ACK、外し-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
６
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
Valueフィールドは、エラーの原因を指定する整数を含む、4つのオクテットです。値0〜199と300〜399は予約されています。これらの値はだけ切断-ACK又はアシルCoA-ACKメッセージ内で送信することができ、切断-NAKまたはアシルCoA-NAK内で送信してはならないことに200-299は、正常終了を表す値。値
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:
400-499は、それらがアシルCoA-NAKまたは外し-NAKメッセージ内で送信することができるように、RADIUSサーバによってコミット致命的なエラーを表し、とCoA-ACKまたは外し-ACKメッセージの中に送ってはいけません。値500-599は、それらがアシルCoA-NAKと切り離し-NAKメッセージ内で送信することができるように、致命的なエラーが、NASまたはRADIUSプロキシ上で発生表し、とCoA-ACKまたは外し-ACKメッセージの中に送ってはいけません。エラー原因値はRADIUSサーバによって記録されるべきです。 （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.
ユーザーセッションは、もはや有効であれば、「除去された残留セッション・コンテキストは」切断リクエストに応答して送信されていないが、残留セッションコンテキストが見つかったと正常に削除。この値は、接続解除-ACK内で送信されるとCoA-ACK、外し-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識別ミスマッチ」は、一つ以上の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.
「無効な要求」は、（例えば、EAP-メッセージ属性（複数可）のような）1つ以上の属性が正しくフォーマットされていない場合など、要求のいくつかの他の態様は、無効である場合に送信される致命的なエラーです。
"Unsupported Service" is a fatal error sent if a Service-Type Attribute included with the Request is sent with an invalid or unsupported value.
「サポートされていないサービスは、」要求が無効またはサポートされていない値で送信されてservice-type属性が含まれている場合送信され、致命的なエラーです。
"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は、セッションコンテキストを見つけることができた場合は外し、要求に応じて送信され、致命的なエラーですが、いくつかの理由のためにそれを削除することができませんでした。それだけ外し-NAKの中に、アシルCoA-ACK、アシルCoA-NAKまたは外し-ACK以内に送ってはいけません。
"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.
「開始された要求は、」「のみ認可」の値を持つservice-type属性を含む要求に応答して送信された致命的なエラーです。それは外しリクエストまたはCoAのリクエストが表彰されていないことを示し、その値を持つservice-type属性を含む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
要求ACK NAKの＃属性0-1 0 0 1ユーザ名0-1 0 0 4 NAS-IP-アドレス0-1 0 0 5 NAS-ポート0-1 0 [注1] [注1] [注1] 0-1 6サービスタイプ[注6] 0-1 0 7入れる-プロトコル[注3] 0-1 0 0 8入れる-IP-ADDRESS [注1] 0-1 0 0 9入れる-IP-ネットマスク0-1 0 0 10入れるルーティング0+ 0 0 11フィルタ-ID [注3] 0-1 0 0 12入れる-MTU [注3] [注3] 0 + 0 13入れる圧縮[注3] [注3] 0+ 0 0 14ログイン-IP-ホスト[注3] 0-1 0 0 15ログイン・サービス[注3] 0-1 0 0 16ログイン - TCPポート[注3] 0+ 0 0 18返信メッセージ[注2] 0-1 0 0 19コールバック番号[注3] 0-1 0 0 20コールバック-ID [注3] 0 + 0 22入り、ルート[注3] 0-1 0 0 23入れる-IPX-ネットワーク[注3] 0-1 0-1 0-1 24ステート[注7] 0 + 0 25クラス[注3] 0 + 0 26ベンダー固有[注釈3] 0- 1 0 0 27セッションタイムアウト[注釈3] 0-1 0 0 28アイドルタイムアウト[注釈3] 0-1 0 0 29終了アクション[注釈3] [注-ステーション-IDと呼ばれる0-1 0 0 30 1] 0-1 0 0 31 [注1] 0-1 0 0 32 NAS-識別子[1] 0+ 0+ 0+ 33プロキシ-STA注のCalling-Station-Id TE 0-1 0 0 34ログイン-LAT-サービス[注3] 0-1 0 0 35ログイン-LATノード0-1 0 0 36ログイン-LAT-グループ[注3] [注3] 0-1 0 0 37入れる-のAppleTalkリンク0+ 0 0 38入れる-のAppleTalk、ネットワーク0-1 0 0 39入れる-のAppleTalkゾーン[注3] [注3] [注3] 0-1 0 0 44 ACCT-セッション - ID [注1] 0-1 0 0 50 ACCT-マルチセッションID [注1] 0-1 0-1 0-1 55イベントタイムスタンプ0-1 0 0 61 NASポート型[注1]要求ACK NAK番号属性
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
要求ACK NAK位項目0-1 0 0 62ポートリミット0-1 0 0 63ログイン-LATポート0+ 0 0 64トンネルタイプ[注3] [注3] [注釈5] 0 + 0 65トンネルミディアムタイプ0+ 0 0 66トンネルクライアントエンドポイント[注5] 0+ 0 0 67トンネル - サーバー - エンドポイントは0+ 0 0 69トンネル・パスワード[注5] [注5] [注5] 0 -1 0 0 71 ARAP-特徴[注3] 0-1 0 0 72 ARAPゾーンアクセス[注釈3] 0 + 0 78の構成トークン[注3] 0+ 0-1 0 79 EAP-メッセージ[注2] 0-1 0-1 0-1 80メッセージ認証0+ 0 0 81トンネルプライベートグループID [注5] 0 + 0 82トンネル割り当て-ID [注5] 0 + 0 83トンネル嗜好[注釈5] 0-1 0 0 85 ACCT-中間間隔[注釈3] 0-1 0 0 87 NAS-ポートID [注1] 0-1 0 0 88が入れるプール[注3 ] 0 + 0 90トンネルクライアント-AUTH-ID [注5] 0 + 0 91トンネルサーバー-AUTH-ID [注5] 0-1 0 0 94発信ライン情報[注1] 0- 1 0 0 95 NAS-のIPv6アドレス[注1] 0-1 0 0 96入れる-インタフェース-ID [注1] 0 + 0 97入れる-のIPv6プレフィックス[注1] 0 + 0 98ログイン・IPv6の-host [注釈3] 0 + 0 99入れる-のIPv6ルート[注3] 0 -1 0 0 100入れる-IPv6のプール[注釈3] 0 0 0 + 101エラー原因要求ACK NAK番号属性
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
要求ACK NAKの＃属性0-1 0 0 1ユーザ名0-1 0 0 4 NAS-IP-アドレス0-1 0 0 5 NAS-ポート0-1 0 [注1] [注1] [注1] 0-1 6サービスタイプ0-1 0 0 8入れるIPアドレスの0 + 0 18返信メッセージ[注1] [注6] [注2] 0-1 0-1 0-1 24ステート[ 7] 0 + 0 25クラス[注釈4] 0 + 0 26ベンダー固有0 0 30 0-1着信ステーション-ID [1] 0-1 0 0 31注音符発呼ステーション-ID [注1 ] 0-1 0 0 32 NAS-識別子[注1] 0+ 0+ 0+ 33プロキシ状態要求ACK NAK番号属性
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
要求ACK NAK位項目0-1 0 0 44アカウンティング・セッションId 0-1 0-1 0 49 ACCT-終了原因0-1 0 0 50 ACCT-マルチセッションID [注1] [注1] 0-1 0-1 0-1 55イベントタイムスタンプ0-1 0 0 61 NASポート型[注1] 0+ 0-1 0 79 EAP-メッセージ[注2] 0-1 0-1 0- 1 80メッセージ認証0-1 0 0 87 NAS-ポートID [注1] 0-1 0 0 94発信ライン情報[注1] 0-1 0 0 95 NAS-IPv6のアドレス[注1] 0-1 0 0 96入れる-インタフェース-ID [注1] 0 + 0 97入れる-のIPv6プレフィックス[注1] 0 0+ 0+ 101エラー原因要求ACK NAK番号属性
[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).
NAS又はセッション識別属性が切断リクエスト又はアシルCoA-Requestメッセージに含まれている場合[注1]、彼らは、識別目的でのみ使用されています。これらの属性は、（例えば、アシル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]返信メッセージ属性がユーザに表示メッセージを提示するために使用されます。メッセージのみ成功切断リクエストまたは（切断-ACK又はアシルCoA-ACKがその後送信される）のCoA-要求の結果として表示されます。 EAPは、認証に使用される場合、EAP-のメッセージ/通知-request属性には、代わりに送信され、接続解除-ACKまたはアシル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 - 要求内に含まれる場合、これらの属性は、承認変更要求を表します。これらの属性のいずれかがCoAをリクエストから省略された場合、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.
（切断-ACKがその後送信される）成功切断 - 要求内に含まれる場合、[注釈4]、クラス属性は、会計停止パケットに課金サーバーにクライアントによって修飾されていない送信されるべきです。外しリクエストが失敗した場合には、クラス属性は処理されません。
[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 - 要求内に含まれる場合、これらの属性は、承認変更要求を表します。トンネル属性（複数可）の成功のCoA-リクエスト内で送信されている場合は、すべての既存のトンネル属性が削除され、新しい属性（複数可）に置き換えられます。
[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]切断リクエスト又はアシルCoA - 要求内に含まれる場合、サービスタイプは、値と属性要求のみNASとセッション識別属性が含まれていることを示し、NASがアクセスを送信することによって、再承認を試みるべきであること「のみ承認」は値「のみ認可」とservice-type属性を持つ-request。これにより2つのプロトコル間の変換を容易に、直径がサポートされているものと類似の使用モデルを可能にします。 service-type属性のサポートは、COA要求および接続解除要求メッセージ内のオプションです。それが含まれていない場合、要求メッセージは、識別及び許可属性の両方を含んでいてもよいです。外しリクエスト内「のみ認可」の値でservice-type属性をサポートしていないNASは外し-NAK何service-type属性を含めないで応じなければなりません。値「サポートされていないサービス」とのエラー原因の属性が含まれるかもしれません。 CoAのリクエストの中に「のみ認可」の値でservice-type属性をサポートしていないNASにはservice-type属性を含めないの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.
値のservice-type属性を含む、それぞれの切断-NAKまたはCoAの-NAKで応答しなければなら外しリクエストまたはCoAのリクエストメッセージ内の「オーソライズのみ」サービスタイプ値をサポートするNAS「のみ認可」、およびエラー値が「開始された要求を」属性-Cause。 NASは、値「のみ認可」とservice-type属性をRADIUSサーバへのアクセス要求を送信します。このアクセス要求は、[RFC2865]で指定されたNASが切断またはCoAのリクエスト、並びにアクセス要求に含めるための法的要求からセッション属性から属性を含む、[RFC2868]、[RFC2869]と[SHOULD RFC3162]。 [RFC2869]のセクション5.19で述べたように、Message-Authenticatorアトリビュートは、ユーザーパスワード、CHAP-パスワード、ARAP - パスワードまたはEAP-メッセージ属性が含まれていないアクセス要求に含まれるべきです。 RADIUSサーバは、それを承認し、接続許可（再）セッションまたはアクセス拒否（再）に拒否することを承認するに送り返す必要があります。
[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
状態属性が切断リクエスト又はアシルCoA-Requestメッセージ内のNASにRADIUSサーバにより送信されるために利用可能であり、後続のACKまたはNAKメッセージにRADIUSサーバへのNASから修飾されていない送信されなければならない[注7]。値のservice-type属性を外しリクエストまたは状態属性と一緒のCoA-Requestに含まれている「だけ認可」場合には、国家の属性は、得られたAccess-RequestにRADIUSサーバへのNASからそのまま送らなければなりませんもしあれば、RADIUSサーバに送信されます。状態属性はまたRADIUSリクエストの値と属性終了-アクションを含んでいるのCoA-RequestにNASにRADIUSサーバが送信することが可能です。クライアントは、現在のセッションの終了時に、新たなアクセス要求を送信することにより終了アクションを実行する場合、それは国家を含まなければなりません
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.
そのアクセス要求に変わらない属性。いずれかの使用法では、クライアントは、ローカルに属性を解釈してはいけません。外しリクエストまたはアシルCoA-RequestパケットのState Attributeは0か1を持っている必要があります。州属性の使い方は実装依存です。 RADIUSサーバがアクセス要求における国家の属性を認識しない場合、それはアクセス拒否を送らなければなりません。
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]名前空間を使用し、<http://www.iana.org/assignments/radius-types>参照してください。 RADIUSパケットタイプコード：セクションのための6つのアップデートがあります。これらのパケットタイプは、[RADIANA]に割り当てられます。
40 - Disconnect-Request 41 - Disconnect-ACK 42 - Disconnect-NAK 43 - CoA-Request 44 - CoA-ACK 45 - CoA-NAK
40 - 切断 - 要求41 - 外し-ACK 42 - 外し-NAK 43 - アシルCoA - 要求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:
「唯一の認可」のための新たなサービスタイプ値の割り当てが要求されています。この文書はまた、UDP [RFC768]名前空間を使用し、<http://www.iana.org/assignments/port-numbers>参照してください。著者らは、登録ポート範囲からポート割り当てを要求します。最後に、この仕様は以下の小数点以下の値を持つエラー - 原因属性（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
開始503セッション・コンテキストが見つかりませんでした504セッション・コンテキスト取り外し不可505の他のプロキシ処理エラー506リソースの利用不可507リクエスト
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は、複数のプロバイダによって共有されている場合は1つのプロバイダを外しリクエストまたは別のプロバイダのセッションに影響を与えるの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を、要求が許可RADIUSサーバに由来することを確認するためにチェックを実行する必要があります。また、明示的に切断し、リクエストまたはセッションの特定のクラスに関係の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メッセージに含まれるセッション識別属性を使用します。切断リクエストまたはCoAをリクエストの送信元アドレスがこのセット内にある場合、その要求は転送されます。それ以外の場合は静かに捨てなければなりません。
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]から領域を抽出User-Name属性内に含まれる、プロキシルーティングテーブル内の対応するRADIUSサーバを決定します。そのレルムのためのRADIUSサーバは、パケットの送信元アドレスと比較されます。何の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を送信する許可を送信元アドレスと対応する共有秘密に基づいて決定されるので、のNASまたはプロキシは、各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サーバは、使用する秘密を共有したかを決定するためにRADIUS UDPパケットの送信元IPアドレスを使用する必要があります。
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-アドレスまたはNAS-IPv6のアドレス属性は、通常、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識別属性の正しさを確認しません。これは、それが可能に不正なNASはNAS-IP-アドレスを偽造できるようになり、NAS-のIPv6アドレスまたはNAS-Identifierが別のNASを偽装するために、RADIUSアクセス要求内の属性。不正なNASは、セッション識別は、または発信ライン情報[NASREQ]-駅-IDを呼び出し、呼び出され-駅-IDなどの属性偽造することも可能です。これは、攻撃者が標的と切り離しリクエストまたはCoAのリクエスト偽造セッション識別を含むメッセージNASに属性を送信するにRADIUSサーバをだますことができます。
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を参照）はNASから発信するパケットの送信元アドレスと一致するかどうかを確認する必要があります。 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アドレスに解決できないかもしれません。また、どこNATは実行可能ではないかもしれないNAS-IP-アドレスまたはNAS-IPv6のアドレス属性を確認し、RADIUSクライアントとプロキシの間に存在します。
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のメッセージに加えて、本文書に記載のプロトコル交換はRADIUS [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と一緒にIPsec [RFC2401]、[RFC2409]をサポートすべきです。 IPsecのESP null以外で[RFC2406]変換がサポートされるべきであり、IPsecのESP null以外の暗号化と変換し、認証サポートは、パケットごとの機密性、認証、完全性、リプレイ保護を提供するために使用されるべきです。 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アカウンティング[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の使用null以外のRADIUSアプリケーション層セキュリティの代わりに十分なセキュリティサービスを提供することができます変換。 IPsecのAHまたは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.
RADIUSが非ヌル変換でのIPsec ESP上で実行されている場合、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ポリシーは、IPsec SAが送信前RADIUSトラフィックにRADIUSクライアントによって設定されます。クライアントから連絡いくつかのRADIUSサーバがIPsecをサポートしていない場合は、よりきめ細かいポリシーが必要になります：「私からのIPsec対応のRADIUSサーバに、IPsecを開始し、宛先ポート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.
この仕様を実装するクライアントの場合、ポリシーは以下のようになります「宛先ポートUDP 3799私にいずれかから、IPsecを受け入れます」。これは、IPsecを使用する（必要ではない）を受け入れるようにRADIUSクライアントが発生します。一部の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ポリシー「には、いずれかからの私には、宛先ポート1812をIPsecを受け入れる」です。これは、IPsecを使用する（必要ではない）を受け入れるようにRADIUSサーバを引き起こします。一部の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拡張トラフィックを送信する際にIPsecを開始するRADIUSサーバが発生します。サーバーから連絡いくつかのRADIUSクライアントがIPsecをサポートしていない場合は、よりきめ細かいポリシーは、「私からのIPsec対応 - RADIUSクライアント、宛先ポート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アドレス（事前共有鍵とIKEアグレッシブモードの場合）または（証明書認証用）のFQDNで構成することができます。独立した認証局（CA）がRADIUSクライアントのために存在している場合あるいは、その後、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アグレッシブモードの場合）または（証明書認証のための）のFQDNで構成することができます。別のCAは、RADIUSサーバのために存在する場合あるいは、その後、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
RADIUSクライアントは、動的に（例えばアクセスポイント支持DHCPなど）、それらのIPアドレスを取得することができる場合は、このグループの使用を必要とするため、事前共有キーでメインモード[RFC2409]は、使用されるべきではありません
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クライアントのアドレスが静的に割り当てられている場合は、アグレッシブモードまたはメインモードのいずれかを使用することができます。証明書認証では、メインモードを使用する必要があります。
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のマッピングは、不可能です。結果として、ID_FQDNアイデンティティペイロードはアグレッシブモードが事前共有鍵および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のSAと交渉したものとは異なるセキュリティ・サービスのセットを必要とRADIUS交換が新しいIPsecのSAをネゴシエートする必要がありますようにIPsecで、セキュリティサービスは、IPsecのSAの粒度で交渉していることに注意してください。別々のIPsec SAのサービスの考慮事項の品質が異なる取り扱いRADIUSの会話を指示する場所にもお勧めです。同様の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サーバの両方が静かにイベントのタイムスタンプ属性を欠いているメッセージを破棄するように設定すべきである（SHOULD）。 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
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:
アカウンティング・セッション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
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:
フレームを選ぶ-IP-アドレスで接続解除要求：
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
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]ミルズ、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.、ベラー、M。およびR.カネッティ、 "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]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998.
[RFC2401]ケント、S.とR.アトキンソン、 "インターネットプロトコルのためのセキュリティー体系"、RFC 2401、1998年11月。
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998.
[RFC2406]ケント、S.とR.アトキンソン、 "IPカプセル化セキュリティペイロード（ESP）"、RFC 2406、1998年11月。
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998.
[RFC2409]ハーキンとD.とD.カレル、 "インターネットキー交換（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.、ウィレンス、S.、ルーベン、A.とW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W.およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、ゾルン、G.およびD.ミットン、 "RADIUSとIPv6"、RFC 3162、2001年8月。
[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.、ポーク、W.、フォード、W.およびD.ソロ、 "インターネット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]ミトン、D.、 "ネットワークアクセスサーバー要件：拡張RADIUSプラクティス"、RFC 2882、2000年7月。
[RFC2983] Black, D. "Differentiated Services and Tunnels", RFC 2983, October 2000.
[RFC2983]ブラック、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.、およびJ.ウッド、 "認証、認可およびアカウンティング（AAA）のトランスポート・プロファイル"、RFC 3539、2003年6月。
[Diameter] Calhoun, P., et al., "Diameter Base Protocol", Work in Progress.
[直径]カルフーン、P.、ら。、 "直径ベースプロトコル"、ProgressのWork。
[MD5Attack] Dobbertin, H., "The Status of MD5 After a Recent Attack", CryptoBytes Vol.2 No.2, Summer 1996.
[MD5Attack] Dobbertin、H.、 "最近の攻撃の後MD5の状況"、CryptoBytes第2巻第2号、夏1996。
[NASREQ] Calhoun, P., et al., "Diameter Network Access Server Application", Work in Progress.
[NASREQ]カルフーン、P.、ら。、 "直径ネットワークアクセスサーバーアプリケーション"、ProgressのWork。
[NTPAUTH] Mills, D., "Public Key Cryptography for the Network Time Protocol", Work in Progress.
[NTPAUTH]ミルズ、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は、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックとstandards-関連文書の権利に関する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.
このプロトコルは、最初の昇順通信によって開発され、配布されました。サンプルコードは、それらの自由サーバーキットで配布されました。
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>
アビLIOR <avi@bridgewatersystems.com>、ランディブッシュ<randy@psg.net>、スティーブBellovin氏<smb@research.att.com>グレンソーン<gwz@cisco.com>、マーク・ジョーンズ<mjones@bridgewatersystems.com> 、クラウディオLapidus <clapidus@hotmail.com>、アヌラーグバッタ<Anurag_Batta@3com.com>、Kuntalチョードリー<chowdury@nortelnetworks.com>、そしてティム・ムーア<timmoore@microsoft.com>。ラスHousley <housley@vigilsec.com>
Murtaza Chiba Cisco Systems, Inc. 170 West Tasman Dr. San Jose CA, 95134
Murtaza千葉シスコシステムズ、株式会社170西タスマン博士サンノゼCA、95134
EMail: mchiba@cisco.com Phone: +1 408 525 7198
メールアドレス：mchiba@cisco.com電話：+1 408 525 7198
Gopal Dommety Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
ゴパルDommetyシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134
EMail: gdommety@cisco.com Phone: +1 408 525 1404
メールアドレス：gdommety@cisco.com電話：+1 408 525 1404
Mark Eklund Cisco Systems, Inc. 170 West Tasman Dr. San Jose, CA 95134
マーク・エクランドシスコシステムズ、株式会社170西タスマン博士サンノゼ、CA 95134
EMail: meklund@cisco.com Phone: +1 865 671 6255
メールアドレス：meklund@cisco.com電話：+1 865 671 6255
David Mitton Circular Logic UnLtd. 733 Turnpike Street #154 North Andover, MA 01845
デヴィッド・ミトン円形ロジックUNLTD。 733ターンパイクストリート＃154ノースアンドーヴァー、MA 01845
EMail: david@mitton.com Phone: +1 978 683 1814
メールアドレス：david@mitton.com電話：+1 978 683 1814
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メールアドレス：bernarda@microsoft.com電話：+1 425 706 6605ファックス：+1 425 936 7329
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（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 Editor機能のための基金は現在、インターネット協会によって提供されます。