Network Working Group B. Aboba
Request for Comments: 3575 Microsoft
Updates: 2865 July 2003
Category: Standard Track
IANA Considerations for RADIUS
(Remote Authentication Dial In User Service)
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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document describes the IANA considerations for the Remote Authentication Dial In User Service (RADIUS).
このドキュメントでは、ユーザーサービス（RADIUS）でリモート認証ダイヤルインのためにIANAの考慮事項について説明します。
This document updates RFC 2865.
この文書は、RFC 2865に更新します。
This document provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the Remote Authentication Dial In User Service (RADIUS), defined in [RFC2865], in accordance with BCP 26, [RFC2434]. It also reserves Packet Type Codes that are or have been in use on the Internet.
この文書では、BCP 26、[RFC2434]に従って、[RFC2865]で定義されたユーザーサービス（RADIUS）においてリモート認証ダイヤル、に関連する値の登録に関してインターネット割り当て番号機関（IANA）へのガイダンスを提供します。それはまたあるか、インターネット上で使用されてきたパケットタイプコードを留保します。
In this document, several words are used to signify the requirements of the specification. These words are often capitalized. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
このドキュメントでは、いくつかの単語は、仕様の要件を意味するために使用されています。これらの言葉は、多くの場合、資産計上されます。この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
The following terms are used here with the meanings defined in BCP 26: "name space", "assigned value", "registration".
「名前空間」、「割り当てられた値」、「登録」：次の用語は、BCP 26で定義される意味と共にここで使用されています。
The following policies are used here with the meanings defined in BCP 26: "Private Use", "First Come First Served", "Expert Review", "Specification Required", "IESG Approval", "IETF Consensus", "Standards Action".
次のポリシーは、BCP 26で定義される意味と共にここで使用されている：「私用」、「まず第一に役立ってくる」、「エキスパートレビュー」、「仕様が必要である」、「IESG承認」、「IETFコンセンサス」、「標準アクション」 。
There are three name spaces in RADIUS that require registration: Packet Type Codes, Attribute Types, and Attribute Values (for certain Attributes). This document creates no new IANA registries, since a RADIUS registry was created by [RFC2865].
パケットタイプコードタイプ属性、および（特定の属性の）属性値：そこ登録を必要とRADIUSで3名のスペースがあります。 RADIUSレジストリは[RFC2865]によって作成されたので、この文書は、新しいIANAレジストリを作成しません。
RADIUS is not intended as a general-purpose protocol, and allocations SHOULD NOT be made for purposes unrelated to Authentication, Authorization or Accounting.
RADIUSは、汎用プロトコルとして意図されていない、および割り当ては、認証、認可、またはアカウンティングとは無関係の目的のために作られるべきではありません。
For registration requests where a Designated Expert should be consulted, the responsible IESG area director should appoint the Designated Expert. The intention is that any allocation will be accompanied by a published RFC. However, the Designated Expert can approve allocations once it seems clear that an RFC will be published, allowing for the allocation of values prior to the document being approved for publication as an RFC. The Designated Expert will post a request to the AAA WG mailing list (or a successor designated by the Area Director) for comment and review, including an Internet-Draft. Before a period of 30 days has passed, the Designated Expert will either approve or deny the registration request, publish a notice of the decision to the AAA WG mailing list or its successor, and inform IANA of its decision. A denial notice must be justified by an explanation and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable.
Expertが相談されるべきである登録要求のために、責任がIESGのエリアディレクターはDesignated Expertを任命するべきです。その意図は、任意の割り当てが公開RFCを伴うことになるということです。前にRFCとして公表のために承認されている文書への値の割り当てを可能に、RFCが公開されることは明らかと思われるしかし、一度指定Expertは配分を承認することができます。指定専門家は、インターネットドラフトを含め、コメントやレビューのためにAAA WGメーリングリストへの要求（または地域ディレクターが指定する後継）を掲載します。 30日間の期間が経過する前に、指定Expertは承認または拒否登録要求を、AAA WGメーリングリストやその後継者に決定の通知を発行し、その決定のIANAに通知しますか。拒否通知は説明によって正当化や、許容なるように要求を変更することができますどのようにそれが可能である場合に、具体的な提案されなければなりません。
Packet Type Codes have a range from 1 to 253. RADIUS Type Codes 1-5 and 11-13 were allocated in [RFC2865], while Type Codes 40-45, 250-253 are allocated by this document. Type Codes 250-253 are allocated for Experimental Uses, and 254-255 are reserved. Packet Type Codes 6-10, 12-13, 21-34, 50-51 have no meaning defined by an IETF RFC, but are reserved until a specification is provided for them. This is being done to avoid interoperability problems with software that implements non-standard RADIUS extensions that are or have been in use on the Internet. Because a new Packet Type has considerable impact on interoperability, a new Packet Type Code requires IESG Approval. The intention is that any allocation will be accompanied by a published RFC. Type Codes 52-249 should be allocated first; when these are exhausted, Type Codes 14-20, 35-39, 46-49 may be allocated. For a list of Type Codes, see Appendix A.
パケットタイプコードは、範囲1から253までの半径型コード1-5および11-13を有するタイプコード40~45が、250から253はこのドキュメントによって割り当てられ、[RFC2865]に割り当てられました。タイプ・コード250から253は、実験的使用のために割り当てられ、254から255は予約されています。パケットタイプ・コード6-10、12-13、21-34、50-51は、IETF RFCで定義された意味を持ちませんが、仕様が彼らのために提供されるまでに予約されています。これはあるか、インターネット上で使用されている非標準のRADIUS拡張を実装するソフトウェアとの相互運用性の問題を回避するために行われています。新しいパケットタイプは、相互運用性に大きな影響を持っているので、新しいパケットタイプコードは、IESGの承認が必要です。その意図は、任意の割り当てが公開RFCを伴うことになるということです。タイプコード52から249は、最初に割り当てられなければなりません。これらが排出される際に、タイプ・コード14-20、35-39、46-49を割り当てることができます。タイプ・コードのリストについては、付録Aを参照してください。
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,94-100 have been allocated, with 17 and 21 available for re-use. Attributes 17, 21, 54, 56-59, 89, 101-191 may be allocated by IETF Consensus. It is recommended that attributes 17 and 21 be used only after all others are exhausted.
属性タイプは、このように注意して割り当てられる必要があり、1から255までの範囲を持ち、RADIUSで希少な資源です。 1-53,55,60-88,90-91,94-100は17と再使用のために利用可能な21で、割り当てられている属性。 17、21、54、56-59、89、101から191は、IETF合意によって割り当てることができる属性。 17の属性および21は、他のすべてが使い果たされた後にのみ使用することをお勧めします。
Note that RADIUS defines a mechanism for Vendor-Specific extensions (Attribute 26) for functions specific only to one vendor's implementation of RADIUS, where no interoperability is deemed useful. For functions specific only to one vendor's implementation of RADIUS, the use of that should be encouraged instead of the allocation of global attribute types.
RADIUSのみ何らの相互運用性が有用とみなされていないRADIUSのベンダの実装に特定の機能のためのベンダー固有の拡張子（項目26）ためのメカニズムを定義することに留意されたいです。だけRADIUSの1つのベンダーの実装に固有の機能については、その使用は、グローバル属性タイプの割り当ての代わりに奨励されるべきです。
As noted in [RFC2865]:
[RFC2865]で述べたように：
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.
タイプ値192から223は、実験的な使用のために予約されている属性、224から240が実装固有の使用のために予約されている値、および予約されている241-255値と使用すべきではありません。
Therefore Attribute Type values 192-240 are considered Private Use, and values 241-255 require Standards Action.
したがって、タイプがプライベート利用とみなされる192から240の値、および241-255は標準アクションを必要とする値属性。
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. Additional values can be allocated by the Designated Expert. The exception to this policy is the Service-Type attribute (6), whose values define new modes of operation for RADIUS. Values 1-16 of the Service-Type attribute have been allocated. Allocation of new Service-Type values are by IETF Consensus. The intention is that any allocation will be accompanied by a published RFC.
RADIUSにおける特定の属性（例えば、NASポート型）は、様々な意味に対応する値のリストを定義します。各属性の40億（2 ^ 32）の値が存在する場合があります。追加の値を指定エキスパートによって割り当てることができます。この方針の例外は、その値がRADIUSのための動作の新しいモードを定義するservice-type属性（6）、です。 service-type属性の1-16が割り当てられている値。新しいサービスタイプ値の割当ては、IETFコンセンサスです。その意図は、任意の割り当てが公開RFCを伴うことになるということです。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[RFC2865] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000.
[RFC2865] Rigney、C.、ウィレンス、S.、ルーベン、A.とW.シンプソン、RFC 2865、2000年6月 "ユーザーサービス（RADIUS）でリモート認証ダイヤル"。
[RFC2607] Aboba, B. and J. Vollbrecht, "Proxy Chaining and Policy Implementation in Roaming", RFC 2607, June 1999.
[RFC2607] Aboba、B.、およびJ. Vollbrecht、 "ローミング中のプロキシ連鎖とポリシー実装"、RFC 2607、1999年6月。
[RFC2866] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[RFC2866] Rigney、C.、 "RADIUSアカウンティング"、RFC 2866、2000年6月。
[RFC2867] Zorn, G., Aboba, B. and D. Mitton, "RADIUS Accounting Modifications for Tunnel Protocol Support", RFC 2867, June 2000.
[RFC2867]ソーン、G.、Aboba、B.とD.ミトン、 "トンネルプロトコルサポートのためのRADIUSアカウンティングの変更"、RFC 2867、2000年6月。
[RFC2868] Zorn, G., Leifer, D., Rubens, A., Shriver, J., Holdrege, M. and I. Goyret, "RADIUS Attributes for Tunnel Protocol Support", RFC 2868, June 2000.
[RFC2868]ゾルン、G.、Leifer、D.、ルーベンス、A.、シュライバー、J.、ホールドレッジ、M.及びI. Goyret、RFC 2868、2000年6月 "RADIUSトンネルプロトコルサポートのための属性"。
[RFC2869] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", RFC 2869, June 2000.
[RFC2869] Rigney、C.、Willats、W.およびP.カルフーン、 "RADIUS拡張機能"、RFC 2869、2000年6月。
[RFC2869bis] Aboba, B. and P. Calhoun, "RADIUS Support for Extensible Authentication Protocol (EAP)", Work in Progress.
【RFC2869bis] Aboba、B.およびP.カルフーン、 "拡張認証プロトコル（EAP）のためのRADIUSサポート"、ProgressのWork。
[RFC2882] Mitton, D., "Network Access Servers Requirements: Extended RADIUS Practices", RFC 2882, July 2000.
[RFC2882]ミトン、D.、 "ネットワークアクセスサーバーの要件：拡張RADIUSプラクティス"、RFC 2882、2000年7月。
[RFC3162] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, August 2001.
[RFC3162] Aboba、B.、ゾルン、G.およびD.ミットン、 "RADIUSとIPv6"、RFC 3162、2001年8月。
[DynAuth] Chiba, M., Dommety, G., Eklund, M., Mitton, D. and B. Aboba, "Dynamic Authorization Extensions to Remote Authentication Dial In User Service (RADIUS)", RFC 3576, July 2003.
[DynAuth]千葉、M.、Dommety、G.、エクランド、M.、ミトン、D.とB. Aboba、 "ダイナミックな承認拡張機能は、ユーザーサービス（RADIUS）でリモート認証ダイヤルへ"、RFC 3576、2003年7月。
The security considerations detailed in [RFC2434] are generally applicable to this document. Security considerations relating to the RADIUS protocol are discussed in [RFC2607], [RFC2865], [RFC3162], [DynAuth], and [RFC2869bis].
[RFC2434]に詳述されたセキュリティ上の考慮事項は、一般的に、この文書に適用されます。 RADIUSプロトコルに関連するセキュリティ上の考慮事項は、[RFC2607]に記載されている、[RFC2865]、[RFC3162]、[DynAuth]、および[RFC2869bis]。
Appendix A - RADIUS Packet Types
付録A - RADIUSパケットタイプ
A list of RADIUS Packet Type Codes is given below. This document instructs IANA to list them in the registry of Packet Type Codes. Note that Type Codes 40-45, defined in [DynAuth], are being formally allocated here. Codes 40-45 were listed in [RFC2882] and have been implemented and used. Given their current widespread usage, these assignments are not reclaimable in practice.
RADIUSパケットタイプコードの一覧は以下のとおりです。この文書では、パケットタイプコードのレジストリでそれらを一覧表示するIANAに指示します。 [DynAuth]、正式にここに割り当てられている中で定義されているタイプ・コード40〜45を、注意してください。符号40~45は、[RFC2882]に記載されているし、実装し、使用されてきました。彼らの現在の広範な使用状況を考えると、これらの割り当ては、実際には再利用できません。
# Message Reference
---- ------------------------- ---------
1 Access-Request [RFC2865]
2 Access-Accept [RFC2865]
3 Access-Reject [RFC2865]
4 Accounting-Request [RFC2865]
5 Accounting-Response [RFC2865]
6 Accounting-Status [RFC2882]
(now Interim Accounting)
7 Password-Request [RFC2882]
8 Password-Ack [RFC2882]
9 Password-Reject [RFC2882]
10 Accounting-Message [RFC2882]
11 Access-Challenge [RFC2865]
12 Status-Server (experimental) [RFC2865]
13 Status-Client (experimental) [RFC2865]
21 Resource-Free-Request [RFC2882]
22 Resource-Free-Response [RFC2882]
23 Resource-Query-Request [RFC2882]
24 Resource-Query-Response [RFC2882]
25 Alternate-Resource-
Reclaim-Request [RFC2882]
26 NAS-Reboot-Request [RFC2882]
27 NAS-Reboot-Response [RFC2882]
28 Reserved
29 Next-Passcode [RFC2882]
# Message Reference
---- ------------------------- ---------
30 New-Pin [RFC2882]
31 Terminate-Session [RFC2882]
32 Password-Expired [RFC2882]
33 Event-Request [RFC2882]
34 Event-Response [RFC2882]
40 Disconnect-Request [DynAuth]
41 Disconnect-ACK [DynAuth]
42 Disconnect-NAK [DynAuth]
43 CoA-Request [DynAuth]
44 CoA-ACK [DynAuth]
45 CoA-NAK [DynAuth]
50 IP-Address-Allocate [RFC2882]
51 IP-Address-Release [RFC2882]
250-253 Experimental Use
254 Reserved
255 Reserved [RFC2865]
Intellectual Property Statement
知的財産に関する声明
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards- related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF Secretariat.
IETFは、そのような権限下で、ライセンスがたりないかもしれない可能性があるためにどの本書または程度に記載されている技術の実装や使用に関係すると主張される可能性があります任意の知的財産やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能。また、そうした権利を特定するために取り組んできたことを表していないん。スタンダードトラックとstandards-関連文書の権利に関するIETFの手続きの情報は、BCP-11に記載されています。権利の主張のコピーは、出版のために利用可能とライセンスの保証が利用できるようにする、あるいは本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますIETF事務局から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFは、その注意にこの標準を実践するために必要な場合があり技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 IETF専務に情報を扱ってください。
Acknowledgments
謝辞
Thanks to Ignacio Goyret of Lucent, Allison Mankin of Lucent Bell Labs, Thomas Narten of IBM, Glen Zorn and Harald Alvestrand of Cisco for discussions relating to this document.
このドキュメントに関連する議論のためのルーセントのイグナシオGoyret、ルーセントのベル研究所のアリソンマンキン、IBMのトーマスNarten氏、グレン・ソーンとシスコのハラルドAlvestrandに感謝します。
Authors' Addresses
著者のアドレス
Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052
バーナードAbobaマイクロソフト社1マイクロソフト道、レッドモンド、ワシントン98052
EMail: bernarda@microsoft.com Phone: +1 425 706 6605 Fax: +1 425 936 7329
メールアドレス：bernarda@microsoft.com電話：+1 425 706 6605ファックス：+1 425 936 7329
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees.
上記の制限は永続的なものであり、インターネットソサエティもしくはその継承者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。