RFC2869 日本語訳
2869 RADIUS Extensions. C. Rigney, W. Willats, P. Calhoun. June 2000. (Format: TXT=96854 bytes) (Updated by RFC3579, RFC5080) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Rigney
Request for Comments: 2869 Livingston
Category: Informational W. Willats
Cyno Technologies
P. Calhoun
Sun Microsystems
June 2000
Rigneyがコメントのために要求するワーキンググループC.をネットワークでつないでください: 2869年のリビングストンカテゴリ: 情報のW.のWillats Cyno技術P.カルフーンサン・マイクロシステムズ2000年6月
RADIUS Extensions
半径拡大
Status of this Memo
この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.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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].
このドキュメントは、RFC2865[1]とRFC2866[2]で説明されたRemote Authentication Dial In User Service(RADIUS)プロトコルを使用することでNetwork Access Server(NAS)と共有されたAccounting Serverの間まで認証、承認、および課金情報を運ぶために追加属性について説明します。
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
1. 序論… 2 1.1 要件の仕様… 3 1.2用語… 3 2. 操作… 2.1RADIUSがInterim Accounting Updatesのためにサポートする4… 4 2.2RADIUSが、アップルのためにRemote Accessがプロトコルであるとサポートします… 5 2.3 拡張認証プロトコル(EAP)の半径サポート… 11 2.3 .1 概要について議定書の中で述べてください… 11 2.3 .2Retransmission… 13 2.3 .3断片化… 14 2.3 .4の例… 14 2.3 .5 代替の用途… 19 3. パケット形式… 19 4. パケットはタイプされます… 19 5. 属性… 20
Rigney, et al. Informational [Page 1] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [1ページ]情報のRFC2869半径拡大2000年6月
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
5.1 Acctはギガワードを入力しました… 22 5.2 Acctはギガワードを出力しました… 23 5.3イベントタイムスタンプ… 23 5.4アラップ-パスワード… 24 5.5 アラップ-特徴… 25 5.6 アラップのゾーンアクセス… 26 5.7アラップ-セキュリティ… 27 5.8のアラップ-セキュリティー・データ… 28 5.9 パスワードで再試行してください… 28 5.10 うながします。 29 5.11 インフォメーションを接続します… 30 5.12構成トークン… 31 5.13EAP-メッセージ… 32 5.14メッセージ固有識別文字… 33 5.15アラップ-チャレンジレスポンス… 35 5.16のAcctの当座の間隔… 36 5.17 NASはイドを移植します… 37 5.18 縁どられたプール… 属性の37 5.19テーブル… 38 6. IANA問題… 39 7. セキュリティ問題… 39 7.1 メッセージ固有識別文字セキュリティ… 39 7.2 EAPセキュリティ… 39 7.2 .1 EAPサーバとPPP固有識別文字の分離。 40 7.2 .2 接続ハイジャック… 41 7.2 .3 中央攻撃でやれやれ… 41 7.2 .4 倍数データベース… 41 7.2 .5 交渉は攻撃されます… 42 8. 参照… 43 9. 承認… 44 10. 議長のアドレス… 44 11. 作者のアドレス… 45 12. 完全な著作権宣言文… 47
1. Introduction
1. 序論
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.
それが今日実装されて、配布されるとき、RFC2865[1]はRADIUSプロトコルについて説明します、そして、RFC2866[2]はRADIUSと共にAccountingをどう実行できるかを説明します。
Rigney, et al. Informational [Page 2] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [2ページ]情報のRFC2869半径拡大2000年6月
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に加えることができる数個の追加Attributesを示します。 これらのAttributesはまだ広範囲な野外経験を持っていなくて、したがって、実験的であると考えられるべきです。
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の中の追加認証方法のサポートを提供するPPP拡張子です。 このメモはEAP-メッセージとMessage固有識別文字属性が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長さの価値の3tuplesから成ります。 プロトコルの不穏な既存の実装なしで新しい属性値を加えることができます。
1.1. Specification of Requirements
1.1. 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[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."
それが実装するプロトコルのための要件ではなく、必須か必須の1つ以上を満たさないなら、実装は対応しません。 そして、すべての必須を満たす実装、必須である、プロトコルのためのどんな要件も「無条件に言いなりになる」と言われていません;であるべきです または、要件ではなく、すべての必須と必須を満たしますが、すべて満足するというわけではないもの、「条件付きに言いなりになる」とプロトコルのためのどんな要件も言うべきではありません。
A NAS that does not implement a given service MUST NOT implement the RADIUS attributes for that service. For example, a NAS that is unable to offer 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が属性であると実装してはいけません。 代わりにアクセス廃棄物として入手できないサービスを要求するRADIUSがアクセスして要求するNAS MUSTの御馳走。
1.2. Terminology
1.2. 用語
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
ダイヤルインのユーザへのNASがセッションを構成するセッションの始まりが最初に、サービスを提供して、セッションの終わりがどこかをポイントと定義したポイントと定義されている状態で、セッションEachはサービスを修理します。
Rigney, et al. Informational [Page 3] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [3ページ]情報のRFC2869半径拡大2000年6月
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がそれをサポートするなら各セッションが別々の始めを生成していて平行な複数のセッションかシリーズを持って、会計帳簿を止めるかもしれません。
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
さらに処理しながら、静かにThis手段を実装がパケットを捨てる捨ててください。 実装SHOULDは静かに捨てられたパケットのコンテンツを含む誤りを登録する能力を提供します、そして、SHOULDは統計カウンタに出来事を記録に残します。
2. Operation
2. 操作
Operation is identical to that defined in RFC 2865 [1] and RFC 2866 [2].
操作はRFC2865[1]とRFC2866[2]で定義されたそれと同じです。
2.1. RADIUS support for Interim Accounting Updates
2.1. Interim Accounting UpdatesのRADIUSサポート
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サーバはaに対応してAccess受け入れているうまくいっているAccess-要求を出します。 サーバが与えられたユーザのために当座の会計メッセージを受け取りたいなら、それはメッセージにAcctの当座の間隔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自身で静的に当座の値を構成するのも可能です。 aが中で局所的に値が見つけたNAS MUSTオーバーライドの値を構成したことに注意してください、Access受け入れてください。
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サーバが新しいAttributeを絶対に加えないので、この体系は後方の相互運用性を壊しません。 この拡大をサポートしないNASesがAttributeを無視するでしょう。
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.
Interim Accountingは記録します。それが思い描かれる、それ、(Acct状態タイプで、=当座のアップデート(3))は通常、Acct用語原因属性を除いて、Accounting Stopメッセージで見つけられた属性のすべてを含んでいるでしょう。
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 MUSTは、与えられたセッションへの当座のAccountingメッセージの1世代だけがその時々で再送キューで存在しているのを確実にします。
Rigney, et al. Informational [Page 4] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [4ページ]情報のRFC2869半径拡大2000年6月
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 MAYは、別々のセッションへのInterim Accountingメッセージの間の無作為の遅れを加えるのにファッジ要素を使用します。 これは、1サイクルがすぐにすべてのメッセージを送るところで防がれて、そうでなければ、プライマリリンクであるなら起こるかもしれないときそのようなものが最近、回復して、多くのダイアルアップユーザーがすぐに同じNASに向けられたのを確実にするでしょう。
The Network and NAS CPU load of using Interim Updates should be carefully considered, and appropriate values of Acct-Interim-Interval chosen.
Interim Updatesを使用するNetworkとNAS CPU荷重は選ばれたAcctの当座の間隔の慎重に考えられて、適切な値であるべきです。
2.2. RADIUS support for Apple Remote Access Protocol
2.2. RADIUSは、アップルのためにRemote Accessがプロトコルであるとサポートします。
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(リモート中のAuthentication Dial User Service)プロトコルは複数のダイヤルインのNetwork Access Server(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.
アップルRemote Accessプロトコル(ARAP)は、二地点間リンクの上の送付AppleTalkネットワークトラフィックにメソッドを通常提供しますが、排他的に提供するというわけではありません、非同期、そして、ISDN交換回線網接続。 アップルは今後のリモートアクセス・サービスのためにPPPの上のATCPに近づいていますが、ARAPはそれでも、マッキントッシュユーザのインストールされたベースがリモートネットワーク接続を作る一般的な方法であり、それほどしばらく残っていそうです。
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と共にしばしば認証されるというわけではありませんか、または各ベンダーは個々のソリューションを問題に作成します。
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
2. バンドのアウトは通信します。 いつでも、NASはARAクライアントへのダイヤルインのユーザのスクリーンにダイアログボックスの中に現れるメッセージを送ることができます。 これらは、認証の一部でなく、またここに属しません。 しかしながら、私たちは、aが中の属性をReply通信させることに注意します。
Rigney, et al. Informational [Page 5] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [5ページ]情報のRFC2869半径拡大2000年6月
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.
Access受け入れてください。日のストリングのサインオンなメッセージとしてバンドで出かけているチャンネルを使用することでユーザまで送ってもよいです。
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プロトコルの精神をできるだけ尊敬しようとしました、デザインを従来技術とのコンパチブル決定にして。 さらに、私たちはただ一つの多重送信されたARAP属性ストリング以内かExtended Authenticationプロトコル(EAP)[3]機械の中に新しい属性でRADIUS世界をあふれさせて、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は二相における接続を認証します。 1番目がaである、「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_挑戦パケットのダイヤルインのクライアントに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. ダイヤルインのクライアントはユーザのパスワードをDESに使用します。NASによってそれに送られた2つの乱数を暗号化してください。 そして、ダイヤルインのクライアントはそれ自身のこの結果、ユーザの名前、および2つの32ビットの乱数をARAP msg_auth_リクエスト・パケットの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_応答パケットでダイヤルインのクライアントにそれを送り返します。
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_応答パケットを受けるとき、それは、_再びARAP msg_でパケットをauthすると認めるでしょう。
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
この最初の「DESフェーズ」の後に、ARAP NAS MAYは、アップルが「アドインセキュリティーモジュール」と呼ぶものを使用することでセカンダリ認証フェーズを開始します。 セキュリティModulesが稼働するコードの小さい断片である、オン
Rigney, et al. Informational [Page 6] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [6ページ]情報のRFC2869半径拡大2000年6月
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.
そして、クライアントとサーバの両方、追加認証機能を実行するためにコミュニケーションリンクの向こう側に任意のデータを読み書きするのが許容されています。 様々なセキュリティトークンベンダーは、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 Phaseの後とSecurity Moduleフェーズの前に何らかのプロフィール情報を下に降ろします。 これは、また、挑戦への応答以外にこのプロフィール情報もいくらか珍しい時に存在していなければならないことを意味します。 幸い、情報はこのドキュメントがただ一つの新しい属性に梱包するパスワードに関連するほんの数数値データです。
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接続を代表してAccess-要求をRADIUSに提示するのは簡単です。 ARAP NASは乱数が挑戦であると生成して、次に、ダイヤルインのクライアントの応答、ダイヤルインのクライアントの挑戦、およびユーザの名前を受け取ります。 ユーザがゲストでないと仮定して、Access-リクエスト・パケットで以下の情報を転送します: Service-タイプ、NAS IPアドレス、NAS-イド、NASポートタイプ、NAS-ポート、NASポートイド、Connect-インフォメーションなどのように必要なユーザ名(最大31のキャラクタが切望する)、Framed-プロトコル(3、ARAPに設定する)、ARAP-パスワード、およびどんな追加属性
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.
Request Authenticatorによるaが、16八重奏が乱数であるとNAS生成したということです。 4つの八重奏の無作為の番号がARAP msg_auth_挑戦パケットで必要とした2としてこの数の下位の8つの八重奏をダイヤルインのユーザに送ります。 八重奏0-3は最初の乱数です、そして、Octets4-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-要求におけるARAP-パスワードは、16八重奏乱数分野を含んでいて、NASへのNAS挑戦とクライアントの自己の挑戦へのダイヤルインのユーザの応答を運ぶのに使用されます。 高いオーダー八重奏はNASへのダイヤルインのユーザの挑戦を含んでいます、そして、(2 32が数に噛み付きました、8つの八重奏)下位の八重奏はNAS挑戦(2つの32ビットの番号、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.
Access-要求、または1つ以上のEAP-メッセージに存在しているUser-パスワード、CHAP-パスワード、またはARAP-パスワードの必要性の1つだけ。
If the RADIUS server does not support ARAP it SHOULD return an Access-Reject to the NAS.
RADIUSサーバがARAPをサポートしない、それ、SHOULDはAccess-廃棄物をNASに返します。
Rigney, et al. Informational [Page 7] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [7ページ]情報のRFC2869半径拡大2000年6月
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をサポートするなら、それは、Challenge(Request Authenticatorの下層階級8八重奏からの)とユーザの応答を使用することでユーザの応答について確かめるべきです(安値から、ARAP-パスワードの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サーバはAccess-廃棄物パケットをNASに返すべきです、任意のPassword-再試行とReply-メッセージ属性で。 Password-再試行の存在は、ARAP NAS MAYが、もう1チャレンジレスポンスサイクルを開始するのを選ぶのを示します、Password-再試行属性の整数値と等しい回の総数まで。
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サーバはAccess受け入れているパケット(コード2)をNASに返すべきです、IDとResponse Authenticatorが通常通りであり、属性は以下の通りで:
Service-Type of Framed-Protocol.
縁どられたプロトコルのサービスタイプ。
Framed-Protocol of ARAP (3).
アラップ(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).
秒のユーザにとって、最大の接続時間があるセッションタイムアウト。 無制限な時間をユーザに与えるつもりであるなら、Access受け入れているパケットでSession-タイムアウトを含めるべきではありません、そして、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.
ダイヤルインのクライアントの挑戦への応答による8つの八重奏を含むARAP挑戦応答。 RADIUSサーバは、ARAP-パスワードの8つの八重奏が結果と考える高位からダイヤルインのクライアントの挑戦を取って、キーとして認証しているユーザのパスワードでこの値にDES暗号化を実行することによって、この値について計算します。 ユーザのパスワードが長さが8つ未満の八重奏であるなら、キーとしてそれを使用する前に、パスワードは終わりにNULL八重奏で8の長さに水増しされます。 ユーザのパスワードが長さが8つ以上の八重奏であるなら、代わりにAccess-廃棄物を送らなければなりません。
ARAP-Features, containing information that the NAS should send to
the user in an ARAP "feature flags" packet.
「旗を特徴としてください」というARAPパケットに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)。
Rigney, et al. Informational [Page 8] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [8ページ]情報のRFC2869半径拡大2000年6月
Octet 2-5: Password creation date in Macintosh format, defined
as 32 bits unsigned representing seconds since Midnight GMT
January 1, 1904.
八重奏2-5: Midnight以来1904年1月1日にグリニッジ標準時に32ビットの未署名の表す秒と定義されたマッキントッシュ書式におけるパスワード作成日付。
Octet 6-9 Password Expiration Delta from create date in
seconds.
八重奏6-9Password Expirationデルタ、秒に日付を作成してください。
Octet 10-13: Current RADIUS time in Macintosh format
八重奏10-13: マッキントッシュ形式における現在の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-メッセージは、日の対話に関する署名する/メッセージに表示するためにユーザにダウンします。
Framed-AppleTalk-Network may be included.
縁どられたAppleTalkネットワークは含まれるかもしれません。
Framed-AppleTalk-Zone, up to 32 characters in length, may be
included.
縁どられたAppleTalkゾーン(長さにおける最大32のキャラクタ)は含まれるかもしれません。
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はユーザのためにゾーンのリストの概念を定義します。 ゾーン名のリストと共に、Zone Access Flagは定義されます(ゾーン名のリストを使用する方法を言います)(そして、NASが使用されます)。 すなわち、ダイヤルインのユーザは、Default Zone、ゾーンリストのゾーン(包括的な)だけまたはそれら以外のゾーンリストのどんなゾーンも(排他的)であると見ることができるだけであるかもしれません。
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-アイダホ州が参照をつけなければならないということです。
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ゾーンアクセスはこのユーザへの「ゾーンリスト」がどう使用されるべきであるかを指定する整数を含んでいます。 また、値がこの属性が存在していて、2か4であるなら、Filter-イドも、アクセス旗を適用するゾーンリストフィルタを命名するために存在していなければなりません。
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受け入れている5月のCallback-数かCallback-イド属性の包含で、ARAPの特定の方法でコールバック処理を始めるためにFeature Flagsを送った後に、ARAP NASは切断します。
Rigney, et al. Informational [Page 9] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [9ページ]情報のRFC2869半径拡大2000年6月
Other attributes may be present in the Access-Accept packet as well.
他の属性はまた、Access受け入れているパケットに存在しているかもしれません。
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が、他の情報が、クライアントでダイヤルに接続を育て終える必要がありますが、この情報をARAP NASが少しも助けなしでSNMP、NAS運用管理プログラムでRADIUSからどちらか構成まで提供するか、または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値。 Framed-AppleTalkネットワーク属性か構成かAppleTalkスタックonthe NASからAppearAsNetを取ることができます。
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ゾーン属性で指定できます。)
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. このユーザへの「ゾーンList」情報。 ARAP仕様は実際に未使用であることの「ゾーンカウント」分野を定義します。
RADIUS supports ARAP Security Modules in the following manner.
RADIUSは以下の方法でARAP Security Modulesをサポートします。
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サーバは、ダイヤルインのユーザのために1つ以上のセキュリティーモジュールを実行するようARAP NASに命令するかもしれません。 基本的なプロトコルは、実行が複数のセキュリティーモジュールであると連続的にサポートしますが、すべての現在の実装で、実際には、1つを実行するだけです。 複数のAccess-挑戦要求の使用で、複数のモジュールをサポートすることができますが、この施設はたぶん決して使用されないでしょう。
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:
RADIUSサーバが、セキュリティーモジュールを実行するようARAP NASに命令したいなら、(任意に)州属性、ARAP-挑戦応答、ARAP-特徴、およびもう2つの属性があるNASにAccess-挑戦パケットを送るべきです:
Rigney, et al. Informational [Page 10] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 10] RFC 2869 RADIUS Extensions June 2000
ARAP-Security: a four octet security module signature, containing a Macintosh OSType.
ARAP-Security: a four octet security module signature, containing a Macintosh OSType.
ARAP-Security-Data, a string to carry the actual security module challenge and response.
ARAP-Security-Data, a string to carry the actual security module challenge and response.
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.
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.3. RADIUS Support for Extensible Authentication Protocol (EAP)
2.3. RADIUS Support for Extensible Authentication Protocol (EAP)
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.
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.
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.
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.
2.3.1. Protocol Overview
2.3.1. Protocol Overview
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.
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.
Rigney, et al. Informational [Page 11] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 11] RFC 2869 RADIUS Extensions June 2000
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.
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.
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.
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.
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.
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.
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.
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.
Rigney, et al. Informational [Page 12] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 12] RFC 2869 RADIUS Extensions June 2000
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.
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.
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.
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.
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.
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.
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.
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.
2.3.2. Retransmission
2.3.2. Retransmission
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.
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.
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.
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.
Rigney, et al. Informational [Page 13] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 13] RFC 2869 RADIUS Extensions June 2000
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.
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.
2.3.3. Fragmentation
2.3.3. Fragmentation
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.
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.
2.3.4. Examples
2.3.4. Examples
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.
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.
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
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 ->
<- 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 ->
Rigney, et al. Informational [Page 14] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 14] RFC 2869 RADIUS Extensions June 2000
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:
In the case where the NAS first sends an EAP-Start packet to the RADIUS server, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
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 ->
<- 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 ->
Rigney, et al. Informational [Page 15] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 15] RFC 2869 RADIUS Extensions June 2000
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:
In the case where the client fails EAP authentication, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
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/
<- 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/
Rigney, et al. Informational [Page 16] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 16] RFC 2869 RADIUS Extensions June 2000
EAP-Message/
EAP-Response/
OTP, OTPpw ->
<- RADIUS
Access-Reject/
EAP-Message/EAP-Failure
EAP-Message/ EAP-Response/ OTP, OTPpw -> <- RADIUS Access-Reject/ EAP-Message/EAP-Failure
<- PPP EAP-Failure
(client disconnected)
<- PPP EAP-Failure (client disconnected)
In the case that the RADIUS server or proxy does not support EAP-Message, the conversation would appear as follows:
In the case that the RADIUS server or proxy does not support EAP-Message, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
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:
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:
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
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
Rigney, et al. Informational [Page 17] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 17] RFC 2869 RADIUS Extensions June 2000
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 (proxied from remote RADIUS Server) <- PPP LCP Terminate (User Disconnected)
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:
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:
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
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:
In the case where the NAS does not support EAP, but where EAP is required for that user, the conversation would appear as follows:
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
Authenticating Peer NAS RADIUS Server ------------------- --- -------------
<- PPP LCP Request-CHAP
auth
<- PPP LCP Request-CHAP auth
Rigney, et al. Informational [Page 18] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 18] RFC 2869 RADIUS Extensions June 2000
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)
2.3.5. Alternative uses
2.3.5. Alternative uses
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.
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.
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.
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.
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.
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.
3. Packet Format
3. Packet Format
Packet Format is identical to that defined in RFC 2865 [1] and 2866 [2].
Packet Format is identical to that defined in RFC 2865 [1] and 2866 [2].
4. Packet Types
4. Packet Types
Packet types are identical to those defined in RFC 2865 [1] and 2866 [2].
Packet types are identical to those defined in RFC 2865 [1] and 2866 [2].
See "Table of Attributes" below to determine which types of packets can contain which attributes defined here.
See "Table of Attributes" below to determine which types of packets can contain which attributes defined here.
Rigney, et al. Informational [Page 19] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 19] RFC 2869 RADIUS Extensions June 2000
5. Attributes
5. Attributes
RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response.
RADIUS Attributes carry the specific authentication, authorization and accounting details for the request and response.
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.
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.
The end of the list of attributes is indicated by the Length of the RADIUS packet.
The end of the list of attributes is indicated by the Length of the RADIUS packet.
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.
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.
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
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:
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:
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
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
Rigney, et al. Informational [Page 20] RFC 2869 RADIUS Extensions June 2000
Rigney, et al. Informational [Page 20] RFC 2869 RADIUS Extensions June 2000
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
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
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.
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.
Value
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.
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.
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.
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.
The format of the value field is one of five data types. Note
that type "text" is a subset of type "string."
The format of the value field is one of five data types. Note that type "text" is a subset of type "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 octets containing UTF-8 encoded 10646 [8] characters. Text of length zero (0) MUST NOT be sent; omit the entire attribute instead.
Rigney, et al. Informational [Page 21] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [21ページ]情報のRFC2869半径拡大2000年6月
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 バイナリ・データ(10進的であって、包括的に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は最初に、未署名の値、最も重要な八重奏に噛み付きました--協定世界時0時0分0秒、1970年1月1日以来の秒時。
5.1. Acct-Input-Gigawords
5.1. Acct入力ギガワード
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入力八重奏カウンタが何回およそ2^32を包装したかを示して、単にAcct状態タイプがStopかInterimアップデートに用意ができているAccounting-要求記録に存在している場合があります。
A summary of the Acct-Input-Gigawords attribute format is shown below. The fields are transmitted from left to right.
Acct入力ギガワード属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
52 for Acct-Input-Gigawords.
52 Acct入力ギガワードのために。
Length
長さ
6
6
Value
値
The Value field is four octets.
Value分野は4つの八重奏です。
Rigney, et al. Informational [Page 22] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [22ページ]情報のRFC2869半径拡大2000年6月
5.2. Acct-Output-Gigawords
5.2. Acct出力ギガワード
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出力八重奏カウンタが何回およそ2^32を包装したかを示して、Acct状態タイプがStopに用意ができているAccounting-要求記録かInterim-アップデートだけで存在している場合があります。
A summary of the Acct-Output-Gigawords attribute format is shown below. The fields are transmitted from left to right.
Acct出力ギガワード属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
53 for Acct-Output-Gigawords.
53 Acct出力ギガワードのために。
Length
長さ
6
6
Value
値
The Value field is four octets.
Value分野は4つの八重奏です。
5.3. Event-Timestamp
5.3. イベントタイムスタンプ
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.
この属性は、1970年1月1日協定世界時0時0分のこのイベントが以来秒にNASに起こった時に記録するためにAccounting-リクエスト・パケットに含まれています。
A summary of the Event-Timestamp attribute format is shown below. The fields are transmitted from left to right.
Event-タイムスタンプ属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
Rigney, et al. Informational [Page 23] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [23ページ]情報のRFC2869半径拡大2000年6月
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(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.
1970年1月1日協定世界時0時0分以来Value分野は秒数に従った符号のない整数をコード化する4つの八重奏です。
5.4. ARAP-Password
5.4. アラップ-パスワード
Description
記述
This attribute is only present in an Access-Request packet
containing a Framed-Protocol of ARAP.
ARAPのFramed-プロトコルを含んでいて、この属性は単にAccess-リクエスト・パケットに存在しています。
Only one of User-Password, CHAP-Password, or ARAP-Password needs
to be present in an Access-Request, or one or more EAP-Messages.
Access-要求、または1つ以上のEAP-メッセージに存在しているUser-パスワード、CHAP-パスワード、またはARAP-パスワードの必要性の1つだけ。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| Value1+++++++++++++++++++++++++++++++++| Value2+++++++++++++++++++++++++++++++++| Value3+++++++++++++++++++++++++++++++++| Value4+++++++++++++++++++++++++++++++++| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rigney, et al. Informational [Page 24] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [24ページ]情報のRFC2869半径拡大2000年6月
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).
この属性は16八重奏ストリングを含んでいます、NASへのNAS挑戦とクライアントの自己の挑戦へのダイヤルインのユーザの応答を運ぶのにおいて、使用されています。 高位八重奏(Value1とValue2)はNAS(2つの32ビットの番号、8つの八重奏)へのダイヤルインのユーザの挑戦を含んでいます、そして、下位の八重奏(Value3とValue4)はNAS挑戦(2つの32ビットの番号、8つの八重奏)へのダイヤルインのユーザの応答を含んでいます。
5.5. ARAP-Features
5.5. アラップ-特徴
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.
この属性は、ARAPのFramedプロトコルがあるAccess受け入れているパケットで送られて、「旗を特徴としてください」というARAPパケットにユーザに送って、NASがそうするべきであるというパスワード情報を含んでいます。
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| Value1| Value2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value3| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value4| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value5| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
71 for ARAP-Features.
71 アラップ-特徴のために。
Length
長さ
16
16
Rigney, et al. Informational [Page 25] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [25ページ]情報のRFC2869半径拡大2000年6月
Value
値
The Value field is a compound string containing information the
NAS should send to the user in the ARAP "feature flags" packet.
Value分野はARAP「特徴旗」パケットにNASがユーザに送るはずである情報を含む合成ストリングです。
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: 1904年1月1日にグリニッジ標準時にMidnight以来の秒を表す未署名の32ビットと定義されたマッキントッシュ書式におけるパスワード作成日付。
Value4: Password Expiration Delta from create date in seconds.
Value4: パスワードExpirationデルタ、秒に日付を作成してください。
Value5: Current RADIUS time in Macintosh format.
Value5: マッキントッシュ形式における現在のRADIUS時間。
5.6. ARAP-Zone-Access
5.6. アラップのゾーンアクセス
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.
この属性はAccess受け入れているパケットにARAPのFramed-プロトコルで含まれていて、ユーザへのARAPゾーンリストがどう使用されるべきであるかを示します。
A summary of the ARAP-Zone-Access 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
72 for ARAP-Zone-Access.
72 アラップゾーンアクセサリーのために
Length
長さ
6
6
Rigney, et al. Informational [Page 26] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [26ページ]情報のRFC2869半径拡大2000年6月
Value
値
The Value field is four octets encoding an integer with one of the
following values:
Value分野は以下の値の1つに従った整数をコード化する4つの八重奏です:
1 Only allow access to default zone
2 Use zone filter inclusively
4 Use zone filter exclusively
1が許容するだけである、デフォルトゾーン2Useゾーンへのアクセスは包括的に排他的に4Useゾーンフィルタをフィルターにかけます。
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実装手段が「すべて区分する」指定aでないのと同じ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-イドも、アクセス旗を適用するゾーンリストフィルタを命名するために存在していなければなりません。
5.7. ARAP-Security
5.7. アラップ-セキュリティ
Description
記述
This attribute identifies the ARAP Security Module to be used in
an Access-Challenge packet.
この属性は、Access-挑戦パケットで使用されるためにARAP Security Moduleを特定します。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
73 for ARAP-Security.
73 アラップ-セキュリティのために。
Length
長さ
6
6
Rigney, et al. Informational [Page 27] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [27ページ]情報のRFC2869半径拡大2000年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分野はマッキントッシュOSTypeであるセキュリティーモジュール署名を指定する整数を含む4つの八重奏です。 (マッキントッシュOSTypesは32ビットの整数として4ASCIIキャラクタキャストです)
5.8. ARAP-Security-Data
5.8. アラップ-セキュリティー・データ
Description
記述
This attribute contains the actual security module challenge or
response, and can be found in Access-Challenge and Access-Request
packets.
この属性は、実際のセキュリティーモジュール挑戦か応答を含んでいて、Access-挑戦とAccess-リクエスト・パケットで見つけることができます。
A summary of the ARAP-Security-Data attribute format is shown below. The fields are transmitted from left to right.
ARAPセキュリティデータ属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
74 for ARAP-Security-Data.
74 アラップ-セキュリティー・データのために。
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-セキュリティで指定されるARAP Security Moduleに関連しているセキュリティーモジュール挑戦か応答を含んでいます。
5.9. Password-Retry
5.9. パスワード再試行
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-廃棄物に含まれるかもしれません。
It is primarily intended for use with ARAP authentication.
それはARAP認証による使用のために主として意図します。
Rigney, et al. Informational [Page 28] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [28ページ]情報のRFC2869半径拡大2000年6月
A summary of the Password-Retry attribute format is shown below. The fields are transmitted from left to right.
Password-再試行属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(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つの八重奏です。
5.10. Prompt
5.10. プロンプト
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-挑戦パケットだけで使用されて、それがそれが入られるのに従ってユーザの応答をまねるべきではありませんし、またそれを反響するべきでないかをNASに示します。
A summary of the Prompt attribute format is shown below. The fields are transmitted from left to right.
Prompt属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
76 for Prompt.
76 プロンプトに。
Rigney, et al. Informational [Page 29] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [29ページ]情報のRFC2869半径拡大2000年6月
Length
長さ
6
6
Value
値
The Value field is four octets.
Value分野は4つの八重奏です。
0 No Echo
1 Echo
0 いいえエコー1エコー
5.11. Connect-Info
5.11. インフォメーションを接続します。
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 MAYは、ユーザの接続の本質を示すためにAccess-要求かAccounting-要求でこの属性を送ります。
A summary of the Connect-Info attribute format is shown below. The fields are transmitted from left to right.
Connect-インフォメーション属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
77 for Connect-Info.
77、インフォメーションを接続します。
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-インフォメーション属性の始めにSHOULDを促進します。 送受信、接続速度が異なって、それらが最初の属性にともに含まれるかもしれない、最初に(NASモデムが伝わる速度)速度を伝えてください、aスラッシュ(/)、速度、任意に他の当時の情報を受け取ってください。
Rigney, et al. Informational [Page 30] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [30ページ]情報のRFC2869半径拡大2000年6月
For example, "28800 V42BIS/LAPM" or "52000/31200 V90"
例えば、「28800V42BIS/LAPM」か「52000/31200V90"」
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.
1つ以上のConnect-インフォメーション属性が、モデムに252の八重奏を超えるかもしれない標準書式の、より多くの接続情報を報告させるようにITUで予想された取り組みを収容するためにAccounting-リクエスト・パケットに存在しているかもしれません。
5.12. Configuration-Token
5.12. 構成トークン
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.
この属性はプロキシに基づく大きい分配された認証ネットワークにおける使用のためのものです。 使用されるために一種のユーザを示すためにAccess受け入れているプロフィールでRADIUS ProxyサーバからRADIUS Proxy Clientにそれを送ります。 それをNASに送るべきではありません。
A summary of the Configuration-Token attribute format is shown below. The fields are transmitted from left to right.
Configuration-トークン属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
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.
この仕様の範囲の外にこの分野の許容用法の範囲の成文化があります。
Rigney, et al. Informational [Page 31] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [31ページ]情報のRFC2869半径拡大2000年6月
5.13. EAP-Message
5.13. EAP-メッセージ
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.
この属性は、NASがEAP EAPプロトコルを理解する必要はなくてを通してダイヤルインのユーザを認証するのを許容するためにExtended Accessがプロトコル[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属性に置いて、Access-要求の一部としてそれらをRADIUS Serverに送ります。(要求は、Access挑戦におけるメッセージをEAPに返して、Access受け入れて、パケットをAccess拒絶できます)。
A RADIUS Server receiving EAP messages that it does not understand
SHOULD return an Access-Reject.
SHOULDがAccess-廃棄物を返すのを理解していないというEAPメッセージを受け取るRADIUS Server。
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-メッセージ属性に置いて、Access-要求メッセージの中のRADIUS Serverにそれらを送ります。 複数のEAPメッセージがAccess-要求かAccess挑戦パケットの中に含まれているなら、彼らは整然とするに違いありません、そして、Access-要求かAccess-挑戦パケットの連続した属性であるに違いありません。 アクセスして受け入れてください。そうすれば、EAP-成功かEAPの故障を含んでいて、Access-廃棄物パケットSHOULDはそれらにONE EAP-メッセージ属性を持っているだけです。
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-成功かEAP-失敗パケット)を攻撃することによってEAPを打倒するのを防ぐために、ものがEAPでメソッド自体を使用したので、RADIUS/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.
したがって、Access-要求、Access-挑戦がAccess受け入れるすべて、およびEAP-メッセージ属性を含むAccess-廃棄物パケットを保護するのに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.
RADIUSサーバによって捨てられて、Message-固有識別文字属性SHOULDなしでEAP-メッセージ属性を含むアクセスリクエスト・パケットは静かにそうです。送られた値を合わせないなら、EAP-メッセージをサポートするRADIUS ServerはMessage-固有識別文字の正しい値について計算して、静かにパケットを捨てなければなりません。 EAP-メッセージ属性を含んでいて、Access-要求を受け取るなら、EAP-メッセージをサポートしないRADIUS ServerはAccess廃棄物を返さなければなりません。 それが理解していないEAP-メッセージ属性を受けるRADIUS ServerはAccess-廃棄物を返さなければなりません。
Rigney, et al. Informational [Page 32] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [32ページ]情報のRFC2869半径拡大2000年6月
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.
NASによって捨てられて、Access受け入れているアクセス挑戦かMessage-固有識別文字属性SHOULDなしでEAP-メッセージ属性を含むAccess-廃棄物パケットが静かにそうです。 送られた値を合わせないなら、EAP-メッセージをサポートするNASはMessage-固有識別文字の正しい値について計算して、静かにパケットを捨てなければなりません。
A summary of the EAP-Message attribute format is shown below. The fields are transmitted from left to right.
EAP-メッセージ属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
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.
String分野は[3]で定義されるようにEAPパケットを含んでいます。 複数のEAP-メッセージ属性がパケットに存在しているなら、それらの値は連結されるべきです。 これで、RADIUSは253の八重奏より長いEAPパケットが通ります。
5.14. Message-Authenticator
5.14. メッセージ固有識別文字
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.
この属性は、Access-要求がCHAPを使用するか、ARAPまたはEAP認証方法であると偽造するのを防ぐというAccess-要求に署名するのに使用されるかもしれません。 それはどんなAccess-要求でも使用されるかもしれません。 どんなAccess-要求、EAP-メッセージ属性を含んでいるAccess受け入れているAccess-廃棄物かAccess挑戦にもそれを使用しなければなりません。
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固有識別文字Attributeが存在していた状態でAccess-要求を受け取るRADIUS ServerはMessage-固有識別文字の正しい値について計算して、静かにパケットを捨てなければなりません。
Rigney, et al. Informational [Page 33] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [33ページ]情報のRFC2869半径拡大2000年6月
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.
送られた値を合わせないなら、Access受け入れているAccess-廃棄物かMessage-固有識別文字とのAccess-挑戦のAttributeプレゼントを受けるRADIUS ClientはMessage-固有識別文字の正しい値について計算して、静かにパケットを捨てなければなりません。
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.
このメモの以前の草稿はこの属性の名前として「署名」を使用しましたが、Message-固有識別文字は、より正確です。 操作が変えられて、正当でないのに持っている、名前。
A summary of the Message-Authenticator attribute format is shown below. The fields are transmitted from left to right.
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
80 for 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.
Access-リクエスト・パケットに存在しているとき、Message-固有識別文字は全体のAccess-リクエスト・パケットのHMAC-MD5[9]チェックサムです、Type、ID、Length、および固有識別文字を含んでいて、キーとして共有秘密キーを使用して、以下の通りです。
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
メッセージ固有識別文字=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:
Access-挑戦において、パケットをAccess受け入れて、Access拒絶してください、そして、Message-固有識別文字は以下の通り計算されます、このパケットが以下に対してあるというAccess-要求からRequest-固有識別文字を使用して
Message-Authenticator = HMAC-MD5 (Type, Identifier, Length,
Request Authenticator, Attributes)
メッセージ固有識別文字=HMAC-MD5(タイプ、識別子、長さ、要求固有識別文字、属性)
Rigney, et al. Informational [Page 34] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [34ページ]情報のRFC2869半径拡大2000年6月
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.
チェックサムが計算されるとき、署名ストリングはゼロの16の八重奏であると考えられるべきです。 共有秘密キーはHMAC-MD5ハッシュにキーとして使用されます。 Response Authenticatorが計算される前に、パケットに計算されて、挿入されます。
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-パスワード属性が存在しているなら必要ではありませんが、他のタイプの認証に対する攻撃を防ぐことの役に立ちます。 この属性が「凶暴な」NASをセットアップして、RADIUSサーバに対してオンライン辞書攻撃を実行する攻撃者による試みを阻むことを意図します。それは、CHAP挑戦と応答を含んでいて(例えば)、攻撃者がパケットを妨害するところに「オフライン」の攻撃に対して保護しないで、それらのパケットに対して辞書攻撃をオフラインで実行します。
IP Security will eventually make this attribute unnecessary, so it
should be considered an interim measure.
IP Securityが結局この属性を不要にするので、それは一時的な方策であると考えられるべきです。
5.15. ARAP-Challenge-Response
5.15. アラップ-チャレンジレスポンス
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のFramedプロトコルがあるAccess受け入れているパケットで送られて、ダイヤルインのクライアントの挑戦への応答を含んでいます。
A summary of the ARAP-Challenge-Response 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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
84 for ARAP-Challenge-Response.
84 アラップ-チャレンジレスポンスのために。
Length
長さ
10
10
Rigney, et al. Informational [Page 35] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [35ページ]情報のRFC2869半径拡大2000年6月
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.
Value分野はダイヤルインのクライアントの挑戦への8八重奏応答を含んでいます。 RADIUSサーバは、ARAP-パスワードの8つの八重奏が結果と考える高位からダイヤルインのクライアントの挑戦を取って、キーとして認証しているユーザのパスワードでこの値にDES暗号化を実行することによって、この値について計算します。 ユーザのパスワードが長さが8つ未満の八重奏であるなら、キーとしてそれを使用する前に、パスワードは終わりにNULL八重奏で8の長さに水増しされます。
5.16. Acct-Interim-Interval
5.16. Acctの当座の間隔
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.
この属性は秒にこの特定のセッションのためにそれぞれの当座のアップデートの間の秒数を示します。 この値はAccess受け入れているメッセージに現れることができるだけです。
A summary of the Acct-Interim-Interval attribute format is shown below. The fields are transmitted from left to right.
Acctの当座の間隔属性形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| 値の+++++++++++++++++++++++++++++++++| 値(cont)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
85 for Acct-Interim-Interval.
85 Acctの当座の間隔の間。
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.
Value分野はこのセッションのためにNASから送られるそれぞれの当座のアップデートの間の秒数を含んでいます。 値は60より小さいはずがありません。 ネットワークの影響への600、および熟慮であるべきであるより小さい当然のことがトラフィックであったならSHOULD NOTを評価してください。
Rigney, et al. Informational [Page 36] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [36ページ]情報のRFC2869半径拡大2000年6月
5.17. NAS-Port-Id
5.17. NASポートイド
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.
このAttributeはユーザを認証しているNASのポートを特定するテキスト文字列を含んでいます。 それはAccess-要求とAccounting-リクエスト・パケットで使用されるだけです。 これが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ポートイドSHOULDのどちらか、NASがポートの中で差別化するなら、Accessリクエスト・パケットに存在してください。 NASポートイドは使用のために便利に彼らのポートに付番できないNASesによって意図されます。
A summary of the NAS-Port-Id Attribute format is shown below. The fields are transmitted from left to right.
NASポートイドAttribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
87 for NAS-Port-Id.
87 NAS Portアイダホ州に
Length
長さ
>= 3
>= 3
Text
テキスト
The Text field contains the name of the port using UTF-8 encoded
10646 [8] characters.
Text分野は、使用することでポートの名前を含んでいます。UTF-8は[8]10646のキャラクタをコード化しました。
5.18. Framed-Pool
5.18. 縁どられたプール
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.
このAttributeはユーザのためにアドレスを割り当てるのにおいて使用されていた状態でSHOULDがある割り当てられたアドレスプールの名前を含んでいます。 NASが、複数のアドレスがプールであるとサポートしないなら、NASはこのAttributeを無視するはずです。 アドレスプールをIPアドレスに通常使用されますが、NASがそれらのプロトコルのためにプールを支えるなら、他のプロトコルに使用できます。
Rigney, et al. Informational [Page 37] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [37ページ]情報のRFC2869半径拡大2000年6月
A summary of the Framed-Pool Attribute format is shown below. The fields are transmitted from left to right.
Framed-プールAttribute形式の概要は以下に示されます。 野原は左から右まで伝えられます。
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...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
タイプ
88 for Framed-Pool
88 縁どられたプールに
Length
長さ
>= 3
>= 3
String
ストリング
The string field contains the name of an assigned address pool
configured on the NAS.
文字列欄はNASで構成された割り当てられたアドレスプールの名前を含んでいます。
5.19. Table of Attributes
5.19. 属性のテーブル
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にギガワードを入力してください、そして、Acct-出力ギガワード、Event-タイムスタンプ、およびNASポートイドはAccounting-リクエスト・パケットに0-1 インスタンスを持ってもよいです。 インフォメーションを接続する、Accounting-リクエスト・パケットに0+インスタンスを持っているかもしれません。 本書では加えられた他の属性はAccounting-要求に存在しているはずがありません。
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
71アラップ-特徴0 0-1 0 0 72アラップのゾーンアクセス0-1 0 0 0-1 73アラップ-セキュリティ0+0 0 0+74アラップ-セキュリティー・データ0 0 0-1 0 75が0 0 0 0-1インフォメーションを接続している76の迅速な0-1 0 0 0 77 0 0 +をパスワードで再試行するという廃棄物挑戦#属性0-1 0 0 0 70アラップ-パスワードメモ1 0 0-1 0 0-1を受け入れるよう要求してください; 0 0 78構成トークン0+0+0+0+79EAP-メッセージ注意1 0-1 0-1 0-1 0-1 80メッセージ固有識別文字注意1 0 0-1 0 0-1 84アラップ-チャレンジレスポンス0 0-1 0 0 85Acctの当座の間隔0-1 0 0 0 87NASポートイド0 0-1 0 0 88縁どられたプール要求は廃棄物挑戦#属性を受け入れます。
Rigney, et al. Informational [Page 38] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [38ページ]情報のRFC2869半径拡大2000年6月
[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] User-パスワードかCHAP-パスワードかARAP-パスワードか1つ以上のEAP-メッセージ属性のどちらかを含むAccess-要求はそれらの4つの属性の1つ以上のタイプを含んではいけません。 それらの4つの属性のいずれも含んでいなくて、それはSHOULDです。Message-固有識別文字を含んでください。 また、何かパケットタイプが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-1 この属性のゼロか1つのインスタンスが存在しているかもしれません。 1 まさにこの属性の1つのインスタンスが存在していなければなりません。
6. IANA Considerations
6. IANA問題
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].
このドキュメントで定義されたPacket Type Codes、Attribute Types、およびAttribute Valuesは[1]の「IANA問題」セクションで説明されるようにインターネットAssigned民数記Authority(IANA)によって空間というRADIUS名から登録されます、BCP26[10]によると。
7. Security Considerations
7. セキュリティ問題
The attributes other than Message-Authenticator and EAP-Message in this document have no additional security considerations beyond those already identified in [1].
Message-固有識別文字とEAP-メッセージ以外の属性に、[1]で既に特定されたものを超えて追加担保問題が全く本書ではありません。
7.1. Message-Authenticator Security
7.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.
User-パスワードがあるアクセスリクエスト・パケットはAccess-要求を送るユーザとNASの両方のアイデンティティを確立します、NASとRADIUSサーバの間の共有秘密キーが使用されている方法のために。 CHAP-パスワードかEAP-メッセージがあるアクセスリクエスト・パケットにはUser-パスワード属性がないので、Message-固有識別文字属性はUserパスワードを持っていないアクセス要求パケットで使用されるべきです、要求を送るNASのアイデンティティを確立するために。
7.2. EAP Security
7.2. EAPセキュリティ
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
中央でのEAPサーバとPPP固有識別文字ConnectionハイジャックManの分離はMultipleデータベースを攻撃します。
Rigney, et al. Informational [Page 39] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [39ページ]情報のRFC2869半径拡大2000年6月
Negotiation attacks
交渉攻撃
7.2.1. Separation of EAP server and PPP authenticator
7.2.1. 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終点が互いに認証するのにおいてそれは可能です、そして、ciphersuiteを交渉してください、そして、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.
EAPがRADIUSと共に使用されるとき、状況は、より複雑です、PPP固有識別文字がEAPサーバと同じマシンの上に通常ないので。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かトンネルサーバのアイデンティティを有効にする話している同輩には、それが可能でないことを意味します。
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-固有識別文字属性がNASかトンネルサーバからRADIUSサーバに送られたEAP/RADIUS Access-要求で必要です。Message-固有識別文字属性がHMAC-MD5ハッシュにかかわるので、RADIUSサーバがNASかトンネルサーバのアイデンティティと同様にAccess-要求の保全について確かめるのは、可能です。 また、同様に、RADIUSサーバからNASに送られたAccess-挑戦パケットは認証されました、そして、保全はHMAC-MD5ハッシュを使用することで保護されました、NASかトンネルサーバがパケットの保全を決定して、RADIUSサーバのアイデンティティについて確かめるのを可能にして。そのうえ、それら自身の保全保護を含むメソッドで送られた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サーバの間で交渉されたセッションキーが、固有識別文字に伝えられる必要があるということです。 したがって、メカニズムは、キーを使用する必要がある固有識別文字かEAPサーバからトンネルサーバまで主要なセッションを伝えるために提供される必要があります。 このドキュメントの範囲の外にこのトランジットメカニズムの仕様があります。
Rigney, et al. Informational [Page 40] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [40ページ]情報のRFC2869半径拡大2000年6月
7.2.2. Connection hijacking
7.2.2. 接続ハイジャック
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サーバとバックエンドセキュリティサーバとの会話にパケットを注ぐのを試みます。RADIUSは暗号化をサポートしません、そして、[1]で説明されるように、唯一のAccess-回答とAccess-挑戦パケットは保護された保全です。 そのうえ、[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交換における、すべてのパケットの認証に備えるために、Message-固有識別文字属性を使用して、すべてのEAP/RADIUSパケットを認証しなければなりません、以前に説明されるように。
7.2.3. Man in the middle attacks
7.2.3. 中央攻撃でやれやれ
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パケットを変更できるでしょう。
7.2.4. Multiple databases
7.2.4. 複数のデータベース
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に供給するために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実装を提供してください。 両方を統合するのによるバックエンドセキュリティサーバと同じマシンへのRADIUSサーバ。
Rigney, et al. Informational [Page 41] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [41ページ]情報のRFC2869半径拡大2000年6月
7.2.5. Negotiation attacks
7.2.5. 交渉攻撃
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タイプで認証される接続はそれほど安全でないEAPタイプで起こります、MD5などのように。 [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サーバ側の認証している同輩側の1接続あたりの方針の実装、および1ユーザあたりの方針でこれを達成できます。
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.
認証には、じっと見てください、そして、認証方針は1接続あたり1個のベースに設定されるべきです。 1つのサービスと呼ぶとき、認証している同輩は別のサービスのために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.
1接続あたりの方針で、認証している同輩は、EAPサポートが予想されるセッションのためにEAPを交渉するのを試みるだけでしょう。 その結果、EAPを選択する認証している同輩がそのレベルのセキュリティを必要とするという推定があります。 認証している同輩は間違ったサーバに連絡しています。それを提供できないなら、ある種のmisconfigurationがあるはずがありませんか、NASがEAPを交渉さえできるはずがなくなければならなそうですか、NASによって送られたEAP-要求が異なった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と共に認証するのに必要であるかどうか決定するのは可能でないかもしれません。 例えば、共有された用途NASesに関して、1つの再販業者が別のものが実装していない間、EAPを実装するのにおいてそれは可能です。 そのような場合、NAS MUSTのどれかユーザがEAPをするなら、NAS MUSTは、あらゆる呼び出しのためにEAPを交渉するのを試みます。 これは、EAP有能なクライアントに1認証させるのを避けます。(認証はセキュリティを弱めます)。
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
CHAPが交渉されると、NASはUser-名前とCHAPパスワード属性をAccess-リクエスト・パケットのRADIUS Serverに通過するでしょう。 ユーザがEAP、RADIUS Serverが応じるその時を使用する必要はない、パケットをAccess受け入れるか、またはAccess拒絶してください、適宜。 しかしながら、RADIUS CHAPが交渉されましたが、EAPが必要であるなら
Rigney, et al. Informational [Page 42] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [42ページ]情報のRFC2869半径拡大2000年6月
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.
サーバはEAP Access EAP挑戦/メッセージ/リクエスト・パケットよりむしろAccess-廃棄物で反応しなければなりません。 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プロキシかサーバによってサポートされないなら、サーバかプロキシがAccess-廃棄物で応じなければなりません。 これらの場合では、NAS MUSTが発信する、ユーザをLCP終えて、切断してください。 認証している同輩が、EAPが交渉されると予想しているので、これは正しい振舞いです、そして、その期待が実現できません。 EAPが初めは交渉されていたなら、EAP有能な認証している同輩は、認証プロトコルを再交渉するのを拒否しなければなりません。 1つの位置(EAP有能なプロキシがある)から直通電話にかけるのがEAPを通して首尾よく認証できるかもしれないユーザ以来非EAPの有能なRADIUSプロキシに関する問題が診断するのが難しいと判明できたことに注意してください、もう1つの位置(EAP無能なプロキシに遭遇して)にダイヤルする同じユーザ一貫して切断されるかもしれませんが。
8. References
8. 参照
[1] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000.
[1]RigneyとC.とウィレンスとS.とルーベン、A.とW.シンプソン、「ユーザサービス(半径)におけるリモート認証ダイヤル」RFC2865(2000年6月)。
[2] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[2]Rigney、C.、「半径会計」、RFC2866、2000年6月。
[3] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[3]BlunkとL.と1998年のJ.Vollbrecht、「ppp拡張認証プロトコル(EAP)」、RFC2284行進。
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March, 1997.
[4] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[5] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC 1700,
October 1994.
[5] レイノルズとJ.とJ.ポステル、「規定番号」、STD2、RFC1700、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]ゾルン、G.、ライファー、D.、ルーベン、A.、シュライバー、J.、Holdrege、M.、およびI.Goyret、「トンネルへの半径属性はサポートについて議定書の中で述べます」、RFC2868、2000年6月。
[7] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting
Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[7] ゾルンとG.とAbobaとB.とD.ミットン、「トンネルプロトコルサポートのための半径会計変更」、RFC2867、2000年6月。
[8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[8]Yergeau、1998年1月のF.、「UTF-8、ISO10646の変換形式」RFC2279。
Rigney, et al. Informational [Page 43] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [43ページ]情報のRFC2869半径拡大2000年6月
[9] Krawczyk, H., Bellare, M. and R. Canetti, "HMAC: Keyed-Hashing
for Message Authentication", RFC 2104, February 1997.
[9]Krawczyk、H.、Bellare、M.、およびR.カネッティ、「HMAC:」 「通報認証のための合わせられた論じ尽くす」RFC2104、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[11] Slatalla, M., and Quittner, J., "Masters of Deception."
HarperCollins, New York, 1995.
[11] Slatalla、M.とQuittner、J.、「詐欺のマスターズ。」 HarperCollins、ニューヨーク1995。
9. Acknowledgements
9. 承認
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 Accountingは元々、それらのNetwork Access ServersのPortMasterシリーズのためにリビングストンエンタープライズ(現在のルーセントテクノロジーズの一部)によって開発されました。
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 )の区Willatsによる「アップルの遠隔アクセスのコネクションズを認証するのに半径を使用します」ゆえ許可で採用されます。
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の当座の間隔のセクションは許可でサン・マイクロシステムズのパットCalhoun、CompuserveのマークBeadles、およびUUNET Technologiesのアレックス・ラトクリフによる進行中の以前の仕事から採用されます。
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の上のセクションは許可でサン・マイクロシステムズのパットCalhoun、Merit Networkのアラン・ルーベンス、およびマイクロソフトのバーナードAbobaによる進行中の以前の仕事から採用されます。 また、この問題スペースの役に立つ議論をマイクロソフトのAscendのデーヴ・ドーソンとカールフォックス、Glenゾルン、およびNarendra Gidwaniをありがとうございます。
10. Chair's Address
10. 議長のアドレス
The RADIUS working group can be contacted via the current chair:
現在のいすを通してRADIUSワーキンググループに連絡できます:
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Roadプレザントン、カールRigneyリビングストンエンタープライズ4464Willowカリフォルニア 94588
Phone: +1 925 737 2100 EMail: cdr@telemancy.com
以下に電話をしてください。 +1 2100年の925 737メール: cdr@telemancy.com
Rigney, et al. Informational [Page 44] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [44ページ]情報のRFC2869半径拡大2000年6月
11. Authors' Addresses
11. 作者のアドレス
Questions about this memo can also be directed to:
また、このメモに関する質問による以下のことよう指示できます。
Carl Rigney Livingston Enterprises 4464 Willow Road Pleasanton, California 94588
Roadプレザントン、カールRigneyリビングストンエンタープライズ4464Willowカリフォルニア 94588
EMail: cdr@telemancy.com
メール: 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
Aveサンノゼ、区Willats Cyno技術1082谷間Echoカリフォルニア 95125
Phone: +1 408 297 7766 EMail: ward@cyno.com
以下に電話をしてください。 +1 7766年の408 297メール: ward@cyno.com
Rigney, et al. Informational [Page 45] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [45ページ]情報のRFC2869半径拡大2000年6月
Questions on EAP and RADIUS may be directed to any of the following:
EAPとRADIUSの質問は以下のどれかに向けられるかもしれません:
Pat R. Calhoun Network and Security Research Center Sun Microsystems, Inc. 15 Network Circle Menlo Park, CA 94025
メンローパーク、パットR.カルフーンネットワークとセキュリティリサーチセンターサン・マイクロシステムズ・インク15ネットワーク円のカリフォルニア 94025
Phone: +1 650 786 7733 EMail: pcalhoun@eng.sun.com
以下に電話をしてください。 +1 7733年の650 786メール: pcalhoun@eng.sun.com
Allan C. Rubens Tut Systems, Inc. 220 E. Huron, Suite 260 Ann Arbor, MI 48104
Inc.220E.ヒューロン族、アナーバー、アランC.ルーベンツタンカーメンシステムSuite260MI 48104
Phone: +1 734 995 1697 EMail: arubens@tutsys.com
以下に電話をしてください。 +1 1697年の734 995メール: arubens@tutsys.com
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン 98052
Phone: +1 425 936 6605 EMail: bernarda@microsoft.com
以下に電話をしてください。 +1 6605年の425 936メール: bernarda@microsoft.com
Rigney, et al. Informational [Page 46] RFC 2869 RADIUS Extensions June 2000
Rigney、他 [46ページ]情報のRFC2869半径拡大2000年6月
12. Full Copyright Statement
12. 完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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 Editor機能のための基金は現在、インターネット協会によって提供されます。
Rigney, et al. Informational [Page 47]
Rigney、他 情報[47ページ]
一覧
スポンサーリンク
