この文書はRFC2865の日本語訳（和訳）です。 この文書の翻訳内容の正確さは保障できないため、 正確な知識を求める方は原文を参照してください。 翻訳者はこの文書によって読者が被り得る如何なる損害の責任をも負いません。 この翻訳内容に誤りがある場合、訂正版の公開や、 誤りの指摘は適切です。 この文書の配布は元のＲＦＣ同様に無制限です。
Network Working Group C. Rigney
Request for Comments: 2865 S. Willens
Obsoletes: 2138 Livingston
Category: Standards Track A. Rubens
Merit
W. Simpson
Daydreamer
June 2000
Remote Authentication Dial In User Service (RADIUS)
ダイヤルインユーザーサービスの遠隔認証（ラディウス）
Status of this Memo
この文書の状態
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
この文書はインターネット共同体のためのインターネット標準化作業中のプ
ロトコルを指定して、そして改良のために議論と提案を求めます。標準化状
態とこのプロトコル状態は「インターネット公式プロトコル標準」（ＳＴＤ
１）の現在の版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2000). All Rights Reserved.
IESG Note:
IESGノート：
This protocol is widely implemented and used. Experience has shown
that it can suffer degraded performance and lost data when used in
large scale systems, in part because it does not include provisions
for congestion control. Readers of this document may find it
beneficial to track the progress of the IETF's AAA working group,
which may develop a successor protocol that better addresses the
scaling and congestion control issues.
このプロトコルは広く実装され使われます。経験的に、輻輳制御を含んでな
いため、大規模なシステムで使われる時、パフォーマンス低下とデータ損失
がある事が示されています。この文書の読者がＩＥＴＦのＡＡＡワーキング
グループの進歩を追跡することが有益であるかもしれず、より良くスケーラ
ビリティと輻輳制御を扱える後継プロトコルを開発するかもしれません。
Abstract
概要
This document describes a protocol for carrying authentication,
authorization, and configuration information between a Network Access
Server which desires to authenticate its links and a shared
Authentication Server.
この文書は、リンク認証を望むネットワークアクセスサーバーと共有された
認証サーバー間に認証と許可と設定情報を運ぶプロトコルを記述します。
Implementation Note
実装メモ
This memo documents the RADIUS protocol. The early deployment of
RADIUS was done using UDP port number 1645, which conflicts with the
"datametrics" service. The officially assigned port number for
RADIUS is 1812.
この文書はラディウスプロトコルを文書化します。ラディウスの初期の実装
はＵＤＰポート番号１６４５を使っており、これは"datametrics"サービスと
競合します。ラディウスに公式に割り当てられたポート番号は１８１２です。
Table of Contents
目次
1. Introduction
1. はじめに
1.1 Specification of Requirements
1.1 条件仕様
1.2 Terminology
1.2 専門用語
2. Operation
2. 運用
2.1 Challenge/Response
2.1 チャレンジ／レスポンス
2.2 Interoperation with PAP and CHAP
2.2 ＰＡＰとＣＨＡＰの相互運用
2.3 Proxy
2.3 プロクシ
2.4 Why UDP?
2.4 なぜＵＤＰか？
2.5 Retransmission Hints
2.5 再送のヒント
2.6 Keep-Alives Considered Harmful
2.6 有害と思われる生存確認
3. Packet Format
3. パケットフォーマット
4. Packet Types
4. パケットタイプ
4.1 Access-Request
4.1 アクセス要求
4.2 Access-Accept
4.2 アクセス許可
4.3 Access-Reject
4.3 アクセス拒否
4.4 Access-Challenge
4.4 アクセスチャレンジ
5. Attributes
5. 属性
5.1 User-Name
5.1 ユーザ名
5.2 User-Password
5.2 ユーザパスワード
5.3 CHAP-Password
5.3 ＣＨＡＰパスワード
5.4 NAS-IP-Address
5.4 ＮＡＳ−ＩＰアドレス
5.5 NAS-Port
5.5 ＮＡＳポート
5.6 Service-Type
5.6 サービスタイプ
5.7 Framed-Protocol
5.7 フレームプロトコル
5.8 Framed-IP-Address
5.8 フレームＩＰアドレス
5.9 Framed-IP-Netmask
5.9 フレームＩＰネットマスク
5.10 Framed-Routing
5.10 フレームルーチング
5.11 Filter-Id
5.11 フィルターＩＤ
5.12 Framed-MTU
5.12 フレームＭＴＵ
5.13 Framed-Compression
5.13 フレーム圧縮
5.14 Login-IP-Host
5.14 ログインＩＰホスト
5.15 Login-Service
5.15 ログインサービス
5.16 Login-TCP-Port
5.16 ログインＴＣＰポート
5.17 (unassigned)
5.17 （未割当て）
5.18 Reply-Message
5.18 応答メッセージ
5.19 Callback-Number
5.19 コールバック番号
5.20 Callback-Id
5.20 コールバックＩＤ
5.21 (unassigned)
5.21 （未割当て）
5.22 Framed-Route
5.22 フレーム経路
5.23 Framed-IPX-Network
5.23 フレームＩＰＸネットワーク
5.24 State
5.24 状態
5.25 Class
5.25 クラス
5.26 Vendor-Specific
5.26 ベンダー特有
5.27 Session-Timeout
5.27 セッションタイムアウト
5.28 Idle-Timeout
5.28 アイドルタイムアウト
5.29 Termination-Action
5.29 終了行動
5.30 Called-Station-Id
5.30 着信端末識別子
5.31 Calling-Station-Id
5.31 発信端末識別子
5.32 NAS-Identifier
5.32 ＮＡＳ識別子
5.33 Proxy-State
5.33 プロキシ状態
5.34 Login-LAT-Service
5.34 ログインＬＡＴサービス
5.35 Login-LAT-Node
5.35 ログインＬＡＴノード
5.36 Login-LAT-Group
5.36 ログインＬＡＴグループ
5.37 Framed-AppleTalk-Link
5.37 フレームアップルトークリンク
5.38 Framed-AppleTalk-Network
5.38 フレームアップルトークネットワーク
5.39 Framed-AppleTalk-Zone
5.39 フレームアップルトークゾーン
5.40 CHAP-Challenge
5.40 ＣＨＡＰチャレンジ
5.41 NAS-Port-Type
5.41 ＮＡＳポートタイプ
5.42 Port-Limit
5.42 ポート限界
5.43 Login-LAT-Port
5.43 ログインＬＡＴポート
5.44 Table of Attributes
5.44 属性表
6. IANA Considerations
6. ＩＡＮＡの考慮
6.1 Definition of Terms
6.1 用語の定義
6.2 Recommended Registration Policies
6.2 推薦された登録ポリシー
7. Examples
7. 例
7.1 User Telnet to Specified Host
7.1 指定されたホストへのユーザTelnet
7.2 Framed User Authenticating with CHAP
7.2 ＣＨＡＰを使ったフレームユーザ認証
7.3 User with Challenge-Response card
7.3 チャレンジレスポンスカードをつユーザー
8. Security Considerations
8. セキュリティの考察
9. Change Log
9. 変更履歴
10. References
10. 参考文献
11. Acknowledgements
11. 謝辞
12. Chair's Address
12. 議長のアドレス
13. Authors' Addresses
13. 著者のアドレス
14. Full Copyright Statement
14. 著作権表示全文
1. Introduction
1. はじめに
This document obsoletes RFC 2138 [1]. A summary of the changes
between this document and RFC 2138 is available in the "Change Log"
appendix.
この文書はRFC2138[1]を時代遅れにします。RFC2138とこの文書との差の要約
が付録「変更ログ」で利用可能です。
Managing dispersed serial line and modem pools for large numbers of
users can create the need for significant administrative support.
Since modem pools are by definition a link to the outside world, they
require careful attention to security, authorization and accounting.
This can be best achieved by managing a single "database" of users,
which allows for authentication (verifying user name and password) as
well as configuration information detailing the type of service to
deliver to the user (for example, SLIP, PPP, telnet, rlogin).
分散した大量のシリアル回線やモデムプールの管理は多数のユーザーの管理
サポートを要求します。定義によりモデムプールが外の世界へのリンクであ
るので、それらはセキュリティと許可と課金に注意を必要とします。これは、
単一のユーザー「データベース」を管理することによって、最も良く成し遂
げられることができ、データベースは認証を可能にし（ユーザ名とパスワー
ドを検証）、ユーザを接続するサービスの種類（例えば、SLIP、PPP、telnet、
rlogin）を記述する設定情報も認めます。
Key features of RADIUS are:
ラディウスの鍵となる機能は：
Client/Server Model
クライアント／サーバモデル
A Network Access Server (NAS) operates as a client of RADIUS. The
client is responsible for passing user information to designated
RADIUS servers, and then acting on the response which is returned.
ネットワークアクセスサーバー（NAS）がラディウスのクライアントとし
て機能します。クライアントは指定されたラディウス課金サーバーにユー
ザー情報を手渡し、帰ってきた回答を実施する責任があります。
RADIUS servers are responsible for receiving user connection
requests, authenticating the user, and then returning all
configuration information necessary for the client to deliver
service to the user.
ラディウスサーバーはユーザ接続要請を受け取り、ユーザを認証し、ク
ライアントがユーザを接続するために必要な全ての設定情報を返す責任
があります。
A RADIUS server can act as a proxy client to other RADIUS servers
or other kinds of authentication servers.
ラディウスサーバは他の種類のラディウスサーバの代理クライアントの役
を務めることができます。
Network Security
ネットワークセキュリティ
Transactions between the client and RADIUS server are
authenticated through the use of a shared secret, which is never
sent over the network. In addition, any user passwords are sent
encrypted between the client and RADIUS server, to eliminate the
possibility that someone snooping on an unsecure network could
determine a user's password.
クライアントとラディウスサーバーの間の処理が共有秘密鍵の使用を通し
て認証され、鍵はネットワークの上に決して送られません。加えて、どん
なユーザーパスワードも安全でないネットワーク上を詮索している誰かが
ユーザーのパスワードを決定することができる可能性を削除するため、ク
ライアントとラディウスサーバー間で暗号化されて送られます。
Flexible Authentication Mechanisms
柔軟な認証メカニズム
The RADIUS server can support a variety of methods to authenticate
a user. When it is provided with the user name and original
password given by the user, it can support PPP PAP or CHAP, UNIX
login, and other authentication mechanisms.
ラディウスサーバーはユーザーを認証するいろいろな方法をサポートでき
ます。それがユーザ名とユーザーの示したオリジナルパスワードで行われ
る時、ラディウスはＰＰＰ−ＰＡＰやＣＨＡＰやＵＮＩＸログインや他の
認証メカニズムをサポートできます。
Extensible Protocol
拡張可能プロトコル
All transactions are comprised of variable length Attribute-
Length-Value 3-tuples. New attribute values can be added without
disturbing existing implementations of the protocol.
すべての処理は可変長の属性−長さ−値の３項組みで構成されています。
新しい属性値が既存プロトコル実装をプロトコルを不安定にすることなく
加えられることができます。
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 BCP 14 [2]. These key
words mean the same thing whether capitalized or not.
この文書のキーワードは "MUST"と"MUST NOT"と"REQUIRED"と"SHALL"と
"SHALL NOT"と"SHOULD"と"SHOULD NOT"と"RECOMMENDED"と"MAY"と"OPTIONAL"
はBCP 14 [2]で記述されるように、解釈されるはずである。これらのキーワー
ドは、大文字かどうかに関わらず、同じことを意味します。
An implementation is not compliant if it fails to satisfy one or more
of the must or must not requirements for the protocols it implements.
An implementation that satisfies all the must, must not, should and
should not requirements for its protocols is said to be
"unconditionally compliant"; one that satisfies all the must and must
not requirements but not all the should or should not requirements
for its protocols is said to be "conditionally compliant".
もし実装プログラムがプロトコル実装のためのmustかmust notの条件を１つ
でも満足しないなら、この実装はプロトコル準拠でじゃありません。プロト
コルのすべてのmustとmust notとshouldとshould notの条件を満足した実装
は「無条件準拠」といいます；プロトコルのすべてのmustとmust notの条件
を満足するが、shouldとshould notの条件を一部満足していない実装は「条
件的準拠」と言います。
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-accept authorizing an
unavailable service as an access-reject instead.
所定のサービスを実行しないＮＡＳがそのサービスのラディウス属性を実装
してはなりません(MUST NOT)。例えば、ＡＲＡＰサービスが不可能なＮＡＳ
がＡＲＡＰのためにラディウス属性を実装してはなりません(MUST NOT)。Ｎ
ＡＳがaccess-rejectの代わりに利用できないサービスを決定するのにラディ
ウスaccess-acceptを使わなければなりません(MUST)。
1.2. Terminology
1.2. 専門用語
This document frequently uses the following terms:
この文書は以下の用語を使います：
service The NAS provides a service to the dial-in user, such as PPP
or Telnet.
サービス ＮＡＳは、ＰＰＰやｔｅｌｎｅｔなどのサービスをダイアルイン
ユーザに供給します。
session Each service provided by the NAS to a dial-in user
constitutes a session, with the beginning of the session
defined as the point where service is first provided and
the end of the session defined as the point where service
is ended. A user may have multiple sessions in parallel or
series if the NAS supports that.
セッション ＮＡＳがダイヤルインユーザに供給する各サービスはセッション
を形成し、セッションの開始はサービスが最初に供給された時点
で、セッションの終わりはサービスが終了した時点です。もしＮ
ＡＳがサポートするなら、ユーザは同時にあるいは順番に複数の
セッションを持つかもしれません。
silently discard
This means the implementation discards the packet without
further processing. The implementation SHOULD provide the
capability of logging the error, including the contents of
the silently discarded packet, and SHOULD record the event
in a statistics counter.
静かに捨てる
これはプログラムがなにも処理せずにパケットを捨てることを意
味します。実装は、静かに捨てられたパケットの中身を含むエラー
をログファイルに書く機能を供給すべきで(SHOULD)、統計カウン
ターでイベントを記録するべきです(SHOULD)。
2. Operation
2. 運用
When a client is configured to use RADIUS, any user of the client
presents authentication information to the client. This might be
with a customizable login prompt, where the user is expected to enter
their username and password. Alternatively, the user might use a
link framing protocol such as the Point-to-Point Protocol (PPP),
which has authentication packets which carry this information.
クライアントがラディウスを使うように設定される時、クライアントのユー
ザは認証情報をクライアントに示します。これはカスタマイズ可能なログイ
ンプロンプトを持つかもしれず、そこでユーザーはユーザ名とパスワードを
入力することを期待されます。代わりに、ユーザーはポイントポイントプロ
トコル（PPP）のようなプロトコルを使ったリンクを使うかもしれず、ＰＰＰ
はこの情報を運ぶ認証パケットを持っています。
Once the client has obtained such information, it may choose to
authenticate using RADIUS. To do so, the client creates an "Access-
Request" containing such Attributes as the user's name, the user's
password, the ID of the client and the Port ID which the user is
accessing. When a password is present, it is hidden using a method
based on the RSA Message Digest Algorithm MD5 [3].
クライアントがこのような情報を得ると、ラディウスを使う認証を選択する
かもしれません。そうするために、クライアントはユーザー名やユーザパス
ワードやクライアントＩＤやユーザの使用しているポートのＩＤを含む「ア
クセス要求」を作ります。パスワードが存在している時、パスワードはＲＡ
ＳメッセージダイジェストアルゴリズムＭＤ５[3]に基づいく方法を使って
暗号化されます。
The Access-Request is submitted to the RADIUS server via the network.
If no response is returned within a length of time, the request is
re-sent a number of times. The client can also forward requests to
an alternate server or servers in the event that the primary server
is down or unreachable. An alternate server can be used either after
a number of tries to the primary server fail, or in a round-robin
fashion. Retry and fallback algorithms are the topic of current
research and are not specified in detail in this document.
アクセス要求ははネットワークを通してラディウスサーバーに届きます。も
し長時間回答が返らないならば、要求は何回か再送します。クライアントは、
主サーバーがダウンしているか、到達不可能である場合、同じ要求を代替サー
バに転送することができます。代替サーバは主サーバーへの試みが多数失敗
した後、あるいはラウンドロビン方式で使うことができます。再送と次候補
アルゴリズムは現在の研究のトピックであって、この文書で詳細で指定され
ません。
Once the RADIUS server receives the request, it validates the sending
client. A request from a client for which the RADIUS server does not
have a shared secret MUST be silently discarded. If the client is
valid, the RADIUS server consults a database of users to find the
user whose name matches the request. The user entry in the database
contains a list of requirements which must be met to allow access for
the user. This always includes verification of the password, but can
also specify the client(s) or port(s) to which the user is allowed
access.
ラディウスサーバーが要求を受け取ると、まず送信しているクライアントの
妥当検査します。ラディウスサーバーが共有秘密鍵を持たないクライアント
からの要求が静かに捨てられなくてはなりません(MUST)。もしクライアント
が正当であるなら、ラディウスサーバーは名前が要求と一致するユーザーを
見つけるためにユーザーのデータベースを調べます。データベース内のユー
ザーエントリーはユーザーのアクセスを許すために満たされなくてはならな
い必要条件のリストを含んでいます。これは常にパスワードの証明を含みま
す、同時にユーザーがアクセスを許されるクライアントやポートを指定する
ことができます。
The RADIUS server MAY make requests of other servers in order to
satisfy the request, in which case it acts as a client.
ラディウスサーバーは要求を満たすために他のサーバーへ要請をしてもよく
(MAY)、この場合はクライアントの役を務めます。
If any Proxy-State attributes were present in the Access-Request,
they MUST be copied unmodified and in order into the response packet.
Other Attributes can be placed before, after, or even between the
Proxy-State attributes.
もしプロクシ状態属性がアクセスリクエストで存在していたなら、属性を順
番に修正せずにコピーしなくてはなりません(MUST)。他の属性が前か後かプ
ロクシ属性の間に置くことができます。
If any condition is not met, the RADIUS server sends an "Access-
Reject" response indicating that this user request is invalid. If
desired, the server MAY include a text message in the Access-Reject
which MAY be displayed by the client to the user. No other
Attributes (except Proxy-State) are permitted in an Access-Reject.
もし条件が満たされないなら、ラディウスサーバーは「アクセス拒否」回
答でこのユーザー要求が無効であることを示します。もし望むなら、サー
バーはアクセス拒否に、クライアントがユーザーに示すかもしれない(MAY)
テキストメッセージを含めてもよいです(MAY)。他の属性は（プロクシ属
性以外）がアクセス拒否で認められません。
If all conditions are met and the RADIUS server wishes to issue a
challenge to which the user must respond, the RADIUS server sends an
"Access-Challenge" response. It MAY include a text message to be
displayed by the client to the user prompting for a response to the
challenge, and MAY include a State attribute.
もしすべての条件が満たされ、ラディウスサーバーがユーザーが返答しなく
てはならないチャレンジを質問することを望むなら、ラディウスサーバーは
「アクセスチャレンジ」回答を送ります。それはユーザーにチャレンジに対
する反応を促すプロンプトを出すためクライアントに示されるテキストメッ
セージを含むかもしれなくて(MAY)、状態属性を含むかもしれません(MAY)。
If the client receives an Access-Challenge and supports
challenge/response it MAY display the text message, if any, to the
user, and then prompt the user for a response. The client then re-
submits its original Access-Request with a new request ID, with the
User-Password Attribute replaced by the response (encrypted), and
including the State Attribute from the Access-Challenge, if any.
Only 0 or 1 instances of the State Attribute SHOULD be
present in a request. The server can respond to this new Access-
Request with either an Access-Accept, an Access-Reject, or another
Access-Challenge.
もしクライアントがアクセスチャレンジ受取りチャレンジ／レスポンスをサ
ポートするなら、クライアントは可能ならユーザにメッセージを示し(MAY)、
回答の入力をユーザーに促します。それからクライアントは、新しいリクエ
ストＩＤで、ユーザパスワード属性を（暗号化した）回答にして、もしあれ
ばアクセスチャレンジの状態属性を付けて、元のアクセス要求を再送します。
０か１かの状態属性だけが応答に存在するべきです(SHOULD)。サーバーは新
しいアクセス要求にアクセス許可かアクセス拒否かアクセスチャレンジを返
答できます。
If all conditions are met, the list of configuration values for the
user are placed into an "Access-Accept" response. These values
include the type of service (for example: SLIP, PPP, Login User) and
all necessary values to deliver the desired service. For SLIP and
PPP, this may include values such as IP address, subnet mask, MTU,
desired compression, and desired packet filter identifiers. For
character mode users, this may include values such as desired
protocol and host.
もしすべての条件が満たされるなら、ユーザーの設定値リストがアクセス受
理回答におかれます。これらの値はサービスのタイプ（例：SLIP、PPP、ログ
インユーザーに）と望ましいサービスを配達するために必要なすべての値を
含みます。SLIPとPPPで、これはＩＰアドレスやサブネットマスクやＭＴＵや
望ましい圧縮や望ましいパケットフィルター識別子を含みます。キャラクタ
モードユーザーには望ましいプロトコルとホストのような値を含むかもしれ
ません。
2.1. Challenge/Response
2.1. チャレンジ／レスポンス
In challenge/response authentication, the user is given an
unpredictable number and challenged to encrypt it and give back the
result. Authorized users are equipped with special devices such as
smart cards or software that facilitate calculation of the correct
response with ease. Unauthorized users, lacking the appropriate
device or software and lacking knowledge of the secret key necessary
to emulate such a device or software, can only guess at the response.
チャレンジ／レスポンス認証で、ユーザーは予想できない数を与えられ、そ
れを暗号化し、結果を返すように挑まれます。認証されるユーザーは正しい
回答の計算を容易にするスマートカードやソフトウェアのような特別な装置
が設置されています。無許可のユーザーは、適切な装置あるいはソフトウェ
アがなく、このような装置あるいはソフトウェアを模倣するために必要な秘
密鍵の知識に欠けて、ただ回答を推測することができるだけです。
The Access-Challenge packet typically contains a Reply-Message
including a challenge to be displayed to the user, such as a numeric
value unlikely ever to be repeated. Typically this is obtained from
an external server that knows what type of authenticator is in the
possession of the authorized user and can therefore choose a random
or non-repeating pseudorandom number of an appropriate radix and
length.
アクセスチャレンジパケットは、ユーザに示す、典型的に繰り返し利用され
ない数字の様なチャレンジを含む、応答メッセージを含んでいます。典型的
にどの種類の認証を認証されるユーザが持つかと、従って適切な基底と長さ
の乱数か繰り返しでない擬似乱数を知っている外部のサーバーから得られま
す。
The user then enters the challenge into his device (or software) and
it calculates a response, which the user enters into the client which
forwards it to the RADIUS server via a second Access-Request. If the
response matches the expected response the RADIUS server replies with
an Access-Accept, otherwise an Access-Reject.
ユーザーはそれからチャレンジを彼の装置（あるいはソフトウェア）に入力
し、回答を計算し、クライアントに入力し、クライアントは２番目のアクセ
ス要求によってそれをラディウスサーバーに転送します。もし回答が期待さ
れた回答と一致するなら、ラディウスサーバーはアクセス許可を、さもなけ
ればアクセス拒否を返事します。
Example: The NAS sends an Access-Request packet to the RADIUS Server
with NAS-Identifier, NAS-Port, User-Name, User-Password (which may
just be a fixed string like "challenge" or ignored). The server
sends back an Access-Challenge packet with State and a Reply-Message
along the lines of "Challenge 12345678, enter your response at the
prompt" which the NAS displays. The NAS prompts for the response and
sends a NEW Access-Request to the server (with a new ID) with NAS-
Identifier, NAS-Port, User-Name, User-Password (the response just
entered by the user, encrypted), and the same State Attribute that
came with the Access-Challenge. The server then sends back either an
Access-Accept or Access-Reject based on whether the response matches
the required value, or it can even send another Access-Challenge.
例：ＮＡＳはＮＡＳ識別子とＮＡＳポートとユーザ名とユーザパスワード
（これは"challenge"の様なか無視される固定文字列です）と共にラディウス
サーバーへアクセス要求パケットを送ります。サーバーは状態と応答メッセー
ジを含むアクセスチャレンジパケットを返送します、応答メッセージはＮＡ
Ｓが表示する「１２３４５６７８に対するあなたの回答を入力してください」
を含みます。ＮＡＳは反応を促すプロンプトを出し、そしてはＮＡＳ識別子
とＮＡＳポートとユーザ名とユーザーパスワード（ユーザーの入力した回答、
暗号化）とアクセスチャレンジで送られてきた状態属性を含む（新しいＩＤ
の）アクセス要求をサーバーに送ります。サーバーは要求された値と一致す
るかによってアクセス許可かアクセス拒否を返すか、他のアクセスチャレン
ジを返送します。
2.2. Interoperation with PAP and CHAP
2.2. ＰＡＰとＣＨＡＰの相互運用
For PAP, the NAS takes the PAP ID and password and sends them in an
Access-Request packet as the User-Name and User-Password. The NAS MAY
include the Attributes Service-Type = Framed-User and Framed-Protocol
= PPP as a hint to the RADIUS server that PPP service is expected.
ＰＡＰのために、ＮＡＳはＰＡＰＩＤとパスワードを得て、アクセス要求の
ユーザ名とユーザーパスワードとしてそれらを送ります。ＮＡＳは、ＰＰＰ
サービスが期待されるとラディウスサーバーへ伝えるため、サービスタイプ
特質＝フレームユーザーとフレームプロトコル属性＝ＰＰＰをヒントとして
含めるかもしれません(MAY)。
For CHAP, the NAS generates a random challenge (preferably 16 octets)
and sends it to the user, who returns a CHAP response along with a
CHAP ID and CHAP username. The NAS then sends an Access-Request
packet to the RADIUS server with the CHAP username as the User-Name
and with the CHAP ID and CHAP response as the CHAP-Password
(Attribute 3). The random challenge can either be included in the
CHAP-Challenge attribute or, if it is 16 octets long, it can be
placed in the Request Authenticator field of the Access-Request
packet. The NAS MAY include the Attributes Service-Type = Framed-
User and Framed-Protocol = PPP as a hint to the RADIUS server that
PPP service is expected.
ＣＨＡＰのために、ＮＡＳはランダムチャレンジ（なるべく１６オクテット）
を生成し、ＣＨＡＰ識別子とＣＨＡＰユーザ名とともにＣＨＡＰ回答をする
ユーザーに送ります。ＮＡＳはユーザ名を含むＣＨＡＰユーザ名とＣＨＡＰ
識別子とＣＨＡＰ回答を含むＣＨＡＰパスワードと（３属性）を含むアクセ
ス要求パケットをラディウスサーバーに送ります。ランダムチャレンジはＣ
ＨＡＰチャレンジ属性に含ることもでき、もし１６オクテット長ならアクセ
ス要求パケットのリクエスト認証子フィールドに置くことができます。ＮＡ
Ｓは、ＰＰＰサービスが期待されるとラディウスサーバーへ伝えるため、サー
ビスタイプ特質＝フレームユーザーとフレームプロトコル属性＝ＰＰＰをヒ
ントとして含めるかもしれません(MAY)。
The RADIUS server looks up a password based on the User-Name,
encrypts the challenge using MD5 on the CHAP ID octet, that password,
and the CHAP challenge (from the CHAP-Challenge attribute if present,
otherwise from the Request Authenticator), and compares that result
to the CHAP-Password. If they match, the server sends back an
Access-Accept, otherwise it sends back an Access-Reject.
ラディウスサーバーはユーザ名に基づいてパスワードを検索し、ＣＨＡＰ識
別子オクテットとパスワードとＣＨＡＰチャレンジ（もしあればＣＨＡＰチャ
レンジ属性から、なければリクエスト認証子から）上でチャレンジをＭＤ５
ＣＨＡＰパスワードの結果と比較します。もしそれらが一致する、サーバー
はアクセス許可を返送し、さもなければアクセス拒否を返送します。
If the RADIUS server is unable to perform the requested
authentication it MUST return an Access-Reject. For example, CHAP
requires that the user's password be available in cleartext to the
server so that it can encrypt the CHAP challenge and compare that to
the CHAP response. If the password is not available in cleartext to
the RADIUS server then the server MUST send an Access-Reject to the
client.
もしラディウスサーバーが求められた認証を行うことが不可能なら、アクセ
ス拒否を返さなくてはなりません(MUST)。例えば、ＣＨＡＰは、それがＣＨ
ＡＰチャレンジを暗号化しＣＨＡＰ回答と比較できるように、ユーザーのパ
スワードがテキストのままサーバーに利用可能であることを要求します。も
しパスワードがテキストのままでラディウスサーバーに利用可能でないなら、
サーバーはクライアントにアクセス拒否を送らなくてはなりません(MUST)。
2.3. Proxy
2.3. プロクシ
With proxy RADIUS, one RADIUS server receives an authentication (or
accounting) request from a RADIUS client (such as a NAS), forwards
the request to a remote RADIUS server, receives the reply from the
remote server, and sends that reply to the client, possibly with
changes to reflect local administrative policy. A common use for
proxy RADIUS is roaming. Roaming permits two or more administrative
entities to allow each other's users to dial in to either entity's
network for service.
プロクシラディウスは、認証（あるいは課金）要求を（ＮＡＳのような）ラ
ディウスクライアントから受け取り、要求を遠隔ラディウスサーバーに転送
し、遠隔サーバーから答えを受け取り、そして、多分ローカル管理ポリシー
を反映した変更をして、クライアントに返送します。プロクシラディウス
(RADIUS) の普通の用途がさまよっています。ローミングは２つ以上の管理
者にそれぞれのユーザが他方のネットワークにダイアルインを許すサービス
です。
The NAS sends its RADIUS access-request to the "forwarding server"
which forwards it to the "remote server". The remote server sends a
response (Access-Accept, Access-Reject, or Access-Challenge) back to
the forwarding server, which sends it back to the NAS. The User-Name
attribute MAY contain a Network Access Identifier [8] for RADIUS
Proxy operations. The choice of which server receives the forwarded
request SHOULD be based on the authentication "realm". The
authentication realm MAY be the realm part of a Network Access
Identifier (a "named realm"). Alternatively, the choice of which
server receives the forwarded request MAY be based on whatever other
criteria the forwarding server is configured to use, such as Called-
Station-Id (a "numbered realm").
ＮＡＳはラディウスアクセス要求を、「遠隔のサーバ」に転送する「転送サー
バ」に、送ります。遠隔のサーバは転送サーバに回答（アクセス許可や、ア
クセス拒否や、アクセスチャレンジ）を送り、転送サーバは回答をＮＡＳに
送り返します。ユーザ名属性はラディウスプロクシ操作のためにネットワー
クアクセス識別子[8]を含んでいるかもしれません(MAY)。いずれのサーバが
転送された要求を受け取るかについての選択は認証「領域」に基づくべきで
す(SHOULD)。認証領域はネットワークアクセス識別子の領域部分（「領域名」）
かもしれません(MAY)。代わりに、どのサーバーが転送リクエストを受け取る
かの選択は、呼出し局識別子（「領域番号」）のような、転送サーバに設定
された他の基準にでも基づくかもしれません(MAY)。
A RADIUS server can function as both a forwarding server and a remote
server, serving as a forwarding server for some realms and a remote
server for other realms. One forwarding server can act as a
forwarder for any number of remote servers. A remote server can have
any number of servers forwarding to it and can provide authentication
for any number of realms. One forwarding server can forward to
another forwarding server to create a chain of proxies, although care
must be taken to avoid introducing loops.
ラディウスサーバーが転送サーバと遠隔サーバのどちらとしても動作可能で、
ある領域で転送サーバとして他の領域で遠隔のサーバーとして仕える事がで
きます。１つの転送サーバが多数の遠隔のサーバの転送者の役を務めること
ができます。遠隔のサーバが多数の転送サーバからの転送を受付可能で、多
数の領域の認証を提供できます。１つの転送サーバーが、ループが生じない
ように注意が必要ですが、他の転送サーバに転送してプロキシチェーンを作
ることが出来ます。
The following scenario illustrates a proxy RADIUS communication
between a NAS and the forwarding and remote RADIUS servers:
次のシナリオはＮＡＳと転送と遠隔のラディウスサーバー間のプロクシラ
ディウス通信を説明します：
1. A NAS sends its access-request to the forwarding server.
1. ＮＡＳが転送サーバーにアクセス要求を送ります。
2. The forwarding server forwards the access-request to the remote
server.
2. 転送サーバーはアクセス要求を遠隔のサーバーに転送します。
3. The remote server sends an access-accept, access-reject or
access-challenge back to the forwarding server. For this example,
an access-accept is sent.
3. 遠隔のサーバーはアクセス許可かアクセス拒否かアクセスチェンジを転送
サーバーに返します。この例でアクセス許可が送られます。
4. The forwarding server sends the access-accept to the NAS.
4. 転送サーバーはＮＡＳにアクセス許可を送ります。
The forwarding server MUST treat any Proxy-State attributes already
in the packet as opaque data. Its operation MUST NOT depend on the
content of Proxy-State attributes added by previous servers.
転送サーバーはパケット内の状態属性を不透明なデータと扱わなくてはなり
ません(MUST)。そのオペレーションは前のサーバーの加えたプロクシ状態属
性の内容に依存してはなりません(MUST NOT)。
If there are any Proxy-State attributes in the request received from
the client, the forwarding server MUST include those Proxy-State
attributes in its reply to the client. The forwarding server MAY
include the Proxy-State attributes in the access-request when it
forwards the request, or MAY omit them in the forwarded request. If
the forwarding server omits the Proxy-State attributes in the
forwarded access-request, it MUST attach them to the response before
sending it to the client.
もしクライアントから受け取った要求にプロクシ状態属性があるなら、転送
サーバーはクライアントへの回答にそれらのプロクシ状態属性を含めなくて
はなりません(MUST)。転送サーバーは、要求を転送する時のアクセス要求に
プロキシ状態属性を含めるか(MAY)、転送する要求で取り除いてもよいです
(MAY)。もし転送サーバーが転送するアクセス要求でプロクシ状態属性を除く
なら、クライアントに回答を送る前にプロクシ状態属性を回答に付け加えま
す(MUST)。
We now examine each step in more detail.
各ステップの詳細を調べます。
1. A NAS sends its access-request to the forwarding server. The
forwarding server decrypts the User-Password, if present, using
the shared secret it knows for the NAS. If a CHAP-Password
attribute is present in the packet and no CHAP-Challenge attribute
is present, the forwarding server MUST leave the Request-
Authenticator untouched or copy it to a CHAP-Challenge attribute.
1. ＮＡＳが転送サーバーにアクセス要求を送ります。転送サーバーは、もし
あるなら、ＮＡＳの知っている共有秘密鍵を使ってユーザーパスワードを
解読します。もしＣＨＡＰパスワード属性がパケットにあり、ＣＨＡＰチャ
レンジ属性がないなら、転送サーバーは要求認証子触らないか、ＣＨＡＰ
チャレンジ属性にコピーしなくてはなりません(MUST)。
'' The forwarding server MAY add one Proxy-State attribute to the
packet. (It MUST NOT add more than one.) If it adds a Proxy-
State, the Proxy-State MUST appear after any other Proxy-States in
the packet. The forwarding server MUST NOT modify any other
Proxy-States that were in the packet (it may choose not to forward
them, but it MUST NOT change their contents). The forwarding
server MUST NOT change the order of any attributes of the same
type, including Proxy-State.
'' 転送サーバーはパケットに１つのプロキシ状態を加えてもよいです(MAY)。
（２つ以上加えてはなりません(MUST NOT)。）もしプロキシ状態を加える
なら、プロクシ状態はパケットの他のプロクシ状態の後に加えます(MUST)。
転送サーバーはパケット内のプロクシ状態を修正してはなりません(MUST
NOT)（プロクシ状態を転送しなくてもかまいませんが、内容を変えてはな
りません(MUST NOT)）。転送サーバーはプロクシ状態を含め同じ種類の属
性の順序を変えてはなりません(MUST NOT)。
2. The forwarding server encrypts the User-Password, if present,
using the secret it shares with the remote server, sets the
Identifier as needed, and forwards the access-request to the
remote server.
2. 転送サーバーは、もしあれば、遠隔のサーバーとの共有秘密鍵を使ってユー
ザーパスワードを暗号化し、必要なように識別子を設定して、アクセス要
求を遠隔サーバーに転送します。
3. The remote server (if the final destination) verifies the user
using User-Password, CHAP-Password, or such method as future
extensions may dictate, and returns an access-accept, access-
reject or access-challenge back to the forwarding server. For
this example, an access-accept is sent. The remote server MUST
copy all Proxy-State attributes (and only the Proxy-State
attributes) in order from the access-request to the response
packet, without modifying them.
3. 遠隔のサーバーは（もし最終宛先なら）ユーザーパスワードかＣＨＡＰパ
スワードか将来の拡張が要求するそのような手段を使っているユーザーを
確かめ、アクセス許可かアクセス拒否かアクセスチャレンジを転送サーバー
に返します。この例で、アクセス許可が送られます。遠隔のサーバーはア
クセス要求から回答パケットに、順番を変えずに、修正せずに、プロクシ
状態属性を（そしてプロクシ状態属性だけを）コピーしなくてはなりませ
ん(MUST)。
4. The forwarding server verifies the Response Authenticator using
the secret it shares with the remote server, and silently discards
the packet if it fails verification. If the packet passes
verification, the forwarding server removes the last Proxy-State
(if it attached one), signs the Response Authenticator using the
secret it shares with the NAS, restores the Identifier to match
the one in the original request by the NAS, and sends the access-
accept to the NAS.
4. 転送サーバーは遠隔サーバーとの共有秘密鍵を使って回答認証子を検証し、
もし検証に失敗するなら、静かにパケットを捨てます。もしパケットが検
証できれば、転送サーバーは、（もしプロクシ状態を加えていれば）最後
のプロクシ状態を削除し、ＮＡＳとの共有秘密鍵を使って回答認証子に署
名し、ＮＡＳからの元の要求に合う識別子を復活させ、アクセス許可をＮ
ＡＳに送ります。
A forwarding server MAY need to modify attributes to enforce local
policy. Such policy is outside the scope of this document, with the
following restrictions. A forwarding server MUST not modify existing
Proxy-State, State, or Class attributes present in the packet.
転送サーバーがローカルポリシーを実施するために属性を修正する必要があ
るかもしれません(MAY)。このようなポリシーはこの文書の範囲外で、次の制
限を持ちます。転送サーバーは、パケットに存在するプロクシ状態や状態や
クラス属性を修正してはなりません(MUST not)。
Implementers of forwarding servers should consider carefully which
values it is willing to accept for Service-Type. Careful
consideration must be given to the effects of passing along Service-
Types of NAS-Prompt or Administrative in a proxied Access-Accept, and
implementers may wish to provide mechanisms to block those or other
service types, or other attributes. Such mechanisms are outside the
scope of this document.
転送サーバーの実装は慎重にサービスタイプのどの値が受け入れ可能か考え
るべきです。ＮＡＳプロンプトのサービスタイプかプロキシアクセス許可の
管理を通過させる影響は慎重に考慮しなければなりません、そして実装者は
それらや他のサービスタイプや他の属性を妨げるためにメカニズムを供給す
ることを望むかもしれません。このようなメカニズムはこの文書の範囲の外
です。
2.4. Why UDP?
2.4. なぜＵＤＰか？
A frequently asked question is why RADIUS uses UDP instead of TCP as
a transport protocol. UDP was chosen for strictly technical reasons.
しばしばされた質問はなぜラディウスがＴＣＰの代わりにＵＤＰを転送プロ
トコルとして用いるかです。ＵＤＰは厳密に技術的な理由で選ばれました。
There are a number of issues which must be understood. RADIUS is a
transaction based protocol which has several interesting
characteristics:
理解しなくてはならない多くの問題があります。ラディウスはいくつかの面
白い特徴を持つ取引を基礎としたプロトコルです：
1. If the request to a primary Authentication server fails, a
secondary server must be queried.
1. もし主要認証サーバーへの要求が失敗するなら、第２サーバへ問合せなく
てはなりません。
To meet this requirement, a copy of the request must be kept above
the transport layer to allow for alternate transmission. This
means that retransmission timers are still required.
この条件を満たすために、要求のコピーが代わりの送達を考慮するために
転送層の上で保持されなくてはなりません。これは再送タイマーが必要な
ことを意味します。
2. The timing requirements of this particular protocol are
significantly different than TCP provides.
2. このプロトコルが要求するタイミングはＴＣＰが供給するタイミングと異
なります。
At one extreme, RADIUS does not require a "responsive" detection
of lost data. The user is willing to wait several seconds for the
authentication to complete. The generally aggressive TCP
retransmission (based on average round trip time) is not required,
nor is the acknowledgement overhead of TCP.
極端な話、ラディウスは失われたデータの「敏感な」検出を必要としませ
ん。ユーザーは数秒間の認証が完了するのを待つことをいといません。一
般に（平均の往復時間に基づく）攻撃的なＴＣＰ再送やＴＣＰ確認のオー
バーヘッドは必要ありません。
At the other extreme, the user is not willing to wait several
minutes for authentication. Therefore the reliable delivery of
TCP data two minutes later is not useful. The faster use of an
alternate server allows the user to gain access before giving up.
他の極端な場合、ユーザーは数分認証を待つことをいやがります。それ
故にＴＣＰデータの信頼性が高い２分後の配達は有用ではありません。
代わりのサーバーのより速い使用はユーザーがあきらめる前にアクセス
を得ることを許します。
3. The stateless nature of this protocol simplifies the use of UDP.
3. このプロトコルのステートレスな性質はＵＤＰの使用を単純化します。
Clients and servers come and go. Systems are rebooted, or are
power cycled independently. Generally this does not cause a
problem and with creative timeouts and detection of lost TCP
connections, code can be written to handle anomalous events. UDP
however completely eliminates any of this special handling. Each
client and server can open their UDP transport just once and leave
it open through all types of failure events on the network.
クライアントとサーバーが来て行きます。システムのリブートや起動は独
立です。一般にこれは問題を起こさず、タイムアウトの生成と失われたＴ
ＣＰ接続の検出で、コードが異常なイベントを処理するよう書くことがで
きます。ＵＤＰはしかしながら完全にこの特別扱いのどれも排除します。
各クライアントとサーバーが１度だけＵＤＰ転送を開き、ネットワーク上
にあらゆるタイプの失敗イベントの間それを開いているままにしておくこ
とができます。
4. UDP simplifies the server implementation.
4. ＵＤＰはサーバー実装を単純化します
In the earliest implementations of RADIUS, the server was single
threaded. This means that a single request was received,
processed, and returned. This was found to be unmanageable in
environments where the back-end security mechanism took real time
(1 or more seconds). The server request queue would fill and in
environments where hundreds of people were being authenticated
every minute, the request turn-around time increased to longer
than users were willing to wait (this was especially severe when a
specific lookup in a database or over DNS took 30 or more
seconds). The obvious solution was to make the server multi-
threaded. Achieving this was simple with UDP. Separate processes
were spawned to serve each request and these processes could
respond directly to the client NAS with a simple UDP packet to the
original transport of the client.
ラディウスの最も初期の実装で、サーバーはシングルスレッドでした。こ
れはひとつの要求が受け取られて、処理されて、そして返されたことを意
味します。これは背景セキュリティ機構がリアルタイム（１秒以上）を要
求する環境で問題があることがわかりました。毎分何百という人々が認証
されていた環境でサーバー要求待ち行列はいっぱいになり、応答時間がユー
ザーが待てないほど長く増加しました（これは、データベースかＤＮＳの
特定の検索が３０秒以上かかった時に、特にひどくなりました）。明白な
解決はサーバーをマルチスレッドにすることです。これを成し遂げるのに
ＵＤＰは単純でした。別のプロセスがそれぞれの要求を送るために生まれ、
これらのプロセスはに単純なＵＤＰパケットで直接クライアントＮＡＳに
返答することができました。
It's not all a panacea. As noted, using UDP requires one thing which
is built into TCP: with UDP we must artificially manage
retransmission timers to the same server, although they don't require
the same attention to timing provided by TCP. This one penalty is a
small price to pay for the advantages of UDP in this protocol.
これは万能薬ではありません。気付かれるように、ＵＤＰを使うとＴＣＰで
は組み込まれているものを必要とします：ＵＤＰでは同じサーバへの再送タ
イマーを人工的に管理しなければなりません、タイミングへの同じ注意がＴ
ＣＰでは要求されません。この１つのペナルティはこのプロトコルでＵＤＰ
を使う利点に比べて小さいです。
Without TCP we would still probably be using tin cans connected by
string. But for this particular protocol, UDP is a better choice.
ＴＣＰがなければ我々はまだ恐らく文字列で結ばれるブリキ缶を使っている
でしょう。この特定のプロトコルがなければ、ＵＤＰはもっとも良い選択で
す。
2.5. Retransmission Hints
2.5. 再送のヒント
If the RADIUS server and alternate RADIUS server share the same
shared secret, it is OK to retransmit the packet to the alternate
RADIUS server with the same ID and Request Authenticator, because the
content of the attributes haven't changed. If you want to use a new
Request Authenticator when sending to the alternate server, you may.
もしラディウスサーバーと代わりのラディウスサーバーが同じ共有秘密鍵を
共有するなら、属性の内容が変らないので、同じ識別子と認証子で代わりの
ラディウスサーバーにパケットを再び送って問題がありません。もし代わり
のサーバーに送る時、新しい要求認証子を使うことを望むなら、そうしても
よいです。
If you change the contents of the User-Password attribute (or any
other attribute), you need a new Request Authenticator and therefore
a new ID.
もしユーザーパスワード属性（あるいは他の属性）の中身を変えるなら、新
しい要求認証子とそれ故に新しい識別子を必要とします。
If the NAS is retransmitting a RADIUS request to the same server as
before, and the attributes haven't changed, you MUST use the same
Request Authenticator, ID, and source port. If any attributes have
changed, you MUST use a new Request Authenticator and ID.
もしＮＡＳが前と同じサーバーにラディウス要求を再び送り、属性が変わら
なかったなら、同じ要求認証子と識別子とソースポートを使わなくてはなり
ません(MUST)。もし属性が変わったなら、新しい要求認証子と識別子を使わ
なくてはなりません(MUST)。
A NAS MAY use the same ID across all servers, or MAY keep track of
IDs separately for each server, it is up to the implementer. If a
NAS needs more than 256 IDs for outstanding requests, it MAY use
additional source ports to send requests from, and keep track of IDs
for each source port. This allows up to 16 million or so outstanding
requests at one time to a single server.
ＮＡＳがすべてのサーバで同じＩＤを使っても(MAY)、あるいは各サーバ毎
に別に識別子を記録・追跡してもよく(MAY)、それは実装者依存です。もし
ＮＡＳが外向き要求で２５６個以上の識別子を必要とするなら、要求を送る
追加のソースポートを使い、それぞれのソースポートで識別子を記録・追跡
するかもしれません(MAY)。これは同時に同じサーバに向けて最大１千６百
万ぐらいの外向き要求を許します。
2.6. Keep-Alives Considered Harmful
2.6. 有害と思われる生存確認
Some implementers have adopted the practice of sending test RADIUS
requests to see if a server is alive. This practice is strongly
discouraged, since it adds to load and harms scalability without
providing any additional useful information. Since a RADIUS request
is contained in a single datagram, in the time it would take you to
send a ping you could just send the RADIUS request, and getting a
reply tells you that the RADIUS server is up. If you do not have a
RADIUS request to send, it does not matter if the server is up or
not, because you are not using it.
ある実装者がサーバーが生きているかどうか見るテストラディウス要求を送
る実装を採用しました。この実装は、有用な情報の供給なしに、負荷とスケー
ラビリティを傷つけるので、強く不賛成です。ラディウス要求が１つのデー
タグラムにあるので、ピングを送る間にラディウス要求を送る事ができ、ラ
ディウスサーバが生きていれば答えを得ることができます。もし送信するラ
ディウス要求を持ってないなら、サーバを使っていないので、サーバーが生
きているかは重要ではありません。
If you want to monitor your RADIUS server, use SNMP. That's what
SNMP is for.
もしラディウスサーバーをモニターしたいならＳＮＭＰを使ってください。
ＳＮＭＰはそのためのものです。
3. Packet Format
3. パケットフォーマット
Exactly one RADIUS packet is encapsulated in the UDP Data field [4],
where the UDP Destination Port field indicates 1812 (decimal).
正確に１つのラディウスパケットがＵＤＰデータフィールド[4]にカプセル
化され、ＵＤＰ宛先ポートフィールドは１８１２（１０進数）を示します。
When a reply is generated, the source and destination ports are
reversed.
回答が生成されると、ソースポートと宛先ポートは逆にされます。
This memo documents the RADIUS protocol. The early deployment of
RADIUS was done using UDP port number 1645, which conflicts with the
"datametrics" service. The officially assigned port number for
RADIUS is 1812.
この文書はラディウスプロトコルを文書化します。ラディウスの初期の展開
はＵＤＰポートナンバー１６４５を使ってされましたが、これは
"datametrics"サービスと対立します。ラディウスに公式に割り当てられた
ポート番号は１８１２です。
A summary of the RADIUS data format is shown below. The fields are
transmitted from left to right.
ラディウスデータフォーマットの要約を下に記述します。フィールドは左か
ら右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
| コード | 識別子 | 長さ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authenticator |
| 認証子 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
| 属性 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
The Code field is one octet, and identifies the type of RADIUS
packet. When a packet is received with an invalid Code field, it
is silently discarded.
コードフィールドは１つのオクテットで、ラディウスパケットのタイプを
識別します。パケットが無効なコードフィールドで受信される時、これは
静かに捨てられます。
RADIUS Codes (decimal) are assigned as follows:
ラディウスコード（１０進数）が次のように割り当てられます：
1 Access-Request
アクセス要求
2 Access-Accept
アクセス許可
3 Access-Reject
アクセス拒否
4 Accounting-Request
課金要求
5 Accounting-Response
課金応答
11 Access-Challenge
アクセスチャレンジ
12 Status-Server (experimental)
サーバ状態（実験的）
13 Status-Client (experimental)
クライアント状態（実験的）
255 Reserved
予約
Codes 4 and 5 are covered in the RADIUS Accounting document [5].
Codes 12 and 13 are reserved for possible use, but are not further
mentioned here.
コード４と５がラディウス課金文書[5]にあります。コード１２と１３が使用
の可能性があるために確保されますが、ここでは言及しません。
Identifier
識別子
The Identifier field is one octet, and aids in matching requests
and replies. The RADIUS server can detect a duplicate request if
it has the same client source IP address and source UDP port and
Identifier within a short span of time.
識別子フィールドは１オクテットで、要求と応答の対応を手助けします。
ラディウスサーバーは、同じクライアントソースＩＰアドレスとソース
ＵＤＰポートから短い時間内に識別子得られれば、重複の要求を検出で
きます。
Length
長さ
The Length field is two octets. It indicates the length of the
packet including the Code, Identifier, Length, Authenticator and
Attribute fields. Octets outside the range of the Length field
MUST be treated as padding and ignored on reception. If the
packet is shorter than the Length field indicates, it MUST be
silently discarded. The minimum length is 20 and maximum length
is 4096.
長さフィールドは２オクテットです。これはコードと識別子と長さと認証
子と属性フィールドを含むパケットの長さを示します。長さフィールドの
指定するオクテット以降のデータがパディングを扱われ、受信時に無視さ
れなくてはなりません(MUST)。もしパケットが長さフィールドが示す長さ
より短いなら、パケットは静かに捨てられなくてはなりません(MUST)。最
小長は２０で、最大長は４０９６です。
Authenticator
認証子
The Authenticator field is sixteen (16) octets. The most
significant octet is transmitted first. This value is used to
authenticate the reply from the RADIUS server, and is used in the
password hiding algorithm.
認証子フィールドは１６オクテットです。最も重要なオクテットは最初に
送信されます。この値はラディウス課金サーバの応答の認証とパスワード
隠ぺいアルゴリズムに使われます。
Request Authenticator
要求認証子
In Access-Request Packets, the Authenticator value is a 16
octet random number, called the Request Authenticator. The
value SHOULD be unpredictable and unique over the lifetime of a
secret (the password shared between the client and the RADIUS
server), since repetition of a request value in conjunction
with the same secret would permit an attacker to reply with a
previously intercepted response. Since it is expected that the
same secret MAY be used to authenticate with servers in
disparate geographic regions, the Request Authenticator field
SHOULD exhibit global and temporal uniqueness.
アクセス要求パケットで、認証子値は要求認証子と呼ばれる１６オク
テット乱数です。値は予想できなくて、秘密（クライアントとラディ
ウスサーバーが共有するパスワード）の寿命の間はユニークであるべ
きです(SHOULD)、同じ秘密と関連するリクエスト値の反復は攻撃者に
前に途中で捕えられた反応を返す事を認めるでしょう。同じ秘密が異
なる地理的範囲でサーバを認証するために使われるかもしれないので
(MAY)、要求認証子フィールドはグローバルと一時的なユニークさを
示すべきです(SHOULD)。
The Request Authenticator value in an Access-Request packet
SHOULD also be unpredictable, lest an attacker trick a server
into responding to a predicted future request, and then use the
response to masquerade as that server to a future Access-
Request.
アクセス要求パケットの中の要求認証子値は、攻撃者がサーバーをだ
まして予想した要求認証子の返答を得て、次に未来のアクセス要求に
対しそのサーバーとしてふりをして回答する事がないように、予想で
きない値にすべきです(SHOULD)。
Although protocols such as RADIUS are incapable of protecting
against theft of an authenticated session via realtime active
wiretapping attacks, generation of unique unpredictable
requests can protect against a wide range of active attacks
against authentication.
ラディウスのようなプロトコルがリアルタイムのアクティブな盗聴に
よる認証されたセッションの盗みを保護する能力がないが、ユニーク
で予想できない要求の生成が認証に対する広範囲なアクティブな攻撃
から保護することができます。
The NAS and RADIUS server share a secret. That shared secret
followed by the Request Authenticator is put through a one-way
MD5 hash to create a 16 octet digest value which is xored with
the password entered by the user, and the xored result placed
in the User-Password attribute in the Access-Request packet.
See the entry for User-Password in the section on Attributes
for a more detailed description.
ＮＡＳとラディウスサーバーは秘密鍵を共有します。要求認証子に続
く共有秘密鍵が１６オクテットダイジェスト値を作るために一方向Ｍ
Ｄ５ハッシュに入力され、これとユーザの入力したパスワードのＸＯ
Ｒが計算され、計算結果がアクセス要求のユーザーパスワード属性に
設定されます。いっそう詳細な記述は属性の章のユーザーパスワード
の項目を見てください。
Response Authenticator
回答認証子
The value of the Authenticator field in Access-Accept, Access-
Reject, and Access-Challenge packets is called the Response
Authenticator, and contains a one-way MD5 hash calculated over
a stream of octets consisting of: the RADIUS packet, beginning
with the Code field, including the Identifier, the Length, the
Request Authenticator field from the Access-Request packet, and
the response Attributes, followed by the shared secret. That
is, ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret) where +
denotes concatenation.
アクセス許可とアクセス拒否とアクセスチャレンジパケットの中の認
証子フィールド値が回答認証子と呼ばれ、以下のオクテット列から計
算した一方向ＭＤ５ハッシュを含んでいます：コードフィールドフィー
ルドから始まり、識別子と、長さと、アクセス要求パケットの要求認
証子と、回答属性を含むラディウスパケット、とそれに続く共有秘密
鍵。すなわち、+を結合とすると、ResponseAuth =
MD5(Code+ID+Length+RequestAuth+Attributes+Secret)です。
Administrative Note
管理上のメモ
The secret (password shared between the client and the RADIUS
server) SHOULD be at least as large and unguessable as a well-
chosen password. It is preferred that the secret be at least 16
octets. This is to ensure a sufficiently large range for the
secret to provide protection against exhaustive search attacks.
The secret MUST NOT be empty (length 0) since this would allow
packets to be trivially forged.
秘密鍵（クライアントとラディウスサーバーが共有するパスワード）は少
なくともよく選択されたパスワードと同じぐらい大きくていそして予想不
可能であるべきです(SHOULD NOT)。秘密鍵が少なくとも１６オクテットで
あることが望ましいです。これは秘密鍵が徹底的な捜索攻撃に対して保護
を供給するのに十分に大きい範囲を保証するはずです。秘密鍵は、パケッ
トが平凡に作り出されることがないように、空（長さ０）であってはなり
ません。
A RADIUS server MUST use the source IP address of the RADIUS UDP
packet to decide which shared secret to use, so that RADIUS
requests can be proxied.
ラディウスサーバーがどの共有秘密鍵を使うべきか決めるためにラディウ
スＵＤＰパケットのソースＩＰアドレスを使わなくてはなりません(MUST)、
これでラディウス要求がプロキシできます。
When using a forwarding proxy, the proxy must be able to alter the
packet as it passes through in each direction - when the proxy
forwards the request, the proxy MAY add a Proxy-State Attribute,
and when the proxy forwards a response, it MUST remove its Proxy-
State Attribute if it added one. Proxy-State is always added or
removed after any other Proxy-States, but no other assumptions
regarding its location within the list of attributes can be made.
Since Access-Accept and Access-Reject replies are authenticated on
the entire packet contents, the stripping of the Proxy-State
attribute invalidates the signature in the packet - so the proxy
has to re-sign it.
転送プロキシを使う時、プロキシは、それがそれぞれの方向に通過できる
ようにパケットを変えることができなければなりません−プロキシが要求
を転送する時、プロクシはプロクシ状態属性を加えるかもしれません(MAY)、
そしてプロキシが回答を転送する時、加えたプロクシ状態属性を取り除か
なくてはなりません(MUST)。プロクシ状態は常に他のプロクシ状態の後に
追加し、後のを削除しますが、リスト内の他の属性との場所の関係も仮定
されません。アクセス許可とアクセス拒否応答が全部のパケット内容が認
証されるので、プロクシ状態属性の取り除きはパケットの署名を無効にし
ます−そのためプロキシは最署名しなければなりません。
Further details of RADIUS proxy implementation are outside the
scope of this document.
ラディウスプロクシ実装のこれ以上の細部がこの文書の範囲の外です。
4. Packet Types
4. パケットタイプ
The RADIUS Packet type is determined by the Code field in the first
octet of the Packet.
ラディウスパケットタイプはパケットの最初のオクテットのコードフィール
ドによって決定されます。
4.1. Access-Request
4.1. アクセス要求
Description
解説
Access-Request packets are sent to a RADIUS server, and convey
information used to determine whether a user is allowed access to
a specific NAS, and any special services requested for that user.
An implementation wishing to authenticate a user MUST transmit a
RADIUS packet with the Code field set to 1 (Access-Request).
アクセス要求パケットがラディウスサーバーに送られ、ユーザがそのＮＡ
Ｓにアクセスが許されるか、何かそのユーザに要求する特別なサービスが
あるかを決定するために使われる情報を運びます。ユーザー認証を望んで
いる実装がコードフィールドを１に設定（アクセス要求）したラディウス
パケットを転送しなくてはなりません(MUST)。
Upon receipt of an Access-Request from a valid client, an
appropriate reply MUST be transmitted.
正当なクライアントからアクセス要求か来たら、適切な答えが送信されな
くてはなりません(MUST)。
An Access-Request SHOULD contain a User-Name attribute. It MUST
contain either a NAS-IP-Address attribute or a NAS-Identifier
attribute (or both).
アクセス要求がユーザ名属性を含んでいるべきです(SHOULD)。アクセス要
求はＮＡＳ−ＩＰアドレス属性かＮＡＳ識別子属性（あるいは両方とも）
を含まなければなりません(MUST)。
An Access-Request MUST contain either a User-Password or a CHAP-
Password or a State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow
other kinds of authentication information to be conveyed, the
attribute for that can be used in an Access-Request instead of
User-Password or CHAP-Password.
アクセス要求がユーザーパスワードやＣＨＡＰパスワードや状態を含まな
ければなりません(MUST)。アクセス要求はユーザーパスワードとＣＨＡＰ
パスワードの両方を含まなければなりません(MUST NOT)。もし未来の拡張
が認証情報の他の種類を運ぶことを許すなら、その属性がユーザーパスワー
ドやＣＨＡＰパスワード属性の代わりとしてアクセス要求で使うことがで
きます。
An Access-Request SHOULD contain a NAS-Port or NAS-Port-Type
attribute or both unless the type of access being requested does
not involve a port or the NAS does not distinguish among its
ports.
求められているアクセスのタイプがポートに関係ないかＮＡＳがポートを
区別しない場合を除き、アクセス要求にはＮＡＳポート属性かＮＡＳポー
トタイプ属性かあるいは両方を含むべきです(SHOULD)。
An Access-Request MAY contain additional attributes as a hint to
the server, but the server is not required to honor the hint.
アクセス要求はサーバーへのヒントとして追加の属性を含むかもしれませ
んが(MAY)、サーバーはヒントを重要視するように要求されません。
When a User-Password is present, it is hidden using a method based
on the RSA Message Digest Algorithm MD5 [3].
ユーザーパスワードが存在している時、これはＲＳＡメッセージダイジェ
ストアルゴリズムＭＤ５[3]に基づく方法を使って隠されます。
A summary of the Access-Request packet format is shown below. The
fields are transmitted from left to right.
アクセス要求パケットフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
| コード | 識別子 | 長さ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Request Authenticator |
| 要求認証子 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
| 属性 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
1 for Access-Request.
1 アクセス要求
Identifier
識別子
The Identifier field MUST be changed whenever the content of the
Attributes field changes, and whenever a valid reply has been
received for a previous request. For retransmissions, the
Identifier MUST remain unchanged.
識別子フィールドは属性フィールドの内容が変化する時はいつも、そして
正当な答えが前の要求に対して受け取られた時はいつでも、変えられなく
てはなりません(MUST)。再送の際は、識別子は変化しないままでいなくて
はなりません(MUST)。
Request Authenticator
要求認証子
The Request Authenticator value MUST be changed each time a new
Identifier is used.
要求認証子値は、新しい識別子が使われるたびに、変えられなくてはなり
ません(MUST)。
Attributes
属性
The Attribute field is variable in length, and contains the list
of Attributes that are required for the type of service, as well
as any desired optional Attributes.
属性フィールドは可変長で、サービスタイプに必要な属性と望ましい任意
の属性のリストを含んでいます。
4.2. Access-Accept
4.2. アクセス許可
Description
解説
Access-Accept packets are sent by the RADIUS server, and provide
specific configuration information necessary to begin delivery of
service to the user. If all Attribute values received in an
Access-Request are acceptable then the RADIUS implementation MUST
transmit a packet with the Code field set to 2 (Access-Accept).
アクセス許可パケットがラディウスサーバーに送られる、ユーザーにサー
ビスの提供するのに必要な特定の設定情報を供給します。もしすべてのア
クセス要求で受け取った属性値が許容できるなら、ラディウス実装はコー
ドフィールドに２（アクセス許可）を設定したパケットを転送しなくては
なりません(MUST)。
On reception of an Access-Accept, the Identifier field is matched
with a pending Access-Request. The Response Authenticator field
MUST contain the correct response for the pending Access-Request.
Invalid packets are silently discarded.
アクセス許可の受信をしたら、識別子フィールドは送ったアクセス要求に
合わせらます。回答認証子フィールドは元のアクセス要求に対する正しい
回答を含んでいなければなりません(MUST)。無効なパケットが静かに捨て
られます。
A summary of the Access-Accept packet format is shown below. The
fields are transmitted from left to right.
アクセス許可パケットフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
| コード | 識別子 | 長さ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| 回答認証子 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
| 属性 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
2 for Access-Accept.
2 アクセス許可
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Access-Request which caused this Access-Accept.
識別子フィールドはアクセス許可をもたらしたアクセス要求の識別子フィー
ルドのコピーです。
Response Authenticator
回答認証子
The Response Authenticator value is calculated from the Access-
Request value, as described earlier.
回答認証子値は、前に記述されるように、アクセス要求値から計算されて
います。
Attributes
属性
The Attribute field is variable in length, and contains a list of
zero or more Attributes.
属性フィールドは可変長で、ゼロ以上の属性のリストを含んでいます。
4.3. Access-Reject
4.3. アクセス拒否
Description
解説
If any value of the received Attributes is not acceptable, then
the RADIUS server MUST transmit a packet with the Code field set
to 3 (Access-Reject). It MAY include one or more Reply-Message
Attributes with a text message which the NAS MAY display to the
user.
受信した属性のどれかが受理できなければ、ラディウスサーバはコード
フィールドが３（アクセス拒否）のパケットを返送します(MUST)。これ
はＮＡＳがユーザに表示するかもしれない(MAY)テキストメッセージを
含む１つ以上の応答メッセージ属性を含みます(MAY)
A summary of the Access-Reject packet format is shown below. The
fields are transmitted from left to right.
アクセス拒否パケットフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
| コード | 識別子 | 長さ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| 回答認証子 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
| 属性 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
3 for Access-Reject.
3 アクセス拒否
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Access-Request which caused this Access-Reject.
識別子フィールドはアクセス拒否をもたらしたアクセス要求の識別子フィー
ルドのコピーです。
Response Authenticator
回答認証子
The Response Authenticator value is calculated from the Access-
Request value, as described earlier.
回答認証子値は、前に記述されるように、アクセス要求値から計算されて
います。
Attributes
属性
The Attribute field is variable in length, and contains a list of
zero or more Attributes.
属性フィールドは可変長で、ゼロ以上の属性のリストを含んでいます。
4.4. Access-Challenge
4.4. アクセスチャレンジ
Description
解説
If the RADIUS server desires to send the user a challenge
requiring a response, then the RADIUS server MUST respond to the
Access-Request by transmitting a packet with the Code field set to
11 (Access-Challenge).
もしラディウスサーバーがユーザーの回答を必要とするチャレンジを送る
ことを望むなら、ラディウスサーバーはコードフィールドを１１（アクセ
スチャレンジ）に設定したパケットを送ることによってアクセス要求に返
答しなくてはなりません(MUST)。
The Attributes field MAY have one or more Reply-Message
Attributes, and MAY have a single State Attribute, or none.
Vendor-Specific, Idle-Timeout, Session-Timeout and Proxy-State
attributes MAY also be included. No other Attributes defined in
this document are permitted in an Access-Challenge.
属性フィールドは１つ以上の応答メッセージ属性を持つかもしれなくて
(MAY)、そして１つの状態属性があったりなかったりします(MAY)。ベン
ダー特有の、アイドルタイムアウトとセッションタイムアウトとプロク
シ状態属性が同じく含まれるかもしれません(MAY)。この文書で定義され
た他の属性はアクセスチャレンジで認められません。
On receipt of an Access-Challenge, the Identifier field is matched
with a pending Access-Request. Additionally, the Response
Authenticator field MUST contain the correct response for the
pending Access-Request. Invalid packets are silently discarded.
アクセスチャレンジを受信すると、識別子フィールドが送信したアクセス
要求と比較さられます。さらに、回答認証子フィールドは送信したアクセ
ス要求に対する正しい回答を含んでいなくてはなりません(MUST)。無効な
パケットが静かに捨てられます。
If the NAS does not support challenge/response, it MUST treat an
Access-Challenge as though it had received an Access-Reject
instead.
もしＮＡＳがチャレンジ／レスポンスをサポートしないなら、その代わり
にアクセス拒否を受け取ったかのように、アクセスチャレンジを処理しな
くてはなりません(MUST)。
If the NAS supports challenge/response, receipt of a valid
Access-Challenge indicates that a new Access-Request SHOULD be
sent. The NAS MAY display the text message, if any, to the user,
and then prompt the user for a response. It then sends its
original Access-Request with a new request ID and Request
Authenticator, with the User-Password Attribute replaced by the
user's response (encrypted), and including the State Attribute
from the Access-Challenge, if any. Only 0 or 1 instances of the
State Attribute can be present in an Access-Request.
もしＮＡＳがチャレンジ／レスポンスをサポートするなら、正当なアクセ
スチャレンジの受信は新しいアクセス要求が送られるべきである(SHOULD)
ことを示します。ＮＡＳは、もしあれば、ユーザーにテキストメッセージ
を示してもよく(MAY)、それから回答の入力をユーザーに促します。ＮＡＳ
は元のアクセス要求の、ユーザーパスワード属性を（暗号化された）ユー
ザの回答で置き換え、もしあればアクセスチャレンジの状態属性を含めを、
新しいリクエストＩＤと要求認証子を設定してアクセス要求送ります。状
態属性は０か１の値だけがアクセス要求で存在し得ます。
A NAS which supports PAP MAY forward the Reply-Message to the
dialing client and accept a PAP response which it can use as
though the user had entered the response. If the NAS cannot do
so, it MUST treat the Access-Challenge as though it had received
an Access-Reject instead.
ＰＡＰをサポートするＮＡＳが応答メッセージを電話してるクライアント
に転送し、ユーザーが回答を入力したかのように使うことができるＰＡＰ
回答を受け入れてもよいです(MAY)。もしＮＡＳがそうすることができな
いなら、その代わりにアクセス拒否を受け取ったかのように、アクセスチャ
レンジを処理しなくてはなりません(MUST)。
A summary of the Access-Challenge packet format is shown below. The
fields are transmitted from left to right.
アクセスチャレンジパケットフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
| コード | 識別子 | 長さ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Response Authenticator |
| 回答認証子 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attributes ...
| 属性 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
コード
11 for Access-Challenge.
11 アクセスチャレンジ
Identifier
識別子
The Identifier field is a copy of the Identifier field of the
Access-Request which caused this Access-Challenge.
識別子フィールドはアクセスチャレンジをもたらしたアクセス要求の識別子
フィールドのコピーです。
Response Authenticator
回答認証子
The Response Authenticator value is calculated from the Access-
Request value, as described earlier.
回答認証子値は、前に記述されるように、アクセス要求値から計算されて
います。
Attributes
属性
The Attributes field is variable in length, and contains a list of
zero or more Attributes.
属性フィールドは可変長で、ゼロ以上の属性のリストを含んでいます。
5. Attributes
5. 属性
RADIUS Attributes carry the specific authentication, authorization,
information and configuration details for the request and reply.
ラディウス属性が要求と応答で認証と認可と情報と設定細部を伴います。
The end of the list of Attributes is indicated by the Length of the
RADIUS packet.
属性リストの終わりはラディウスパケット長で示されます。
Some Attributes MAY be included more than once. The effect of this
is Attribute specific, and is specified in each Attribute
description. A summary table is provided at the end of the
"Attributes" section.
ある属性が２つ以上含まれるかもしれません(MAY)。この効果は属性に特有で、
各属性の記述で指定されます。要約表が「属性」章の終わりで供給されます。
If multiple Attributes with the same Type are present, the order of
Attributes with the same Type MUST be preserved by any proxies. The
order of Attributes of different Types is not required to be
preserved. A RADIUS server or client MUST NOT have any dependencies
on the order of attributes of different types. A RADIUS server or
client MUST NOT require attributes of the same type to be contiguous.
もし同じタイプの多数の属性があるなら、同じタイプの属性の順序はプロキ
シで維持されるに違いありません(MUST)。異なるタイプの属性の順序は維持
されるように要求されません。ラディウスサーバーあるいはクライアントが
異なったタイプの属性の順序に依存してはなりません(MUST NOT)。ラディウ
スサーバーあるいはクライアントが同じタイプの属性が連続的であるように
要求してはなりません(MUST NOT)。
Where an Attribute's description limits which kinds of packet it can
be contained in, this applies only to the packet types defined in
this document, namely Access-Request, Access-Accept, Access-Reject
and Access-Challenge (Codes 1, 2, 3, and 11). Other documents
defining other packet types may also use Attributes described here.
To determine which Attributes are allowed in Accounting-Request and
Accounting-Response packets (Codes 4 and 5) refer to the RADIUS
Accounting document [5].
属性の記述で属性がどの種類のパケットに含められるかを制限する所は、こ
の文書、すなわちアクセス要求とアクセス許可とアクセス拒否とアクセスチャ
レンジで定義されたパケットタイプにだけ当てはまります（コード１と２と
３と１１）。他のパケットタイプを定義している他の文書がここで記述され
た属性を使うかもしれません。課金要求と課金応答パケット（コード４と５）
でどの属性が許されるか決定するために、ラディウス課金文書[5]参照してく
ださい。
Likewise where packet types defined here state that only certain
Attributes are permissible in them, future memos defining new
Attributes should indicate which packet types the new Attributes may
be present in.
ここで定義されたパケットタイプがある特定の属性だけが許されると述べて
いますが、新しい属性を定義している将来の文書が新しい属性がどのパケッ
トタイプで存在しているか示すべきです。
A summary of the Attribute format is shown below. The fields are
transmitted from left to right.
属性のフォーマットの概要が以下の通りです。フィールドは左から右に転送さ
れます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Value ...
| タイプ | 長さ | 値 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
The Type field is one octet. Up-to-date values of the RADIUS Type
field are specified in the most recent "Assigned Numbers" RFC [6].
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.
タイプフィールドは1オクテットです。ラディウスタイプフィールドの最
新値が最新の「番号割当て」 RFC[6]で指定されます。値１９２-２２３
が実験的な使用のために確保されます、値２２４-２４０が実装特有の使
用のために確保されます、値２４１-２５５が留保されて、使われるべき
ではありません。
A RADIUS server MAY ignore Attributes with an unknown Type.
ラディウスサーバーが未知のタイプの属性を無視してもよいです(MAY)。
A RADIUS client MAY ignore Attributes with an unknown Type.
ラディウスクライアントが未知のタイプの属性を無視してもよいです(MAY)。
This specification concerns the following values:
この仕様は次の値に関係します：
1 User-Name
ユーザ名
2 User-Password
ユーザパスワード
3 CHAP-Password
ＣＨＡＰパスワード
4 NAS-IP-Address
ＮＡＳ−ＩＰアドレス
5 NAS-Port
ＮＡＳポート
6 Service-Type
サービスタイプ
7 Framed-Protocol
フレームプロトコル
8 Framed-IP-Address
フレームＩＰアドレス
9 Framed-IP-Netmask
フレームＩＰネットマスク
10 Framed-Routing
フレームルーチング
11 Filter-Id
フィルターＩＤ
12 Framed-MTU
フレームＭＴＵ
13 Framed-Compression
フレーム圧縮
14 Login-IP-Host
ログインＩＰホスト
15 Login-Service
ログインサービス
16 Login-TCP-Port
ログインＴＣＰポート
17 (unassigned)
（未割当て）
18 Reply-Message
応答メッセージ
19 Callback-Number
コールバック番号
20 Callback-Id
コールバックＩＤ
21 (unassigned)
（未割当て）
22 Framed-Route
フレーム経路
23 Framed-IPX-Network
フレームＩＰＸネットワーク
24 State
状態
25 Class
クラス
26 Vendor-Specific
ベンダー特有
27 Session-Timeout
セッションタイムアウト
28 Idle-Timeout
アイドルタイムアウト
29 Termination-Action
終了行動
30 Called-Station-Id
着信端末識別子
31 Calling-Station-Id
発信端末識別子
32 NAS-Identifier
ＮＡＳ識別子
33 Proxy-State
プロキシ状態
34 Login-LAT-Service
ログインＬＡＴサービス
35 Login-LAT-Node
ログインＬＡＴノード
36 Login-LAT-Group
ログインＬＡＴグループ
37 Framed-AppleTalk-Link
フレームアップルトークリンク
38 Framed-AppleTalk-Network
フレームアップルトークネットワーク
39 Framed-AppleTalk-Zone
フレームアップルトークゾーン
40-59 (reserved for accounting)
（課金のために予約）
60 CHAP-Challenge
ＣＨＰチャレンジ
61 NAS-Port-Type
ＮＡＳポートタイプ
62 Port-Limit
ポート限界
63 Login-LAT-Port
ログインＬＡＴポート
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 an Access-Request but with an invalid
Length, an Access-Reject SHOULD be transmitted. If an Attribute
is received in an Access-Accept, Access-Reject or Access-Challenge
packet with an invalid length, the packet MUST either be treated
as an Access-Reject or else silently discarded.
長さフィールドは１オクテットで、タイプと長さと値フィールドを含めて
のこの属性の長さを示します。もし属性がアクセス要求受取られ、長さが
無効なら、アクセス拒否が伝達されるべきです(SHOULD)。もし属性がアク
セス許可かアクセス拒否かアクセスチャレンジパケットで受取られ、長さ
が無効なら、パケットはアクセス拒否として取り扱われるか、静かに捨て
られなくてはなりません(MUST)。
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.
値フィールドはゼロ以上のオクテットで、属性に特有な情報を含んでいま
す。値フィールドのフォーマットと長さはタイプと長さフィールドによっ
て決定されます。
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
[7] 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.
ラディウスのどのタイプもNUL（１６進数の００）で終わらないことに注
意を払ってください。特に、ラディウスの「テキスト」と「文字列」タイ
プがNUL（１６進数の００）で終わりません。属性は長さフィールドを持
ち、終了記号を使いません。テキストがUTF-8コード化された10646 [7]文
字を含み、文字列が８ビットの２進データを含んでいます。サーバーとサー
バーとクライアントは埋め込まれたnullsを扱うことができなければなり
ません(MUST)。Ｃを使っているラディウス実装が文字列を扱うときに
strcpy()を使わないように注意して下さい。
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 [7]
characters. Text of length zero (0) MUST NOT be sent;
omit the entire attribute instead.
テキスト UTF-8コードの10646 [7]を含む1-253オクテット。長さゼロ（０）
のテキストが送られてはなりません(MUST NOT)；その代わりに
属性全体を省略します。
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オクテット。長さゼロ（０）の文字列が送られてはなりま
せん(MUST NOT)；その代わりに属性全体を省略します。
address 32 bit value, most significant octet first.
アドレス ３２ビットの値、最上位オクテットが最初。
integer 32 bit unsigned value, most significant octet first.
整数 ３２ビットの符号無しの値、最上位オクテットが最初。
time 32 bit unsigned value, most significant octet first --
seconds since 00:00:00 UTC, January 1, 1970. The
standard Attributes do not use this data type but it is
presented here for possible use in future attributes.
時刻 ３２ビット符号無しの値、最上位オクテットが最初--グリニッ
ジ標準時１９７０年１月１日００：００：００からの秒数。標
準属性はこのデータタイプを使いませんが、将来の属性で使用
可能にするためここで提出されます。
5.1. User-Name
5.1. ユーザ名
Description
解説
This Attribute indicates the name of the user to be authenticated.
It MUST be sent in Access-Request packets if available.
この属性は認証されるユーザーの名前を示します。
It MAY be sent in an Access-Accept packet, in which case the
client SHOULD use the name returned in the Access-Accept packet in
all Accounting-Request packets for this session. If the Access-
Accept includes Service-Type = Rlogin and the User-Name attribute,
a NAS MAY use the returned User-Name when performing the Rlogin
function.
これは、もし利用可能なら、アクセス要求パケットで送られなくてはなり
ません(MUST)。これはアクセス許可パケットで送られるかもしれず(MAY)、
その場合クライアントはこのセッションのすべての課金要求パケットでア
クセス許可パケットで返された名前を使うべきです(SHOULD)。もしアクセ
ス許可がサービスタイプ＝Rloginとユーザ名属性を含むなら、ＮＡＳが
Rlogin機能を実行する時返されたユーザ名を使ってもよいです(MAY)。
A summary of the User-Name Attribute format is shown below. The
fields are transmitted from left to right.
ユーザ名属性のフォーマットの概要が以下の通りです。フィールドは左から右
に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
1 for User-Name.
1 ユーザ名
Length
長さ
>= 3
>= 3
String
文字列
The String field is one or more octets. The NAS may limit the
maximum length of the User-Name but the ability to handle at least
63 octets is recommended.
文字列フィールドは１つ以上のオクテットです。ＮＡＳはユーザ名の最大
長を制限してもよいですが、少なくとも６３オクテットを扱う能力が推薦
されています。
The format of the username MAY be one of several forms:
ユーザ名のフォーマットは以下の形式の１つかもしれません(MAY)：
text Consisting only of UTF-8 encoded 10646 [7] characters.
テキスト UTF-8コード化した10646 [7]文字だけから成り立つ。
network access identifier
A Network Access Identifier as described in RFC 2486
[8].
ネットワークアクセス識別子
RFC 2486[8]で記述されるネットワークアクセス識別子。
distinguished name
A name in ASN.1 form used in Public Key authentication
systems.
著名な名前
公開鍵認証システムを使われるASN.１形式の名前。
5.2. User-Password
5.2. ユーザパスワード
Description
解説
This Attribute indicates the password of the user to be
authenticated, or the user's input following an Access-Challenge.
It is only used in Access-Request packets.
この属性は認証されるユーザーのパスワードか、アクセスチャレンジに対
するユーザーの入力を示します。これはアクセス要求パケットで使うだけ
です。
On transmission, the password is hidden. The password is first
padded at the end with nulls to a multiple of 16 octets. A one-
way MD5 hash is calculated over a stream of octets consisting of
the shared secret followed by the Request Authenticator. This
value is XORed with the first 16 octet segment of the password and
placed in the first 16 octets of the String field of the User-
Password Attribute.
送信時にパスワードは暗号化されます。パスワードが１６オクテットの倍
数になるように終わりにヌルを付け加えます。共有秘密鍵と要求認証子か
ら成り立つオクテット列上で一方向のＭＤ５ハッシュが計算されます。こ
の値とパスワードの最初の１６のオクテットの部分のＸＯＲをして、ユー
ザーパスワード属性の文字列フィールドの最初の１６オクテットに置かれ
ます。
If the password is longer than 16 characters, a second one-way MD5
hash is calculated over a stream of octets consisting of the
shared secret followed by the result of the first xor. That hash
is XORed with the second 16 octet segment of the password and
placed in the second 16 octets of the String field of the User-
Password Attribute.
もしパスワードが１６文字より長いなら、共有秘密鍵と最初のＸＯＲの結
果から成り立つオクテット列上で２番目の一方向ＭＤ５ハッシュが計算さ
れます。そのハッシュはパスワードの２番目の１６オクテット部分とＸＯ
Ｒし、ユーザーパスワード属性の文字列フィールドの２番目の１６オクテッ
トに置かれます。
If necessary, this operation is repeated, with each xor result
being used along with the shared secret to generate the next hash
to xor the next segment of the password, to no more than 128
characters.
もし必要であるなら、１２８以上の文字を超えない範囲で、この共有秘密
鍵と各ＸＯＲの結果が次のハッシュを生成し、パスワードの次の部分とＸ
ＯＲするという操作が繰り返されます。
The method is taken from the book "Network Security" by Kaufman,
Perlman and Speciner [9] pages 109-110. A more precise
explanation of the method follows:
この方法はKaufmanとPerlmanとSpecinerの"Network Security"という本
[9]のページ１０９-１１０からとられます。この方法のより正確な説明
が次です：
Call the shared secret S and the pseudo-random 128-bit Request
Authenticator RA. Break the password into 16-octet chunks p1, p2,
etc. with the last one padded at the end with nulls to a 16-octet
boundary. Call the ciphertext blocks c(1), c(2), etc. We'll need
intermediate values b1, b2, etc.
共有秘密鍵をSと、疑似乱数１２８ビットの要求認証子をRAと呼びます。
パスワードを１６オクテット単位に分解し、p1、p2、などとし、最後の
部分は１６オクテットになるように終わりにヌルを付け加えます。暗号
文ブロックをc(1)、c(2)などと呼びます。 中間値b1、b2などを必要とし
ます。
b1 = MD5(S + RA) c(1) = p1 xor b1
b2 = MD5(S + c(1)) c(2) = p2 xor b2
. .
. .
. .
bi = MD5(S + c(i-1)) c(i) = pi xor bi
The String will contain c(1)+c(2)+...+c(i) where + denotes
concatenation.
+を結合とすると、文字列はc(1)+c(2)+...+c(i)を含みます。
On receipt, the process is reversed to yield the original
password.
受信すると、プロセスはオリジナルのパスワードを得るため逆演算を
します。
A summary of the User-Password Attribute format is shown below. The
fields are transmitted from left to right.
ユーザパスワード属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
2 for User-Password.
2 パスワード
Length
長さ
At least 18 and no larger than 130.
最小１８、１３０を超えない
String
文字列
The String field is between 16 and 128 octets long, inclusive.
文字列フィールドは１６オクテット以上１２８オクテット以下
5.3. CHAP-Password
5.3. ＣＨＡＰパスワード
Description
解説
This Attribute indicates the response value provided by a PPP
Challenge-Handshake Authentication Protocol (CHAP) user in
response to the challenge. It is only used in Access-Request
packets.
このチャレンジに応えてＰＰＰチャレンジハンドシェーク認証プロト
コル（ＣＨＡＰ）ユーザーによって供給された回答値を示します。こ
れはアクセス要求パケットでだけ使います。
The CHAP challenge value is found in the CHAP-Challenge Attribute
(60) if present in the packet, otherwise in the Request
Authenticator field.
ＣＨＡＰチャレンジ値は、もしパケットにあれば、ＣＨＡＰチャレン
ジ属性（６０）に設定され、さもなければ要求認証子フィールドに設
定されます。
A summary of the CHAP-Password Attribute format is shown below. The
fields are transmitted from left to right.
ＣＨＡＰパスワード属性のフォーマットの概要が以下の通りです。フィールド
は左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | CHAP Ident | String ...
| タイプ | 長さ | CHAP識別子 | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
3 for CHAP-Password.
3 ＣＨＡＰパスワード
Length
長さ
19
19
CHAP Ident
CHAP識別子
This field is one octet, and contains the CHAP Identifier from the
user's CHAP Response.
このフィールドは１オクテットで、ユーザーのＣＨＡＰ回答のＣＨＡＰ識
別子を含んでいます。
String
文字列
The String field is 16 octets, and contains the CHAP Response from
the user.
文字列フィールドは１６オクテットで、ユーザーからのＣＨＡＰ回答を含
んでいます。
5.4. NAS-IP-Address
5.4. ＮＡＳ−ＩＰアドレス
Description
解説
This Attribute indicates the identifying IP Address of the NAS
which is requesting authentication of the user, and SHOULD be
unique to the NAS within the scope of the RADIUS server. NAS-IP-
Address is only used in Access-Request packets. Either NAS-IP-
Address or NAS-Identifier MUST be present in an Access-Request
packet.
この属性はユーザー認証を求めているＮＡＳを識別するＩＰアドレス
を示し、ラディウスサーバーの範囲のＮＡＳをユニークに識別できる
べきです(SHOULD)。ＮＡＳ−ＩＰアドレスはアクセス要求パケットで
だけ使います。ＮＡＳ−ＩＰアドレスかＮＡＳ識別子のいずれかがア
クセス要求パケットに存在しているに違いありません(MUST)。
Note that NAS-IP-Address MUST NOT be used to select the shared
secret used to authenticate the request. The source IP address of
the Access-Request packet MUST be used to select the shared
secret.
ＮＡＳ−ＩＰアドレスはリクエストを認証するために使われる共有秘
密鍵の選択に使われてはならない(MUST NOT)ことに注意してください。
アクセス要求パケットのソースＩＰアドレスが共有秘密鍵を選ぶため
に使われなくてはなりません(MUST)。
A summary of the NAS-IP-Address Attribute format is shown below. The
fields are transmitted from left to right.
ＮＡＳ−ＩＰアドレス属性のフォーマットの概要が以下の通りです。フィールド
は左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
| タイプ | 長さ | アドレス
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
アドレス（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
4 for NAS-IP-Address.
4 ＮＡＳ−ＩＰアドレス
Length
長さ
6
6
Address
アドレス
The Address field is four octets.
アドレスフィールドは４オクテットです。
5.5. NAS-Port
5.5. ＮＡＳポート
Description
解説
This Attribute indicates the physical port number of the NAS which
is authenticating the user. It is only used in Access-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. Either NAS-Port or NAS-Port-Type (61) or both SHOULD
be present in an Access-Request packet, if the NAS differentiates
among its ports.
この属性はユーザーを認証しているＮＡＳの物理的なポート番号を示しま
す。これはアクセス要求パケットでだけ使います。これはＮＡＳの物理的
な意味での「ポート」で、ＴＣＰやＵＤＰのポート番号の意味でないこと
を注意してください。もしＮＡＳがポートを区別するなら、ＮＡＳポート
やＮＡＳポートタイプ（６１）あるいは両方が、アクセス要求パケットに
あるべきです(SHOULD)。
A summary of the NAS-Port Attribute format is shown below. The
fields are transmitted from left to right.
ＮＡＳポート属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
5 for NAS-Port.
5 ＮＡＳポート
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは４オクテットです。
5.6. Service-Type
5.6. サービスタイプ
Description
解説
This Attribute indicates the type of service the user has
requested, or the type of service to be provided. It MAY be used
in both Access-Request and Access-Accept packets. A NAS is not
required to implement all of these service types, and MUST treat
unknown or unsupported Service-Types as though an Access-Reject
had been received instead.
この属性はユーザーが求めたサービスのタイプ、あるいは供給されるサー
ビスのタイプを示します。これはアクセス要求とアクセス許可パケットで
使われるかもしれません(MAY)。ＮＡＳがこれらすべてのサービスタイプを
実行するようには要求されてなくて、未知か対応していないサービスタイ
プの場合はアクセス拒否が受け取られたかのようにサービスタイプを扱わ
なくてはなりません(MUST)。
A summary of the Service-Type Attribute format is shown below. The
fields are transmitted from left to right.
サービスタイプ属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
6 for Service-Type.
6 サービスタイプ
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは４オクテットです。
1 Login
ログイン
2 Framed
フレーム
3 Callback Login
コールバックログイン
4 Callback Framed
コールバックフレーム
5 Outbound
外行き
6 Administrative
管理
7 NAS Prompt
ＮＡＳプロンプト
8 Authenticate Only
認証のみ
9 Callback NAS Prompt
コールバックＮＡＳプロンプト
10 Call Check
コールチェック
11 Callback Administrative
コールバック管理
The service types are defined as follows when used in an Access-
Accept. When used in an Access-Request, they MAY be considered to
be a hint to the RADIUS server that the NAS has reason to believe
the user would prefer the kind of service indicated, but the
server is not required to honor the hint.
サービスタイプは、アクセス許可で使われる時、次のように定義されます。
アクセス要求で使われる時、ユーザーが実施したいとＮＡＳが信じる理由
がある種類のサービスをラディウスサーバーに伝えるヒントと考えられま
す(MAY)、が、サーバーはヒントを重視する必要がありません。
Login The user should be connected to a host.
ログイン ユーザーはホストに接続するべきです。
Framed A Framed Protocol should be started for the
User, such as PPP or SLIP.
フレーム ＰＰＰやＳＬＩＰの様なフレームプロトコルをユー
ザーのために始めるべきです。
Callback Login The user should be disconnected and called
back, then connected to a host.
コールバックログイン ユーザーは接続を切られ、コールバックされ、ホ
ストに接続されるべきです。
Callback Framed The user should be disconnected and called
back, then a Framed Protocol should be started
for the User, such as PPP or SLIP.
コールバックフレーム ユーザーは接続を切られて、コールバックされ、
ＰＰＰやＳＬＩＰの様なフレームプロトコルをユー
ザーのために始めるべきです。
Outbound The user should be granted access to outgoing
devices.
外行き ユーザーは外向的デバイスへのアクセスを与えられ
るべきです。
Administrative The user should be granted access to the
administrative interface to the NAS from which
privileged commands can be executed.
管理 ユーザーは特権を与えられたコマンドが実行できる
ＮＡＳ管理インタフェースにアクセスを与えられる
べきです。
NAS Prompt The user should be provided a command prompt
on the NAS from which non-privileged commands
can be executed.
ＮＡＳプロンプト ユーザーには特権を与えられていないコマンドが実
行できるＮＡＳ上のコマンドプロンプトを用意され
るべきです。
Authenticate Only Only Authentication is requested, and no
authorization information needs to be returned
in the Access-Accept (typically used by proxy
servers rather than the NAS itself).
認証のみ ただ認証だけが求められ、認可情報がアクセス許可
で返される必要がありません（一般にＮＡＳにでは
なくプロクシサーバーによって使われます）。
Callback NAS Prompt The user should be disconnected and called
back, then provided a command prompt on the
NAS from which non-privileged commands can be
executed.
コールバックＮＡＳプロンプト ユーザーは接続を切られて、コールバック
され、特権を与えられていないコマンドが実行でき
るＮＡＳ上のコマンドプロンプトを用意されるべき
です。
Call Check Used by the NAS in an Access-Request packet to
indicate that a call is being received and
that the RADIUS server should send back an
Access-Accept to answer the call, or an
Access-Reject to not accept the call,
typically based on the Called-Station-Id or
Calling-Station-Id attributes. It is
recommended that such Access-Requests use the
value of Calling-Station-Id as the value of
the User-Name.
電話チェック アクセス要求でＮＡＳが呼を受信したことを示すの
に使い、一般に着信者端末識別子か発信者端末識別
子属性にもとづいいて、ラディウスサーバが呼に答
えるようにアクセス許可を送り返すべきか、呼に答
えないようにアクセス拒否を送り返すべきです。こ
のようなアクセス要求が発信端末識別子の値をユー
ザ名の値として用いることが勧められます。
Callback Administrative
The user should be disconnected and called
back, then granted access to the
administrative interface to the NAS from which
privileged commands can be executed.
コールバック管理 ユーザーは接続を切られて、コールバックされ、ユー
ザーは特権を与えられたコマンドが実行できるＮＡ
Ｓ管理インタフェースにアクセスを与えられるべき
です。
5.7. Framed-Protocol
5.7. フレームプロトコル
Description
解説
This Attribute indicates the framing to be used for framed access.
It MAY be used in both Access-Request and Access-Accept packets.
この特質はフレームアクセスに使われるフレームを示します。これはアク
セス要求とアクセス許可パケットで使われるかもしれません(MAY)。
A summary of the Framed-Protocol Attribute format is shown below.
The fields are transmitted from left to right.
フレームプロトコル属性のフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
7 for Framed-Protocol.
7 フレームプロトコル
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは４オクテットです。
1 PPP
ＰＰＰ
2 SLIP
ＳＬＩＰ
3 AppleTalk Remote Access Protocol (ARAP)
アップルトークリモートアクセスプロトコル（ＡＲＡＰ）
4 Gandalf proprietary SingleLink/MultiLink protocol
Gandalf専有シングルリンク／マルチリンク
プロトコル
5 Xylogics proprietary IPX/SLIP
ザイロジックス所有ＩＰＸ／ＳＬＩＰ
6 X.75 Synchronous
同期Ｘ．７５
5.8. Framed-IP-Address
5.8. フレームＩＰアドレス
Description
解説
This Attribute indicates the address to be configured for the
user. It MAY be used in Access-Accept packets. It MAY be used in
an Access-Request packet as a hint by the NAS to the server that
it would prefer that address, but the server is not required to
honor the hint.
この属性はユーザーに設定されるアドレスを示します。これはアクセス許
可パケットで使われるかもしれません(MAY)。これがアクセス要求パケッ
トでＮＡＳからサーバへのヒントとして使われるかもしれませんが(MAY)、
サーバーがヒントを重視することが要求されません。
A summary of the Framed-IP-Address Attribute format is shown below.
The fields are transmitted from left to right.
フレームＩＰアドレス属性のフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
| タイプ | 長さ | アドレス
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
アドレス（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
8 for Framed-IP-Address.
8 フレームＩＰアドレス
Length
長さ
6
6
Address
アドレス
The Address field is four octets. The value 0xFFFFFFFF indicates
that the NAS Should allow the user to select an address (e.g.
Negotiated). The value 0xFFFFFFFE indicates that the NAS should
select an address for the user (e.g. Assigned from a pool of
addresses kept by the NAS). Other valid values indicate that the
NAS should use that value as the user's IP address.
アドレスフィールドは４オクテットです。値0xFFFFFFFFは、ＮＡＳがユー
ザーにアドレスを選択（例えばネゴシエーション）することを許すべきこ
とを示します。値0xFFFFFFFEはユーザーのためにＮＡＳがアドレスを選択
する（例えば、ＮＡＳの保持するアドレスプールからの割り当て）べきで
あることを示します。他の有効な値がＮＡＳがその値をユーザーのＩＰア
ドレスとして用いるべきであることを示します。
5.9. Framed-IP-Netmask
5.9. フレームＩＰネットマスク
Description
解説
This Attribute indicates the IP netmask to be configured for the
user when the user is a router to a network. It MAY be used in
Access-Accept packets. It MAY be used in an Access-Request packet
as a hint by the NAS to the server that it would prefer that
netmask, but the server is not required to honor the hint.
この特質は、ユーザーがネットワークのルーターである時、ユーザーに設
定されるＩＰネットマスクを示します。これはアクセス許可パケットで使
われるかもしれません(MAY)。これはＮＡＳがサーバに好ましいネットマ
スクを示すヒントとしてアクセス要求パケットで使われるかもしれません
(MAY)が、サーバーがヒントを重視する事を要求されません。
A summary of the Framed-IP-Netmask Attribute format is shown below.
The fields are transmitted from left to right.
フレームＩＰネットマスク属性のフォーマットの概要が以下の通りです。
フィールドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
| タイプ | 長さ | アドレス
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
アドレス（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
9 for Framed-IP-Netmask.
9 フレームＩＰネットマスク
Length
長さ
6
6
Address
アドレス
The Address field is four octets specifying the IP netmask of the
user.
アドレスフィールドはユーザーのＩＰネットマスクを指定する４オクテッ
トです。
5.10. Framed-Routing
5.10. フレームルーチング
Description
解説
This Attribute indicates the routing method for the user, when the
user is a router to a network. It is only used in Access-Accept
packets.
この属性はユーザーがネットワークのルーターの時にユーザーのルーティ
ング方法を示します。これはアクセス許可パケットで使うだけです。
A summary of the Framed-Routing Attribute format is shown below. The
fields are transmitted from left to right.
フレームルーチング属性のフォーマットの概要が以下の通りです。フィールド
は左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
10 for Framed-Routing.
10 フレームルーチング
Length
長さ
6
6
Value
値
The Value field is four octets.
値は４オクテットです。
0 None
なし
1 Send routing packets
ルーチングパケットを送る
2 Listen for routing packets
ルーチングパケットを受取る
3 Send and Listen
送信と受信
5.11. Filter-Id
5.11. フィルターＩＤ
Description
解説
This Attribute indicates the name of the filter list for this
user. Zero or more Filter-Id attributes MAY be sent in an
Access-Accept packet.
この属性はこのユーザーのためのフィルターリストの名前を示します。
ゼロ以上のフィルターＩＤ属性がアクセス許可パケットで送られるか
もしれません(MAY)。
Identifying a filter list by name allows the filter to be used on
different NASes without regard to filter-list implementation
details.
名前でフィルターリストを識別すると、フィルターリストの実装の詳細
に関係なく、異なるＮＡＳでフィルターを使用できます。
A summary of the Filter-Id Attribute format is shown below. The
fields are transmitted from left to right.
フィルターＩＤ属性のフォーマットの概要が以下の通りです。フィールド
は左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
| タイプ | 長さ | テキスト ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
11 for Filter-Id.
11 フィルターＩＤ
Length
長さ
>= 3
>= 3
Text
テキスト
The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable and
MUST NOT affect operation of the protocol. It is recommended that
the message contain UTF-8 encoded 10646 [7] characters.
テキストフィールドは１オクテット以上で、中身は実装に依存します。こ
れは人間が読むことができるように意図されて、プロトコルのオペレー
ションに影響を与えてはなりません(MUST NOT)。メッセージがUTF-8でコー
ド化された１０６４６[7]文字を含んでいることが勧められます。
5.12. Framed-MTU
5.12. フレームＭＴＵ
Description
解説
This Attribute indicates the Maximum Transmission Unit to be
configured for the user, when it is not negotiated by some other
means (such as PPP). It MAY be used in Access-Accept packets. It
MAY be used in an Access-Request packet as a hint by the NAS to
the server that it would prefer that value, but the server is not
required to honor the hint.
この属性は、何か他の（ＰＰＰのような）手段で交渉できなかった場合に、
ユーザに設定する最大限伝送単位を示します。これはアクセス許可パケッ
トで使われるかもしれません(MAY)。ＮＡＳからサーバへ好ましい値を示
すヒントとしてこれがアクセス要求パケットで使われるかもしれません
(MAY)が、サーバーがヒントを重視するように要求されません。
A summary of the Framed-MTU Attribute format is shown below. The
fields are transmitted from left to right.
フレームＭＴＵ属性のフォーマットの概要が以下の通りです。フィールドは左
から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
12 for Framed-MTU.
12 フレームＭＴＵ
Length
長さ
6
6
Value
値
The Value field is four octets. Despite the size of the field,
values range from 64 to 65535.
値フィールドは４オクテットです。フィールドの大きさにもかかわら
ず、値の範囲は６４から６５５３５までです。
5.13. Framed-Compression
5.13. フレーム圧縮
Description
解説
This Attribute indicates a compression protocol to be used for the
link. It MAY be used in Access-Accept packets. It MAY be used in
an Access-Request packet as a hint to the server that the NAS
would prefer to use that compression, but the server is not
required to honor the hint.
この属性はリンクで使われる圧縮プロトコルを示します。これはアクセス
許可パケットで使われるかもしれません(MAY)。ＮＡＳからサーバへ好ま
しい圧縮を示すヒントとしてこれがアクセス要求パケットで使われるかも
しれません(MAY)が、サーバーがヒントを重視するように要求されません。
More than one compression protocol Attribute MAY be sent. It is
the responsibility of the NAS to apply the proper compression
protocol to appropriate link traffic.
１つ以上の圧縮プロトコル属性が送られるかもしれません(MAY)。適切な
圧縮プロトコルを適切なリンクトラフィックに適用するのはＮＡＳの責
任です。
A summary of the Framed-Compression Attribute format is shown below.
The fields are transmitted from left to right.
フレーム圧縮属性のフォーマットの概要が以下の通りです。フィールドは左か
ら右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
13 for Framed-Compression.
13 フレーム圧縮
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは４オクテットです。
0 None
なし
1 VJ TCP/IP header compression [10]
ＴＣＰ／ＩＰヘッダ圧縮[10]
2 IPX header compression
ＩＰＸヘッダ圧縮
3 Stac-LZS compression
Stac-LZS圧縮
5.14. Login-IP-Host
5.14. ログインＩＰホスト
Description
解説
This Attribute indicates the system with which to connect the user,
when the Login-Service Attribute is included. It MAY be used in
Access-Accept packets. It MAY be used in an Access-Request packet as
a hint to the server that the NAS would prefer to use that host, but
the server is not required to honor the hint.
ログインサービス属性が含まれるときに、この属性はユーザーを接続する
システムを示します。これはアクセス許可パケットで使われるかもしれま
せん(MAY)。ＮＡＳからサーバへ好ましいホストを示すヒントとしてこれ
がアクセス要求パケットで使われるかもしれません(MAY)が、サーバーが
ヒントを重視するように要求されません。
A summary of the Login-IP-Host Attribute format is shown below. The
fields are transmitted from left to right.
フレーム圧縮属性のフォーマットの概要が以下の通りです。フィールドは左か
ら右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Address
| タイプ | 長さ | アドレス
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Address (cont) |
アドレス（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
14 for Login-IP-Host.
14 フレーム圧縮
Length
長さ
6
6
Address
アドレス
The Address field is four octets. The value 0xFFFFFFFF indicates
that the NAS SHOULD allow the user to select an address. The
value 0 indicates that the NAS SHOULD select a host to connect the
user to. Other values indicate the address the NAS SHOULD connect
the user to.
アドレスフィールドは４オクテットです。値0xFFFFFFFFは、ＮＡＳがユー
ザーにアドレスを選択（例えばネゴシエーション）することを許すべきこ
とを示します(SHOULD)。値０はユーザーのためにＮＡＳがユーザを接続す
るホストを選択すべきことを示します(SHOULD)。他の値がＮＡＳがユーザ
を接続するアドレスを示します(SHOULD)。
5.15. Login-Service
5.15. ログインサービス
Description
解説
This Attribute indicates the service to use to connect the user to
the login host. It is only used in Access-Accept packets.
この属性はユーザーをログインホストと接続するために使うべきサービス
を示します。これはアクセス許可パケットでだけ使います。
A summary of the Login-Service Attribute format is shown below. The
fields are transmitted from left to right.
ログインサービス属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
15 for Login-Service.
15 ログインサービス
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは４オクテットです。
0 Telnet
1 Rlogin
2 TCP Clear
3 PortMaster (proprietary)
4 LAT
5 X25-PAD
6 X25-T3POS
8 TCP Clear Quiet (suppresses any NAS-generated connect string)
5.16. Login-TCP-Port
5.16. ログインＴＣＰポート
Description
解説
This Attribute indicates the TCP port with which the user is to be
connected, when the Login-Service Attribute is also present. It
is only used in Access-Accept packets.
ログインサービス属性があるときに、この属性はユーザーが接続されるは
ずであるＴＣＰポートを示します。これはアクセス許可パケットでだけ使
います。
A summary of the Login-TCP-Port Attribute format is shown below. The
fields are transmitted from left to right.
ログインＴＣＰポート属性のフォーマットの概要が以下の通りです。フィール
ドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
16 for Login-TCP-Port.
16 ログインＴＣＰポート
Length
長さ
6
6
Value
値
The Value field is four octets. Despite the size of the field,
values range from 0 to 65535.
値フィールドは４オクテットです。フィールドサイズにかかわらず、
値が０から６５５３５までの範囲です。
5.17. (unassigned)
5.17. （未割当て）
Description
解説
ATTRIBUTE TYPE 17 HAS NOT BEEN ASSIGNED.
属性タイプ１７が割り当てられませんでした。
5.18. Reply-Message
5.18. 応答メッセージ
Description
解説
This Attribute indicates text which MAY be displayed to the user.
この属性はユーザーに示されるかもしれないテキストを示します(MAY)。
When used in an Access-Accept, it is the success message.
アクセス許可で使われる時、これは成功メッセージです。
When used in an Access-Reject, it is the failure message. It MAY
indicate a dialog message to prompt the user before another
Access-Request attempt.
アクセス拒否で使われる時、これは失敗メッセージです。これは他のア
クセス要求の試みの前にユーザーを促すダイアログメッセージを示すか
もしれません(MAY)。
When used in an Access-Challenge, it MAY indicate a dialog message
to prompt the user for a response.
アクセスチャレンジで使われる時、これは回答の入力をユーザーに促す
ダイアログメッセージを示すかもしれません(MAY)。
Multiple Reply-Message's MAY be included and if any are displayed,
they MUST be displayed in the same order as they appear in the
packet.
訳注：RFC誤植情報によると上記の"Reply-Message's"は"Reply-Messages"が正しいそうです
多数の応答メッセージが含まれるかもしれません(MAY)、そしてもしど
れかが表示されるなら、それらはパケットに現われるのと同じ順序で表
示されなくてはなりません(MUST)。
A summary of the Reply-Message Attribute format is shown below. The
fields are transmitted from left to right.
応答メッセージ属性のフォーマットの概要が以下の通りです。フィールドは左
から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
| タイプ | 長さ | テキスト ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
18 for Reply-Message.
18 for 応答メッセージ
Length
長さ
>= 3
>= 3
Text
テキスト
The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable,
and MUST NOT affect operation of the protocol. It is recommended
that the message contain UTF-8 encoded 10646 [7] characters.
テキストフィールドは１オクテット以上で、中身は実装に依存します。
これは人間が読むことができるように意図され、プロトコルのオペレー
ションに影響を与えてはなりません(MUST NOT)。メッセージがUTF-8で
コードされた10646 [7]文字を含むことが勧められます。
5.19. Callback-Number
5.19. コールバック番号
Description
解説
This Attribute indicates a dialing string to be used for callback.
It MAY be used in Access-Accept packets. It MAY be used in an
Access-Request packet as a hint to the server that a Callback
service is desired, but the server is not required to honor the
hint.
この属性はコールバックで使うダイヤル番号を示します。これはアクセ
ス許可パケットで使われるかもしれません(MAY)。ＮＡＳからサーバへ
のコールバックサービスが要望されることを示すヒントとして、これが
アクセス要求パケットで使われるかもしれません(MAY)が、サーバーが
ヒントを重視するように要求されません。
A summary of the Callback-Number Attribute format is shown below.
The fields are transmitted from left to right.
コールバック番号属性のフォーマットの概要が以下の通りです。フィール
ドは左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
19 for Callback-Number.
19 コールバック番号
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.
文字列フィールドは１オクテット以上です。情報の実際のフォーマットは
サイトかアプリケーション特有で、強固な実装は平凡なオクテットとして
フィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使用範囲の成文化はこの仕様書の範囲の外です。
5.20. Callback-Id
5.20. コールバックＩＤ
Description
解説
This Attribute indicates the name of a place to be called, to be
interpreted by the NAS. It MAY be used in Access-Accept packets.
この属性はＮＡＳによって翻訳される呼出す場所の名前を示します。こ
れはアクセス許可パケットで使われるかもしれません(MAY)。
A summary of the Callback-Id Attribute format is shown below. The
fields are transmitted from left to right.
コールバックＩＤ属性のフォーマットの概要が以下の通りです。フィールド
は左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
20 for Callback-Id.
20 コールバックＩＤ
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.
文字列フィールドは１オクテット以上です。情報の実際のフォーマットは
サイトかアプリケーション特有で、強固な実装は平凡なオクテットとして
フィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使用範囲の成文化はこの仕様書の範囲の外です。
5.21. (unassigned)
5.21. （未割当て）
Description
解説
ATTRIBUTE TYPE 21 HAS NOT BEEN ASSIGNED.
属性タイプ２１が割り当てられませんでした。
5.22. Framed-Route
5.22. フレーム経路
Description
解説
This Attribute provides routing information to be configured for
the user on the NAS. It is used in the Access-Accept packet and
can appear multiple times.
この属性はＮＡＳ上にユーザー設定する経路情報を提供します。これは
アクセス許可パケットで使われ、いくつも存在できます。
A summary of the Framed-Route Attribute format is shown below. The
fields are transmitted from left to right.
フレーム経路属性のフォーマットの概要が以下の通りです。フィールドは左か
ら右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | Text ...
| タイプ | 長さ | テキスト ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
22 for Framed-Route.
22 フレーム経路
Length
長さ
>= 3
>= 3
Text
テキスト
The Text field is one or more octets, and its contents are
implementation dependent. It is intended to be human readable and
MUST NOT affect operation of the protocol. It is recommended that
the message contain UTF-8 encoded 10646 [7] characters.
テキストフィールドは１オクテット以上で、その中身は実装に依存します。
これは人間が読むことができるように意図され、プロトコルのオペレーショ
ンに影響を与えてはなりません(MUST NOT)。メッセージがUTF-8でコード
された10646[7]文字を含んでいることが勧められます。
For IP routes, it SHOULD contain a destination prefix in dotted
quad form optionally followed by a slash and a decimal length
specifier stating how many high order bits of the prefix to use.
That is followed by a space, a gateway address in dotted quad
form, a space, and one or more metrics separated by spaces. For
example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length
specifier may be omitted, in which case it defaults to 8 bits for
class A prefixes, 16 bits for class B prefixes, and 24 bits for
class C prefixes. For example, "192.168.1.0 192.168.1.1 1".
ＩＰ経路では、これはドットクワッド形式の宛先プレフィックスと、オプ
ションのスラッシュとプレフィックスの上位何ビットが使われているか示
す１０進数の長さ指定を含むべきです(SHOULD)。これはスペースに続いて、
ドットクワッド形式のゲートウェイアドレスと、スペースと、スペースで
区切られた１つ以上のメトリックが続きます。例えば"192.168.1.0/24
192.168.1.1 1 2 -1 3 400"です。長さ指定が省略されるかもしれず、こ
の場合はクラスＡは８ビット、クラスＢは16ビット、クラスＣは２４ビッ
トをデフォルトとします。例えば"192.168.1.0 192.168.1.1 1"です。
Whenever the gateway address is specified as "0.0.0.0" the IP
address of the user SHOULD be used as the gateway address.
ゲートウェイアドレスが"0.0.0.0"と明示される時は、ユーザーのＩＰア
ドレスがゲートウェイアドレスとして用いられるべきです(SHOULD)。
5.23. Framed-IPX-Network
5.23. フレームＩＰＸネットワーク
Description
解説
This Attribute indicates the IPX Network number to be configured
for the user. It is used in Access-Accept packets.
この属性はユーザーのために設定するＩＰＸネットワーク番号を示しま
す。それはアクセス許可パケットで使われます。
A summary of the Framed-IPX-Network Attribute format is shown below.
The fields are transmitted from left to right.
フレームＩＰＸネットワーク属性のフォーマットの概要が以下の通りです。
フィールドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
23 for Framed-IPX-Network.
23 フレームＩＰＸネットワーク
Length
長さ
6
6
Value
値
The Value field is four octets. The value 0xFFFFFFFE indicates
that the NAS should select an IPX network for the user (e.g.
assigned from a pool of one or more IPX networks kept by the NAS).
Other values should be used as the IPX network for the link to the
user.
値フィールドは４オクテットです。値0xFFFFFFFEはＮＡＳがユーザーのた
めにＩＰＸネットワークを選択するべきことを示します（例えばＮＡＳが
プールするＩＸＰネットワークの中から１つを割当てます）。他の値がユー
ザーへのリンクのＩＰＸネットワークとして使われるべきです。
5.24. State
5.24. 状態
Description
解説
This Attribute is available to be sent by the server to the client
in an Access-Challenge and MUST be sent unmodified from the client
to the server in the new Access-Request reply to that challenge,
if any.
この属性はサーバーからクライアントにアクセスチャレンジで送られ、チャ
レンジに対する新しいアクセス要求でクライアントからサーバに修正なし
で返送される(MUST)のに利用可能です。
This Attribute is available to be sent by the server to the client
in an Access-Accept that also includes a Termination-Action
Attribute with the value of RADIUS-Request. If the NAS performs
the Termination-Action by sending a new Access-Request upon
termination of the current session, it MUST include the State
attribute unchanged in that Access-Request.
この属性はサーバーからアクセス許可でクライアントに送るのが可能で、
同時にラディウス要求値の終了行動属性を含みます。もしＮＡＳが新しい
アクセス要求を現在のセッションの終了の上で送る終了行動を行うなら、
そのアクセス要求で変更なしの状態属性を含まなくてはなりません(MUST)。
In either usage, the client MUST NOT interpret the attribute
locally. A packet must have only zero or one State Attribute.
Usage of the State Attribute is implementation dependent.
いずれかの使用方法で、クライアントはローカルに属性を翻訳しては
なりません(MUST NOT)。パケットが０個か１個の状態属性だけを持た
なくてはなりません。状態属性の使用方法は実装に依存します。
A summary of the State Attribute format is shown below. The fields
are transmitted from left to right.
状態属性のフォーマットの概要が以下の通りです。フィールドは左から右
に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
24 for State.
24 状態
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.
文字列フィールドは１オクテット以上です。情報の実際のフォーマットは
サイトかアプリケーション特有で、強固な実装が平凡なオクテットとして
フィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使用方法の範囲の成文化はこの仕様書の範囲の
外です。
5.25. Class
5.25. クラス
Description
解説
This Attribute is available to be sent by the server to the client
in an Access-Accept and SHOULD be sent unmodified by the client to
the accounting server as part of the Accounting-Request packet if
accounting is supported. The client MUST NOT interpret the
attribute locally.
この属性はサーバからクライアントへアクセス許可で送信可能で、もし課
金がサポートされるなら、課金要求パケットの一部としてクライアントか
ら課金サーバに修正なしで送られるべきです(SHOULD)。クライアントはロー
カルに属性を翻訳してはなりません(MUST NOT)。
A summary of the Class Attribute format is shown below. The fields
are transmitted from left to right.
クラス属性のフォーマットの概要が以下の通りです。フィールドは左から
右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
25 for Class.
25 クラス
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.
文字列フィールドは１オクテット以上です。情報の実際のフォーマットは
サイトかアプリケーション特有で、強固な実装が平凡なオクテットとして
フィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使用方法の範囲の成文化はこの仕様書の範囲の
外です。
5.26. Vendor-Specific
5.26. ベンダー特有
Description
解説
This Attribute is available to allow vendors to support their own
extended Attributes not suitable for general usage. It MUST not
affect the operation of the RADIUS protocol.
この属性は一般的な用法でないベンダー独自の拡張属性をサポートするた
めに利用可能です。これはラディウスプロトコルのオペレーションに影響
を与えてはなりません(MUST not)。
Servers not equipped to interpret the vendor-specific information
sent by a client MUST ignore it (although it may be reported).
Clients which do not receive desired vendor-specific information
SHOULD make an attempt to operate without it, although they may do
so (and report they are doing so) in a degraded mode.
クライアントが送ったベンダー特有情報を解釈できないサーバーは（リポー
トされるかもしれないが）それを無視しなくてはなりません(MUST)。望ま
しいベンダー特有情報を受け取らなかったクライアントは、グレードダウ
ンモード動作して（そしてそれを報告して）もよいけれど、それ無しで動
作を試みるべきです(SHOULD)。
A summary of the Vendor-Specific Attribute format is shown below.
The fields are transmitted from left to right.
ベンダー特有属性フォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Vendor-Id
| タイプ | 長さ | ベンダＩＤ
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | String...
ベンダＩＤ（続き） | 文字列...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
26 for Vendor-Specific.
26 ベンダー特有
Length
長さ
>= 7
>= 7
Vendor-Id
ベンダＩＤ
The high-order octet is 0 and the low-order 3 octets are the SMI
Network Management Private Enterprise Code of the Vendor in
network byte order, as defined in the "Assigned Numbers" RFC [6].
上位オクテットは０で、下位３オクテットは「番号割り当て」RFC[6]で
定義されるように、ネットワークバイトオーダーのベンダーのＳＭＩネッ
トワークマネージメント私企業コードです。
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.
文字列フィールドは１オクテット以上です。情報の実際のフォーマットは
サイトかアプリケーション特有で、強固な実装が平凡なオクテットとして
フィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使用方法の範囲の成文化はこの仕様書の範囲の
外です。
It SHOULD be encoded as a sequence of vendor type / vendor length
/ value fields, as follows. The Attribute-Specific field is
dependent on the vendor's definition of that attribute. An
example encoding of the Vendor-Specific attribute using this
method follows:
これはベンダータイプ／ベンダー長／値フィールドの連続として、次のよ
うにコード化されるべきです(SHOULD)。属性特有フィールドはベンダーに
よるその特質の定義に依存しています。この方法を使うベンダー特有属性
のコーディング例が次の通りです：
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 | Vendor-Id
| タイプ | 長さ | ベンダＩＤ
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Vendor-Id (cont) | Vendor type | Vendor length |
ベンダＩＤ（続き） | ベンダタイプ | ベンダ長 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attribute-Specific...
| 属性特有...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Multiple subattributes MAY be encoded within a single Vendor-
Specific attribute, although they do not have to be.
多数の副属性はベンダー特有属性でコード化されるかもしれません(MAY)、
そうでなくてもかまいません。
5.27. Session-Timeout
5.27. セッションタイムアウト
Description
解説
This Attribute sets the maximum number of seconds of service to be
provided to the user before termination of the session or prompt.
This Attribute is available to be sent by the server to the client
in an Access-Accept or Access-Challenge.
この属性はセッション終了までユーザに提供するサービスか、プロンプト
の最大秒数を定めます。この属性はサーバーからアクセス許可かアクセス
チャレンジででクライアントに送ることができます。
A summary of the Session-Timeout Attribute format is shown below.
The fields are transmitted from left to right.
セッションタイムアウト属性のフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
27 for Session-Timeout.
27 セッションタイムアウト
Length
長さ
6
6
Value
値
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of seconds this user should be allowed to
remain connected by the NAS.
このフィールドは４オクテットで、このユーザーがＮＡＳによって接続
されたままでいることを許されるべき最大秒数を示す３２ビットの符号
なしの整数を含みます。
5.28. Idle-Timeout
5.28. アイドルタイムアウト
Description
解説
This Attribute sets the maximum number of consecutive seconds of
idle connection allowed to the user before termination of the
session or prompt. This Attribute is available to be sent by the
server to the client in an Access-Accept or Access-Challenge.
この属性はセッションかプロンプトの終了の前にユーザーに許されたア
イドル接続の最大連続秒数を設定します。この属性はサーバがアクセス
許可かアクセスチャレンジでクライアントに送る事ができます。
A summary of the Idle-Timeout Attribute format is shown below. The
fields are transmitted from left to right.
アイドルタイムアウト属性のフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
28 for Idle-Timeout.
28 アイドルタイムアウト
Length
長さ
6
6
Value
値
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of consecutive seconds of idle time this user
should be permitted before being disconnected by the NAS.
このフィールドは４オクテットで、このユーザーがＮＡＳが切断する前
に許されるべきアイドル時間の最大連続秒数を示す３２ビットの符号な
しの整数を含みます。
5.29. Termination-Action
5.29. 終了行動
Description
解説
This Attribute indicates what action the NAS should take when the
specified service is completed. It is only used in Access-Accept
packets.
この属性はＮＡＳが指定されたサービスが完了した時に何の行動をとる
べきであるかを示します。これはアクセス許可パケットでだけ使います。
A summary of the Termination-Action Attribute format is shown below.
The fields are transmitted from left to right.
終了行動属性のフォーマットの概要が以下の通りです。フィールドは左から
右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
29 for Termination-Action.
29 終了行動
Length
長さ
6
6
Value
値
The Value field is four octets.
値フィールドは４オクテット
0 Default
デフォルト
1 RADIUS-Request
ラディウス要請
If the Value is set to RADIUS-Request, upon termination of the
specified service the NAS MAY send a new Access-Request to the
RADIUS server, including the State attribute if any.
もし値がラディウス要請に設定されたら、指定されたサービスの終了
時にＮＡＳはラディウスサーバーに、もしあれば状態属性を含めて、
新しいアクセス要求を送ってもよいです(MAY)。
5.30. Called-Station-Id
5.30. 着信端末識別子
Description
解説
This Attribute allows the NAS to send in the Access-Request packet
the phone number that the user called, using Dialed Number
Identification (DNIS) or similar technology. Note that this may
be different from the phone number the call comes in on. It is
only used in Access-Request packets.
この属性はＮＡＳがユーザが呼んだダイヤル番号識別子か類似の電話番号
をアクセス要求パケットで送るのに使用します。これが着信する電話番号
と異なっているかもしれないことに注意してください。これはアクセス要
求パケットでだけ使います。
A summary of the Called-Station-Id Attribute format is shown below.
The fields are transmitted from left to right.
着信端末識別子属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
30 for Called-Station-Id.
30 着信端末識別子
Length
長さ
>= 3
>= 3
String
文字列
The String field is one or more octets, containing the phone
number that the user's call came in on.
文字列フィールドは１オクテット以上で、ユーザーの電話が入ってきた電
話番号を含んでいます。
The actual format of the information is site or application
specific. UTF-8 encoded 10646 [7] characters are recommended, but
a robust implementation SHOULD support the field as
undistinguished octets.
情報の実際のフォーマットはサイトかアプリケーションに特有です。
UTF-8でコード化された10646[7]文字が推薦されていますが、強固な実装
が平凡なオクテットとしてフィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使い方の制限の成文化はこの仕様書の範囲の
外です。
5.31. Calling-Station-Id
5.31. 発信端末識別子
Description
解説
This Attribute allows the NAS to send in the Access-Request packet
the phone number that the call came from, using Automatic Number
Identification (ANI) or similar technology. It is only used in
Access-Request packets.
この属性はＮＡＳがアクセス要求パケットで、自動番号表示（ＡＮＩ）や
あるいは類似の技術を使って示された発信者電話番号を送ることを許しま
す。これはアクセス要求パケットでだけ使います。
A summary of the Calling-Station-Id Attribute format is shown below.
The fields are transmitted from left to right.
発信端末識別子属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
31 for Calling-Station-Id.
31 発信端末識別子
Length
長さ
>= 3
>= 3
String
文字列
The String field is one or more octets, containing the phone
number that the user placed the call from.
The String field is one or more octets, containing the phone
number that the user's call came in on.
文字列フィールドは１オクテット以上で、ユーザが使った電話の電話番
号を含んでいます。
The actual format of the information is site or application
specific. UTF-8 encoded 10646 [7] characters are recommended, but
a robust implementation SHOULD support the field as
undistinguished octets.
情報の実際のフォーマットはサイトかアプリケーションに特有です。
UTF-8でコード化された10646[7]文字が推薦されていますが、強固な実装
が平凡なオクテットとしてフィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使い方の制限の成文化はこの仕様書の範囲の
外です。
5.32. NAS-Identifier
5.32. ＮＡＳ識別子
Description
解説
This Attribute contains a string identifying the NAS originating
the Access-Request. It is only used in Access-Request packets.
Either NAS-IP-Address or NAS-Identifier MUST be present in an
Access-Request packet.
この属性はアクセス要求を生成したＮＡＳを識別する文字列を含んでい
ます。これはアクセス要求パケットで使うだけです。ＮＡＳ−ＩＰアド
レスあるいはＮＡＳ識別子がアクセス要求パケットで存在しているに違
いありません(MUST)。
Note that NAS-Identifier MUST NOT be used to select the shared
secret used to authenticate the request. The source IP address of
the Access-Request packet MUST be used to select the shared
secret.
ＮＡＳ識別子が要求を認証するために使われた共有秘密鍵を選ぶために
使われてはならないことに注意を払ってください(MUST NOT)。アクセス
要求パケットのソースＩＰアドレスが共有秘密鍵を選ぶために使われな
くてはなりません(MUST)。
A summary of the NAS-Identifier Attribute format is shown below. The
fields are transmitted from left to right.
ＮＡＳ識別子属性のフォーマットの概要が以下の通りです。フィールドは左
から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
32 for NAS-Identifier.
32 ＮＡＳ識別子
Length
長さ
>= 3
>= 3
String
文字列
The String field is one or more octets, and should be unique to
the NAS within the scope of the RADIUS server. For example, a
fully qualified domain name would be suitable as a NAS-Identifier.
文字列フィールドは１オクテット以上で、ラディウスサーバーの範囲内
でＮＡＳに特有であるべきです。例えば、完全に指定されたドメイン名
がＮＡＳ識別子として適当であるでしょう。
The actual format of the information is site or application
specific, and a robust implementation SHOULD support the field as
undistinguished octets.
情報の実際のフォーマットはサイトかアプリケーション特有で、強固な
実装が平凡なオクテットとしてフィールドをサポートするべきです
(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使い方の制限の成文化はこの仕様書の範囲の
外です。
5.33. Proxy-State
5.33. プロキシ状態
Description
解説
This Attribute is available to be sent by a proxy server to
another server when forwarding an Access-Request and MUST be
returned unmodified in the Access-Accept, Access-Reject or
Access-Challenge. When the proxy server receives the response to
its request, it MUST remove its own Proxy-State (the last Proxy-
State in the packet) before forwarding the response to the NAS.
この属性はプロキシサーバが他のサーバへ転送するときにアクセス要
求で設定可能で、そしてアクセス許可かアクセス拒否かアクセスチャ
レンジで修正されずに返されなければなりません(MUST)。プロクシサー
バーが要求の回答を受け取る時、回答をＮＡＳに転送する前に自分自
身のプロクシ状態（（パケットの中の最後のプロクシ状態）を取り除
かなくてはなりません(MUST)。
If a Proxy-State Attribute is added to a packet when forwarding
the packet, the Proxy-State Attribute MUST be added after any
existing Proxy-State attributes.
もしパケットを転送する時にプロクシ状態属性がパケットに加えられ
るなら、プロクシ状態属性は既存のプロクシ状態属性の後に加えなけ
ればなりません(MUST)。
The content of any Proxy-State other than the one added by the
current server should be treated as opaque octets and MUST NOT
affect operation of the protocol.
現在のサーバーによって加えられたもの以外のプロクシ状態の内容は
不透明なオクテットとして取り扱われるべきであり、プロトコルのオ
ペレーションに影響を与えてはなりません(MUST NOT)。
Usage of the Proxy-State Attribute is implementation dependent. A
description of its function is outside the scope of this
specification.
プロクシ状態状態の使い方は実装に依存します。その機能の記述がこの
仕様書の範囲の外です。
A summary of the Proxy-State Attribute format is shown below. The
fields are transmitted from left to right.
プロキシ状態属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
33 for Proxy-State.
33 プロキシ状態
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.
文字列フィールドは１オクテット以上です。情報の実際のフォーマットは
サイトかアプリケーションに特有で、強固な実装が平凡なオクテットとし
てフィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使い方の制限の成文化はこの仕様書の範囲の外
です。
5.34. Login-LAT-Service
5.34. ログインＬＡＴサービス
Description
解説
This Attribute indicates the system with which the user is to be
connected by LAT. It MAY be used in Access-Accept packets, but
only when LAT is specified as the Login-Service. It MAY be used
in an Access-Request packet as a hint to the server, but the
server is not required to honor the hint.
この属性はＬＡＴによってユーザーが接続するはずであるシステムを示
します。これは、ＬＡＴがログインサービスとして明示される時だけ、
アクセス許可パケットで使われるかもしれません(MAY)。これはサーバへ
のヒントとしてアクセス要求で使われるかもしれません(MAY)が、サーバー
がヒントを重視するように要求されません。
Administrators use the service attribute when dealing with
clustered systems, such as a VAX or Alpha cluster. In such an
environment several different time sharing hosts share the same
resources (disks, printers, etc.), and administrators often
configure each to offer access (service) to each of the shared
resources. In this case, each host in the cluster advertises its
services through LAT broadcasts.
管理者がＶＡＸやＡｌｐｈａのような集団システムを扱う時、このサー
ビス属性を使います。このような環境でいくつかの異なったタイムシェ
アリングホストが同じ資源（ディスク、プリンタ、など）を共有し、管
理者が共有資源のそれぞれにアクセス（サービス）を申し出るためにそ
れぞれを設定します。この場合、集団の各ホストがＬＡＴブロードキャ
ストを通してそのサービスを広告します。
Sophisticated users often know which service providers (machines)
are faster and tend to use a node name when initiating a LAT
connection. Alternately, some administrators want particular
users to use certain machines as a primitive form of load
balancing (although LAT knows how to do load balancing itself).
洗練されたユーザーがしばしばどのサービスプロバイダ（マシン）がよ
り速いか知っていて、ＬＡＴ接続を始める時にノード名を使う傾向があ
ります。代わりに、（ＬＡＴ自身がどのように負荷分散すべきか知って
いるが）ある管理者が負荷分散の基本形として特定のユーザーが特定の
マシンを使うようにする事を望みます。
A summary of the Login-LAT-Service Attribute format is shown below.
The fields are transmitted from left to right.
ログインＬＡＴサービス属性のフォーマットの概要が以下の通りです。
フィールドは左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
34 for Login-LAT-Service.
34 ログインＬＡＴサービス
Length
長さ
>= 3
>= 3
String
文字列
The String field is one or more octets, and contains the identity
of the LAT service to use. The LAT Architecture allows this
string to contain $ (dollar), - (hyphen), . (period), _
(underscore), numerics, upper and lower case alphabetics, and the
ISO Latin-1 character set extension [11]. All LAT string
comparisons are case insensitive.
文字列フィールドは１オクテット以上で、使うべきＬＡＴサービスの識別
子を含んでいます。ＬＡＴアーキテクチャはこの文字列に $ （ドル）と
− （ハイフン）と . （ピリオド）と _ （下線）と数字と大文字と小文
字のアルファベットとＩＳＯラテン１文字セット拡張[11]を含むことを許
します。すべてのＬＡＴ文字列の比較は大文字小文字の違いを無視します。
5.35. Login-LAT-Node
5.35. ログインＬＡＴノード
Description
解説
This Attribute indicates the Node with which the user is to be
automatically connected by LAT. It MAY be used in Access-Accept
packets, but only when LAT is specified as the Login-Service. It
MAY be used in an Access-Request packet as a hint to the server,
but the server is not required to honor the hint.
この属性はユーザーが自動的にＬＡＴによって接続されるはずであるノー
ドを示します。これは、ＬＡＴがログインサービスとして明示される時
だけ、アクセス許可パケットで使われるかもしれません(MAY)。これは
アクセス要求パケットでサーバーへのヒントとして使われるかもしれま
せんが、サーバーがヒントを重視するように要求されません(MAY)。
A summary of the Login-LAT-Node Attribute format is shown below. The
fields are transmitted from left to right.
ログインＬＡＴノード属性のフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
35 for Login-LAT-Node.
35 ログインＬＡＴノード
Length
長さ
>= 3
>= 3
String
文字列
The String field is one or more octets, and contains the identity
of the LAT Node to connect the user to. The LAT Architecture
allows this string to contain $ (dollar), - (hyphen), . (period),
_ (underscore), numerics, upper and lower case alphabetics, and
the ISO Latin-1 character set extension. All LAT string
comparisons are case insensitive.
文字列フィールドは１オクテット以上で、ユーザが接続するＬＡＴノード
の識別子を含んでいます。ＬＡＴアーキテクチャはこの文字列に $ （ド
ル）と − （ハイフン）と . （ピリオド）と _ （下線）と数字と大文字
と小文字のアルファベットとＩＳＯラテン１文字セット拡張[11]を含むこ
とを許します。すべてのＬＡＴ文字列の比較は大文字小文字の違いを無視
します。
5.36. Login-LAT-Group
5.36. ログインＬＡＴグループ
Description
解説
This Attribute contains a string identifying the LAT group codes
which this user is authorized to use. It MAY be used in Access-
Accept packets, but only when LAT is specified as the Login-
Service. It MAY be used in an Access-Request packet as a hint to
the server, but the server is not required to honor the hint.
この属性はこのユーザーが使う権限を与えられるＬＡＴグループコード
を識別する文字列を含んでいます。これは、ＬＡＴがログインサービス
として明示される時だけ、アクセス許可パケットで使われるかもしれま
せん(MAY)。それはアクセス要求パケットでサーバへのヒントとして使
われるかもしれません(MAY)が、サーバーがヒントを重視するように要
求されません。
LAT supports 256 different group codes, which LAT uses as a form
of access rights. LAT encodes the group codes as a 256 bit
bitmap.
ＬＡＴは２５６の異なったグループコードをサポートし、ＬＡＴはこれ
をアクセス権の形式として使います。ＬＡＴは２５６ビットのビットマッ
プとしてグループコードをコード化します。
Administrators can assign one or more of the group code bits at
the LAT service provider; it will only accept LAT connections that
have these group codes set in the bit map. The administrators
assign a bitmap of authorized group codes to each user; LAT gets
these from the operating system, and uses these in its requests to
the service providers.
管理者がＬＡＴサービスプロバイダに１つ以上のコードを与えます；これ
は、ビットマップを設定したグループコードを持つ接続だけを受け入れる
でしょう。管理者は公認のグループコードのビットマップをそれぞれのユー
ザーに割り当てます；ＬＡＴはオペレーティング・システムからこれらを
得て、サービスプロバイダへのリクエストでこれらを使います。
A summary of the Login-LAT-Group Attribute format is shown below.
The fields are transmitted from left to right.
ログインＬＡＴグループ属性のフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
36 for Login-LAT-Group.
36 ログインＬＡＴグループ
Length
長さ
34
34
String
文字列
The String field is a 32 octet bit map, most significant octet
first. A robust implementation SHOULD support the field as
undistinguished octets.
文字列フィールドは３２オクテットビットマップで、最上位オクテット
が最初です。強固な実装が平凡なオクテットとしてフィールドをサポー
トするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使い方の制限の成文化はこの仕様書の範囲の
外です。
5.37. Framed-AppleTalk-Link
5.37. フレームアップルトークリンク
Description
解説
This Attribute indicates the AppleTalk network number which should
be used for the serial link to the user, which is another
AppleTalk router. It is only used in Access-Accept packets. It
is never used when the user is not another router.
この属性はルータであるユーザーへのシリアルリンクに使われるべき
AppleTalkネットワーク番号を示します。これはアクセス許可パケット
でだけ使います。これは、ユーザーがルーターではない時、決して使
われません。
A summary of the Framed-AppleTalk-Link Attribute format is shown
below. The fields are transmitted from left to right.
フレームアップルトークリンク属性のフォーマットの概要が以下の通りです。
フィールドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
37 for Framed-AppleTalk-Link.
37 フレームアップルトークリンク
Length
長さ
6
6
Value
値
The Value field is four octets. Despite the size of the field,
values range from 0 to 65535. The special value of 0 indicates
that this is an unnumbered serial link. A value of 1-65535 means
that the serial line between the NAS and the user should be
assigned that value as an AppleTalk network number.
値フィールドは４オクテットです。フィールドの大きさにもかかわらず、
値が０から６５５３５までです。０の特別な値はこれが番号なしのシリ
アルリンクであることを示します。１から６５５３５の値がＮＡＳとユー
ザーの間のシリアルラインにAppleTalkネットワーク番号として割り当て
られるべき番号を意味します。
5.38. Framed-AppleTalk-Network
5.38. フレームアップルトークネットワーク
Description
解説
This Attribute indicates the AppleTalk Network number which the
NAS should probe to allocate an AppleTalk node for the user. It
is only used in Access-Accept packets. It is never used when the
user is another router. Multiple instances of this Attribute
indicate that the NAS may probe using any of the network numbers
specified.
この属性はＮＡＳがユーザーのAppleTalkノードの割り当てを探るべき
であるAppleTalkネットワーク番号を示します。これはアクセス許可パ
ケットでだけ使います。これは、ユーザールーターである時は決して使
われません。この属性が多数存在するときはＮＡＳが示されたどのネッ
トワーク番号で探ってもよいことを示します。
A summary of the Framed-AppleTalk-Network Attribute format is shown
below. The fields are transmitted from left to right.
フレームアップルトークネットワーク属性のフォーマットの概要が以下の
通りです。フィールドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
38 for Framed-AppleTalk-Network.
38 フレームアップルトークネットワーク
Length
長さ
6
6
Value
値
The Value field is four octets. Despite the size of the field,
values range from 0 to 65535. The special value 0 indicates that
the NAS should assign a network for the user, using its default
cable range. A value between 1 and 65535 (inclusive) indicates
the AppleTalk Network the NAS should probe to find an address for
the user.
値フィールドは４オクテットです。フィールドの大きさにもかかわらず、
値が０から６５５３５までです。特別な値０は、デフォルトケーブルレン
ジを使って、ＮＡＳがユーザーのためにネットワークを割り当てるべきで
あることを示します。１以上６５５３５以下の値がＮＡＳがユーザーのア
ドレスを見いだすために探るべきであるAppleTalkネットワークを示します。
5.39. Framed-AppleTalk-Zone
5.39. フレームアップルトークゾーン
Description
解説
This Attribute indicates the AppleTalk Default Zone to be used for
this user. It is only used in Access-Accept packets. Multiple
instances of this attribute in the same packet are not allowed.
この属性はこのユーザーに使われるAppleTalkデフォルトゾーンを示しま
す。これはアクセス許可パケットでだけ使います。この同じパケットで
の多数の属性は許されません。
A summary of the Framed-AppleTalk-Zone Attribute format is shown
below. The fields are transmitted from left to right.
フレームアップルトークゾーン属性のフォーマットの概要が以下の通りで
す。フィールドは左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
39 for Framed-AppleTalk-Zone.
39 フレームアップルトークゾーン
Length
長さ
>= 3
>= 3
String
文字列
The name of the Default AppleTalk Zone to be used for this user.
A robust implementation SHOULD support the field as
undistinguished octets.
このユーザーに使われるデフォルトAppleTalkゾーン名。強固な実装が
平凡なオクテットとしてフィールドをサポートするべきです(SHOULD)。
The codification of the range of allowed usage of this field is
outside the scope of this specification.
このフィールドの許された使い方の制限の成文化はこの仕様書の範囲
の外です。
5.40. CHAP-Challenge
5.40. ＣＨＡＰチャレンジ
Description
解説
This Attribute contains the CHAP Challenge sent by the NAS to a
PPP Challenge-Handshake Authentication Protocol (CHAP) user. It
is only used in Access-Request packets.
この属性は、ＮＡＳがＰＰＰチャレンジハンドシェーク認証プロトコル
（ＣＨＡＰ）ユーザーに送るＣＨＡＰチャレンジを含んでいます。これは
アクセス要求パケットでだけ使用します。
If the CHAP challenge value is 16 octets long it MAY be placed in
the Request Authenticator field instead of using this attribute.
もしＣＨＡＰチャレンジ値が１６オクテット長なら、ＣＨＡＰチャレンジ
値はこの属性でなく要求認証子フィールドに置かれるかもしれません(MAY)。
A summary of the CHAP-Challenge Attribute format is shown below. The
fields are transmitted from left to right.
ＣＨＡＰチャレンジ属性のフォーマットの概要が以下の通りです。フィールド
は左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
60 for CHAP-Challenge.
60 ＣＨＡＰチャレンジ
Length
長さ
>= 7
>= 7
String
文字列
The String field contains the CHAP Challenge.
文字列フィールドはＣＨＡＰチャレンジを含んでいます。
5.41. NAS-Port-Type
5.41. ＮＡＳポートタイプ
Description
解説
This Attribute indicates the type of the physical port of the NAS
which is authenticating the user. It can be used instead of or in
addition to the NAS-Port (5) attribute. It is only used in
Access-Request packets. Either NAS-Port (5) or NAS-Port-Type or
both SHOULD be present in an Access-Request packet, if the NAS
differentiates among its ports.
この属性はユーザーを認証しているＮＡＳの物理的なポートのタイプを示
します。これはＮＡＳポート属性の代わりにあるいは追加に使うことがで
きます。これはアクセス要求パケットでだけ使用します。もしＮＡＳがポー
トを区別するならＮＡＳポート(5)かＮＡＳポートタイプあるいは両方が、
アクセス要求パケットにあるべきです(SHOULD)。
A summary of the NAS-Port-Type Attribute format is shown below. The
fields are transmitted from left to right.
ＮＡＳポートタイプ属性のフォーマットの概要が以下の通りです。フィール
ドは左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
61 for NAS-Port-Type.
61 ＮＡＳポートタイプ
Length
長さ
6
6
Value
値
The Value field is four octets. "Virtual" refers to a connection
to the NAS via some transport protocol, instead of through a
physical port. For example, if a user telnetted into a NAS to
authenticate himself as an Outbound-User, the Access-Request might
include NAS-Port-Type = Virtual as a hint to the RADIUS server
that the user was not on a physical port.
値フィールドは４オクテットです。"Virtual"はＮＡＳによる転送プロト
コルの接続を示し、物理的なポートではありません。例えば、もしユーザー
がＮＡＳ自身の認証のため外向きユーザとしてｔｅｌｎｅｔするなら、ユー
ザーが物理的なポートの上になかったというラディウスサーバーへのヒン
トとして、アクセス要求はＮＡＳ ポートタイプ＝Virtualを含むかもしれ
ません。
0 Async
1 Sync
2 ISDN Sync
3 ISDN Async V.120
4 ISDN Async V.110
5 Virtual
6 PIAFS
7 HDLC Clear Channel
8 X.25
9 X.75
10 G.3 Fax
11 SDSL - Symmetric DSL
12 ADSL-CAP - Asymmetric DSL, Carrierless Amplitude Phase
Modulation
13 ADSL-DMT - Asymmetric DSL, Discrete Multi-Tone
14 IDSL - ISDN Digital Subscriber Line
15 Ethernet
16 xDSL - Digital Subscriber Line of unknown type
17 Cable
18 Wireless - Other
19 Wireless - IEEE 802.11
PIAFS is a form of wireless ISDN commonly used in Japan, and
stands for PHS (Personal Handyphone System) Internet Access Forum
Standard (PIAFS).
PIAFSは日本で一般に使われる無線ＩＳＤＮ形式で、ＰＨＳ(Personal
Handyphone System)インターネット・アクセス・フォーラム・標準
（ＰＩＡＦＳ）標準です。
5.42. Port-Limit
5.42. ポート限界
Description
解説
This Attribute sets the maximum number of ports to be provided to
the user by the NAS. This Attribute MAY be sent by the server to
the client in an Access-Accept packet. It is intended for use in
conjunction with Multilink PPP [12] or similar uses. It MAY also
be sent by the NAS to the server as a hint that that many ports
are desired for use, but the server is not required to honor the
hint.
この属性はＮＡＳがユーザに供給するポートの最大数を定めます。この属
性はアクセス許可パケットでサーバーからクライアントに送られるかもし
れません(MAY)。これはマルチリンクＰＰＰ[12]や類似使い方と関連した
使用を意図されます。これは同じく使いたいポート数を示すＮＡＳからサー
バへヒントとして送られるかもしれません(MAY)が、サーバーはヒントを
重視するように要求されません。
A summary of the Port-Limit Attribute format is shown below. The
fields are transmitted from left to right.
ポート限界属性のフォーマットの概要が以下の通りです。フィールドは
左から右に転送されます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Value
| タイプ | 長さ | 値
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Value (cont) |
値（続き） |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
タイプ
62 for Port-Limit.
62 ポート限界
Length
長さ
6
6
Value
値
The field is 4 octets, containing a 32-bit unsigned integer with
the maximum number of ports this user should be allowed to connect
to on the NAS.
フィールドはこのユーザーがＮＡＳ上で接続することを許されるべきポー
トの最大数を示す３２ビットの符号なしの整数を含んでいる４つのオクテッ
トです。
5.43. Login-LAT-Port
5.43. ログインＬＡＴポート
Description
解説
This Attribute indicates the Port with which the user is to be
connected by LAT. It MAY be used in Access-Accept packets, but
only when LAT is specified as the Login-Service. It MAY be used
in an Access-Request packet as a hint to the server, but the
server is not required to honor the hint.
この属性はユーザーが接続すべきＬＡＴポートを示します。ＬＡＴがロ
グインサービスとして明示される時だけ、これはアクセス許可パケット
で使われるかもしれません(MAY)。これはアクセス要求パケットでサー
バへのヒントとして使われるかもしれません(MAY)が、サーバーはヒン
トを重視するに要求されません。
A summary of the Login-LAT-Port Attribute format is shown below. The
fields are transmitted from left to right.
ログインＬＡＴポート属性のフォーマットの概要が以下の通りです。フィー
ルドは左から右に転送されます。
0 1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Type | Length | String ...
| タイプ | 長さ | 文字列 ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Type
タイプ
63 for Login-LAT-Port.
63 ログインＬＡＴポート
Length
長さ
>= 3
>= 3
String
文字列
The String field is one or more octets, and contains the identity
of the LAT port to use. The LAT Architecture allows this string
to contain $ (dollar), - (hyphen), . (period), _ (underscore),
numerics, upper and lower case alphabetics, and the ISO Latin-1
character set extension. All LAT string comparisons are case
insensitive.
文字列フィールドは１オクテット以上で、ユーザが使うＬＡＴポートの識
別子を含んでいます。ＬＡＴアーキテクチャはこの文字列に $ （ドル）
と − （ハイフン）と . （ピリオド）と _ （下線）と数字と大文字と小
文字のアルファベットとＩＳＯラテン１文字セット拡張[11]を含むことを
許します。すべてのＬＡＴ文字列の比較は大文字小文字の違いを無視しま
す。
5.44. Table of Attributes
5.44. 属性表
The following table provides a guide to which attributes may be found
in which kinds of packets, and in what quantity.
次の表は属性がどのパケット種類で、何個あるかのガイドを供給します。
Request Accept Reject Challenge # Attribute
0-1 0-1 0 0 1 User-Name
0-1 0 0 0 2 User-Password [Note 1]
0-1 0 0 0 3 CHAP-Password [Note 1]
0-1 0 0 0 4 NAS-IP-Address [Note 2]
0-1 0 0 0 5 NAS-Port
0-1 0-1 0 0 6 Service-Type
0-1 0-1 0 0 7 Framed-Protocol
0-1 0-1 0 0 8 Framed-IP-Address
0-1 0-1 0 0 9 Framed-IP-Netmask
0 0-1 0 0 10 Framed-Routing
0 0+ 0 0 11 Filter-Id
0-1 0-1 0 0 12 Framed-MTU
0+ 0+ 0 0 13 Framed-Compression
0+ 0+ 0 0 14 Login-IP-Host
0 0-1 0 0 15 Login-Service
0 0-1 0 0 16 Login-TCP-Port
0 0+ 0+ 0+ 18 Reply-Message
0-1 0-1 0 0 19 Callback-Number
0 0-1 0 0 20 Callback-Id
0 0+ 0 0 22 Framed-Route
0 0-1 0 0 23 Framed-IPX-Network
0-1 0-1 0 0-1 24 State [Note 1]
0 0+ 0 0 25 Class
0+ 0+ 0 0+ 26 Vendor-Specific
0 0-1 0 0-1 27 Session-Timeout
0 0-1 0 0-1 28 Idle-Timeout
0 0-1 0 0 29 Termination-Action
0-1 0 0 0 30 Called-Station-Id
0-1 0 0 0 31 Calling-Station-Id
0-1 0 0 0 32 NAS-Identifier [Note 2]
0+ 0+ 0+ 0+ 33 Proxy-State
0-1 0-1 0 0 34 Login-LAT-Service
0-1 0-1 0 0 35 Login-LAT-Node
0-1 0-1 0 0 36 Login-LAT-Group
0 0-1 0 0 37 Framed-AppleTalk-Link
0 0+ 0 0 38 Framed-AppleTalk-Network
0 0-1 0 0 39 Framed-AppleTalk-Zone
0-1 0 0 0 60 CHAP-Challenge
0-1 0 0 0 61 NAS-Port-Type
0-1 0-1 0 0 62 Port-Limit
0-1 0-1 0 0 63 Login-LAT-Port
Request Accept Reject Challenge # Attribute
[Note 1] An Access-Request MUST contain either a User-Password or a
CHAP-Password or State. An Access-Request MUST NOT contain both a
User-Password and a CHAP-Password. If future extensions allow other
kinds of authentication information to be conveyed, the attribute for
that can be used in an Access-Request instead of User-Password or
CHAP-Password.
［ノート１］アクセス要求がユーザーパスワードあるいはＣＨＡＰパスワー
ドあるいは状態を含んでいなくてはなりません(MUST)。アクセス要求がユー
ザーパスワードとＣＨＡＰパスワードの両方を含んでいてはなりません(MUST
NOT)。もし未来の拡張が認証情報の他の種類に伝達を許すなら、それ属性が
ユーザーパスワードやＣＨＡＰパスワードの代わりにアクセス要求で使うこ
とができます。
[Note 2] An Access-Request MUST contain either a NAS-IP-Address or a
NAS-Identifier (or both).
［ノート２］アクセス要求がＮＡＳ−ＩＰアドレスあるいはＮＡＳ識別子
（あるいは両方とも）を含んでいなくてはなりません。
The following table defines the meaning of the above table entries.
次の表は上記の表の項目を定義します。
0 This attribute MUST NOT be present in packet.
この属性は存在しません(MUST NOT)
0+ Zero or more instances of this attribute MAY be present in packet.
この属性は０個以上あります(MAY)
0-1 Zero or one instance of this attribute MAY be present in packet.
この属性は０個か１個あります(MAY)
1 Exactly one instance of this attribute MUST be present in packet.
この属性は正確に１個あります(MUST)
6. IANA Considerations
6. ＩＡＮＡの考慮
This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the
RADIUS protocol, in accordance with BCP 26 [13].
この章はラディウスプロトコルと関係がある値の登録に関して、ＢＣＰ２６
[13]のとおりにインターネット番号割当当局（ＩＡＮＡ）に案内を供給します。
There are three name spaces in RADIUS that require registration:
Packet Type Codes, Attribute Types, and Attribute Values (for certain
Attributes).
ラディアスに登録を必要とする３つの名前空間があります：パケットタイプ
コードと属性タイプと（ある特定の属性の）特質値です。
RADIUS is not intended as a general-purpose Network Access Server
(NAS) management protocol, and allocations should not be made for
purposes unrelated to Authentication, Authorization or Accounting.
ラディウスは汎用のネットワークアクセスサーバー（ＮＡＳ）管理プロトコ
ルを意図しません、そして認証か認可か課金と無関係な目的のために作られ
るべきではありません。
6.1. Definition of Terms
6.1. 用語の定義
The following terms are used here with the meanings defined in
BCP 26: "name space", "assigned value", "registration".
次の用語はＢＣＰ２６で定義された意味でここで使われます：「名前空
間」、「割当て値」、「登録」。
The following policies are used here with the meanings defined in
BCP 26: "Private Use", "First Come First Served", "Expert Review",
"Specification Required", "IETF Consensus", "Standards Action".
次のポリシーはＢＣＰ２６で定義された意味でここで使われます：「プ
ライベート利用」、「最初来たのに最初を用意」、「専門家のレビュー」、
「仕様の必要」、「ＩＥＴＦ総意」、「標準行動」。
6.2. Recommended Registration Policies
6.2. 推薦された登録ポリシー
For registration requests where a Designated Expert should be
consulted, the IESG Area Director for Operations should appoint the
Designated Expert.
登録要請はデザイン専門家に相談するべきで、オペレーションのＩＥＳＧエ
リアディレクターはデザイン専門家を任命するべきです。
For registration requests requiring Expert Review, the ietf-radius
mailing list should be consulted.
登録要請のエキスパートのレビューの要求に関して、ietf-radiusメーリン
グリストで相談されるべきです。
Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have
been allocated. Because a new Packet Type has considerable impact on
interoperability, a new Packet Type Code requires Standards Action,
and should be allocated starting at 14.
パケットタイプコードが１から２５４までの範囲で、１−５と１１−１３は
割り当てられました。新しいパケットタイプが互換性にかなりの影響を持つ
から、新しいパケットタイプコードが標準行動を必要とし、１４以降を割り
当てられるべきです。
Attribute Types have a range from 1 to 255, and are the scarcest
resource in RADIUS, thus must be allocated with care. Attributes
1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for
re-use. Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated
following Expert Review, with Specification Required. Release of
blocks of Attribute Types (more than 3 at a time for a given purpose)
should require IETF Consensus. It is recommended that attributes 17
and 21 be used only after all others are exhausted.
属性タイプが１から２５５までの範囲で、ラディウスで最も欠乏しているリ
ソースであり、注意して割り当てられなくてはなりません。属性１−５３と
５５と６０−８８と９０-９１が割り手済みで、１７と２１が利用可能です。
属性１７と２１と５４と５６-５９と８９と９２-１９１が専門家のレビュー
の後に割り当てでき、仕様書が必要です。属性タイプブロックの開放（所定
の目的で一度に３つ以上）がＩＥＴＦ総意を必要とするべきです。属性１７
と２１がすべての値が使い切った後に使われることが勧められます。
Note that RADIUS defines a mechanism for Vendor-Specific extensions
(Attribute 26) and the use of that should be encouraged instead of
allocation of global attribute types, for functions specific only to
one vendor's implementation of RADIUS, where no interoperability is
deemed useful.
ラディウスがベンダー特有の拡張メカニズムを定義します（属性２６）、そ
してその使用がグローバル属性タイプの割り当ての代わりに、１つのベンダー
のラディウス実装に特有の機能に推奨されるべきで、互換性が有用であると
みなされない事に注意してください。
As stated in the "Attributes" section above:
上に「属性」章で述べられるように：
"[Attribute Type] 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."
「［特質タイプ］値１９２-２２３が実験的な使用のために確保されま
す、値２２４-２４０が実装特定の使用のために確保されます、そして
値２４１-２５５が留保されて使われるべきではありません。」
Therefore Attribute values 192-240 are considered Private Use, and
values 241-255 require Standards Action.
それ故に属性値１９２-２４０がプライベート利用と思われ、値２４１-
２５５が標準行動を必要とします。
Certain attributes (for example, NAS-Port-Type) in RADIUS define a
list of values to correspond with various meanings. There can be 4
billion (2^32) values for each attribute. Adding additional values to
the list can be done on a First Come, First Served basis by the IANA.
（例えば、ＮＡＳポートタイプなど）ラディウスある特定の属性がさまざま
な意味の値のリストを定義します。各属性は４０億（２^３２）の値があり
得ます。リストに追加の値を加えることはＩＡＮＡによって先着順に応対の
原則でされることができます。
7. Examples
7. 例
A few examples are presented to illustrate the flow of packets and
use of typical attributes. These examples are not intended to be
exhaustive, many others are possible. Hexadecimal dumps of the
example packets are given in network byte order, using the shared
secret "xyzzy5461".
パケットの流れと典型的な属性の使用を例示するために少数の例を示します。
これらの例が全てではなく、多くの他のものが可能です。パケット例の１６
進数ダンプが、共有秘密鍵"xyzzy5461"を使って、ネットワークバイトオー
ダーです。
7.1. User Telnet to Specified Host
7.1. 指定されたホストへのユーザTelnet
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
RADIUS Server for a user named nemo logging in on port 3 with
password "arctangent".
192.168.1.16のＮＡＳはnemoという名のユーザーがパスワード"arctangent"
でポート３上にログインすることに関してラディウスサーバーにアクセス要
求ＵＤＰパケットを送ります。
The Request Authenticator is a 16 octet random number generated by
the NAS.
要求認証子はＮＡＳの生成する１６オクテット乱数です。
The User-Password is 16 octets of password padded at end with nulls,
XORed with MD5(shared secret|Request Authenticator).
ユーザーパスワードは、終わりはヌルのパディングをし、MD5(共有秘密鍵|
要求認証子)とＸＯＲをとたｔ、１６オクテットパスワードです。
01 00 00 38 0f 40 3f 94 73 97 80 57 bd 83 d5 cb
98 f4 22 7a 01 06 6e 65 6d 6f 02 12 0d be 70 8d
93 d4 13 ce 31 96 e4 3f 78 2a 0a ee 04 06 c0 a8
01 10 05 06 00 00 00 03
1 Code = Access-Request (1)
1 ID = 0
2 Length = 56
16 Request Authenticator
Attributes:
6 User-Name = "nemo"
18 User-Password
6 NAS-IP-Address = 192.168.1.16
6 NAS-Port = 3
The RADIUS server authenticates nemo, and sends an Access-Accept UDP
packet to the NAS telling it to telnet nemo to host 192.168.1.3.
ラディウスサーバーはnemoを認証し、nemoをホスト192.168.1.3にtelnetす
るようにＮＡＳにアクセス許可ＵＤＰパケットを送ります。
The Response Authenticator is a 16-octet MD5 checksum of the code
(2), id (0), Length (38), the Request Authenticator from above, the
attributes in this reply, and the shared secret.
回答認証子は、コード(2)とid(0)と長さ(38)と上記要求認証子と回答の属
性と共有秘密鍵の、１６オクテットＭＤ５チェックサムです。
02 00 00 26 86 fe 22 0e 76 24 ba 2a 10 05 f6 bf
9b 55 e0 b2 06 06 00 00 00 01 0f 06 00 00 00 00
0e 06 c0 a8 01 03
1 Code = Access-Accept (2)
1 ID = 0 (same as in Access-Request)
2 Length = 38
16 Response Authenticator
Attributes:
6 Service-Type (6) = Login (1)
6 Login-Service (15) = Telnet (0)
6 Login-IP-Host (14) = 192.168.1.3
7.2. Framed User Authenticating with CHAP
7.2. ＣＨＡＰを使ったフレームユーザ認証
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
RADIUS Server for a user named flopsy logging in on port 20 with PPP,
authenticating using CHAP. The NAS sends along the Service-Type and
Framed-Protocol attributes as a hint to the RADIUS server that this
user is looking for PPP, although the NAS is not required to do so.
192.168.1.16のＮＡＳはflopsyという名前のユーザーがＰＰＰでポート２０
にログインしてＣＨＡＰで認証するため、ラディウスサーバーにアクセス要
求ＵＤＰパケットを送ります。ＮＡＳがヒントを送るように要求されないけ
れども、ＮＡＳはラディウスサーバーへ、このユーザーがＰＰＰを探してい
るというヒントの意味で、サービスタイプとフレームプロトコル属性を送り
ます。
The Request Authenticator is a 16 octet random number generated by
the NAS, and is also used as the CHAP Challenge.
要求認証子はＮＡＳの生成する１６オクテット乱数で、そして同じくＣＨ
ＡＰチャレンジとして用いられます。
The CHAP-Password consists of a 1 octet CHAP ID, in this case 22,
followed by the 16 octet CHAP response.
ＣＨＡＰパスワードは１オクテットのＣＨＡＰ識別子、この場合２２と、
続いく１６オクテットのＣＨＡＰ回答から成り立ちます。
01 01 00 47 2a ee 86 f0 8d 0d 55 96 9c a5 97 8e
0d 33 67 a2 01 08 66 6c 6f 70 73 79 03 13 16 e9
75 57 c3 16 18 58 95 f2 93 ff 63 44 07 72 75 04
06 c0 a8 01 10 05 06 00 00 00 14 06 06 00 00 00
02 07 06 00 00 00 01
1 Code = 1 (Access-Request)
1 ID = 1
2 Length = 71
16 Request Authenticator
Attributes:
8 User-Name (1) = "flopsy"
19 CHAP-Password (3)
6 NAS-IP-Address (4) = 192.168.1.16
6 NAS-Port (5) = 20
6 Service-Type (6) = Framed (2)
6 Framed-Protocol (7) = PPP (1)
The RADIUS server authenticates flopsy, and sends an Access-Accept
UDP packet to the NAS telling it to start PPP service and assign an
address for the user out of its dynamic address pool.
ラディウスサーバーはflopsyを認証して、ＰＰＰサービスの開始とダイナ
ミックアドレスプールからユーザーにアドレスを割り当てるように言うた
め、ＮＡＳにアクセス許可ＵＤＰパケットを送ります。
The Response Authenticator is a 16-octet MD5 checksum of the code
(2), id (1), Length (56), the Request Authenticator from above, the
attributes in this reply, and the shared secret.
回答認証子は、コード(2)と識別子(1)と長さ(56)と上記の要求認証子と回
答の属性と共有秘密鍵の１６オクテットＭＤ５チェックサムです。
02 01 00 38 15 ef bc 7d ab 26 cf a3 dc 34 d9 c0
3c 86 01 a4 06 06 00 00 00 02 07 06 00 00 00 01
08 06 ff ff ff fe 0a 06 00 00 00 02 0d 06 00 00
00 01 0c 06 00 00 05 dc
1 Code = Access-Accept (2)
1 ID = 1 (same as in Access-Request)
2 Length = 56
16 Response Authenticator
Attributes:
6 Service-Type (6) = Framed (2)
6 Framed-Protocol (7) = PPP (1)
6 Framed-IP-Address (8) = 255.255.255.254
6 Framed-Routing (10) = None (0)
6 Framed-Compression (13) = VJ TCP/IP Header Compression (1)
6 Framed-MTU (12) = 1500
7.3. User with Challenge-Response card
7.3. チャレンジレスポンスカードをつユーザー
The NAS at 192.168.1.16 sends an Access-Request UDP packet to the
RADIUS Server for a user named mopsy logging in on port 7. The user
enters the dummy password "challenge" in this example. The challenge
and response generated by the smart card for this example are
"32769430" and "99101462".
192.168.1.16ＮＡＳはmopsyという名前のユーザーがポート７上でログインす
ることに関してラディウスサーバーにアクセス要求ＵＤＰパケットを送りま
す。この例でユーザーはダミーパスワード"challenge"を入力します。この例
のチャレンジとスマートカードの生成したレスポンスは"32769430"と
"99101462"です。
The Request Authenticator is a 16 octet random number generated by
the NAS.
要求認証子はＮＡＳの生成する１６オクテット乱数です。
The User-Password is 16 octets of password, in this case "challenge",
padded at the end with nulls, XORed with MD5(shared secret|Request
Authenticator).
ユーザーパスワード、この例では"challenge"、の終わりにヌルのパディン
グがされ、MD5(共有秘密鍵|要求認証子)とＸＯＲします。
01 02 00 39 f3 a4 7a 1f 6a 6d 76 71 0b 94 7a b9
30 41 a0 39 01 07 6d 6f 70 73 79 02 12 33 65 75
73 77 82 89 b5 70 88 5e 15 08 48 25 c5 04 06 c0
a8 01 10 05 06 00 00 00 07
1 Code = Access-Request (1)
1 ID = 2
2 Length = 57
16 Request Authenticator
Attributes:
7 User-Name (1) = "mopsy"
18 User-Password (2)
6 NAS-IP-Address (4) = 192.168.1.16
6 NAS-Port (5) = 7
The RADIUS server decides to challenge mopsy, sending back a
challenge string and looking for a response. The RADIUS server
therefore and sends an Access-Challenge UDP packet to the NAS.
ラディウスサーバーはmopsyをチャレンジすると決定し、チャレンジ文字列を
返送して、回答を待ちます。ラディウスサーバーそれ故に、アクセスチャレ
ンジＵＤＰパケットをＮＡＳへ送信します。
The Response Authenticator is a 16-octet MD5 checksum of the code
(11), id (2), length (78), the Request Authenticator from above, the
attributes in this reply, and the shared secret.
回答認証子は、コード(1)と識別子(2)と長さ(78)と上記要求認証子と応答属
性と共有秘密鍵のＭＤ５チェックサムです。
The Reply-Message is "Challenge 32769430. Enter response at prompt."
応答メッセージは"Challenge 32769430. Enter response at prompt."です。
The State is a magic cookie to be returned along with user's
response; in this example 8 octets of data (33 32 37 36 39 34 33 30
in hex).
状態はユーザー回答で持って返されるべきマジッククッキーです；この例で
８オクテットデータです(１６進数33 32 37 36 39 34 33 30)。
0b 02 00 4e 36 f3 c8 76 4a e8 c7 11 57 40 3c 0c
71 ff 9c 45 12 30 43 68 61 6c 6c 65 6e 67 65 20
33 32 37 36 39 34 33 30 2e 20 20 45 6e 74 65 72
20 72 65 73 70 6f 6e 73 65 20 61 74 20 70 72 6f
6d 70 74 2e 18 0a 33 32 37 36 39 34 33 30
1 Code = Access-Challenge (11)
1 ID = 2 (same as in Access-Request)
2 Length = 78
16 Response Authenticator
Attributes:
48 Reply-Message (18)
10 State (24)
The user enters his response, and the NAS send a new Access-Request
with that response, and includes the State Attribute.
ユーザーは回答を入力します、ＮＡＳはその反応と状態属性を含む新しいア
クセス要求を送ります。
The Request Authenticator is a new 16 octet random number.
要求認証子は新しい１６オクテット乱数です。
The User-Password is 16 octets of the user's response, in this case
"99101462", padded at the end with nulls, XORed with MD5(shared
secret|Request Authenticator).
ユーザーパスワードはユーザ回答、この場合"99101462"、の終わりにヌルを
パディングして、MD5(共有秘密鍵|要求認証子)とＸＯＲした１６のオクテッ
トです。
The state is the magic cookie from the Access-Challenge packet,
unchanged.
状態はアクセスチャレンジパケットからの修正なしのマジッククッキーです。
01 03 00 43 b1 22 55 6d 42 8a 13 d0 d6 25 38 07
c4 57 ec f0 01 07 6d 6f 70 73 79 02 12 69 2c 1f
20 5f c0 81 b9 19 b9 51 95 f5 61 a5 81 04 06 c0
a8 01 10 05 06 00 00 00 07 18 10 33 32 37 36 39
34 33 30
1 Code = Access-Request (1)
1 ID = 3 (Note that this changes.)
2 Length = 67
16 Request Authenticator
Attributes:
7 User-Name = "mopsy"
18 User-Password
6 NAS-IP-Address (4) = 192.168.1.16
6 NAS-Port (5) = 7
10 State (24)
The Response was incorrect (for the sake of example), so the RADIUS
server tells the NAS to reject the login attempt.
（例では）回答は正しくなく、ラディウスサーバーはＮＡＳにログインの試
みを拒絶するように言います。
The Response Authenticator is a 16 octet MD5 checksum of the code
(3), id (3), length(20), the Request Authenticator from above, the
attributes in this reply (in this case, none), and the shared secret.
回答認証子はコード(3)識別子(3)と長さ(20)と上の要求認証子とこの答えの
属性と共有秘密鍵の１６オクテットＭＤ５チェックサムです。
03 03 00 14 a4 2f 4f ca 45 91 6c 4e 09 c8 34 0f
9e 74 6a a0
1 Code = Access-Reject (3)
1 ID = 3 (same as in Access-Request)
2 Length = 20
16 Response Authenticator
Attributes:
(none, although a Reply-Message could be sent)
8. Security Considerations
8. セキュリティの考察
Security issues are the primary topic of this document.
セキュリティ問題はこの文書の主要なトピックです。
In practice, within or associated with each RADIUS server, there is a
database which associates "user" names with authentication
information ("secrets"). It is not anticipated that a particular
named user would be authenticated by multiple methods. This would
make the user vulnerable to attacks which negotiate the least secure
method from among a set. Instead, for each named user there should
be an indication of exactly one method used to authenticate that user
name. If a user needs to make use of different authentication
methods under different circumstances, then distinct user names
SHOULD be employed, each of which identifies exactly one
authentication method.
実際は、各ラディウスサーバー内にか接続した、「ユーザー」名と認証情報
（「秘密」）を結び付けるデータベースがあります。特定の名のユーザーが
多数の方法で認証されることは予想されません。これはユーザーを最少のセ
キュリティ手段を交渉する攻撃で攻撃されやすくしるでしょう。その代わり
に、各ユーザー名にユーザ名認証をするために使う正確に１つの方法がある
べきです。もしユーザーが異なった状況の下で異なった認証方法を利用する
必要があるなら、別のユーザ名が使用されるべきで(SHOULD)、そして各ユー
ザ名は正確に１つの認証方法を識別します。
Passwords and other secrets should be stored at the respective ends
such that access to them is as limited as possible. Ideally, the
secrets should only be accessible to the process requiring access in
order to perform the authentication.
パスワードと他の秘密が、それらへのアクセスが可能な限り限定されている
ように、それぞれの終わりに保存されるべきです。理想的には、秘密はただ
認証を行うためにアクセスを必要としているプロセスだけがアクセスできる
べきです。
The secrets should be distributed with a mechanism that limits the
number of entities that handle (and thus gain knowledge of) the
secret. Ideally, no unauthorized person should ever gain knowledge
of the secrets. It is possible to achieve this with SNMP Security
Protocols [14], but such a mechanism is outside the scope of this
specification.
秘密は、秘密を扱う（そして秘密を増加させる）とうエンティティーの数を
制限するメカニズムで配られるべきです。理想的には、無許可の人が秘密の
知識を得るべきではありません。ＳＮＭＰセキュリティプロトコル[14]でこ
れを成し遂げることは可能ですが、このようなメカニズムはこの仕様書の範
囲の外です。
Other distribution methods are currently undergoing research and
experimentation. The SNMP Security document [14] also has an
excellent overview of threats to network protocols.
他の分配方法が現在研究と実験を経験しています。ＳＮＭＰセキュリティ文
書[14]が同じくネットワークプロトコルの脅威の優秀な概観を持っています。
The User-Password hiding mechanism described in Section 5.2 has not
been subjected to significant amounts of cryptanalysis in the
published literature. Some in the IETF community are concerned that
this method might not provide sufficient confidentiality protection
[15] to passwords transmitted using RADIUS. Users should evaluate
their threat environment and consider whether additional security
mechanisms should be employed.
５.２章で記述されたユーザーパスワード隠ぺいメカニズムは出版された文献
で十分な暗号解析を受けていません。ＩＥＴＦ共同体の何人かがこの方法で
伝達されたパスワードがラディウスを使うのに十分な機密性保護[15]を供給
しないかもしれないと心配しています。ユーザーがそれらの脅威環境を評価
し、追加のセキュリティ機構が使用されるべきかどうか考えるべきです。
9. Change Log
9. 変更履歴
The following changes have been made from RFC 2138:
RFC2138から次の変更がされました：
Strings should use UTF-8 instead of US-ASCII and should be handled as
8-bit data.
文字列は合衆国ASCIIの代わりにUTF-8を使うべきで８ビットデータとして扱わ
れるべきです。
Integers and dates are now defined as 32 bit unsigned values.
整数と日付が３２ビット符号無し値と定義されます。
Updated list of attributes that can be included in Access-Challenge
to be consistent with the table of attributes.
属性テーブルと一致させるためにアクセスチャレンジに含めることができる
属性リストを更新。
User-Name mentions Network Access Identifiers.
ユーザ名にネットワークアクセス識別子の話を出しました。
User-Name may now be sent in Access-Accept for use with accounting
and Rlogin.
ユーザ名が課金とRloginでの使用のためにアクセス許可で送られるかもしれ
ません。
Values added for Service-Type, Login-Service, Framed-Protocol,
Framed-Compression, and NAS-Port-Type.
サービスタイプとログインサービスとフレームプロトコルとフレーム圧縮とＮ
ＡＳポートタイプに値を追加しました。
NAS-Port can now use all 32 bits.
ＮＡＳポートはすべての３２ビットを使うことができます。
Examples now include hexadecimal displays of the packets.
例にパケットの１６進表示を含めます。
Source UDP port must be used in conjunction with the Request
Identifier when identifying duplicates.
重複を識別する時、ソースＵＤＰポートがリクエスト識別子と関連して使われ
なくてはなりません。
Multiple subattributes may be allowed in a Vendor-Specific attribute.
多数の副属性がベンダー特有属性で許されるかもしれません。
An Access-Request is now required to contain either a NAS-IP-Address
or NAS-Identifier (or may contain both).
アクセス要求がＮＡＳ−ＩＰアドレスかＮＡＳ識別子（あるいは両方）を含む
ように要求されます。
Added notes under "Operations" with more information on proxy,
retransmissions, and keep-alives.
プロクシと再送と生存確認に関するより多くの情報を「運用」の下にメモで加
えました。
If multiple Attributes with the same Type are present, the order of
Attributes with the same Type MUST be preserved by any proxies.
もし同じタイプの多数の属性があるなら、同じタイプの属性の順序はプロキシ
によって維持されているに違いありません(MUST)。
Clarified Proxy-State.
プロクシ状態を明確にしました。
Clarified that Attributes must not depend on position within the
packet, as long as Attributes of the same type are kept in order.
同じタイプの属性の順序を保つ限り、パケットの中での特質の位置に依存して
はならないことを明確にしました。
Added IANA Considerations section.
ＩＡＮＡの考慮の章を加えました。
Updated section on "Proxy" under "Operations".
「運用」の下の「プロクシ」の章に最新情報を与えました。
Framed-MTU can now be sent in Access-Request as a hint.
フレームＭＴＵはヒントとしてアクセス要求で送ることができます。
Updated Security Considerations.
セキュリティの考慮を更新しました。
Text strings identified as a subset of string, to clarify use of
UTF-8.
UTF-8の使用を明確にするために、テキスト列を文字列の下位グループ
としました。
10. References
10. 参考文献
[1] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2138, April
1997.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March, 1997.
[3] Rivest, R. and S. Dusse, "The MD5 Message-Digest Algorithm",
RFC 1321, April 1992.
[4] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[6] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
1700, October 1994.
[7] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
2279, January 1998.
[8] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
2486, January 1999.
[9] Kaufman, C., Perlman, R., and Speciner, M., "Network Security:
Private Communications in a Public World", Prentice Hall, March
1995, ISBN 0-13-061466-1.
[10] Jacobson, V., "Compressing TCP/IP headers for low-speed serial
links", RFC 1144, February 1990.
[11] ISO 8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets -- Part 1: Latin
Alphabet No. 1, ISO 8859-1:1987.
[12] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990, August
1996.
[13] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October
1998.
[14] Galvin, J., McCloghrie, K. and J. Davin, "SNMP Security
Protocols", RFC 1352, July 1992.
[15] Dobbertin, H., "The Status of MD5 After a Recent Attack",
CryptoBytes Vol.2 No.2, Summer 1996.
11. Acknowledgements
11. 謝辞
RADIUS was originally developed by Steve Willens of Livingston
Enterprises for their PortMaster series of Network Access Servers.
ラディウスは、ネットワークアクセスサーバーのPortMasterシリーズのた
めに元々リビングストン社のSteve Willensによって開発されました。
12. Chair's Address
12. 議長のアドレス
The working group can be contacted via the current chair:
ワーキンググループへのコンタクトは現在の議長によってできます：
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
13. Authors' Addresses
13. 著者のアドレス
Questions about this memo can also be directed to:
このメモについての質問がは直接以下へ送れます：
Carl Rigney
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
Phone: +1 925 737 2100
EMail: cdr@telemancy.com
Allan C. Rubens
Merit Network, Inc.
4251 Plymouth Road
Ann Arbor, Michigan 48105-2785
EMail: acr@merit.edu
William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
EMail: wsimpson@greendragon.com
Steve Willens
Livingston Enterprises
4464 Willow Road
Pleasanton, California 94588
EMail: steve@livingston.com
14. Full Copyright Statement
14. 著作権表示全文
Copyright (C) The Internet Society (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.
上記著作権表示とこの段落が全ての複写や派生的な仕事につけられていれば、
この文書と翻訳は複写や他者への提供ができ、そしてコメントや説明や実装
を支援する派生的な仕事のためにこの文書の全部か一部を制約なく複写や出
版や配布できます。しかし、この文書自身は、英語以外の言葉への翻訳やイ
ンターネット標準を開発する目的で必要な場合以外は、インターネット学会
や他のインターネット組織は著作権表示や参照を削除されるような変更がで
きません、インターネット標準を開発する場合はインターネット標準化プロ
セスで定義された著作権の手順に従われます。
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.
ＲＦＣエディタ機能のための資金供給が現在インターネット学会によって
供給されます。