[要約] RFC 2869は、RADIUSプロトコルの機能を拡張するための追加属性を定義しています。主な拡張として、暫定アカウンティング更新（Interim Accounting Updates）、Apple Remote Access Protocol（ARAP）のサポート、およびRADIUS内でのExtensible Authentication Protocol（EAP）のサポートが含まれます。また、アカウンティングのためのギガワード属性なども導入しています。
Network Working Group C. Rigney
Request for Comments: 2869 Livingston
Category: Informational W. Willats
Cyno Technologies
P. Calhoun
Sun Microsystems
June 2000
RADIUS Extensions
RADIUS Extensions
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 (2000). All Rights Reserved.
著作権（C）インターネットソサエティ（2000）。全著作権所有。
Abstract
概要
This document describes additional attributes for carrying authentication, authorization and accounting information between a Network Access Server (NAS) and a shared Accounting Server using the Remote Authentication Dial In User Service (RADIUS) protocol described in RFC 2865 [1] and RFC 2866 [2].
このドキュメントでは、RFC 2865 [1]およびRFC 2866 [2]で記述されているRemote Authentication Dial In User Service (RADIUS) プロトコルを使用して、ネットワークアクセスサーバ (NAS) と共有アカウンティングサーバ間で認証、認可、およびアカウンティング情報を伝達するための追加属性について説明します。
Table of Contents
目次
1. Introduction .......................................... 2
1.1 Specification of Requirements ................... 3
1.2 Terminology ..................................... 3
2. Operation ............................................. 4
2.1 RADIUS support for Interim Accounting Updates.... 4
2.2 RADIUS support for Apple Remote Access
Protocol ........................................ 5
2.3 RADIUS Support for Extensible Authentication
Protocol (EAP) .................................. 11
2.3.1 Protocol Overview ............................... 11
2.3.2 Retransmission .................................. 13
2.3.3 Fragmentation ................................... 14
2.3.4 Examples ........................................ 14
2.3.5 Alternative uses ................................ 19
3. Packet Format ......................................... 19
4. Packet Types .......................................... 19
5. Attributes ............................................ 20
5.1 Acct-Input-Gigawords ............................ 22
5.2 Acct-Output-Gigawords ........................... 23
5.3 Event-Timestamp ................................. 23
5.4 ARAP-Password ................................... 24
5.5 ARAP-Features ................................... 25
5.6 ARAP-Zone-Access ................................ 26
5.7 ARAP-Security ................................... 27
5.8 ARAP-Security-Data .............................. 28
5.9 Password-Retry .................................. 28
5.10 Prompt .......................................... 29
5.11 Connect-Info .................................... 30
5.12 Configuration-Token ............................. 31
5.13 EAP-Message ..................................... 32
5.14 Message-Authenticator ........................... 33
5.15 ARAP-Challenge-Response ......................... 35
5.16 Acct-Interim-Interval ........................... 36
5.17 NAS-Port-Id ..................................... 37
5.18 Framed-Pool ..................................... 37
5.19 Table of Attributes ............................. 38
6. IANA Considerations ................................... 39
7. Security Considerations ............................... 39
7.1 Message-Authenticator Security .................. 39
7.2 EAP Security .................................... 39
7.2.1 Separation of EAP server and PPP authenticator .. 40
7.2.2 Connection hijacking ............................ 41
7.2.3 Man in the middle attacks ....................... 41
7.2.4 Multiple databases .............................. 41
7.2.5 Negotiation attacks ............................. 42
8. References ............................................ 43
9. Acknowledgements ...................................... 44
10. Chair's Address ....................................... 44
11. Authors' Addresses .................................... 45
12. Full Copyright Statement .............................. 47
RFC 2865 [1] describes the RADIUS Protocol as it is implemented and deployed today, and RFC 2866 [2] describes how Accounting can be performed with RADIUS.
RFC 2865 [1]は、現在実装および展開されているRADIUSプロトコルについて記述しており、RFC 2866 [2]はRADIUSを用いてアカウンティングを実行する方法を記述しています。
This memo suggests several additional Attributes that can be added to RADIUS to perform various useful functions. These Attributes do not have extensive field experience yet and should therefore be considered experimental.
このメモは、RADIUSに追加できる追加の属性を示して、さまざまな有用な機能を実行します。これらの属性はまだ広範な実地経験がないため、実験的なものと見なすべきです。
The Extensible Authentication Protocol (EAP) [3] is a PPP extension that provides support for additional authentication methods within PPP. This memo describes how the EAP-Message and Message-Authenticator attributes may be used for providing EAP support within RADIUS.
拡張認証プロトコル（EAP）[3]は、PPP内の追加の認証方法をサポートするための標準的なメカニズムを提供します。このメモでは、EAP-Message属性とMessage-Authenticator属性をRADIUS内でEAPサポートを提供するためにどのように使用できるかを説明します。
All attributes are comprised of variable length Type-Length-Value 3- tuples. New attribute values can be added without disturbing existing implementations of the protocol.
すべての属性は、可変長Type-Length-Value形式の3要素で構成されています。プロトコルの既存の実装を妨げることなく、新しい属性値を追加できます。
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 RFC 2119 [4].
この文書におけるキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、「OPTIONAL」は、RFC 2119 [4]に記載されているように解釈されます。
An implementation is not compliant if it fails to satisfy one or more of the must or must not requirements for the protocols it implements. An implementation that satisfies all the must, must not, should and should not requirements for its protocols is said to be "unconditionally compliant"; one that satisfies all the must and must not requirements but not all the should or should not requirements for its protocols is said to be "conditionally compliant."
実装が、それが実装するプロトコルに対する「MUST」または「MUST NOT」の要件の1つ以上を満たさない場合、それは準拠していません。プロトコルに対するすべての「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」の要件を満たす実装は、「無条件に準拠している（unconditionally compliant）」と言われます。すべての「MUST」および「MUST NOT」の要件を満たすが、すべての「SHOULD」または「SHOULD NOT」の要件を満たさない実装は、「条件付きで準拠している（conditionally compliant）」と言われます。
A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer ARAP service MUST NOT implement the RADIUS attributes for ARAP. A NAS MUST treat a RADIUS access-request requesting an unavailable service as an access-reject instead.
特定のサービスを実装していないNASは、そのサービスのRADIUS属性を実装してはなりません。たとえば、ARAPサービスを提供できないNASは、ARAPのRADIUS属性を実装してはなりません。NASは、利用できないサービスを要求するRADIUSアクセス要求をAccess-Rejectとして扱う必要があります。
This document uses the following terms:
この文書では以下の用語を使用します。
service The NAS provides a service to the dial-in user, such as PPP or Telnet.
サービス：NASは、PPPやTelnetなどのダイヤルインユーザーにサービスを提供します。
session Each service provided by the NAS to a dial-in 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, with each session generating a separate start and stop accounting record.
セッション：NASによってダイヤルインユーザーに提供される各サービスはセッションを構成します。セッションの開始はサービスが最初に提供された時点と定義され、セッションの終了はサービスが終了した時点と定義されます。NASがそれをサポートしている場合、ユーザーは並列または連続して複数のセッションを持つことができ、各セッションは個別の開始および停止アカウンティングレコードを生成します。
silently discard This means the implementation discards the packet without further processing. The implementation SHOULD provide the capability of logging the error, including the contents of the silently discarded packet, and SHOULD record the event in a statistics counter.
サイレントに破棄：これは、実装がそれ以上の処理なしにパケットを破棄することを意味します。実装は、サイレントに破棄されたパケットの内容を含め、エラーをログに記録する機能を提供すべきであり、統計カウンタにイベントを記録すべきです。
Operation is identical to that defined in RFC 2865 [1] and RFC 2866 [2].
操作はRFC 2865 [1]およびRFC 2866 [2]で定義されているものと同じです。
When a user is authenticated, a RADIUS server issues an Access-Accept in response to a successful Access-Request. If the server wishes to receive interim accounting messages for the given user it must include the Acct-Interim-Interval RADIUS attribute in the message, which indicates the interval in seconds between interim messages.
ユーザーが認証されると、RADIUSサーバーは成功したAccess-Requestに応答してAccess-Acceptを発行します。サーバーが特定のユーザーに対して暫定アカウンティングメッセージを受信したい場合は、メッセージ内にAcct-Interim-Interval RADIUS属性を含める必要があります。これは、暫定メッセージ間の間隔を秒単位で示します。
It is also possible to statically configure an interim value on the NAS itself. Note that a locally configured value on the NAS MUST override the value found in an Access-Accept.
NAS自体に暫定値を静的に設定することも可能です。NAS上のローカルに設定された値は、Access-Accept内の値を上書きする必要があります。
This scheme does not break backward interoperability since a RADIUS server not supporting this extension will simply not add the new Attribute. NASes not supporting this extension will ignore the Attribute.
この拡張機能をサポートしていないRADIUSサーバーは新しい属性を単純に追加しないため、このスキームは下位互換性を損なうことはありません。この拡張機能をサポートしていないNASesは、その属性を無視します。
Note that all information in an interim message is cumulative (i.e. number of packets sent is the total since the beginning of the session, not since the last interim message).
暫定メッセージ内のすべての情報は累積的であることに注意してください（すなわち、送信されたパケットの数は、最後の中間メッセージ以降ではなく、セッション開始時からの合計です）。
It is envisioned that an Interim Accounting record (with Acct-Status-Type = Interim-Update (3)) would contain all of the attributes normally found in an Accounting Stop message with the exception of the Acct-Term-Cause attribute.
暫定アカウンティングレコード（Acct-Status-Type = Interim-Update (3)を持つ）には、Acct-Term-Cause属性を除く、アカウンティング停止メッセージに通常見られるすべての属性が含まれると想定されます。
Since all the information is cumulative, a NAS MUST ensure that only a single generation of an interim Accounting message for a given session is present in the retransmission queue at any given time.
すべての情報が累積的であるため、NASは、特定のセッションの暫定アカウンティングメッセージの単一の生成のみが、常に再送信キューに存在することを確実にしなければなりません。
A NAS MAY use a fudge factor to add a random delay between Interim Accounting messages for separate sessions. This will ensure that a cycle where all messages are sent at once is prevented, such as might otherwise occur if a primary link was recently restored and many dial-up users were directed to the same NAS at once.
NASは、別々のセッションの暫定アカウンティングメッセージ間にランダムな遅延を追加するためにファッジファクタを使用してもよいです。これにより、すべてのメッセージが一度に送信されるサイクルが防止されます。これは、プライマリリンクが最近復元され、多くのダイヤルアップユーザーが一度に同じNASに接続された場合に発生する可能性があります。
The Network and NAS CPU load of using Interim Updates should be carefully considered, and appropriate values of Acct-Interim-Interval chosen.
暫定更新の使用によるネットワークおよびNASのCPU負荷は慎重に検討し、Acct-Interim-Intervalの適切な値を選択すべきです。
The RADIUS (Remote Authentication Dial-In User Service) protocol provides a method that allows multiple dial-in Network Access Server (NAS) devices to share a common authentication database.
RADIUS（リモート認証ダイヤルインユーザーサービス）プロトコルは、複数のダイヤルインネットワークアクセスサーバ（NAS）デバイスが共通認証データベースを共有できるようにする方法を提供します。
The Apple Remote Access Protocol (ARAP) provides a method for sending AppleTalk network traffic over point-to-point links, typically, but not exclusively, asynchronous and ISDN switched-circuit connections. Though Apple is moving toward ATCP on PPP for future remote access services, ARAP is still a common way for the installed base of Macintosh users to make remote network connections, and is likely to remain so for some time.
Apple Remote Access Protocol（ARAP）は、通常、非同期およびISDN回線交換接続を介して、ただしそれに限定されず、ポイントツーポイントリンクを介してAppleTalkネットワークトラフィックを送信する方法を提供します。Appleは将来のリモートアクセスサービスとしてPPP上のATCPに移行しつつありますが、ARAPは依然としてMacintoshユーザーの既存の利用者がリモートネットワーク接続を行う一般的な方法であり、しばらくの間は引き続き使用される可能性が高いです。
ARAP is supported by several NAS vendors who also support PPP, IPX and other protocols in the same NAS. ARAP connections in these multi-protocol devices are often not authenticated with RADIUS, or if they are, each vendor creates an individual solution to the problem.
ARAPは、同じNAS内でPPP、IPX、およびその他のプロトコルもサポートするいくつかのNASベンダーによってサポートされています。これらのマルチプロトコルデバイスにおけるARAP接続は、RADIUSで認証されないことが多く、RADIUSで認証される場合でも、各ベンダーが問題に対する個別の解決策を作成しています。
This section describes the use of additional RADIUS attributes to support ARAP. RADIUS client and server implementations that implement this specification should be able to authenticate ARAP connections in an interoperable manner.
このセクションでは、ARAPをサポートするための追加のRADIUS属性の使用について説明します。この仕様を実装するRADIUSクライアントおよびサーバー実装は、相互運用可能な方法でARAP接続を認証できるようにする必要があります。
This section assumes prior knowledge of RADIUS, and will go into some detail on the operation of ARAP before entering a detailed discussion of the proposed ARAP RADIUS attributes.
このセクションはRADIUSの事前の知識を前提としており、提案されているARAP RADIUS属性の詳細な議論に入る前に、ARAPの操作についていくつかの詳細を説明します。
There are two features of ARAP this document does not address:
このドキュメントでは、ARAPの以下の2つの機能については扱っていません。
1. User initiated password changing. This is not part of RADIUS, but can be implemented through a software process other than RADIUS.
1. ユーザーによるパスワード変更の開始。これはRADIUSの一部ではありませんが、RADIUS以外のソフトウェアプロセスを通じて実装できます。
2. Out-of-Band messages. At any time, the NAS can send messages to an ARA client which appear in a dialog box on the dial-in user's screen. These are not part of authentication and do not belong here. However, we note that a Reply-Message attribute in an Access-Accept may be sent down to the user as a sign-on message of the day string using the out-of-band channel.
2. 帯域外メッセージ。いつでも、NASはダイヤルインユーザーの画面にダイアログボックスとして表示されるメッセージをARAクライアントに送信できます。これらは認証の一部ではなく、ここに含めるべきではありません。ただし、Access-Accept内のReply-Message属性は、帯域外チャネルを使用してその日のサインオンメッセージ文字列としてユーザーに送信される場合があることに注意してください。
We have tried to respect the spirit of the existing RADIUS protocol as much as possible, making design decisions compatible with prior art. Further, we have tried to strike a balance between flooding the RADIUS world with new attributes, and hiding all of ARAP operation within a single multiplexed ARAP attribute string or within Extended Authentication Protocol (EAP) [3] machinery.
我々は、既存のRADIUSプロトコルの精神を可能な限り尊重し、先行技術と互換性のある設計上の決定を行いました。さらに、我々は新しい属性でRADIUSの世界を溢れさせることと、単一の多重化されたARAP属性文字列内または拡張認証プロトコル（EAP）[3]のメカニズム内にARAPのすべての操作を隠すことのバランスを取ろうとしました。
However, we feel ARAP is enough of a departure from PPP to warrant a small set of similarly named attributes of its own.
しかし、我々はARAPがPPPからの十分な逸脱であり、それ自身の同様の名前の属性の小さなセットを正当化すると感じています。
We have assumed that an ARAP-aware RADIUS server will be able to do DES encryption and generate security module challenges. This is in keeping with the general RADIUS goal of smart server / simple NAS.
我々は、ARAP対応のRADIUSサーバーがDES暗号化を行い、セキュリティモジュールのチャレンジを生成できると仮定しました。これは、スマートサーバー/シンプルNASというRADIUSの一般的な目標と合致しています。
ARAP authenticates a connection in two phases. The first is a "Two-Way DES" random number exchange, using the user's password as a key. We say "Two-Way" because the ARAP NAS challenges the dial-in client to authenticate itself, and the dial-in client challenges the ARAP NAS to authenticate itself.
ARAPは接続を2つのフェーズで認証します。最初のフェーズは、ユーザーのパスワードをキーとして使用する「双方向DES」乱数交換です。「双方向」と呼ぶのは、ARAP NASがダイヤルインクライアントに自身を認証するよう要求し、ダイヤルインクライアントがARAP NASに自身を認証するよう要求するからです。
Specifically, ARAP does the following:
具体的には、ARAPは次のことを行います。
1. The NAS sends two 32-bit random numbers to the dial-in client in an ARAP msg_auth_challenge packet.
1. NASは、ARAP msg_auth_challengeパケットで、2つの32ビット乱数をダイヤルインクライアントに送信します。
2. The dial-in client uses the user's password to DES encrypt the two random numbers sent to it by the NAS. The dial-in client then sends this result, the user's name and two 32-bit random numbers of its own back to the NAS in an ARAP msg_auth_request packet.
2. ダイヤルインクライアントは、ユーザーのパスワードを使用して、NASから送信された2つの乱数をDES暗号化します。次に、ダイヤルインクライアントは、この結果、ユーザー名、および自身の2つの32ビット乱数をARAP msg_auth_requestパケットでNASに送り返します。
3. The NAS verifies the encrypted random numbers sent by the dial-in client are what it expected. If so, it encrypts the dial-in client's challenge using the password and sends it back to the dial-in client in an ARAP msg_auth_response packet.
3. NASは、ダイヤルインクライアントから送信された暗号化された乱数が期待どおりであることを検証します。もしそうであれば、パスワードを使用してダイヤルインクライアントのチャレンジを暗号化し、ARAP msg_auth_responseパケットでダイヤルインクライアントに送り返します。
Note that if the dial-in client's response was wrong, meaning the user has the wrong password, the server can initiate a retry sequence up to the maximum amount of retries allowed by the NAS. In this case, when the dial-in client receives the ARAP msg_auth_response packet it will acknowledge it with an ARAP msg_auth_again packet.
ダイヤルインクライアントの応答が間違っていた場合、すなわちユーザーのパスワードが間違っていた場合、サーバーはNASによって許可されている最大再試行回数まで再試行シーケンスを開始できます。この場合、ダイヤルインクライアントがARAP msg_auth_responseパケットを受信すると、ARAP msg_auth_againパケットでそれを確認します。
After this first "DES Phase" the ARAP NAS MAY initiate a secondary authentication phase using what Apple calls "Add-In Security Modules." Security Modules are small pieces of code which run on both the client and server and are allowed to read and write arbitrary data across the communications link to perform additional authentication functions. Various security token vendors use this mechanism to authenticate ARA callers.
この最初の「DESフェーズ」の後、ARAP NASは、Appleが「アドインセキュリティモジュール」と呼ぶものを使用して二次認証フェーズを開始してもよいです。セキュリティモジュールは、クライアントとサーバーの両方で実行され、通信リンクを介して任意のデータを読み書きし、追加の認証機能を実行することを許可された小さなコードです。さまざまなセキュリティトークンベンダーがこのメカニズムを使用してARA発信者を認証します。
Although ARAP allows security modules to read and write anything they like, all existing security modules use simple challenge and response cycles, with perhaps some overall control information. This document assumes all existing security modules can be supported with one or more challenge/response cycles.
ARAPはセキュリティモジュールが任意のデータを読み書きすることを許可していますが、既存のすべてのセキュリティモジュールは、おそらくいくつかの全体的な制御情報とともに、単純なチャレンジ/レスポンスサイクルを使用しています。この文書は、既存のすべてのセキュリティモジュールが1つ以上のチャレンジ/レスポンスサイクルでサポートできると想定しています。
To complicate RADIUS and ARAP integration, ARAP sends down some profile information after the DES Phase and before the Security Module phase. This means that besides the responses to challenges, this profile information must also be present, at somewhat unusual times. Fortunately the information is only a few pieces of numeric data related to passwords, which this document packs into a single new attribute.
RADIUSとARAPの統合を複雑にするために、ARAPはDESフェーズの後、およびセキュリティモジュールフェーズの前にいくつかのプロファイル情報を送信します。これは、課題への応答に加えて、このプロファイル情報も多少通常とは異なるタイミングで存在しなければならないことを意味します。幸いなことに、この情報はパスワードに関連する少数の数値データのみであり、このドキュメントでは単一の新しい属性にまとめられています。
Presenting an Access-Request to RADIUS on behalf of an ARAP connection is straightforward. The ARAP NAS generates the random number challenge, and then receives the dial-in client's response, the dial-in client's challenge, and the user's name. Assuming the user is not a guest, the following information is forwarded in an Access-Request packet: User-Name (up to 31 characters long), Framed-Protocol (set to 3, ARAP), ARAP-Password, and any additional attributes desired, such as Service-Type, NAS-IP-Address, NAS-Id, NAS-Port-Type, NAS-Port, NAS-Port-Id, Connect-Info, etc.
ARAP接続に代わってRADIUSにAccess-Requestを提示することは簡単です。ARAP NASは乱数チャレンジを生成し、ダイヤルインクライアントの応答、ダイヤルインクライアントのチャレンジ、およびユーザーの名前を受け取ります。ユーザーがゲストではないと仮定すると、User-Name（最大31文字）、Framed-Protocol（3、ARAPに設定）、ARAP-Password、およびService-Type、NAS-IP-Address、NAS-Id、NAS-Port-Type、NAS-Port、NAS-Port-Id、Connect-Infoなどの追加の属性がAccess-Requestパケットで転送されます。
The Request Authenticator is a NAS-generated 16 octet random number. The low-order 8 octets of this number are sent to the dial-in user as the two 4 octet random numbers required in the ARAP msg_auth_challenge packet. Octets 0-3 are the first random number and Octets 4-7 are the second random number.
リクエストオーセンティケータは、NASで生成された16オクテットの乱数です。この乱数の下位8オクテットは、ARAP msg_auth_challengeパケットで要求される2つの4オクテット乱数として、ダイヤルインユーザーに送信されます。オクテット0-3は最初の乱数であり、オクテット4-7は2番目の乱数です。
The ARAP-Password in the Access-Request contains a 16 octet random number field, and is used to carry the dial-in user's response to the NAS challenge and the client's own challenge to the NAS. The high-order octets contain the dial-in user's challenge to the NAS (2 32- bit numbers, 8 octets) and the low-order octets contain the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets).
Access-Request内のARAP-Passwordには16オクテットの乱数フィールドが含まれており、ダイヤルインユーザーのNASチャレンジへの応答とクライアント自身のNASへのチャレンジを伝達するために使用されます。上位オクテットには、ダイヤルインユーザーのNASへのチャレンジ（32ビット数2個、8オクテット）が含まれ、下位オクテットには、ダイヤルインユーザーのNASチャレンジへの応答（32ビット数2個、8オクテット）が含まれています。
Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages.
User-Password、CHAP-Password、またはARAP-Passwordのいずれか1つのみがAccess-Requestに存在するか、または1つ以上のEAP-Messagesが存在する必要があります。
If the RADIUS server does not support ARAP it SHOULD return an Access-Reject to the NAS.
RADIUSサーバーがARAPをサポートしていない場合は、NASにAccess-Rejectを返すべきです。
If the RADIUS server does support ARAP, it should verify the user's response using the Challenge (from the lower order 8 octets of the Request Authenticator) and the user's response (from the low order 8 octets of the ARAP-Password).
RADIUSサーバーがARAPをサポートしている場合は、チャレンジ（リクエストオーセンティケータの下位8オクテットから）とユーザーの応答（ARAP-Passwordの下位8オクテットから）を使用して、ユーザーの応答を検証すべきです。
If that authentication fails, the RADIUS server should return an Access-Reject packet to the NAS, with optional Password-Retry and Reply-Messages attributes. The presence of Password-Retry indicates the ARAP NAS MAY choose to initiate another challenge-response cycle, up to a total number of times equal to the integer value of the Password-Retry attribute.
その認証が失敗した場合、RADIUSサーバーは、オプションのPassword-Retry属性とReply-Message属性とともに、NASにAccess-Rejectパケットを返すべきです。Password-Retryの存在は、ARAP NASがPassword-Retry属性の整数値に等しい合計回数まで、別のチャレンジ/レスポンスサイクルを開始してもよいことを示します。
If the user is authenticated, the RADIUS server should return an Access-Accept packet (Code 2) to the NAS, with ID and Response Authenticator as usual, and attributes as follows:
ユーザーが認証された場合、RADIUSサーバーは、通常どおりIDとResponse Authenticatorとともに、Access-Acceptパケット（コード2）をNASに返すべきであり、属性は以下のとおりです。
Service-Type of Framed-Protocol.
Service-Type属性（Framed-Protocol）
Framed-Protocol of ARAP (3).
Framed-Protocol属性（ARAP (3)）
Session-Timeout with the maximum connect time for the user in seconds. If the user is to be given unlimited time, Session-Timeout should not be included in the Access-Accept packet, and ARAP will treat that as an unlimited timeout (-1).
ユーザーの最大接続時間を秒単位で示すSession-Timeout。ユーザーに無制限の時間が与えられる場合、Session-TimeoutはAccess-Acceptパケットに含めるべきではなく、ARAPはそれを無制限のタイムアウト（-1）として扱います。
ARAP-Challenge-Response, containing 8 octets with the response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key. If the user's password is greater than 8 octets in length, an Access-Reject MUST be sent instead.
ARAP-Challenge-Response。ダイヤルインクライアントのチャレンジに対する応答を含む8オクテット。RADIUSサーバーは、ARAP-Password属性の上位8オクテットからダイヤルインクライアントのチャレンジを取得し、認証ユーザーのパスワードをキーとしてこの値にDES暗号化を実行することで、この値を計算します。ユーザーのパスワードの長さが8オクテット未満の場合、パスワードはキーとして使用する前に、NULLオクテットで末尾を8オクテットの長さまでパディングします。ユーザーのパスワードの長さが8オクテットを超える場合、代わりにAccess-Rejectが送信されなければなりません。
ARAP-Features, containing information that the NAS should send to the user in an ARAP "feature flags" packet.
ARAP-Features。NASがARAPの「機能フラグ」パケットでユーザーに送信すべき情報を含みます。
Octet 0: If zero, user cannot change their password. If non-zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.)
オクテット0：ゼロの場合、ユーザーはパスワードを変更できません。ゼロ以外の場合、ユーザーは変更できます。（RADIUSはパスワードの変更を処理しません。単にARAPが変更可能かどうかを示す属性です。）
Octet 1: Minimum acceptable password length (0-8).
オクテット1：許容可能な最小パスワード長（0-8）。
Octet 2-5: Password creation date in Macintosh format, defined as 32 bits unsigned representing seconds since Midnight GMT January 1, 1904.
オクテット2-5：Macintosh形式のパスワード作成日。1904年1月1日GMTの真夜中からの秒数を表す32ビットの符号なし整数として定義されます。
Octet 6-9 Password Expiration Delta from create date in seconds.
オクテット6-9：作成日からのパスワード有効期限の差（秒単位）。
Octet 10-13: Current RADIUS time in Macintosh format
オクテット10-13：Macintosh形式の現在のRADIUS時間
Optionally, a single Reply-Message with a text string up to 253 characters long which MAY be sent down to the user to be displayed in a sign-on/message of the day dialog.
オプションとして、最大253文字の長さのテキスト文字列を持つ単一のReply-Messageは、サインオン/今日のメッセージダイアログに表示するためにユーザーに送信されてもよいです。
Framed-AppleTalk-Network may be included.
Framed-AppleTalk-Networkを含めることができます。
Framed-AppleTalk-Zone, up to 32 characters in length, may be included.
最大32文字の長さのFramed-AppleTalk-Zoneを含めることができます。
ARAP defines the notion of a list of zones for a user. Along with a list of zone names, a Zone Access Flag is defined (and used by the NAS) which says how to use the list of zone names. That is, the dial-in user may only be allowed to see the Default Zone, or only the zones in the zone list (inclusive) or any zone except those in the zone list (exclusive).
ARAPは、ユーザーのゾーンリストの概念を定義します。ゾーン名のリストとともに、ゾーンアクセスフラグが定義され（NASによって使用され）、ゾーン名のリストの使用方法を示します。すなわち、ダイヤルインユーザーはデフォルトゾーンのみ、またはゾーンリスト内のゾーンのみ（包括的）、あるいはゾーンリスト内のゾーンを除くすべてのゾーン（排他的）を見ることが許可される場合があります。
The ARAP NAS handles this by having a named filter which contains (at least) zone names. This solves the problem where a single RADIUS server is managing disparate NAS clients who may not be able to "see" all of the zone names in a user zone list. Zone names only have meaning "at the NAS." The disadvantage of this approach is that zone filters must be set up on the NAS somehow, then referenced by the RADIUS Filter-Id.
ARAP NASは、ゾーン名を含む名前付きフィルターを持つことでこれを処理します。これは、単一のRADIUSサーバーが、ユーザーゾーンリスト内のすべてのゾーン名を「見る」ことができない異なるNASクライアントを管理している問題を解決します。ゾーン名は「NASにおいて」のみ意味を持ちます。このアプローチの欠点は、ゾーンフィルターを何らかの方法でNASに設定し、その後RADIUS Filter-Idによって参照する必要があることです。
ARAP-Zone-Access contains an integer which specifies how the "zone list" for this user should be used. If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to.
ARAP-Zone-Accessには、このユーザーの「ゾーンリスト」をどのように使用すべきかを指定する整数が含まれています。この属性が存在し、値が2または4の場合、アクセスフラグを適用するゾーンリストフィルターを指定するために、Filter-Idも存在しなければなりません。
The inclusion of a Callback-Number or Callback-Id attribute in the Access-Accept MAY cause the ARAP NAS to disconnect after sending the Feature Flags to begin callback processing in an ARAP specific way.
Access-AcceptにCallback-NumberまたはCallback-Id属性を含めることは、機能フラグを送信した後、ARAP固有の方法でコールバック処理を開始するために、ARAP NASを切断させる可能性があります。
Other attributes may be present in the Access-Accept packet as well.
他の属性もAccess-Acceptパケットに存在してもよいです。
An ARAP NAS will need other information to finish bringing up the connection to the dial in client, but this information can be provided by the ARAP NAS without any help from RADIUS, either through configuration by SNMP, a NAS administration program, or deduced by the AppleTalk stack in the NAS. Specifically:
ARAP NASは、ダイヤルインクライアントへの接続を確立するために他の情報を必要としますが、この情報はRADIUSからの助けなしに、SNMPによる設定、NAS管理プログラム、またはNAS内のAppleTalkスタックによって提供されることがあります。具体的には：
1. AppearAsNet and AppearAsNode values, sent to the client to tell it what network and node numbers it should use in its datagram packets. AppearAsNet can be taken from the Framed-AppleTalk-Network attribute or from the configuration or AppleTalk stack onthe NAS.
1. クライアントに送信されるAppearAsNetおよびAppearAsNodeの値は、データグラムパケットで使用すべきネットワーク番号とノード番号をクライアントに伝えます。AppearAsNetは、Framed-AppleTalk-Network属性から、またはNAS上の構成もしくはAppleTalkスタックから取得できます。
2. The "default" zone - that is the name of the AppleTalk zone in which the dial-in client will appear. (Or can be specified with the Framed-AppleTalk-Zone attribute.)
2. 「デフォルト」ゾーン - ダイヤルインクライアントが表示されるAppleTalkゾーンの名前です。（またはFramed-AppleTalk-Zone属性で指定できます。）
3. Other very NAS specific stuff such as the name of the NAS, and smartbuffering information. (Smartbuffering is an ARAP mechanism for replacing common AppleTalk datagrams with small tokens, to improve slow link performance in a few common traffic situations.)
3. NASの名前やSmartBuffering情報など、NASに非常に特有なその他の事項。（SmartBufferingは、いくつかの一般的なトラフィック状況において低速リンクのパフォーマンスを向上させるために、一般的なAppleTalkデータグラムを小さなトークンに置き換えるためのARAPメカニズムです。）
4. "Zone List" information for this user. The ARAP specification defines a "zone count" field which is actually unused.
4. このユーザーの「ゾーンリスト」の情報。ARAP仕様は、実際には未使用の「ゾーン数」フィールドを定義します。
RADIUS supports ARAP Security Modules in the following manner.
RADIUSは以下の方法でARAPセキュリティモジュールをサポートします。
After DES authentication has been completed, the RADIUS server may instruct the ARAP NAS to run one or more security modules for the dial-in user. Although the underlying protocol supports executing multiple security modules in series, in practice all current implementations only allow executing one. Through the use of multiple Access-Challenge requests, multiple modules can be supported, but this facility will probably never be used.
DES認証が完了した後、RADIUSサーバーはARAP NASにダイヤルインユーザーのために1つ以上のセキュリティモジュールを実行するよう指示してもよいです。基盤となるプロトコルは複数のセキュリティモジュールを連続して実行することをサポートしていますが、実際には現在のすべての実装は1つしか実行できません。複数のAccess-Challengeリクエストを使用することで複数のモジュールをサポートできますが、この機能がおそらく使用されることはありません。
We also assume that, even though ARAP allows a free-form dialog between security modules on each end of the point-to-point link, in actual practice all security modules can be reduced to a simple challenge/response cycle.
また、ARAPがポイントツーポイントリンクの両端にあるセキュリティモジュール間の自由形式のダイアログを許可しているとしても、実際のところ、すべてのセキュリティモジュールは単純なチャレンジ/レスポンスサイクルに還元できると仮定しています。
If the RADIUS server wishes to instruct the ARAP NAS to run a security module, it should send an Access-Challenge packet to the NAS with (optionally) the State attribute, plus the ARAP-Challenge-Response, ARAP-Features, and two more attributes: ARAP-Security: a four octet security module signature, containing a Macintosh OSType.
RADIUSサーバーがARAP NASにセキュリティモジュールを実行するよう指示したい場合、(オプションで)State属性、ARAP-Challenge-Response、ARAP-Features、およびさらに2つの属性（ARAP-Security: Macintosh OSTypeを含む4オクテットのセキュリティモジュール署名）を伴うAccess-ChallengeパケットをNASに送信すべきです。
ARAP-Security-Data, a string to carry the actual security module challenge and response.
ARAP-Security-Data。実際のセキュリティモジュールのチャレンジと応答を伝達するための文字列。
When the security module finishes executing, the security module response is passed in an ARAP-Security-Data attribute from the NAS to the RADIUS server in a second Access-Request, also including the State from the Access-Challenge. The authenticator field contains no special information in this case, and this can be discerned by the presence of the State attribute.
セキュリティモジュールが実行を終了すると、セキュリティモジュールの応答は、2番目のAccess-RequestでNASからRADIUSサーバーへARAP-Security-Data属性で渡され、Access-ChallengeからのStateも含まれます。この場合、Authenticatorフィールドには特別な情報は含まれておらず、これはState属性の存在によって識別できます。
The Extensible Authentication Protocol (EAP), described in [3], provides a standard mechanism for support of additional authentication methods within PPP. Through the use of EAP, support for a number of authentication schemes may be added, including smart cards, Kerberos, Public Key, One Time Passwords, and others. In order to provide for support of EAP within RADIUS, two new attributes, EAP-Message and Message-Authenticator, are introduced in this document. This section describes how these new attributes may be used for providing EAP support within RADIUS.
[3]に記載されている拡張認証プロトコル（EAP）は、PPP内の追加の認証方法をサポートするための標準的なメカニズムを提供します。EAPを使用することで、スマートカード、Kerberos、公開鍵、ワンタイムパスワードなどを含む、いくつかの認証方式のサポートを追加することができます。RADIUS内でEAPのサポートを提供するために、この文書ではEAP-MessageとMessage-Authenticatorの2つの新しい属性が導入されています。このセクションでは、RADIUS内でEAPサポートを提供するためにこれらの新しい属性をどのように使用できるかを説明します。
In the proposed scheme, the RADIUS server is used to shuttle RADIUS-encapsulated EAP Packets between the NAS and a backend security server. While the conversation between the RADIUS server and the backend security server will typically occur using a proprietary protocol developed by the backend security server vendor, it is also possible to use RADIUS-encapsulated EAP via the EAP-Message attribute. This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code, which can instead reside on the backend security server.
提案されたスキームでは、RADIUSサーバーはNASとバックエンドセキュリティサーバー間でRADIUSカプセル化されたEAPパケットをシャトルするために使用されます。RADIUSサーバーとバックエンドセキュリティサーバー間の通信は通常、バックエンドセキュリティサーバーベンダーによって開発された独自のプロトコルを使用して行われますが、EAP-Message属性を介してRADIUSカプセル化EAPを使用することも可能です。これにより、RADIUSサーバー内で認証固有のコードを必要とせずにEAPをサポートできるという利点があり、認証固有のコードは代わりにバックエンドセキュリティサーバーに配置できます。
The EAP conversation between the authenticating peer (dial-in user) and the NAS begins with the negotiation of EAP within LCP. Once EAP has been negotiated, the NAS MUST send an EAP-Request/Identity message to the authenticating peer, unless identity is determined via some other means such as Called-Station-Id or Calling-Station-Id. The peer will then respond with an EAP-Response/Identity which the the NAS will then forward to the RADIUS server in the EAP-Message attribute of a RADIUS Access-Request packet. The RADIUS Server will typically use the EAP-Response/Identity to determine which EAP type is to be applied to the user.
認証ピア（ダイヤルインユーザー）とNAS間のEAP会話は、LCP内でのEAPのネゴシエーションから始まります。EAPがネゴシエートされたら、Called-Station-IdやCalling-Station-Idなどの他の手段によってIDが決定されない限り、NASは認証ピアにEAP-Request/Identityメッセージを送信しなければなりません。ピアはEAP-Response/Identityで応答し、それをNASはRADIUS Access-RequestパケットのEAP-Message属性でRADIUSサーバーに転送します。RADIUSサーバーは通常EAP-Response/Identityを使用して、どのEAPタイプをユーザーに適用するかを決定します。
In order to permit non-EAP aware RADIUS proxies to forward the Access-Request packet, if the NAS sends the EAP-Request/Identity, the NAS MUST copy the contents of the EAP-Response/Identity into the User-Name attribute and MUST include the EAP-Response/Identity in the User-Name attribute in every subsequent Access-Request. NAS-Port or NAS-Port-Id SHOULD be included in the attributes issued by the NAS in the Access-Request packet, and either NAS-Identifier or NAS-IP-Address MUST be included. In order to permit forwarding of the Access-Reply by EAP-unaware proxies, if a User-Name attribute was included in an Access-Request, the RADIUS Server MUST include the User-Name attribute in subsequent Access-Accept packets. Without the User-Name attribute, accounting and billing becomes very difficult to manage.
EAPを認識しないRADIUSプロキシがAccess-Requestパケットを転送できるようにするため、NASがEAP-Request/Identityを送信する場合、NASはEAP-Response/Identityの内容をUser-Name属性にコピーし、それ以降のすべてのAccess-RequestでUser-Name属性にEAP-Response/Identityを含めなければなりません。NAS-PortまたはNAS-Port-Idは、Access-Requestパケット内でNASによって発行される属性に含まれるべきであり、NAS-IdentifierまたはNAS-IP-Addressのいずれかが含まれなければなりません。EAPを認識しないプロキシによるAccess-Replyの転送を許可するため、Access-RequestにUser-Name属性が含まれていた場合、RADIUSサーバーはそれ以降のAccess-AcceptパケットにUser-Name属性を含めなければなりません。User-Name属性がない場合、アカウンティングと請求の管理は非常に困難になります。
If identity is determined via another means such as Called-Station-Id or Calling-Station-Id, the NAS MUST include these identifying attributes in every Access-Request.
Called-Station-IdやCalling-Station-Idなどの他の手段によってIDが決定される場合、NASは各Access-Requestにこれらの識別属性を含めなければなりません。
While this approach will save a round-trip, it cannot be universally employed. There are circumstances in which the user's identity may not be needed (such as when authentication and accounting is handled based on Called-Station-Id or Calling-Station-Id), and therefore an EAP-Request/Identity packet may not necessarily be issued by the NAS to the authenticating peer. In cases where an EAP-Request/Identity packet will not be sent, the NAS will send to the RADIUS server a RADIUS Access-Request packet containing an EAP-Message attribute signifying EAP-Start. EAP-Start is indicated by sending an EAP-Message attribute with a length of 2 (no data). However, it should be noted that since no User-Name attribute is included in the Access-Request, this approach is not compatible with RADIUS as specified in [1], nor can it easily be applied in situations where proxies are deployed, such as roaming or shared use networks.
このアプローチは往復を節約しますが、普遍的に採用することはできません。ユーザーのIDが必要とされない場合（Called-Station-IdやCalling-Station-Idに基づいて認証とアカウンティングが処理される場合など）があり、そのためEAP-Request/IdentityパケットがNASから認証ピアに必ずしも発行されない場合があります。EAP-Request/Identityパケットが送信されない場合、NASはEAP-Startを示すEAP-Message属性を含むRADIUS Access-RequestパケットをRADIUSサーバーに送信します。EAP-Startは、長さ2のEAP-Message属性（データなし）を送信することで示されます。ただし、Access-RequestにUser-Name属性が含まれていないため、このアプローチは[1]で指定されているRADIUSとは互換性がなく、ローミングや共有ネットワークなど、プロキシが展開されている状況で簡単に適用できないことに注意すべきです。
If the RADIUS server supports EAP, it MUST respond with an Access-Challenge packet containing an EAP-Message attribute. If the RADIUS server does not support EAP, it MUST respond with an Access-Reject. The EAP-Message attribute includes an encapsulated EAP packet which is then passed on to the authenticating peer. In the case where the NAS does not initially send an EAP-Request/Identity message to the peer, the Access-Challenge typically will contain an EAP-Message attribute encapsulating an EAP-Request/Identity message, requesting the dial-in user to identify themself. The NAS will then respond with a RADIUS Access-Request packet containing an EAP-Message attribute encapsulating an EAP-Response. The conversation continues until either a RADIUS Access-Reject or Access-Accept packet is received.
RADIUSサーバーがEAPをサポートしている場合、EAP-Message属性を含むAccess-Challengeパケットで応答しなければなりません。RADIUSサーバーがEAPをサポートしていない場合、Access-Rejectで応答しなければなりません。EAP-Message属性にはカプセル化されたEAPパケットが含まれており、それは認証ピアに渡されます。NASが最初にEAP-Request/Identityメッセージをピアに送信しない場合、Access-Challengeは通常、EAP-Request/Identityメッセージをカプセル化し、ダイヤルインユーザーに自身を識別するよう要求するEAP-Message属性を含みます。NASはその後、EAP-Responseをカプセル化するEAP-Message属性を含むRADIUS Access-Requestパケットで応答します。通信はRADIUS Access-RejectまたはAccess-Acceptパケットが受信されるまで続行されます。
Reception of a RADIUS Access-Reject packet, with or without an EAP-Message attribute encapsulating EAP-Failure, MUST result in the NAS issuing an LCP Terminate Request to the authenticating peer. A RADIUS Access-Accept packet with an EAP-Message attribute encapsulating EAP-Success successfully ends the authentication phase. The RADIUS Access-Accept/EAP-Message/EAP-Success packet MUST contain all of the expected attributes which are currently returned in an Access-Accept packet.
EAP-Failureをカプセル化するEAP-Message属性の有無にかかわらず、RADIUS Access-Rejectパケットの受信は、NASが認証ピアにLCP Terminate Requestを発行する結果とならなければなりません。EAP-Successをカプセル化するEAP-Message属性を持つRADIUS Access-Acceptパケットは、認証フェーズを正常に終了します。RADIUS Access-Accept/EAP-Message/EAP-Successパケットには、現在Access-Acceptパケットで返されるすべての期待される属性が含まれていなければなりません。
The above scenario creates a situation in which the NAS never needs to manipulate an EAP packet. An alternative may be used in situations where an EAP-Request/Identity message will always be sent by the NAS to the authenticating peer.
上記のシナリオは、NASがEAPパケットを操作する必要がない状況を作り出します。EAP-Request/IdentityメッセージがNASから認証ピアに常に送信される状況では、代替案が使用される場合があります。
For proxied RADIUS requests there are two methods of processing. If the domain is determined based on the Called-Station-Id, the RADIUS Server may proxy the initial RADIUS Access-Request/EAP-Start. If the domain is determined based on the user's identity, the local RADIUS Server MUST respond with a RADIUS Access-Challenge/EAP-Identity packet. The response from the authenticating peer MUST be proxied to the final authentication server.
プロキシRADIUS要求には、2つの処理方法があります。ドメインが呼び出された局IDに基づいて決定された場合、RADIUSサーバは初期RADIUS access-request / EAP-STARTをプロキシすることができます。ドメインがユーザーのIDに基づいて決定された場合、ローカルRADIUSサーバーはRADIUSアクセスチャレンジ/ EAP-IDパケットで応答する必要があります。認証ピアからの応答は、最終認証サーバーにプロキシされている必要があります。
For proxied RADIUS requests, the NAS may receive an Access-Reject packet in response to its Access-Request/EAP-Identity packet. This would occur if the message was proxied to a RADIUS Server which does not support the EAP-Message extension. On receiving an Access-Reject, the NAS MUST send an LCP Terminate Request to the authenticating peer, and disconnect.
プロキシRADIUS要求の場合、NASはそのアクセス要求/ EAP-IDパケットに応答してアクセス拒否パケットを受信することがあります。これは、メッセージがEAP-Message拡張機能をサポートしていないRADIUSサーバーにプロキシされた場合に発生します。アクセス拒否を受信すると、NASは認証ピアにLCP終端要求を送信し、切断する必要があります。
As noted in [3], the EAP authenticator (NAS) is responsible for retransmission of packets between the authenticating peer and the NAS. Thus if an EAP packet is lost in transit between the authenticating peer and the NAS (or vice versa), the NAS will retransmit. As in RADIUS [1], the RADIUS client is responsible for retransmission of packets between the RADIUS client and the RADIUS server.
[3]で述べられているように、EAPオーセンティケータ（NAS）は、認証ピアとNASとの間のパケットの再送信を担当します。したがって、認証ピアとNASとの間で転送中にEAPパケットが失われた場合（またはその逆の場合）、NASがそれを再送信します。RADIUS [1]と同様に、RADIUSクライアントはRADIUSクライアントとRADIUSサーバ間のパケットの再送信を担当します。
Note that it may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout and Password-Retry attributes within the Access-Challenge packet.
特定の場合には、再送戦略と認証タイムアウトを調整する必要があるかもしれません。例えば、トークンカードを使用する場合、ユーザーがカードを見つけてトークンを入力するための追加時間が必要になることがあります。NASは通常、必要なパラメータに関する知識を持っていないため、これらはRADIUSサーバによって提供される必要があります。これは、Access-ChallengeパケットにSession-Timeout属性とPassword-Retry属性を含めることで実現できます。
If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout provides the NAS with the maximum number of seconds the NAS should wait for an EAP-Response before retransmitting the EAP-Message to the dial-in user.
EAP-Messageを含むAccess-ChallengeパケットにSession-Timeout属性が存在する場合、そのSession-Timeoutの値は、NASがダイヤルインユーザへEAP-Messageを再送する前にEAP-Responseを待つべき最大秒数を示します。
Using the EAP-Message attribute, it is possible for the RADIUS server to encapsulate an EAP packet that is larger than the MTU on the link between the NAS and the peer. Since it is not possible for the RADIUS server to use MTU discovery to ascertain the link MTU, the Framed-MTU attribute may be included in an Access-Request packet containing an EAP-Message attribute so as to provide the RADIUS server with this information.
EAP-Message属性を使用すると、RADIUSサーバはNASとピア間のリンクMTUよりも大きなEAPパケットをカプセル化できます。RADIUSサーバはMTU発見機能を使ってリンクMTUを確認することができないため、RADIUSサーバにこの情報を提供するために、EAP-Message属性を含むAccess-RequestパケットにFramed-MTU属性を含めることができます。
The example below shows the conversation between the authenticating peer, NAS, and RADIUS server, for the case of a One Time Password (OTP) authentication. OTP is used only for illustrative purposes; other authentication protocols could also have been used, although they might show somewhat different behavior.
以下の例は、ワンタイムパスワード（OTP）認証の場合の、認証ピア、NAS、およびRADIUSサーバ間の通信を示しています。OTPは説明のためだけに使用されており、他の認証プロトコルも使用できますが、その場合は多少異なる動作を示す可能性があります。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
In the case where the NAS first sends an EAP-Start packet to the RADIUS server, the conversation would appear as follows:
NASが最初にEAP-StartパケットをRADIUSサーバーに送信する場合、会話は次のように表示されます。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
RADIUS
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EA-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
RADIUS Access-Request/ EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Accept/ EAP-Message/EAP-Success (other attributes) <- PPP EAP-Success PPP Authentication Phase complete, NCP Phase starts
In the case where the client fails EAP authentication, the conversation would appear as follows:
クライアントがEAP認証に失敗した場合、会話は次のように表示されます。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP
auth
PPP LCP ACK-EAP
auth ->
Access-Request/
EAP-Message/Start ->
<- RADIUS
Access-Challenge/
EAP-Message/Identity
<- PPP EAP-Request/
Identity
PPP EAP-Response/
Identity (MyID) ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
(MyID) ->
<- RADIUS
Access-Challenge/
EAP-Message/EAP-Request
OTP/OTP Challenge
<- PPP EAP-Request/
OTP/OTP Challenge
PPP EAP-Response/
OTP, OTPpw ->
RADIUS
Access-Request/
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
<- PPP EAP-Failure (client disconnected)
<- PPP EAP-Failure (クライアント切断)
In the case that the RADIUS server or proxy does not support EAP-Message, the conversation would appear as follows:
RADIUSサーバまたはプロキシがEAP-Messageをサポートしていない場合、会話は次のように表示されます。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
<- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
In the case where the local RADIUS Server does support EAP-Message, but the remote RADIUS Server does not, the conversation would appear as follows:
ローカルRADIUSサーバがEAP-Messageをサポートしているが、リモートRADIUSサーバがサポートしていない場合、会話は次のように表示されます。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ Identity
<- PPP LCP Request-EAP auth PPP LCP ACK-EAP auth -> RADIUS Access-Request/ EAP-Message/Start -> <- RADIUS Access-Challenge/ EAP-Message/Identity <- PPP EAP-Request/ Identity
PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (proxied from remote RADIUS Server) <- PPP LCP Terminate (User Disconnected)
PPP EAP-Response/ Identity (MyID) -> RADIUS Access-Request/ EAP-Message/EAP-Response/ (MyID) -> <- RADIUS Access-Reject (リモートRADIUSサーバからプロキシ) <- PPP LCP Terminate (ユーザー切断)
In the case where the authenticating peer does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
認証ピアがEAPをサポートしていないが、そのユーザーにはEAPが必要な場合、会話は次のようになります。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-EAP auth PPP LCP NAK-EAP auth -> <- PPP LCP Request-CHAP auth PPP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
<- PPP LCP Request-EAP auth PPP LCP NAK-EAP auth -> <- PPP LCP Request-CHAP auth PPP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password -> <- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
In the case where the NAS does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
NASがEAPをサポートしていないが、そのユーザーにはEAPが必要な場合、会話は次のようになります。
Authenticating Peer NAS RADIUS Server
------------------- --- -------------
<- PPP LCP Request-CHAP auth
<- PPP LCP Request-CHAP auth
PP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password ->
PP LCP ACK-CHAP auth -> <- PPP CHAP Challenge PPP CHAP Response -> RADIUS Access-Request/ User-Name, CHAP-Password ->
<- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
<- RADIUS Access-Reject <- PPP LCP Terminate (User Disconnected)
Currently the conversation between the backend security server and the RADIUS server is proprietary because of lack of standardization. In order to increase standardization and provide interoperability between Radius vendors and backend security vendors, it is recommended that RADIUS-encapsulated EAP be used for this conversation.
現在、バックエンドセキュリティサーバとRADIUSサーバ間の会話は、標準化がされていないためプロプライエタリなものです。RADIUSベンダーとバックエンドセキュリティベンダー間の相互運用性を高めるために、この会話にはRADIUSでカプセル化されたEAPを使用することが推奨されます。
This has the advantage of allowing the RADIUS server to support EAP without the need for authentication-specific code within the RADIUS server. Authentication-specific code can then reside on a backend security server instead.
これには、RADIUSサーバ内に認証固有のコードを必要とせずに、RADIUSサーバがEAPをサポートできるという利点があります。認証固有のコードは、代わりにバックエンドセキュリティサーバに置くことができます。
In the case where RADIUS-encapsulated EAP is used in a conversation between a RADIUS server and a backend security server, the security server will typically return an Access-Accept/EAP-Success message without inclusion of the expected attributes currently returned in an Access-Accept. This means that the RADIUS server MUST add these attributes prior to sending an Access-Accept/EAP-Success message to the NAS.
RADIUSサーバとバックエンドセキュリティサーバ間の会話でRADIUSカプセル化EAPが使用される場合、セキュリティサーバは通常、Access-Acceptで現在返されると期待される属性を含まずに、Access-Accept/EAP-Successメッセージを返します。これは、RADIUSサーバがAccess-Accept/EAP-SuccessメッセージをNASに送信する前に、これらの属性を追加しなければならないことを意味します。
Packet Format is identical to that defined in RFC 2865 [1] and 2866 [2].
パケットフォーマットは、RFC 2865 [1]および2866 [2]で定義されているものと同じです。
Packet types are identical to those defined in RFC 2865 [1] and 2866 [2].
パケットタイプは、RFC 2865 [1]および2866 [2]で定義されているものと同じです。
See "Table of Attributes" below to determine which types of packets can contain which attributes defined here.
どの種類のパケットにここに定義されている属性を含む可能性があるかを決定するために、「属性の表」を参照してください。
RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response.
RADIUS属性は、リクエストとレスポンスに関する特定の認証、認可、アカウンティングの詳細情報を保持します。
Some attributes MAY be included more than once. The effect of this is attribute specific, and is specified in each attribute description. The order of attributes of the same type SHOULD be preserved. The order of attributes of different types is not required to be preserved.
属性によっては、複数回含まれる場合があります（MAY）。その影響は属性に固有であり、各属性の説明で指定されています。同じタイプの属性の順序は保持されるべきです（SHOULD）。異なるタイプの属性の順序を保持する必要はありません。
The end of the list of attributes is indicated by the Length of the RADIUS packet.
属性のリストの終わりは、RADIUSパケットの長さによって示されます。
A summary of the attribute format is the same as in RFC 2865 [1] but is included here for ease of reference. The fields are transmitted from left to right.
属性フォーマットの概要はRFC 2865 [1]と同じですが、参照を容易にするためにここに含まれています。フィールドは左から右に送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
The Type field is one octet. Up-to-date values of the RADIUS Type field are specified in the most recent "Assigned Numbers" RFC [5]. Values 192-223 are reserved for experimental use, values 224-240 are reserved for implementation-specific use, and values 241-255 are reserved and should not be used. This specification concerns the following values:
Typeフィールドは1オクテットです。RADIUS Typeフィールドの最新の値は、最新の「Assigned Numbers」RFC [5]で指定されています。値192-223は実験用に、値224-240は実装固有の用途に予約されており、値241-255は予約済みであり、使用すべきではありません。この仕様は、以下の値に関するものです。
1-39 (refer to RFC 2865 [1], "RADIUS") 40-51 (refer to RFC 2866 [2], "RADIUS Accounting") 52 Acct-Input-Gigawords 53 Acct-Output-Gigawords 54 Unused 55 Event-Timestamp 56-59 Unused 60-63 (refer to RFC 2865 [1], "RADIUS") 64-67 (refer to [6]) 68 (refer to [7]) 69 (refer to [6]) 70 ARAP-Password 71 ARAP-Features 72 ARAP-Zone-Access 73 ARAP-Security 74 ARAP-Security-Data 75 Password-Retry 76 Prompt 77 Connect-Info 78 Configuration-Token 79 EAP-Message 80 Message-Authenticator 81-83 (refer to [6]) 84 ARAP-Challenge-Response 85 Acct-Interim-Interval 86 (refer to [7]) 87 NAS-Port-Id 88 Framed-Pool 89 Unused 90-91 (refer to [6]) 92-191 Unused
1-39 (refer to RFC 2865 [1], "RADIUS") 40-51 (refer to RFC 2866 [2], "RADIUS Accounting") 52 Acct-Input-Gigawords 53 Acct-Output-Gigawords 54 Unused 55 Event-Timestamp 56-59 Unused 60-63 (refer to RFC 2865 [1], "RADIUS") 64-67 (refer to [6]) 68 (refer to [7]) 69 (refer to [6]) 70 ARAP-Password 71 ARAP-Features 72 ARAP-Zone-Access 73 ARAP-Security 74 ARAP-Security-Data 75 Password-Retry 76 Prompt 77 Connect-Info 78 Configuration-Token 79 EAP-Message 80 Message-Authenticator 81-83 (refer to [6]) 84 ARAP-Challenge-Response 85 Acct-Interim-Interval 86 (refer to [7]) 87 NAS-Port-Id 88 Framed-Pool 89 Unused 90-91 (refer to [6]) 92-191 Unused
Length
長さ
The Length field is one octet, and indicates the length of this attribute including the Type, Length and Value fields. If an attribute is received in a packet with an invalid Length, the entire request should be silently discarded.
Lengthフィールドは1オクテットで、Type、Length、Valueフィールドを含むこの属性の長さを示します。不正な長さを持つ属性をパケットで受信した場合、リクエスト全体が静かに破棄されるべきです (SHOULD)。
Value
値
The Value field is zero or more octets and contains information specific to the attribute. The format and length of the Value field is determined by the Type and Length fields.
Valueフィールドは0個以上のオクテットで、属性固有の情報を含みます。Valueフィールドのフォーマットと長さは、TypeフィールドとLengthフィールドによって決定されます。
Note that none of the types in RADIUS terminate with a NUL (hex 00). In particular, types "text" and "string" in RADIUS do not terminate with a NUL (hex 00). The Attribute has a length field and does not use a terminator. Text contains UTF-8 encoded 10646 [8] characters and String contains 8-bit binary data. Servers and servers and clients MUST be able to deal with embedded nulls. RADIUS implementers using C are cautioned not to use strcpy() when handling strings.
RADIUSのどのタイプもNUL（16進数の00）で終端しないことに注意してください。特に、RADIUSの「text」および「string」タイプはNUL（16進数の00）で終端しません。属性は長さフィールドを持ち、終端文字を使いません。TextにはUTF-8でエンコードされた10646 [8]の文字が含まれ、Stringには8ビットのバイナリデータが含まれます。サーバとクライアントは、埋め込まれたnullを処理できなければなりません（MUST）。C言語を使用するRADIUS実装者は、文字列を処理する際にstrcpy()を使用しないよう注意してください。
The format of the value field is one of five data types. Note that type "text" is a subset of type "string."
Valueフィールドのフォーマットは5つのデータ型の一つです。「text」タイプは「string」タイプのサブセットであることに注意してください。
text 1-253 octets containing UTF-8 encoded 10646 [8] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.
TEXT 1-253 UTF-8エンコード10646 [8]文字を含むオクテット。長さゼロ（0）のテキストを送信してはいけません。代わりに属性全体を省略してください。
string 1-253 octets containing binary data (values 0 through 255 decimal, inclusive). Strings of length zero (0) MUST NOT be sent; omit the entire attribute instead.
1-253バイナリデータを含むオクテット（値0から255の小数点以下）。長さゼロ（0）の文字列を送信してはいけません。代わりに属性全体を省略してください。
address 32 bit unsigned value, most significant octet first.
最初に32ビット符号なし値、最上位オクテット。
integer 32 bit unsigned value, most significant octet first.
整数32ビット符号なし値、最上位オクテット最初の。
time 32 bit unsigned value, most significant octet first -- seconds since 00:00:00 UTC, January 1, 1970.
時間32ビット符号なし値、1970年1月1日、00:00:00 UTCから最初の秒数秒。
Description
description
This attribute indicates how many times the Acct-Input-Octets counter has wrapped around 2^32 over the course of this service being provided, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim-Update.
この属性は、このサービスが提供されている間にAcct-Input-Octetsカウンタが2^32を超えてラップアラウンドした回数を示します。この属性は、Acct-Status-TypeがStopまたはInterim-Updateに設定されているAccounting-Requestレコードにのみ存在できます。
A summary of the Acct-Input-Gigawords attribute format is shown below. The fields are transmitted from left to right.
ACCT-INPUT-GIGAWORDS属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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
タイプ
52 for Acct-Input-Gigawords.
Acct-Input-Gigawordsの場合52。
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは4オクテットです。
Description
description
This attribute indicates how many times the Acct-Output-Octets counter has wrapped around 2^32 in the course of delivering this service, and can only be present in Accounting-Request records where the Acct-Status-Type is set to Stop or Interim-Update.
この属性は、このサービスを提供する過程でAcct-Output-Octetsカウンタが2^32を超えてラップアラウンドした回数を示します。この属性は、Acct-Status-TypeがStopまたはInterim-Updateに設定されているAccounting-Requestレコードにのみ存在できます。
A summary of the Acct-Output-Gigawords attribute format is shown below. The fields are transmitted from left to right.
ACCT-OUTPUT-GIGARORDS属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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
タイプ
53 for Acct-Output-Gigawords.
ACCT-OUTPUT-GIGARORDSの53。
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは4オクテットです。
Description
description
This attribute is included in an Accounting-Request packet to record the time that this event occurred on the NAS, in seconds since January 1, 1970 00:00 UTC.
この属性は、このイベントがNAS上で発生した時刻を記録するために、Accounting-Requestパケットに含まれます。時刻は1970年1月1日00:00 UTCからの秒数で表されます。
A summary of the Event-Timestamp 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
タイプ
55 for Event-Timestamp
イベントタイムスタンプの55
Length
長さ
6
6
Value
値
The Value field is four octets encoding an unsigned integer with the number of seconds since January 1, 1970 00:00 UTC.
Valueフィールドは、1970年1月1日から00:00 UTC以降の符号なし整数を符号化する4つのオクテットです。
Description
description
This attribute is only present in an Access-Request packet containing a Framed-Protocol of ARAP.
この属性は、ARAPのフレーム化プロトコルを含むアクセス要求パケットにのみ存在します。
Only one of User-Password, CHAP-Password, or ARAP-Password needs to be present in an Access-Request, or one or more EAP-Messages.
User-Password、CHAP-Password、またはARAP-Passwordのいずれか1つのみがAccess-Requestに存在するか、または1つ以上のEAP-Messagesが存在する必要があります。
A summary of the ARAP-Password attribute format is shown below. The fields are transmitted from left to right.
ARAPパスワード属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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 | Value1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
70 for ARAP-Password.
アラップパスワードの場合70。
Length
長さ
18
18.
Value
値
This attribute contains a 16 octet string, used to carry the dial-in user's response to the NAS challenge and the client's own challenge to the NAS. The high-order octets (Value1 and Value2) contain the dial-in user's challenge to the NAS (2 32-bit numbers, 8 octets) and the low-order octets (Value3 and Value4) contain the dial-in user's response to the NAS challenge (2 32-bit numbers, 8 octets).
この属性は、NASからのチャレンジに対するダイヤルインユーザの応答と、クライアントからNASへの自身のチャレンジを運ぶために使用される16オクテットの文字列を含みます。上位オクテット（Value1とValue2）はダイヤルインユーザからNASへのチャレンジ（2つの32ビット数、8オクテット）を含み、下位オクテット（Value3とValue4）はNASからのチャレンジに対するダイヤルインユーザの応答（2つの32ビット数、8オクテット）を含みます。
Description
description
This attribute is sent in an Access-Accept packet with Framed-Protocol of ARAP, and includes password information that the NAS should sent to the user in an ARAP "feature flags" packet.
この属性は、Framed-ProtocolがARAPに設定されたAccess-Acceptパケットで送信され、NASがARAPの「機能フラグ」パケットでユーザに送信すべきパスワード情報を含みます。
A summary of the ARAP-Features attribute format is shown below. The fields are transmitted from left to right.
ARAP機能の概要属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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 | Value1 | Value2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
71 for ARAP-Features.
ARAP機能については71。
Length
長さ
16
16.
Value
値
The Value field is a compound string containing information the NAS should send to the user in the ARAP "feature flags" packet.
Valueフィールドは、NASがARAPの「機能フラグ」パケットでユーザに送信すべき情報を含む複合文字列です。
Value1: If zero, user cannot change their password. If non-zero user can. (RADIUS does not handle the password changing, just the attribute which indicates whether ARAP indicates they can.)
Value1: ゼロの場合、ユーザはパスワードを変更できません。ゼロ以外の場合、ユーザは変更できます。（RADIUSはパスワード変更自体は処理せず、ARAPが変更可能かを示す属性を処理するだけです。）
Value2: Minimum acceptable password length, from 0 to 8.
Value2: 許容される最小パスワード長（0から8）。
Value3: Password creation date in Macintosh format, defined as 32 unsigned bits representing seconds since Midnight GMT January 1, 1904.
Value3: Macintoshフォーマットでのパスワード作成日。1904年1月1日午前0時(GMT)からの秒数を表す32ビット符号なし整数として定義されます。
Value4: Password Expiration Delta from create date in seconds.
Value4: パスワード作成日からの有効期限の差（秒単位）。
Value5: Current RADIUS time in Macintosh format.
Value5: Macintoshフォーマットでの現在のRADIUS時間。
Description
description
This attribute is included in an Access-Accept packet with Framed-Protocol of ARAP to indicate how the ARAP zone list for the user should be used.
この属性は、ユーザのARAPゾーンリストをどのように使用すべきかを示すために、Framed-ProtocolがARAPに設定されたAccess-Acceptパケットに含まれます。
A summary of the ARAP-Zone-Access attribute format is shown below. The fields are transmitted from left to right.
Arap-Zone-Access属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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
タイプ
72 for ARAP-Zone-Access.
72 Arap-Zone-Accessの場合。
Length
長さ
6
6
Value
値
The Value field is four octets encoding an integer with one of the following values:
Valueフィールドは、以下のいずれかの値を持つ整数をエンコードする4オクテットです。
1 Only allow access to default zone 2 Use zone filter inclusively 4 Use zone filter exclusively
1: デフォルトゾーンへのアクセスのみを許可\n2: ゾーンフィルタを包括的に使用\n4: ゾーンフィルタを排他的に使用
The value 3 is skipped, not because these are bit flags, but because 3 in some ARAP implementations means "all zones" which is the same as not specifying a list at all under RADIUS.
値3がスキップされるのは、これらがビットフラグだからではなく、いくつかのARAP実装では3が「すべてのゾーン」を意味し、これはRADIUSでリストを全く指定しないことと同じだからです。
If this attribute is present and the value is 2 or 4 then a Filter-Id must also be present to name a zone list filter to apply the access flag to.
この属性が存在し、値が2または4である場合、アクセスフラグを適用するゾーンリストフィルタを名指しするためにFilter-Idも存在しなければなりません。
Description
description
This attribute identifies the ARAP Security Module to be used in an Access-Challenge packet.
この属性は、Access-Challengeパケットで使用されるARAPセキュリティモジュールを識別します。
A summary of the ARAP-Security attribute format is shown below. The fields are transmitted from left to right.
ARAPセキュリティ属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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
タイプ
73 for ARAP-Security.
ARAP-Securityの場合73。
Length
長さ
6
6
Value
値
The Value field is four octets, containing an integer specifying the security module signature, which is a Macintosh OSType. (Macintosh OSTypes are 4 ascii characters cast as a 32-bit integer)
Valueフィールドは、セキュリティモジュール署名を指定する整数を含む4オクテットです。署名はMacintosh OSTypeです。(Macintosh OSTypeは、4つのASCII文字を32ビット整数としてキャストしたものです)
Description
description
This attribute contains the actual security module challenge or response, and can be found in Access-Challenge and Access-Request packets.
この属性は、実際のセキュリティモジュールのチャレンジまたはレスポンスを含み、Access-ChallengeおよびAccess-Requestパケットに存在します。
A summary of the ARAP-Security-Data attribute format is shown below. The fields are transmitted from left to right.
ARAP-Security-Data属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
74 for ARAP-Security-Data.
74 ARAP-Security-Data。
Length
長さ
>=3
> = 3
String
ストリング
The String field contains the security module challenge or response associated with the ARAP Security Module specified in ARAP-Security.
Stringフィールドには、ARAP-Securityで指定されたARAPセキュリティモジュールに関連する、セキュリティモジュールのチャレンジまたはレスポンスが含まれます。
Description
description
This attribute MAY be included in an Access-Reject to indicate how many authentication attempts a user may be allowed to attempt before being disconnected.
この属性は、ユーザが切断されるまでに許可される認証試行の回数を示すために、Access-Rejectに含まれることがあります（MAY）。
It is primarily intended for use with ARAP authentication.
これは主にARAP認証での使用を目的としています。
A summary of the Password-Retry 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
タイプ
75 for Password-Retry.
パスワードの再試行のための75。
Length
長さ
6
6
Value
値
The Value field is four octets, containing an integer specifying the number of password retry attempts to permit the user.
Valueフィールドは4オクテットで、ユーザに許可するパスワード再試行の回数を指定する整数を含みます。
Description
description
This attribute is used only in Access-Challenge packets, and indicates to the NAS whether it should echo the user's response as it is entered, or not echo it.
この属性はAccess-Challengeパケットでのみ使用され、ユーザの応答を入力時にエコー表示するかどうかをNASに示します。
A summary of the Prompt 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
タイプ
76 for Prompt.
プロンプトの76。
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは4オクテットです。
0 No Echo 1 Echo
0: エコーなし\n1: エコーあり
Description
description
This attribute is sent from the NAS to indicate the nature of the user's connection.
この属性は、ユーザーの接続の性質を示すためにNASから送信されます。
The NAS MAY send this attribute in an Access-Request or Accounting-Request to indicate the nature of the user's connection.
NASは、ユーザ接続の性質を示すために、Access-RequestまたはAccounting-Requestでこの属性を送信することがあります（MAY）。
A summary of the Connect-Info attribute format is shown below. The fields are transmitted from left to right.
Connect-Info属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
77 for Connect-Info.
77 Connect-Info。
Length
長さ
>= 3
> = 3
Text
テキスト
The Text field consists of UTF-8 encoded 10646 [8] characters. The connection speed SHOULD be included at the beginning of the first Connect-Info attribute in the packet. If the transmit and receive connection speeds differ, they may both be included in the first attribute with the transmit speed first (the speed the NAS modem transmits at), a slash (/), the receive speed, then optionally other information.
Textフィールドは、UTF-8でエンコードされた10646 [8]の文字で構成されます。接続速度は、パケット内の最初のConnect-Info属性の先頭に含まれるべきです（SHOULD）。送受信の接続速度が異なる場合は、送信速度（NASモデムの送信速度）を先に、次にスラッシュ（/）、受信速度の順で最初の属性に両方を含めることができ、その後オプションで他の情報が続きます。
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
例：「28800 V42BIS/LAPM」または「52000/31200 V90」
More than one Connect-Info attribute may be present in an Accounting-Request packet to accommodate expected efforts by ITU to have modems report more connection information in a standard format that might exceed 252 octets.
ITUによる、252オクテットを超える可能性のある標準フォーマットでモデムがより多くの接続情報を報告するようにするという予想される取り組みに対応するために、複数のConnect-Info属性がAccounting-Requestパケットに存在することがあります。
Description
description
This attribute is for use in large distributed authentication networks based on proxy. It is sent from a RADIUS Proxy Server to a RADIUS Proxy Client in an Access-Accept to indicate a type of user profile to be used. It should not be sent to a NAS.
この属性は、プロキシベースの大規模な分散認証ネットワークで使用するためのものです。RADIUSプロキシサーバからRADIUSプロキシクライアントへ、Access-Acceptで送信され、使用するユーザプロファイルのタイプを示します。NASに送信されるべきではありません。
A summary of the Configuration-Token attribute format is shown below. The fields are transmitted from left to right.
構成トークン属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
78 for Configuration-Token.
コンフィギュレーショントークンの78。
Length
長さ
>= 3
> = 3
String
ストリング
The String field is one or more octets. The actual format of the information is site or application specific, and a robust implementation SHOULD support the field as undistinguished octets.
Stringフィールドは1つ以上のオクテットです。情報の実際のフォーマットはサイトまたはアプリケーションに固有であり、堅牢な実装では、このフィールドを未定義のオクテットとしてサポートすべきです（SHOULD）。
The codification of the range of allowed usage of this field is outside the scope of this specification.
この分野の許容された使用範囲の範囲の成長は、この仕様の範囲外です。
Description
description
This attribute encapsulates Extended Access Protocol [3] packets so as to allow the NAS to authenticate dial-in users via EAP without having to understand the EAP protocol.
この属性は、EAPプロトコルを理解しなくても、NASがEAPを介してダイヤルインユーザを認証できるように、拡張アクセスプロトコル[3]パケットをカプセル化します。
The NAS places any EAP messages received from the user into one or more EAP attributes and forwards them to the RADIUS Server as part of the Access-Request, which can return EAP messages in Access-Challenge, Access-Accept and Access-Reject packets.
NASは、ユーザから受信したEAPメッセージを1つ以上のEAP属性に配置し、それらをアクセス要求の一部としてRADIUSサーバに転送します。これにより、アクセスチャレンジ、アクセス許可、およびアクセス拒否パケットにEAPメッセージを返します。
A RADIUS Server receiving EAP messages that it does not understand SHOULD return an Access-Reject.
理解していないEAPメッセージを受信するRADIUSサーバは、アクセス拒否を返すべきです。
The NAS places EAP messages received from the authenticating peer into one or more EAP-Message attributes and forwards them to the RADIUS Server within an Access-Request message. If multiple EAP-Messages are contained within an Access-Request or Access-Challenge packet, they MUST be in order and they MUST be consecutive attributes in the Access-Request or Access-Challenge packet. Access-Accept and Access-Reject packets SHOULD only have ONE EAP-Message attribute in them, containing EAP-Success or EAP-Failure.
NASは、認証ピアから受信したEAPメッセージを1つ以上のEAPメッセージ属性に配置し、それらをアクセス要求メッセージ内でRADIUSサーバに転送する。複数のEAPメッセージがアクセス要求またはアクセスチャレンジパケット内に含まれている場合、それらは順番になければならず、それらはアクセス要求またはアクセスチャレンジパケット内の連続した属性でなければなりません。Access-AcceptおよびAccess-Rejectパケットには、EAP-SuccessまたはEAP FAILUREを含む1つのEAP-MESSAGE属性のみがあります。
It is expected that EAP will be used to implement a variety of authentication methods, including methods involving strong cryptography. In order to prevent attackers from subverting EAP by attacking RADIUS/EAP, (for example, by modifying the EAP-Success or EAP-Failure packets) it is necessary that RADIUS/EAP provide integrity protection at least as strong as those used in the EAP methods themselves.
EAPは、強い暗号化を含む方法を含む、さまざまな認証方法を実装するために使用されることが予想されます。RADIUS / EAPを攻撃して（たとえば、EAP-SUCCESSまたはEAP障害パケットを変更することによって）EAPを攻撃しないようにするためには、RADIUS / EAPが少なくともEAPで使用されているものと同じくらい強力に整合性保護を提供する必要があります。メソッド自体。
Therefore the Message-Authenticator attribute MUST be used to protect all Access-Request, Access-Challenge, Access-Accept, and Access-Reject packets containing an EAP-Message attribute.
したがって、message-authenticator属性を使用して、EAP-Message属性を含むすべてのアクセス要求、アクセスチャレンジ、アクセス許可、およびアクセスリジェクトパケットを保護する必要があります。
Access-Request packets including an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the RADIUS server. A RADIUS Server supporting EAP-Message MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent. A RADIUS Server not supporting EAP-Message MUST return an Access-Reject if it receives an Access-Request containing an EAP-Message attribute. A RADIUS Server receiving an EAP-Message attribute that it does not understand MUST return an Access-Reject.
message-authenticator属性を持たないEAP-MESSAGE属性を含むアクセス要求パケットは、RADIUSサーバーによって黙って破棄されるべきです。EAP-MessageをサポートするRADIUSサーバーは、メッセージオーセンティケータの正しい値を計算し、送信された値と一致しない場合はパケットをサイレントに破棄しなければなりません。EAP-MESSAGEをサポートしていないRADIUSサーバーは、EAP-MESSAGE属性を含むアクセス要求を受信した場合にアクセス拒否を返す必要があります。理解していないEAP-MESSAGE属性を受信するRADIUSサーバーは、アクセス拒否を返す必要があります。
Access-Challenge, Access-Accept, or Access-Reject packets including an EAP-Message attribute without a Message-Authenticator attribute SHOULD be silently discarded by the NAS. A NAS supporting EAP-Message MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
message-authenticator属性を持たないEAP-MESSAGE属性を含むアクセスチャレンジ、アクセス許可、またはアクセス拒否パケットは、NASによって静かに破棄されるべきです。EAP-MessageをサポートするNASは、メッセージオーセンティケータの正しい値を計算し、それが送信された値と一致しない場合はパケットを静的に破棄しなければなりません。
A summary of the EAP-Message attribute format is shown below. The fields are transmitted from left to right.
EAP-MESSAGE属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
79 for EAP-Message.
79 EAP - メッセージの場合。
Length
長さ
>= 3
> = 3
String
ストリング
The String field contains EAP packets, as defined in [3]. If multiple EAP-Message attributes are present in a packet their values should be concatenated; this allows EAP packets longer than 253 octets to be passed by RADIUS.
[3]で定義されているEAPパケットは、「文字列」フィールドにはEAPパケットが含まれています。複数のEAPメッセージ属性がパケットに存在する場合、それらの値は連結されるべきです。これにより、253オクテットを超えるEAPパケットを半径で渡すことができます。
Description
description
This attribute MAY be used to sign Access-Requests to prevent spoofing Access-Requests using CHAP, ARAP or EAP authentication methods. It MAY be used in any Access-Request. It MUST be used in any Access-Request, Access-Accept, Access-Reject or Access-Challenge that includes an EAP-Message attribute.
この属性は、CHAP、ARAPまたはEAP認証方法を使用したスプーフィングを防ぐためにアクセス要求に署名するために使用されます。それは任意のアクセス要求で使用されるかもしれません。EAP-MESSAGE属性を含む任意のアクセス要求、アクセス許可、アクセス拒否またはアクセスチャレンジで使用する必要があります。
A RADIUS Server receiving an Access-Request with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
Message-Authenticator属性を持つアクセス要求を受信したRADIUSサーバーは、メッセージオーセンティケータの正しい値を計算し、それが送信された値と一致しない場合はパケットを静的に破棄しなければなりません。
A RADIUS Client receiving an Access-Accept, Access-Reject or Access-Challenge with a Message-Authenticator Attribute present MUST calculate the correct value of the Message-Authenticator and silently discard the packet if it does not match the value sent.
Message-Authenticator属性を持つアクセス許可、アクセス拒否、またはアクセスチャレンジを受信したRADIUSクライアントは、メッセージオーセンティケータの正しい値を計算し、送信された値と一致しない場合はパケットをサイレントに破棄しなければなりません。
Earlier drafts of this memo used "Signature" as the name of this attribute, but Message-Authenticator is more precise. Its operation has not changed, just the name.
このメモの以前のドラフトは、この属性の名前として「シグネチャ」を使用しましたが、メッセージオーセンティケータはより正確です。その操作は変更されていません、名前だけです。
A summary of the Message-Authenticator attribute format is shown below. The fields are transmitted from left to right.
メッセージオーセンティケータ属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
80 for Message-Authenticator
Message-Authenticator用の80
Length
長さ
18
18.
String
ストリング
When present in an Access-Request packet, Message-Authenticator is an HMAC-MD5 [9] checksum of the entire Access-Request packet, including Type, ID, Length and authenticator, using the shared secret as the key, as follows.
アクセス要求パケットに存在する場合、Message-Authenticatorは、次のように、タイプ、ID、長さ、およびオーセンティケータを含む、Access-Requestパケット全体のHMAC-MD5 [9]チェックサムです。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes)
Message-Authenticator = HMAC-MD5（タイプ、識別子、長さ、要求オーセンティケータ、属性）
When the checksum is calculated the signature string should be considered to be sixteen octets of zero.
チェックサムが計算されると、署名文字列は16個のゼロのオクテットと見なされるべきです。
For Access-Challenge, Access-Accept, and Access-Reject packets, the Message-Authenticator is calculated as follows, using the Request-Authenticator from the Access-Request this packet is in reply to:
アクセスチャレンジ、アクセス許可、およびアクセス拒否パケットの場合、メッセージオーセンティケータは次のように計算されます。このパケットは次のように返信します。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length, Request Authenticator, Attributes) When the checksum is calculated the signature string should be considered to be sixteen octets of zero. The shared secret is used as the key for the HMAC-MD5 hash. The is calculated and inserted in the packet before the Response Authenticator is calculated.
Message-Authenticator = HMAC-MD5（タイプ、識別子、長さ、要求オーセンティケータ、属性）チェックサムが計算されると、シグニチャストリングはゼロの16オクテットと見なされるべきです。共有秘密は、HMAC-MD5ハッシュのキーとして使用されます。応答オーセンティケータが計算される前に、パケットに計算され挿入されます。
This attribute is not needed if the User-Password attribute is present, but is useful for preventing attacks on other types of authentication. This attribute is intended to thwart attempts by an attacker to setup a "rogue" NAS, and perform online dictionary attacks against the RADIUS server. It does not afford protection against "offline" attacks where the attacker intercepts packets containing (for example) CHAP challenge and response, and performs a dictionary attack against those packets offline.
user-password属性が存在する場合はこの属性は必要ありませんが、他の種類の認証に対する攻撃を防ぐのに役立ちます。この属性は、攻撃者が「Rogue」NASを設定し、RADIUSサーバーに対するオンライン辞書攻撃を実行することによる試行を妨げることを目的としています。攻撃者が（たとえば）CHAPのチャレンジと応答を含むパケットを傍受し、オフラインにするパケットに対する辞書攻撃を実行する「オフライン」攻撃に対する保護はありません。
IP Security will eventually make this attribute unnecessary, so it should be considered an interim measure.
IPセキュリティは、最終的にこの属性を不要にするため、中間測定と見なされるべきです。
Description
description
This attribute is sent in an Access-Accept packet with Framed-Protocol of ARAP, and contains the response to the dial-in client's challenge.
この属性は、ARAPのフレーム化プロトコルを使用してAccess-Acceptパケットで送信され、ダイヤルインクライアントのチャレンジに対する応答が含まれています。
A summary of the ARAP-Challenge-Response attribute format is shown below. The fields are transmitted from left to right.
Arap-Challenge-Response属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
84 for ARAP-Challenge-Response.
ARAPチャレンジ対応のための84。
Length
長さ
10
10.
Value
値
The Value field contains an 8 octet response to the dial-in client's challenge. The RADIUS server calculates this value by taking the dial-in client's challenge from the high order 8 octets of the ARAP-Password attribute and performing DES encryption on this value with the authenticating user's password as the key. If the user's password is less than 8 octets in length, the password is padded at the end with NULL octets to a length of 8 before using it as a key.
[値]フィールドには、ダイヤルインクライアントのチャレンジに対する8オクテット応答が含まれています。RADIUSサーバは、Arap-Password属性の高次8オクテットからダイヤルインクライアントのチャレンジを取得し、この値でDES暗号化を鍵としての認証ユーザーのパスワードを実行してこの値を計算します。ユーザーのパスワードが長さ8オクテット未満の場合、パスワードはゼロとしてゼロの長さで8個までの長さ8の長さで埋め込まれます。
Description
description
This attribute indicates the number of seconds between each interim update in seconds for this specific session. This value can only appear in the Access-Accept message.
この属性は、この特定のセッションの各暫定更新間の秒数を秒単位で示します。この値はアクセス許可メッセージにのみ表示できます。
A summary of the Acct-Interim-Interval attribute format is shown below. The fields are transmitted from left to right.
ACCT-Interim-Interval属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
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
タイプ
85 for Acct-Interim-Interval.
acct-interim-intervalの場合は85です。
Length
長さ
6
6
Value
値
The Value field contains the number of seconds between each interim update to be sent from the NAS for this session. The value MUST NOT be smaller than 60. The value SHOULD NOT be smaller than 600, and careful consideration should be given to its impact on network traffic.
[値]フィールドには、このセッションのNASから送信される各暫定アップデート間の秒数が含まれています。値は60より小さくしてはいけません。値は600より小さくしないでください。ネットワークトラフィックへの影響を慎重に検討する必要があります。
Description
description
This Attribute contains a text string which identifies the port of the NAS which is authenticating the user. It is only used in Access-Request and Accounting-Request packets. Note that this is using "port" in its sense of a physical connection on the NAS, not in the sense of a TCP or UDP port number.
この属性には、ユーザーを認証しているNASのポートを識別するテキスト文字列が含まれています。アクセス要求およびアカウンティング要求パケットにのみ使用されます。これは、TCPまたはUDPポート番号の意味ではなく、NAS上の物理接続の意味で「ポート」を使用しています。
Either NAS-Port or NAS-Port-Id SHOULD be present in an Access-Request packet, if the NAS differentiates among its ports. NAS-Port-Id is intended for use by NASes which cannot conveniently number their ports.
NASがそのポート間を微分すると、NASポートまたはNAS-Port-IDのいずれかがアクセス要求パケットに存在する必要があります。NAS-Port-IDは、自分のポートを便利に番号に番号を付けることができないNaseによる使用を目的としています。
A summary of the NAS-Port-Id Attribute format is shown below. The fields are transmitted from left to right.
NAS-Port-ID属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Text...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
87 for NAS-Port-Id.
NAS-Port-IDの87。
Length
長さ
>= 3
> = 3
Text
テキスト
The Text field contains the name of the port using UTF-8 encoded 10646 [8] characters.
テキストフィールドには、UTF-8 Encoded 10646 [8]文字を使用したポートの名前が含まれています。
Description
description
This Attribute contains the name of an assigned address pool that SHOULD be used to assign an address for the user. If a NAS does not support multiple address pools, the NAS should ignore this Attribute. Address pools are usually used for IP addresses, but can be used for other protocols if the NAS supports pools for those protocols.
この属性には、ユーザーのアドレスを割り当てるために使用される割り当てられたアドレスプールの名前が含まれています。NASが複数のアドレスプールをサポートしていない場合、NASはこの属性を無視します。アドレスプールは通常IPアドレスに使用されますが、NASがそれらのプロトコルのプールをサポートしている場合は、他のプロトコルに使用できます。
A summary of the Framed-Pool Attribute format is shown below. The fields are transmitted from left to right.
フレーム付きプール属性フォーマットの概要を以下に示します。フィールドは左から右へ送信されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | String...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
88 for Framed-Pool
フレームプールのための88
Length
長さ
>= 3
> = 3
String
ストリング
The string field contains the name of an assigned address pool configured on the NAS.
Stringフィールドには、NASに設定されている割り当てられたアドレスプールの名前が含まれています。
The following table provides a guide to which attributes may be found in which kind of packets. Acct-Input-Gigawords, Acct-Output-Gigawords, Event-Timestamp, and NAS-Port-Id may have 0-1 instances in an Accounting-Request packet. Connect-Info may have 0+ instances in an Accounting-Request packet. The other attributes added in this document must not be present in an Accounting-Request.
次の表は、どの種類のパケットにどの属性が見つかるかを説明しています。ACCT-INPUT-GIGAWORDS、ACCT-AUTPUT-GIGARORDS、EVENT-TIMESTAMP、およびNAS-PORT-IDは、アカウンティング要求パケット内の0-1インスタンスを持つことができます。Connect-Infoは、アカウンティング要求パケットに0インスタンスを持つことができます。この文書に追加された他の属性は、アカウンティング要求に存在してはいけません。
Request Accept Reject Challenge # Attribute
0-1 0 0 0 70 ARAP-Password [Note 1]
0 0-1 0 0-1 71 ARAP-Features
0 0-1 0 0 72 ARAP-Zone-Access
0-1 0 0 0-1 73 ARAP-Security
0+ 0 0 0+ 74 ARAP-Security-Data
0 0 0-1 0 75 Password-Retry
0 0 0 0-1 76 Prompt
0-1 0 0 0 77 Connect-Info
0 0+ 0 0 78 Configuration-Token
0+ 0+ 0+ 0+ 79 EAP-Message [Note 1]
0-1 0-1 0-1 0-1 80 Message-Authenticator [Note 1]
0 0-1 0 0-1 84 ARAP-Challenge-Response
0 0-1 0 0 85 Acct-Interim-Interval
0-1 0 0 0 87 NAS-Port-Id
0 0-1 0 0 88 Framed-Pool
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request that contains either a User-Password or CHAP-Password or ARAP-Password or one or more EAP-Message attributes MUST NOT contain more than one type of those four attributes. If it does not contain any of those four attributes, it SHOULD contain a Message-Authenticator. If any packet type contains an EAP-Message attribute it MUST also contain a Message-Authenticator.
[注1]ユーザーパスワードまたはCHAPパスワード、またはARAPパスワード、または1つ以上のEAP-MESSAGE属性のいずれかを含むアクセス要求は、これらの4つの属性の複数のタイプを含んではいけません。これら4つの属性のいずれも含まれていない場合は、メッセージオーセンティケータを含める必要があります。任意のパケットタイプがEAP-MESSAGE属性を含む場合、メッセージオーセンティケータも含まなければなりません。
The following table defines the above table entries.
次の表は、上記のテーブルエントリを定義します。
0 This attribute MUST NOT be present 0+ Zero or more instances of this attribute MAY be present. 0-1 Zero or one instance of this attribute MAY be present. 1 Exactly one instance of this attribute MUST be present.
0この属性は存在してはいけません0 0以上この属性のインスタンスが存在する場合があります。0 - 1 0またはこの属性の1つのインスタンスが存在する場合があります。1正確にこの属性の1つのインスタンスがある必要があります。
The Packet Type Codes, Attribute Types, and Attribute Values defined in this document are registered by the Internet Assigned Numbers Authority (IANA) from the RADIUS name spaces as described in the "IANA Considerations" section of [1], in accordance with BCP 26 [10].
この文書で定義されているパケットタイプコード、属性タイプ、属性値は、BCP 26に準拠して[1]の「IANA考慮事項」のセクションで説明されているように、RADIUS Nameスペースからインターネット割り当てられた番号局（IANA）によって登録されています。[10]。
The attributes other than Message-Authenticator and EAP-Message in this document have no additional security considerations beyond those already identified in [1].
このドキュメントのMessage-AuthenticatorおよびEAP-Message以外の属性には、[1]で既に識別されているものを超えて追加のセキュリティ上の考慮はありません。
Access-Request packets with a User-Password establish the identity of both the user and the NAS sending the Access-Request, because of the way the shared secret between NAS and RADIUS server is used. Access-Request packets with CHAP-Password or EAP-Message do not have a User-Password attribute, so the Message-Authenticator attribute should be used in access-request packets that do not have a User-Password, in order to establish the identity of the NAS sending the request.
ユーザパスワードを備えたアクセス要求パケットは、NASサーバとRADIUSサーバ間の共有秘密が使用されているため、アクセス要求を送信するユーザとNASの両方のIDを確立します。chap-passwordまたはeap-messagesを使用したアクセス要求パケットには、ユーザーパスワード属性がありませんので、IDを確立するために、message-authenticator属性をアクセス要求パケットに使用する必要があります。リクエストを送信するNASの。
Since the purpose of EAP is to provide enhanced security for PPP authentication, it is critical that RADIUS support for EAP be secure. In particular, the following issues must be addressed:
EAPの目的はPPP認証のための強化されたセキュリティを提供することであるため、EAPのRADIUSサポートが安全であることが重要です。特に、以下の問題を解決する必要があります。
Separation of EAP server and PPP authenticator Connection hijacking Man in the middle attacks Multiple databases Negotiation attacks
EAPサーバーとPPPオーセンティケーター接続の分離ミドル攻撃で男性をハイジャックする複数のデータベースネゴシエーション攻撃
It is possible for the EAP endpoints to mutually authenticate, negotiate a ciphersuite, and derive a session key for subsequent use in PPP encryption.
EAPエンドポイントが相互認証、暗号化のネゴシエーション、およびPPP暗号化での使用のためのセッションキーを導出することが可能です。
This does not present an issue on the peer, since the peer and EAP client reside on the same machine; all that is required is for the EAP client module to pass the session key to the PPP encryption module.
ピアクライアントとEAPクライアントは同じマシン上にあるため、これはピア上の問題はありません。必要なのは、EAPクライアントモジュールがセッションキーをPPP暗号化モジュールに渡すためのものです。
The situation is more complex when EAP is used with RADIUS, since the PPP authenticator will typically not reside on the same machine as the EAP server. For example, the EAP server may be a backend security server, or a module residing on the RADIUS server.
PPPオーセンティケータは通常EAPサーバと同じマシン上に存在しないため、EAPがRADIUSで使用されると、状況はより複雑です。例えば、EAPサーバはバックエンドセキュリティサーバ、またはRADIUSサーバ上に存在するモジュールであり得る。
In the case where the EAP server and PPP authenticator reside on different machines, there are several implications for security. Firstly, mutual authentication will occur between the peer and the EAP server, not between the peer and the authenticator. This means that it is not possible for the peer to validate the identity of the NAS or tunnel server that it is speaking to.
EAPサーバーとPPPオーセンティケータが異なるマシンに存在する場合は、セキュリティにはいくつかの影響があります。第一に、ピアとオーセンティケータの間ではなく、ピアとEAPサーバ間で相互認証が行われます。つまり、ピアが発話しているNASまたはTunnel ServerのIDを検証できないことを意味します。
As described earlier, when EAP/RADIUS is used to encapsulate EAP packets, the Message-Authenticator attribute is required in EAP/RADIUS Access-Requests sent from the NAS or tunnel server to the RADIUS server. Since the Message-Authenticator attribute involves a HMAC-MD5 hash, it is possible for the RADIUS server to verify the integrity of the Access-Request as well as the NAS or tunnel server's identity. Similarly, Access-Challenge packets sent from the RADIUS server to the NAS are also authenticated and integrity protected using an HMAC-MD5 hash, enabling the NAS or tunnel server to determine the integrity of the packet and verify the identity of the RADIUS server. Moreover, EAP packets sent via methods that contain their own integrity protection cannot be successfully modified by a rogue NAS or tunnel server.
前述のように、EAP / RADIUSがEAPパケットをカプセル化するために使用されるとき、Message-Authenticator属性は、NASまたはTunnel ServerからRADIUSサーバーに送信されたEAP / RADIUSアクセス要求で必要です。message-authenticator属性はHMAC-MD5ハッシュを含みますので、RADIUSサーバーはアクセス要求の整合性とNASまたはトンネルサーバーのIDを検証できます。同様に、RADIUSサーバからNASに送信されたアクセスチャレンジパケットも、HMAC-MD5ハッシュを使用して認証され、NASまたはTunnel Serverがパケットの整合性を判断でき、RADIUSサーバーのIDを確認できます。さらに、独自のIntegrity Protectionを含むメソッドを介して送信されるEAPパケットは、不正なNASまたはトンネルサーバーによって正常に変更できません。
The second issue that arises in the case of an EAP server and PPP authenticator residing on different machines is that the session key negotiated between the peer and EAP server will need to be transmitted to the authenticator. Therefore a mechanism needs to be provided to transmit the session key from the EAP server to the authenticator or tunnel server that needs to use the key. The specification of this transit mechanism is outside the scope of this document.
EAPサーバーとPPPオーセンティケータの場合、異なるマシンに存在する2つ目の問題は、ピアサーバとEAPサーバ間でネゴシエートされたセッションキーをオーセンティケータに送信する必要があることです。したがって、キーを使用する必要があるオーセンティケータまたはトンネルサーバからAuthenticatorまたはTunnel Serverにセッションキーを送信するためにメカニズムを提供する必要があります。この通過メカニズムの仕様はこの文書の範囲外です。
In this form of attack, the attacker attempts to inject packets into the conversation between the NAS and the RADIUS server, or between the RADIUS server and the backend security server. RADIUS does not support encryption, and as described in [1], only Access-Reply and Access-Challenge packets are integrity protected. Moreover, the integrity protection mechanism described in [1] is weaker than that likely to be used by some EAP methods, making it possible to subvert those methods by attacking EAP/RADIUS.
この攻撃では、攻撃者は、NASとRADIUSサーバー間の会話にパケットを注入しようとします。RADIUSは暗号化をサポートしていないため、[1]に記載されているように、アクセス応答およびアクセスチャレンジパケットのみが保護されています。さらに、[1]に記載されている完全性保護機構は、EAP法によって使用される可能性が高いほど弱く、EAP / RADIUSを攻撃することによってそれらの方法を覆すことを可能にする。
In order to provide for authentication of all packets in the EAP exchange, all EAP/RADIUS packets MUST be authenticated using the Message-Authenticator attribute, as described previously.
EAP Exchange内のすべてのパケットの認証を提供するためには、前述のように、すべてのEAP / RADIUSパケットをmessage-authenticator属性を使用して認証する必要があります。
Since RADIUS security is based on shared secrets, end-to-end security is not provided in the case where authentication or accounting packets are forwarded along a proxy chain. As a result, attackers gaining control of a RADIUS proxy will be able to modify EAP packets in transit.
RADIUSセキュリティは共有秘密に基づいているため、認証またはアカウンティングパケットがプロキシチェーンに沿って転送される場合には、エンドツーエンドのセキュリティは提供されません。その結果、RADIUSプロキシを制御する攻撃者は、輸送中のEAPパケットを変更することができます。
In many cases a backend security server will be deployed along with a RADIUS server in order to provide EAP services. Unless the backend security server also functions as a RADIUS server, two separate user databases will exist, each containing information about the security requirements for the user. This represents a weakness, since security may be compromised by a successful attack on either of the servers, or their backend databases. With multiple user databases, adding a new user may require multiple operations, increasing the chances for error. The problems are further magnified in the case where user information is also being kept in an LDAP server. In this case, three stores of user information may exist.
多くの場合、EAPサービスを提供するために、Backend Security ServerがRADIUSサーバーと一緒にデプロイされます。バックエンドセキュリティサーバーもRADIUSサーバーとして機能しない限り、それぞれがユーザーのセキュリティ要件に関する情報を含む2つの別々のユーザーデータベースが存在します。セキュリティは、いずれかのサーバー、またはバックエンドデータベースに対する攻撃が成功したことによって危険にさらされる可能性があるため、これは弱さを表します。複数のユーザーデータベースを使用すると、新しいユーザーを追加すると複数の操作が必要な場合があり、エラーのチャンスを増やします。ユーザ情報もLDAPサーバに保持されている場合には、問題がさらに拡大されている。この場合、3枚のユーザ情報が存在する可能性がある。
In order to address these threats, consolidation of databases is recommended. This can be achieved by having both the RADIUS server and backend security server store information in the same backend database; by having the backend security server provide a full RADIUS implementation; or by consolidating both the backend security server and the RADIUS server onto the same machine.
これらの脅威に対処するために、データベースの統合をお勧めします。これは、RADIUSサーバとバックエンドセキュリティサーバの両方を同じバックエンドデータベースに格納することによって達成することができる。バックエンドセキュリティサーバーを提供することによって、完全な半径実装を提供します。または、バックエンドセキュリティサーバーとRADIUSサーバーの両方を同じマシンに統合します。
In a negotiation attack, a rogue NAS, tunnel server, RADIUS proxy or RADIUS server causes the authenticating peer to choose a less secure authentication method so as to make it easier to obtain the user's password. For example, a session that would normally be authenticated with EAP would instead authenticated via CHAP or PAP; alternatively, a connection that would normally be authenticated via one EAP type occurs via a less secure EAP type, such as MD5. The threat posed by rogue devices, once thought to be remote, has gained currency given compromises of telephone company switching systems, such as those described in [11].
交渉攻撃では、不正なNAS、トンネルサーバー、RADIUSプロキシまたはRADIUSサーバーによって、認証ピアには、ユーザーのパスワードの入手が容易になるように、認証ピアが安全な認証方法を選択させます。たとえば、通常はEAPで認証されるセッションは、代わりにCHAPまたはPAPを介して認証されます。あるいは、通常、1つのEAPタイプを介して認証される接続は、MD5などの安全なEAPタイプを介して行われます。不正なデバイスによって提起された脅威は、一度リモートであると考えられている、[11]に記載されているような電話会社のスイッチングシステムの妥協を与えた通貨を獲得しました。
Protection against negotiation attacks requires the elimination of downward negotiations. This can be achieved via implementation of per-connection policy on the part of the authenticating peer, and per-user policy on the part of the RADIUS server.
交渉攻撃に対する保護は、下向き交渉の排除を必要とします。これは、認証ピアの一部の接続ごとのポリシーの実装、およびRADIUSサーバーの一部のユーザーごとのポリシーの実装を介して実現できます。
For the authenticating peer, authentication policy should be set on a per-connection basis. Per-connection policy allows an authenticating peer to negotiate EAP when calling one service, while negotiating CHAP for another service, even if both services are accessible via the same phone number.
認証ピアの場合、認証ポリシーは接続ごとに設定されます。接続ごとのポリシーでは、両方のサービスが同じ電話番号を介してアクセス可能であっても、他のサービスのためにCHAPを交渉するときに、認証ピアは1つのサービスを呼び出すときにEAPをネゴシエートできます。
With per-connection policy, an authenticating peer will only attempt to negotiate EAP for a session in which EAP support is expected. As a result, there is a presumption that an authenticating peer selecting EAP requires that level of security. If it cannot be provided, it is likely that there is some kind of misconfiguration, or even that the authenticating peer is contacting the wrong server. Should the NAS not be able to negotiate EAP, or should the EAP-Request sent by the NAS be of a different EAP type than what is expected, the authenticating peer MUST disconnect. An authenticating peer expecting EAP to be negotiated for a session MUST NOT negotiate CHAP or PAP.
接続ごとのポリシーでは、認証ピアはEAPサポートが予想されるセッションのEAPをネゴシエートしようとします。その結果、EAPを選択する認証ピアがそのレベルのセキュリティを必要とするという推定があります。提供できない場合は、ある種の誤構成がある場合、または認証ピアが間違ったサーバーに連絡している可能性があります。NASがEAPをネゴシエートできない場合、またはNASによって送信されたEAP-Requestが予想されるものとは異なるEAPタイプである場合は、認証ピアが切断されなければなりません。セッションのためにEAPをネゴシエートすることを期待している認証ピアは、CHAPまたはPAPをネゴシエートしてはなりません。
For a NAS, it may not be possible to determine whether a user is required to authenticate with EAP until the user's identity is known. For example, for shared-uses NASes it is possible for one reseller to implement EAP while another does not. In such cases, if any users of the NAS MUST do EAP, then the NAS MUST attempt to negotiate EAP for every call. This avoids forcing an EAP-capable client to do more than one authentication, which weakens security.
NASの場合、ユーザの識別情報が知られるまで、ユーザがEAPで認証する必要があるかどうかを判断することは不可能であるかもしれません。たとえば、Shared-Asse-Naseの場合、1つのリセラーが別のリセラーがEAPを実装していない可能性があります。そのような場合、NASのユーザーがEAPを実行する必要がある場合、NASはすべての呼び出しに対してEAPをネゴシエートしようとしなければなりません。これにより、EAP対応クライアントが複数の認証を行うように強制的に、セキュリティを弱めます。
If CHAP is negotiated, the NAS will pass the User-Name and CHAP-Password attributes to the RADIUS Server in an Access-Request packet. If the user is not required to use EAP, then the RADIUS Server will respond with an Access-Accept or Access-Reject packet as appropriate. However, if CHAP has been negotiated but EAP is required, the RADIUS server MUST respond with an Access-Reject, rather than an Access-Challenge/EAP-Message/EAP-Request packet. The authenticating peer MUST refuse to renegotiate authentication, even if the renegotiation is from CHAP to EAP.
CHAPがネゴシエートされている場合、NASはアクセス要求パケット内のRADIUSサーバにユーザ名とCHAPパスワード属性を渡します。ユーザーがEAPを使用する必要がない場合、RADIUSサーバーは必要に応じてアクセス許可またはアクセス拒否パケットで応答します。ただし、CHAPがネゴシエートされているがEAPが必要な場合、RADIUSサーバはアクセスチャレンジ/ EAP - MESSAGE / EAP要求パケットではなく、アクセス拒否で応答する必要があります。認証ピアは、再ネゴシエーションがCHAPからEAPへのものであっても認証の再認証を拒否する必要があります。
If EAP is negotiated but is not supported by the RADIUS proxy or server, then the server or proxy MUST respond with an Access-Reject. In these cases, the NAS MUST send an LCP-Terminate and disconnect the user. This is the correct behavior since the authenticating peer is expecting EAP to be negotiated, and that expectation cannot be fulfilled. An EAP-capable authenticating peer MUST refuse to renegotiate the authentication protocol if EAP had initially been negotiated. Note that problems with a non-EAP capable RADIUS proxy could prove difficult to diagnose, since a user dialing in from one location (with an EAP-capable proxy) might be able to successfully authenticate via EAP, while the same user dialing into another location (and encountering an EAP-incapable proxy) might be consistently disconnected.
EAPがネゴシエートされているがRADIUSプロキシまたはサーバでサポートされていない場合、サーバまたはプロキシはアクセス拒否で応答する必要があります。このような場合、NASはLCPキーを送信してユーザーを切断しなければなりません。認証ピアがEAPを交渉することを期待しているため、これは正しい動作であり、その期待を満たすことはできません。EAPが最初にネゴシエートされていた場合、EAP対応認証ピアは認証プロトコルを再交渉することを拒否しなければなりません。EAP対応のRADIUSプロキシに関する問題は、（EAP対応のプロキシを使用して）1つの場所からダイヤルインしているユーザーがEAPで正常に認証できますが、同じユーザーが別の場所にダイヤルしている間に診断が困難である可能性があることに注意してください。（そしてEAP-Capable Proxyの遭遇）が一貫して切断される可能性があります。
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[1] Rigney、C、Willens、S.、Rubens、A.およびW.Simpson、「ユーザーサービスのリモート認証ダイヤル（RADIUS）」、RFC 2865、2000年6月。
[2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[2] RFC、RFC 2866、2000年6月、RFC 2866。
[3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication Protocol (EAP)", RFC 2284, March 1998.
[3] Blunk、L.およびJ.Vollbrecht、「PPP Extensible Authentication Protocol（EAP）」、RFC 2284、1998年3月。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March, 1997.
[4] Bradner、S。、「RFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700, October 1994.
[5] Reynolds、J.およびJ. Postel、「割り当てられた番号」、STD 2、RFC 1700、1994年10月。
[6] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[6] Zorn、G.、Leifer、D.、Rubens、A.、Shiver、J.、Holdrege、M.およびI。Goyret、「トンネルプロトコルのサポートのためのRADIUS属性」、RFC 2868、2000年6月。
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[7] Zorn、G.、Aboba、B.およびD. Mitton、「Tunnel Protocol SupportのためのRADIUS会計修正」、RFC 2867、2000年6月。
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.
[8] Yelgeau、F。、「ISO 10646の変換フォーマット」、RFC 2279、1998年1月。
[9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[9] Krawczyk、H.、Bellare、M.およびR. Canetti、 "HMAC：メッセージ認証用キー付きハッシング"、RFC 2104、1997年2月。
[10] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[10] Alvestrand、H.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[11] Slatalla, M., and Quittner, J., "Masters of Deception." HarperCollins, New York, 1995.
[11] Slatalla、M.、およびKeittner、J.、「詐欺のマスター」HarperCollins、ニューヨーク、1995年。
RADIUS and RADIUS Accounting were originally developed by Livingston Enterprises (now part of Lucent Technologies) for their PortMaster series of Network Access Servers.
RADIUSおよびRADIUS会計はもともとPortmasterシリーズのネットワークアクセスサーバーのためのLivingston Enterprises（現在はLucent Technologiesの一部）によって開発されました。
The section on ARAP is adopted with permission from "Using RADIUS to Authenticate Apple Remote Access Connections" by Ward Willats of Cyno Technologies (ward@cyno.com).
ARAPのセクションは、Cyno Technologies（ward@cyno.com）のWard Willatsによって「RADIUSを認証するためのRADIUSの使用」の許可を得て採用されています。
The section on Acct-Interim-Interval is adopted with permission from an earlier work in progress by Pat Calhoun of Sun Microsystems, Mark Beadles of Compuserve, and Alex Ratcliffe of UUNET Technologies.
ACCT-Interim-Intervalのセクションは、Sun MicrosystemsのPat Chalhoun、Compuserveのマークビーズ、およびUUnet TechnologiesのAlex Ratcliffeによって、以前の作業からの許可を得て採用されています。
The section on EAP is adopted with permission from an earlier work in progress by Pat Calhoun of Sun Microsystems, Allan Rubens of Merit Network, and Bernard Aboba of Microsoft. Thanks also to Dave Dawson and Karl Fox of Ascend, and Glen Zorn and Narendra Gidwani of Microsoft for useful discussions of this problem space.
EAPのセクションは、Sun MicrosystemsのPAT Calhoun、Allan MicroitネットワークのAllan Rubens、およびMicrosoftのBernard Abobaによって、以前の作業からの許可を得て採用されています。Dave DawsonとAscendのKarl Fox、およびMicrosoftのGlen ZornとNarendra Gidwaniも、この問題空間の便利な議論をしています。
The RADIUS working group can be contacted via the current chair:
RADIUSワーキンググループは現在の議長を介して連絡することができます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton、カリフォルニア州94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
Questions about this memo can also be directed to:
このメモに関する質問は、次のこともできます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton、カリフォルニア州94588
EMail: cdr@telemancy.com
Questions on ARAP and RADIUS may be directed to:
ARAPとRADIUSに関する質問は次のように指示される可能性があります。
Ward Willats Cyno Technologies 1082 Glen Echo Ave San Jose, CA 95125
Ward Willats Cyno Technologies 1082 Glen Echo Ave San Jose、CA 95125
Phone: +1 408 297 7766 EMail: ward@cyno.com Questions on EAP and RADIUS may be directed to any of the following:
電話：1 408 297 7766 Eメール：ward @ cyno.com EAPとRADIUSに関する質問は、次のいずれかに向けられます。
Pat R. Calhoun Network and Security Research Center Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025
PAT R. Calhounネットワークとセキュリティ研究センターSun Microsystems、Inc。15ネットワークサークルメンロパーク、CA 94025
Phone: +1 650 786 7733
EMail: pcalhoun@eng.sun.com
Allan C. Rubens Tut Systems, Inc. 220 E. Huron, Suite 260 Ann Arbor, MI 48104
Allan C. Rubens Tut Systems、Inc。220 E. Huron、Suite 260 Ann Arbor、MI 48104
Phone: +1 734 995 1697
EMail: arubens@tutsys.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
Bernard Aboba Microsoft Corporation 1つのMicrosoft Way Redmond、WA 98052
Phone: +1 425 936 6605
EMail: bernarda@microsoft.com
Copyright (C) The Internet Society (2000). All Rights Reserved.
著作権（C）インターネットソサエティ（2000）。全著作権所有。
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 assigns.
上記の限られた権限は永続的であり、インターネット社会やその後継者によって取り消されることはありません。
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エディタ機能のための資金は、現在インターネット社会によって提供されています。